Category Archives: Software

Software Centric

GIT it in your development

Software

Over the last several years, I’ve played around and used several Source Control systems. Among the Perforce, GIT, Subversion and a few others. I have to say I’m very happy with GIT thus far. Despite the complaints of some, GIT is an excellent system and has saved me from source code hell a few times.
You can find more about git here:
http://git-scm.com/

The tutorials are quite good and can get you up and running quickly.

Once you’ve created the repository, go ahead and created an annotated tag with, for example the name v0.1.
After this, running the “git describe” command will provide you with incremental versioning, which is very much needed when you’re reporting bugs on a
particular commit. Just try giving your colleagues the SHA1 of the particular commits when they ask you the version in which the bug was found. I suspect they’ll be none too pleased, though you might get to figure out who knows what SHA1 is 😀

This automatic versioning is also useful when using a Continuous Integration server such as Hudson, Jenkins, etc.

Create debug first, software later

Software

Have you ever found a software bug and then went back to add printf and other debugging capabilities later?
I think we’ve all done that. However, that approach is way too late. There is one true maxim in software:

Your software has bugs

Given this, the best approach is likely to add debugging capabilities first, then add the actual code later. There are plenty of advantages for this:
1) You’re much more likely to add the debugging prints if you have easy to use debugging functions
2) Issues will happen almost immediately once you start writing code. You will get to writing working code faster if you have a consistent debug method

In Windows/Linux, printf and similar functions are one way to go. Please note that using a good debugger in itself is critical, however, it’s sometimes easier to see
a chain of events happening when it prints. Make sure to use the line number Macros in C whenever possible since they’ll let you know immediately where the error is.

In embedded systems this becomes a bit more tricky. Embedded debuggers provide the ability to use printf across JTAG and this is quite good sometimes, but it might be better to use a separate UART connection. Another good option is that if your system has any kind of flash storage (such as SD card) then print the log information there. This is useful in the long term when you’re not paying attention and everything comes crashing down. You can then have a look and get a better idea of what is going on.

Configuring and Using the MSP430 UART

MSP430, Software, , , , , ,

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:

http://www.glitovsky.com/Tutorialv0_3.pdf

The information will allow you to communicate with a computer using the USB port

 

9/26/2012

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

3/16/2014

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.

The Software Tradeoff Triangle

Software, ,

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.

Designing a System? Consider NRE vs. COGS

Electrical Engineering, Embedded Systems, Hardware, Software

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.

Free and Open Source MSP430 Debugging

MSP430, Software, , , , ,

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

Then build

make
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.
(mspdebug)

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) erase
(mspdebug) load test.hex
(mspdebug) restart
(mspdebug) run

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.

Building more easily from source

Software

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.