If you haven’t used Doxygen or a similar documentation generator, start using it. If there’s something worse than bad code is bad or uncommented code. Doxygen is so easy to use that there’s really no excuse. There is one exception: there’s not always easy examples of how to use it and nothing really practical. Here’s my attempt at correcting that mistake:
/** \defgroup Example Example
* \brief Sample Function that’s commented
* This is an extended description about the function
* \par More information here is in bold and indented
* @param param1 is the first parameter
* @param param2 is the second parameter
* \return 0 if successful, 1 if failed.
* \par Example Usage:
* doxyFunctionExample1(1, 1);
int doxyFunctionExample1(int param1, int param2)
I apologize for the formatting. Using the template above you get the following results:
The example contains a lot of details left out in many Doxygen tutorials/docs and should cover most cases. You can use the \par to create a custom paragraph, such as the example usage one above.
After several months of being absent from posting, I’ve decided to return and post. Hope the spammers don’t take the fun out of it.
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:
The information will allow you to communicate with a computer using the USB port
I just announced my first release of an open source MSP430 UART driver. If you want to get started using
the MSP430 UART without all the hassles, feel free to give it a try. More information Here
My company’s website www.argenox.com is now the main resource for MSP430 related tutorial. We have greatly improved the information for the MSP430 UART.
Approximately 80% of all embedded systems are delivered late. That is a huge statistic. Software products have a competing aspects of features, schedule and quality. Ideally a product should be delivered on time, with the best quality and the most number of features. That won’t happen and it’s not happening, as noted in the 80%.
It’s interesting to look how some companies behave in this aspect, even if they don’t develop embedded software. Blizzard, which makes Starcraft, Diablo and World of Warcraft, seems to always opt for quality and features. During development they give the usual “It’ll be done when it’s ready”. Their products are arguably some of the best games in their categories. Fans are willing to wait for that quality, but this is not always possible in other industries.
In some cases, working quality and features have delayed products for a long time. Consider Daikatana, the FPS brainchild of game designer John Romero. The game was delayed for several years and was ultimately released to lackluster reviews. The delay to ensure quality in fact caused more quality and feature problems.
Through these examples we can see that when one of the three aspects is sacrificed (schedule in this case), the other two aspects better be taken care of, at least to an acceptable level. If this won’t happen, the product shouldn’t be developed.
There are always tradeoffs between Non Recurring Engineering (NRE, or product development costs) and Costs of Goods Sold (COGS, or the cost of the final product). The balance between the two depends on the project. Simple products will require lower COGS. However, never forget about NRE costs. It is possible for you to increase COGS slightly and save a lot of money on NRE. One example of this is an embedded project requiring UART. Assuming your microcontroller or design has no UART capability, you can go either the software or the hardware route. Most will go the software route. Why? obviously because software is cheap (the most erroneous assumption by some).
When you look at software, development is very expensive. Sure, you can bit bang UART and it will work, but to get it to work reliably will require code design, development and debugging. For just a little added cost to COGS (the price of the final product), you can save yourself major headaches, not to mention that you won’t be burdening your microcontroller with handling UART itself.
If you don’t believe it, consider that IBM’s own analysis of hundreds of software projects finds that software development does not scale linearly with complexity. Simpler software costs less.
Nonetheless, there are cases where hardware won’t do. This is especially true when upgrades will be required. UART is standard and won’t require upgrades, but a proprietary algorithm that’s in flux will change.
Debugging for the MSP430 has always been complicated. The old mspgcc project incorporated the gdbproxy software, which was partially closed source because of the proprietary deubgging interface.
mspdebug is an open source debugger that allows you to debug the msp430 using common interfaces including the FET430UIF (the standard FET interface), EZ430 and EZ430-RF2500.
Installation and use is a breeze. Simply clone the code using git:
git clone git://mspdebug.git.sourceforge.net/gitroot/mspdebug/mspdebug
sudo make install
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
Besides covering the MSP430, it also covers things like UART, SPI and general Embedded systems, so whether you’re using PIC, AVR, or ARM, some nuggets of information will help you.
For anyone building from source on Linux, finding the necessary packages can be journey by itself. Sometimes the failure during make can give insight, but still requires finding the correct name of the packages. For those using distros with aptitude, there is an easy way to obtain source packages for compilation. Lets assume we are compiling package x. Then in the terminal run:
sudo apt-get build-dep x
In this case, APT will download all packages necessary for building x. Note that there are caveats. This will download the dependent packages for the latest version of the software available. If your source code has radically changed since then, these packages might be very old. However, in most cases when you’re trying to compile the latest it will work nicely.