Lighting the LEGO Salt Lake Temple

2015 was a busy year.  The project that I had the most fun with was a bit off the beaten path compared to what I normally do.  This started off as a fun project for a friend.  It started off with, \”I have this LEGO project I need to put LEDs in, can you help me?\”  Sure…Continue reading

Of embedded black boxes

Over the last few months I\’ve been working on projects using PIC microcontrollers. At first I had a rather negative view of the PIC processors. Since I started coding on them, I have come to realize that it is the compiler that I have issues with much more than the hardware. The compiler we\’ve been using by CCS is designed to get projects up and running quickly by abstracting the hardware from the coder. So, instead of directly writing to the registers, you call one of their functions. We\’ve found this works well when it is a mature processor and when we\’re not trying to do too many things at once. Where we ran into lots of frustration was with new processors. We thought we had the code written correctly, yet it wasn\’t working. Now instead of just having our code and hardware errata to look at, I also had to figure out what the CCS code was doing… which means slogging through the disassembled code and looking up the mnemonics for the different assembly operations.

Now, you need to understand where I come from. I\’m a Professional Engineer. When I vouch for something, I\’m saying that it works. When I have the black box of a intrinsic compiler functions, it makes me a little less sure about what is occurring. That\’s one of the reasons why I like the MSP430. TI does a very good job of letting me know what\’s going on with the chip. There\’s not much left to the imagination when using it. The analog functions are well documented and there are good code examples. The Stellaris line of ARM Cortex-M3 chips tries to make both camps happy. It has good documentation of things, but it also comes with a large driver library that encapsulates many of the functions for an engineer to rapidly program on it.

My beef with embedded processor abstraction through libraries or intrinsic functions is that it usually doesn\’t keep up with the latest processors and that it is too easy to do something that modifies something else and then you don\’t know where the problem is being generated because the functions work separately or in a different order. Oh, and they take more memory, on memory constrained processors. What\’s your experience?

Capacitive Touch Sensing on the MSP430

One of the projects I\’m working on involves using capacitive touch sensing (CTS) on the TI MSP430.  TI has been pushing their touch sensing capabilities recently and has even released a library that helps in implementing touch sensing on the MSP430.  I decided to give it a try.  The short story is that there is a lot on TI\’s site and it is easy to get confused as to what you need.  See below for some of my journey getting it going.Continue reading

A Valentine Example for Blinking Lights

For Valentine\’s Day my son needed to make a \”mailbox\” for his kindergarten class. He & his mother made a rocket out of an old oat container. Since this was a family project, I decided that my contribution would be lighting it up. My son was quite excited when I told him that I was putting lights on it and it would have a computer to control them. Being sharp as a tack, he quickly asked, \”Daddy, where will the keyboard go?\” I had to explain that it would be a little computer without a keyboard, just a button. He was still excited.

Continue reading

The Never Ending Conversion

When using the ADC10 in an MSP430 with multiple conversions, the ADC10BUSY bit will stay on even after the conversions are done. Trying to be a good little programmer and checking to make sure the ADC is done will leave you hanging… forever. The conversions must be done for the data transfer and the data transfer controller (DTC) will set the ADC10 interrupt after it is done, therefore, the conversions must be done if the interrupt is run.

MSP430, Entering and Exiting low Power Modes while Debugging

On a recent project I had one heck of a time trying to debug the program flow in CCS 4.2.  I thought the code wasn\’t going anywhere because when I would break the program, it would stop on a line before where it should have been executing.  After a couple days of troubleshooting with an oscilloscope, logic analyzer and TI, I got the bugs worked out of the program, but never did get a good answer as to why there was a debugging problem.  There are known issues with putting  a breakpoint right after an entry into a low power mode (LPM), but avoiding that didn\’t solve it.

My advice to you is to find some unused pins and use those attached to a logic analyzer or oscilloscope to see what is going on.  Hopefully this makes it into Google and saves someone a lot of time.

Debug adapter for eZ430

\"\"

For those of you who do prototyping with the eZ430 or eZ430-RF boards, this may be of interest.  It\’s a debug adapter that you can put inline to make use of  a logic analyzer or other test equipment easier.  It expands out to 0.1\” spacing posts from the 0.05\” spacing used in the eZ430 connectors.  Continue reading