Saturday, October 9, 2010

Focus on What Matters

What Matters?

So I've started getting things together for Episode 3 of the series in which I intent to get SD card functionality working. I quickly got sidetracked and thought it would be useful to mention it. This seems to happen a lot in projects. We let our minds get 3 or 4 steps ahead and we start thinking about details that don't matter now and may never matter but trying to plan for everything slows us down. This is a fine line to try to walk. If you don't plan ahead enough you can really hurt yourself in the long run or make things more difficult. If you plan too much you spend a disproportionate amount of time on ideas or details that may never matter. This has happened over the past couple of days. I started with what matters, getting SD card functionality added to the sensor platform. Then the details set in. SD needs 3.3V instead of the 5V I'm getting from the programmer not to mention the programmer can't source enough current required for SD communication. So I need a power supply. What kind of a power supply do I need? How will I know if the SD stuff is working. I need some sort of debug output. Should I hook up a temporary LCD to debug with? Maybe USB to output to the computer. I got bogged down fast in the details.

Stay Focused

So I decided I was getting too wrapped up in future details. What mattered was getting SD card functionality. I don't need to decide on the power circuitry right now. I just need enough power to get SD working. A USB port can source 100mA without adding communication protocol. That is pushing it so let's just use a wall wart to be safe. Most of us have a box of them lying around anyway and we can refine the power stuff more in the future if we want but the wall wart will get us the power we need right now. As far as confirming the SD stuff is working with an LCD screen, that is overkill. We need to confirm that the PIC can read and write to the SD card. Well, I think I have a simple enough way to do that with just the LED we've already added. Stay tuned for Episode 3 where I'll go through the whole process.

Tuesday, October 5, 2010

Pickit 3 OK...Bootloader Better

What's A Bootloader?

So we've got our platform in a state where we can load new firmware onto it with our programmer. That's great but what if we need to update the platform after we've built some units and sent them off to end users? I guess we could give them all a Pickit and instructions on how to use it. FAIL. We need a better way than that. We need a bootloader. What's a bootloader? Simple, a bootloader allows our microcontroller to be reprogrammed WITHOUT our Pickit.

Basic Operation

When we use the Pickit, or any other programmer for that matter, ones and zeroes are sent on the programming pins after the microcontroller is put into a special programming mode. The microcontroller writes that data into program memory. Most of the PIC microcontrollers nowadays have a “self-write” capability which means that they are capable of writing to their own program memory space during normal operation without going into a special programming mode. We have to be careful though because if we put new programming instructions in the wrong addresses the microcontroller will exhibit unpredictable behavior or stop working altogether until we reprogram it with our Pickit.

When the unit is powered up we can have a small piece of code that checks some type of flag(button pressed, entry in EEPROM memory) to determine whether to run the application code or run the bootloader code. The bootloader code has some mechanism for getting the new firmware instructions into the application code program memory, overwriting the old application code in the process.

Bootloader Spec

I've thought a lot about the best way to implement a bootloader for the EmbeddedFun Sensor Platform. Taking into consideration ease of use and functionality I think the best option is to use an SD card. We can put new firmware on the SD card and the next time they reset the device it can check for new firmware and load it into program memory as well. How we get the firmware onto the SD card is also up to us.

The platform could implement the Mass Storage USB class so we could copy firmware to it like any other external drive or maybe we could get it there wirelessly. The SD card provides other benefits as well. It gives us a ton of storage that the platform can use for things like storing sensor data, settings and other things. Episodes 3 and 4 will cover implementing the bootloader for our sensor platform. Topics covered will include:
  • Reading/Writing to flash program memory on the PIC
  • Communicating with an SD/uSD card