This update is just a quick rundown on how things have progressed so far.
Developing for the Launchpad
I've been very impressed with the Launchpad - building a set of make files and build scripts to compile and deploy the code turned out to be very useful.
I have a main build script that automates a lot of the process for me (you can find it in the main Git repository for the project. It builds a suitable ARM toolchain, the lm4flash utility to transfer binaries to the hardware and builds the StellarisWare library giving access to the ROM routines and other utilities.
The built in driver library in the ROM on the Stellaris has been very useful and makes developing software for the board a lot easier. The final binary for the sampling firmware clocks in at a touch over 2K (admittedly it's not very complex but the firmware for an earlier beta built for an ATMega chip was pushing 8K).
How the Firmware Works
The firmware has a very simple job - it samples 8 ADC channels at a constant 1KHz rate (1000 samples per second) driven by a timer interrupt to maintain a consistant rate. The last seconds worth of data is stored in a circular buffer. At the same time it provides a simple API which allows a client to read the most recent set of samples as well as being able to dump the circular buffer to get a more detailed view.
The API is exposed over a standard serial port (I would have preferred to use I2C for this but the I2C channel is going to be heavily used to drive updates to the LCD).
An extra feature that I haven't implemented yet is setting the voltage reference outputs. I'm planning to use a MCP4822 dual channel DAC from Microchip to do this with the outputs feeding back into ADC channels on the Launchpad to allow the voltage to be adjusted as needed.
The Launchpad provides so much more than what is required by the firmware that it is overkill to use one for such a simple task. It is a cheap and easy to use solution that has got me up and running very quickly though.
About the only limiting factor that makes it difficult to use another device is the amount of RAM available - I need at least 16K of available RAM to store the last seconds worth of data plus another 4K for scratch area and stack. It's very difficult to find microcontrollers with this amount of RAM available on the chip, I could replicate it on something like an LPC1114 but it would need external memory and a way to control the address and data bus (adding more complexity and cost to the circuit). I'd love to see more controllers come out with an increase in available onboard RAM but manufacturers seem to concentrate on increasing the amount of flash available instead.
Current Project Status
So far I have the firmware working and communicating with the UI framework I showed in a previous update with all the analog channels floating for the moment. The UI is still only working over a VNC connection and not the physical hardware. In the current state I can run everything on either a x86 Linux box or on the Raspberry Pi under Raspbian.
I've finally figured out that my personal schedule allows for software development from Monday to Friday and hardware development on the weekends - trying to stick to a different schedule simply leads to frustration and inefficiencies. Given that I now have 2 weeks to go before the competition closes I've optimised what needs to be done to fit within those limitations.
At this stage I really don't think I am going to have a finalised project (not even finalised according to the goals I put forward for my entry let alone the optimisations and design changes I've come up with or want to experiment with since then) at the end date for the competition. I'll be happy if I can present a working prototype (there may be a rats nest of wires, some dodgy manual processes to go through to get it to start up and run and most of the custom circuitry will probably be on a breadboard). That at least is an achievable goal :)
An improvement would be to have the circuitry on stripboard at least and a basic (if not pretty) enclosure/mount for it. Call this my 'stretch' goal.
At the moment I'm just planning things a day or two ahead based on a dynamically changing set of priorities based on what is working at the moment and what isn't. Timing constraints means that hardware issues automatically rise to the top on weekends and software issues on weekdays.
My plan for this weekend is pretty simple - Saturday is devoted to getting the 4 voltage inputs working (with protection for overvoltage and reverse voltage inputs). Sunday is all about the LCD interface to the Raspberry Pi (this involves adding an I2C based IO expander and power supply). My stretch goal is to get the current input channels working as well.
If I can get this done on the weekend that leaves me with a lot of software tasks to complete during the week to handle integration of the new hardware and fixing the inevitable bugs that will arise from that. Extra time can go into modifying the UI and doing some simple optimisation to provide a reasonable user experience.
I'm confident that I'm going to have something that works to show the judges but it's not going to have all the features I described in my original entry. I'm not going to drop the project after the judging date - I will work on it until I have hit all the goals (and those updates will still appear here). I've learnt a lot while doing this project and those lessons are going to be very valuable to me for future work that I do.