TI Has done some pretty interesting things on the board. An e-ink display with capacitive touch. E-ink is a very good pairing with the MSP430 because they’re both targeted towards low power. E-ink displays can hold on to the last data displayed for extended periods of time without the need for power, and this works great for a lot of applications. Although the board is greenish, the actual board released will most likely have a different color scheme.
Despite all this I want to discuss something that we don’t see anymore. Take a look at the back of the board. This is the area usually reserved by TI for the on-board FET debugger.
I’ve been using the MSP430 for over 5 years and for all that time the FET has been built around an MSP430 paired with a TUSB3410 USB to UART, as well as EEPROM and a few external elements. On the Wolverine board, this isn’t there. The markings are not clear, but I believe TI has finally integrated the FET. The main chip that is at an angle is likely an MSP430 with integrated USB capabilities. There’s no longer a need to use an external TUSB3410 device, so the BOM is lower. It makes supporting the platform better. You can use DFU or other mechanisms and its a nice way to display the MSP430 USB capabilities.
The F5529 Launchpad board changed things a bit. The TUSB3410 was replaced by a TUSB2046.
Soon we’ll know.
I’ve restructured the code so the actual UART driver is separate from the example code. Adds a bit more complexity to the project, but makes it easier to reuse code.
It’s a nice example of creating portability in CCS projects.
The EZ430-RF2500 project also compiles but I haven’t tested it on real hardware yet.
I’ve received a lot of questions and requests for information and help on the MSP430 UART, so I decided to make available an driver for it. It’s simple but has plenty of flexibility.
Even more important, it abstracts a lot of the register controls to a level that most users should be comfortable using.
You can find the Driver and MSP430F5438 sample code for CCS here:
The code is heavily commented. More than just a useful driver, I intended it to be easy to use and a guide on using the UART module. My code uses plenty of tricks and pointers to make it flexible (and I might have overdone some of it), but I expect in the near future to complete support for the USART module (USCI is what the MSP430F5438 and similar devices have). Some basic support is there but USART isn’t tested.
You can import the CCS project compile and run it on an F5438 Experimenter board. Using it in your own project is simple, just import uart.h and uart.c and make sure to call the right functions.
Ultimately I have the following goals:
1) Support for most MSP430 devices and UART modules
2) Basic framing including CRC generation and checking
3) Example code for a variety of hardware platforms and variety of use cases
Embedded applications are nowdays rarely completely standalone. You’ll usually have the system communicate with something, usually a computer. The easiest way to do so is with UART, since there are several USB to UART converter ICs out there such as the FT232 from FTDI Chip.
You still need to configure the UART module of the microcontroller to work. For the MSP430, I’ve added quite a lot of practical information on how to get UART running. Take a look at the UART chapter in my tutorial:
sudo is required since mspdebug will want to install in /usr/local/bin.
Once mspdebug is installed, it’s ready for use. For example, lets assume you have a hex file that was compiled using mspgcc or another compiler called “text.hex” and you want to flash it to an EZ430-RF2500 device.
sudo mspdebug rf2500
sudo is again required unless you have permissions for the USB port used for the ez430-rf2500. mspdebug automatically detects an EZ430-RF2500 and connects to it.
The screen will show the following, preceded by a list of useful commands and other relevant information :
Type “help ” for more information.
Press Ctrl+D to quit.
As with GDB, you have complete control interactively and you can type commands by writing and pressing ENTER. We can erase the flash, load the hex file and let it run as follows:
(mspdebug) load test.hex
Besides working as standalone programmer, there are many other features and mspdebug can operate with GDB similar to what OpenOCD does for ARM devices.
This is incredibly powerful and very easy compared to other alternatives and makes a strong argument for MSP430 programming in Linux.
It’s been a while coming but a new updated version of my MSP430 tutorial is available. It’s still a work in progress and I have many new things scheduled to be added, but I know it’s been very helpful for many of you.
If you use the tutorial and you like it, or if you have comments/suggestions, please drop me a line at:
gustavo [at] glitovsky (dot) com
My MSP430 has apparently been used by quite a few people (It shows up as #2 in Google if you look up MSP430 Tutorial). Does it need work? Yes. I’m currently working on adding many new sections, updating old ones and giving it a better look. However, for those who need some starting point, here it is: