Microcontroller Mapper

This is little project that I worked on for a while. Imagine something like processor expert, but for Texas Instruments MSP430 (or most any family of microcontrollers). Its a GUI that allows you to quickly assemble a board definitions include file for use in your project with great ease, and writing the least amount of code by hand (which can be error prone if the project is quite large). I developed this tool after working on a projects that had to be ported to work from one microcontroller to lots of others. Instead of going around writing hundreds of lines of register #defines, I made a program that allows you to quickly assign pins and modules in microcontrollers, while simultaneously verifying that you did not map a pin twice in different functions.


The mapping of the microcontroller is divided into three layers. Modules, Resources and Mapping.


  • Modules are generic macro definitions that descrive microcontroller peripherals. These are generic, and can be reused as many times as copies of the hardware exist inside the microncontroller. For example a DIGITAL_PIN, or a UART.
  • Resources are lists of modules that are given specific locations in a microcontroller. For example, P1.1 and P1.2 as a DIGITAL_PIN.
  • Mapping involves connecting the users project to specific resources in a microcontroller. This translates to giving the resource macro a user friendly name in the location specified by the resource. For example, BUTTON1 in P1.1 (which will automatically get set as a DIGITAL_PIN).


The idea can be seen in the following graph. A single module like a UART can be configures as several resources by assigning it to different pins on the device, while user mappings define which user module is connected to each resource. The user project file only concerns itself with the top level mappings, freeing the labour of tedious datasheet perusing and costly assignment mistakes.


Look and feel

I gave the program a look that fits well with the new styles in use by lots of programs like the CS6 suite and 3dS Max. On the top you can browse and save the project file. The project file includes all the mappings and selections for the current assignment, and also remembers which device is being used. There is an output section that is used to select the header file that will contain the board mappings. Device families are stored in directories, and variants are selected from a drop down combo box.




Writing a module is very straightforward. For the sake of example, I’ll assume we will be using the program to map digital input buttons on an MSP430F5438. Taking a peek into the MSP430F543X Family User Guide, we have the following table describing the Digital I/O registers for port 1 on page 317.




If we want BUTTONA in P1.0 the line of code that we want in our board.h file looks like this:


#define BUTTONA_PIN      BIT0.

Modules have several keywords (identified by being wrapped around curly brackets) that are replaced by the built in parser to signify some relevant part of the design.

  • {NAME} : This keyword is replaced by the name of the user map.
  • {P0}, {P1}, {P2}, …, {PX}: This keyworkd is replaced by the number or letter of the port of the resource.
  • {N0}, {N1}, {N2}, …, {NX}: This keyworkd is replaced by the bit number or sub part of the resource.

The module requires several parts, a name, a base definition, options list name, options definitions and default pins.

Thus, the DIGITAL_INPUT module is written as follows:



Base definition:



Options list:


Options definitions:


Default pins



Once a module is added, it can be used by as many times as necessary by applicable pins or instances of the module exist in the microcontroller.


Adding a resource is simple. Enter the desired name and select the correct module from the available list. Put in the pin where that resource lives and you are done. Note that the {N0} and {P0} keywords will take the values of 1 and 0 respectively from the module name automatically. Internally, all the modules and resources are stored in an XML file that contains all the necessary information for a microcontroller. I chose XML to allow easy modification by popular tools, and since C# has built in tools to handle this data type.


This is the fun part. Once all the work of adding modules and resources is done, the bottom part of the program allows you to add mappings to your project. Chose a name (for example BUTTONA), and write part of the resource name. A dropdown list will populate will all possible matches for your resource. Once the resource is selected, it will tell you what kind of module it is and let you pick optional registers that might be relevant to your module.


Once the mapping is done, you can export the include file with the big Export button in the output section. When adding pins, the system will automatically generate warnings when optional selections interfere with each other, and critical errors when two base modules use the same physical pin. This provides peace of mind, knowing that conflicts can be avoided before they create harmful shorts or hard to detect bugs.


The beauty of the layered approach is that mappings can be done in minutes instead of hours, and migration between microcontrollers in the same family are transparent. Even migrations between different families does not represent too much a task, since most of the base modules can be shared. Once I have built a decent library of microcontrollers I will look into the possibility of making an automated migration button that will try to fit and automap as many user maps to another device. This will come in handy when going from a higher end microcontroller to a lower end one and having to juggle UARTS and pins to make the design fit.


I am making this program freely available under the Creative Commons NonCommercial Licence 4.0. You can find it at:


I welcome suggestions for improvements and/or volunteers that contribute XML files for their favorite microcontrollers.

Disclaimer: This program has been tested working for MSP430F5XXX microcontrollers, and can also work with other families and brands, but no testing has been done yet and should not be used for any medical or critical service application. I am distributing it under the good will that it will help hobbyists and professionals save time in one the most time consuming and least fun tasks of embedded systems development.


Leave a Reply