This post is an attempt to describe how I came to choose the hardware to use for the Bench Testing Tool project. I came to the final selection in an almost organic nature after quite a few false starts and reconsiderations so it's a little difficult to describe in a neat fashion but I'll do my best.
One of the overall requirements was that I would not be using any surface mount technology on any of the custom circuitry. Using readily available modules that had pin headers or through hole mounting adaptors would be acceptable but anything that needed to soldered up during the construction definitely had to be through hole only. This is partly to minimise the complexity of construction and partly to make it more suitable to my own limited soldering skills.
I'd already decided on the main functionality that I needed from the system so it was easy to break it up into a set of modules (seen in the rather simplistic diagram to the left). The next step was to assign hardware components to the individual blocks.
From an early stage I'd decided that at least two microcontrollers would be needed in the system. The first would be used in the analog interface and would have the relatively simple task of sampling all analog inputs at a regular interval. The second would be used on the controller board and have the job of handling user interaction as well as displaying the current values of all inputs. The two devices would communicate using either I2C or SPI with the controller board acting as the master and the analog interface acting as the slave.
Initial Hardware Choices
I'd already decided on what touchscreen display to use - a 320x240 pixel 16 bit color device using a parallel interface (which, due to lack of IO pins on most systems I'd use an I2C IO expander to access) to control the onboard framebuffer and SPI to handle touch input events. Because the screen had it's own framebuffer memory there would be no need to set aside local memory to maintain a copy of the currently displayed screen image.
For the controller board I was considering one of the 32 bit processors that was available in 28 pin DIP format - either the LPC1114FN28 from NXP or the PIC32MX250F128B from Microchip. The NXP chip had the advantage of being fairly simple to program (little more than some supporting circuitry and a serial adaptor required) but had very limited dynamic storage (only 4K of SRAM). The PIC32 had the opposite problem - a reasonable amount of memory (32K of SRAM) but would require some more specialised programming tools that I didn't have available.
Of the two the PIC32 seemed the best choice but would still require some serious gymnastics with the software to get a reasonably nice looking UI to work as well as getting samples at an acceptable rate.
For the analog interface I was hoping to use an ATMega chip (and therefore make some use of my Babyduino design to simplify development). Unfortunately these chips don't have enough analog inputs built in and to expand them would require an external chip - complicating the firmware and making it more difficult to maintain a constant sample rate. The ATMega series also have a limited amount of RAM (usually 1K) which limited the number of samples that could be stored for higher resolution snapshots and more advanced functions.
At this point it was obvious that the complexity of both the circuitry and the software I would have to design, implement and test was increasing dramatically. The cost and sourcing of components was trending upwards at a rapid rate as well.
Secondary Hardware Choices
My next step was to bump everything up a notch - look for a processor module that had more memory and more capabilities to use as the controller board and use one of the 32 bit chips as the analog interface.
I already had a Stellaris Launchpad (the LM4F120 based version) from Texas Instruments which has 256Kb of Flash and 32Kb of RAM which looked comparable in capabilities to the PIC32 but with a much simpler programming interface. There was not a lot of improvement over my previous options.
When I looked at the ADC options for the Launchpad though it seemed it would be a great option for the analog interface. It has 2 ADC convertors which can select from 12 different input channels. Each ADC has a 12 bit resolution and has a wide range of configurable options which could be very useful. The memory available would allow 1 second of data for all 8 channels to be stored at a 2KHz sample rate or 1 second of of data for a single channel to be stored at a 16KHz sample rate. With some clever software I could add some low speed oscilloscope type functionality to the device with this configuration.
This still didn't solve the problem of what to use for the controller board though. I toyed with the idea of using two Launchpads - one for the controller and one for analog sampling but I would still be limited in the user interface I could display on the device (and not be able to make use of the extended analog sampling capabilities on the device itself).
Final Hardware Choices
Around this time the Raspberry Pi Model A started to become readily available. I'd already been using the Model B a fair bit and the difference between the two is fairly minimal (the Model A has 256Mb of RAM, drops the ethernet connector and only has a single USB port). This device is only about twice the price of a Launchpad ($US 25 for the Pi compared to $US 13 for the Launchpad) and provides a system more than capabable of running a full Linux installation with all the benefits that entails.
Generally I try to avoid pre-built modules (mainly because I want to do the work myself to learn how it all fits together) but this combination seems to be the best for this project. Providing and filtering the raw analog inputs is still going to stretch my knowledge and force me to learn new things but at least I will be able to do the software on something I'm very familiar with. Writing code for the Launchpad would still be something new as well.
The end result:
A touchscreen module with an onboard framebuffer. * A Stellaris Launchpad module for analog data acquisation and storage. * A Raspberry Pi Model A for overall control, data storage and user interface. * A custom circuit board for analog input filtering and various glue logic.
Communication between each of these components will occur over I2C or SPI. The external wireless communication can be handled by a Bluetooth dongle on the USB port of the Raspberry Pi. All of the modules should happily talk to each other at 3.3V logic levels so hopefully I can avoid using additional level convertors.
Now that I (hopefully) have the hardware sorted out I need to confirm that everything will talk to everything else. This is going to be mainly software testing at the start (which is good - I won't be limited by access to the the lab) to ensure that the Pi can control the display and the Launchpad, testing transfer speeds, etc. The results of these tests will impact the architecture of the final software suite that will drive it all (and it will be a suite of software - not a single monolithic program). I'm hoping that a lot of this work will result in reusable modules I can repurpose in future projects.