KMI Technology Facts/Opinions
Out of I/O on your Microcontroller? 8/24/08
Are you running out of I/O on your Microcontroller? Seems like I'm always running out. There are never enough pins to attach the parallel display the 3x3 keyboard and the UART and SPI ports. Then you need another UART port and end up running a timer based port. Does this sound familier to you? But, wait theres more. Your boss comes to you and says we absolutely must know the temperature inside the box and outside and we have to keep a log of these temperatures. Now you are looking at adding an I2C bus to handle some serial flash and the temperature sensors. You go back to your boss and ask him for a bigger part to do this. But he says marketing wants to keep the COGs as low as possible. Impossible you say?
Well there is are a pair of small chips that can save the day. They are very inexpensive and can be run with just 5ish I/O pins. They are the 74HCT595 and 74HCT597. These parts are serial to parallel and parallel to serial chips. You can attach a clock a data out and data in and be able to read and write 8 or 16 or 24 or even 32 I/O's. I wouldn't go much beyond 32 as this is a serial process anyway. These parts are easy to bit bang and are very low power.
I have used these chips more than once and they are a great way to interface to displays and keypads. Anything that runs at human speeds are good candidates to be run this way. Each chip is capable of 8 bits so to get more than 8 bits the chips have to be daisy changed. So, depending on the number of chips you have daisy changed you will need to clock them that many times to get the data from or to all the chips. You could also hook up each chip seperatly but that would require more pins and that is exactly what we are trying to save.
It is also a good way to do conversions from 3.3 volt microcontroller to 5 volt peripherals as you usually don't need a level shifter going from 3.3 volt to 5 but you need it going from 5 volt to 3.3. With these chips you only need to down shift one pin. and this is easy with a MOSFET.
uALFAT to MSP430 Interface 8/22/08
I have been working with GHI Electronics uALFAT OEM board. I have it interfaced with an MSP430F1611 microcontroller. I connected the UART of the uALFAT to a UART of the MSP430F1611 and ran the baud rate at 9600. The uALFAT was converted to a uALUSB by a change to the firmware in the OEM board. It was simple to do. The GHI Electronics documentation is very good and I ordered the board through http://www.saelig.com/. They carry all of GHI Electronics devices.
The uALUSB device allows you to hook USB devices to a microcontroller. It provides a host port for USB devices such as mice, keyboards, and thumb drives. It is a very cool device.
I had problems with it at the beginning. The uALUSB would start up but would stop working after a while. While it was doing this I was able to debug my statemachine to allow me to detect failures and start over again. That works great. But, I wanted to make the uALUSB more reliable. I was just about ready to give up on the uALUSB and switch to a Linksys Nslu2 for my project when I was reading in the GHI Electronics forums and it mentioned that you need to hook up VBAT or the uALFAT/uALUSB wouldn't work. I checked my VBAT line and sure enough it wasn't hooked up. I hooked that up and the uALUSB is working great now.
SD Card to MSP430 Interface 8/18/08
I have been working on an SD Card to MSP430F1611 interface. I have the SD Card attached to a SPI port on the MSP430. I found a piece of code that implemented FAT16 without long file names and tried it. It worked but had a couple of missing features that I needed. I needed it to delete files if you created a file that had the same name as an existing file. Also I needed to be able to append to a file if you open an existing file to write to it.
There is some documentation on this from Michigan State University SD Card to MSP430. This document gives you some very good background on this interface and what the SD Card expects to see. There is even some source code although I haven't used the source code.
TI also has an application note that takes about interfacing an MSP430 to an SD Card. This document has a good explanation of the hardware portion of the interface. This application note also includes software to read the SD Card but doesn't include any code to read a FAT file system on the SD Card. I haven't tried this software either.
There are some development cards that are based on an MSP430 and have SD Cards on them. Olimex is a good source for such boards. I usually purchase all of my Olimex boards from MicroController Pros. They are located in the United States have good prices and very good service. This is a cool board with an SD Card connector and a graphical LCD. There is some demo code that goes with it to get you started.
I have given you several examples of documentation to interface an MSP430 to an SD Card. The problem with all of this documentation is that it doesn't talk about a file system. They all talk about reading and writing sectors on the SD Card but not how to interpret a FAT file system contained in the sectors. I had this problem and am usually under the gun to get something done quickly so I looked around for some code that was preferably free. There are several vendors out there that have code for FAT file systems if you are willing to spend some money. I was looking for code for a FAT16 file system. This would give me capacity up to 2 gig which I believe is plenty for my little embedded system. As I looked around Michigan State University came to my rescue with some FAT 16 code. The application note goes into some detail on the FAT 16 layout and how it works. Then it goes into the provided code. One thing this code doesn't support is long file names. But, do you really need long file names? I sure don't.
So, until next time hope this helps any one trying to get an SD Card hooked up to an MSP430. It is do able and makes for a nice permenant storage system for the MSP430.
Tools Tools Tools 8/13/08
I have been struggling as of late with my MSP430 tools. I purchased a license to the Rowley Crossworks compiler. It is an excellent compiler and produces very tight code. My only complaints have been some conditions where the IDE provided with the compiler locks up and the licensing scheme.
The licensing scheme of the Rowley compiler uses a unique serial number generated on the hard disk when the OS is loaded. The key is locked to this hard disk serial number. I reloaded my machine making sure that I retained my Rowley license key so I could restore it after reloading. The reload went smoothly but when I tried to run my compiler it wouldn't work. As the serial number of the disk had changed with the reload. It was a weekend and basically stopped me from working. I was very disappointed. I sent an email to Paul and he explained what I have just mentioned. He said in future versions of the compiler that the license key would be associated with the MAC address instead of the hard disk serial number. This would allow you to reload the machine and have the compiler function correctly after you are done.
I have an issue with this sort of license. I work on products that have long lifetimes. One product I work on is from the 1980's and the tools I use to work on the product is from that era. If the licensing were to be associated with the hard disk serial number and the company that issued the license were out of business you would be out of luck. The tool that I use on the ancient product has a liberal license that allows me to move it around which is very nice.
I have run into this very issue with some of the firms I have contracted with in the past. Seems they call me to work on products that are from 5 to 10 years old. I have to recreate the system then make some changes. The tools are a problem on these old products. They aren't in the source code control system and are sometimes very hard to find.
The bottom line is you need to take care of your tools. They need to be backed up as much as your source code. Without your tools you can do nothing!!!
Creating an MSP430 boot loader 8/6/08
I have needed a boot loader for an MSP430 for some time now. I have looked on the net to glean what information is out there. Most of the information I found had to do with the internal boot loader that uses the serial port to program the flash. This wasn't what I was looking for. I was looking for something that would automatically program flash from an SD card. I did found this little tidbit on the MSP430 group at Yahoo. In the files section, member contributions, loader.zip is a small Rowley project that outlines a bootloader. I started with this code.
The loader.zip code on the Yahoo group was very enlightening. It seems that there are a few memory map problems to having two applications in memory at the same time. Although one application doesn't run at the same time as the other one. The memory map problems have to do with the flash. Both applications must be in flash at the same time so that the boot loader can call the main application after it has been verified. Also the interrupt vectors are a problem. There has to be two interrupt vector locations so that the main applications vectors don't interfere with the boot loader vectors. There also has to be a way to switch between the two sets of vectors.
The loader.zip project contains some files that show where to put the boot loader and main application in flash. There are two different locations for these two pieces of code. So that takes care of the conflict between these two.
The interrupt vectors for the boot loader are in the regular place and the interrupt vectors for the main application are located one sector below them. The boot loader interrupt vectors point to a set of branch instructions in the boot loader start up assembly code. These branch instructions grab addresses in RAM to jump to. To use the interrupts you have to copy your vectors in the application code from flash to the jump table in RAM that the branch instructions access. This is how the vectors are swapped between the boot loader and the main application. The instruction below is the one used to jump through the jump table which is located in the bootload_crt0.asm file in loader.zip.
The loader.zip project places the boot loader at 0xF000 which is towards the end of flash. The reset vectors point to the branch instructions in bootload_crt0.asm. This way the vectors in flash don't need to be altered. The application which is run from the boot loader has its interrupt vector table at 0xefe0 in flash. This table needs to be copied to ram after the application is started. The applications is slated to start at 0x1100 which is the start of flash in the MSP430F149. In the MSP430F1611 the start of flash is at 0x4000. If you want the loader.zip project to run on an MSP430F1611 this would have to be changed.
When the application is started the vectors are copied in the crt0.asm startup code. This will provide proper interrupts for the application. All should work well from this point on. The application can be developed as a normal application once the mapping is taken care of and the interrupt vectors have been copied. This indirect approach to the interrupt vectors does slow the interrupt vectors a bit.
Hysteresis 7/27/08Just some simple ramblings of various things of interest to me.
There is one thing that I have had to develop a few times and that is decisions based on hysteresis. From what I understand hysteresis prevents rapidly changing the state of a variable if the value of the variable changes around a limit. So, to implement hysteresis we need to take into account the historical value of the variable. For example:
If we have a voltage we read from an ADC and we have limits we are suppose to check for like a 5 volt supply and we are to make sure that this supply is within 4.75-5.25 volts with hysteresis of .05 volts. We would inform the user if the voltage exceeds 5.30 volts and also if it is less than 4.70 volts. Now if we are outside the range to get back inside the range the voltage has to be 5.20 volts if we were too high and 4.80 volts if we were too low. This prevents the system from rapidly sending notification if the voltages bounces around a limit.
To implement this I came up with the following: