This is a summary and thoughts about the following paper:
The Toastboard: Ubiquitous Instrumentation and Automated Checking of Breadboarded Circuits
by Daniel Drew, Julie L. Newcomb, William McGrath, Filip Maksimovic, David Mellis, Bjoern Hartmann
Summary
The Toastboard is a breadboard that has diagnostic circuitry taped (yes, taped using electrical transfer tape) to its backplane to allow for real-time introspection of circuit performance. It was designed to be used to improve debugging while prototyping on a breadboard by providing real-time feedback on the hardware itself (via LEDs) and through a web interface (through an IDE).
The core of the implementation is based around a CC3200 Launchpad microcontroller and sets of cascading multiplexers. The basic idea is that the microcontroller has a limited number of ADC channels available, and there are a lot of rows, but it is possible to get a good estimate of the readings of each row if each row can be sampled quickly and many times a second. This is the approach taken for the Toastboard, where the MCU cycles through each row via the cascading multiplexers, at approximately 100 Hz for all rows, or around 1 kHz for a single row continuously.
The Toastboard was also designed to detect whether a given row is floating, which normally is something that would not be possible to tell by just sampling the row and checking its value. The way this was by leveraging the pulldown resistor network in place at the sampling circuit, and connecting the row to be tested (via the multiplexers) to a float testing circuit. This new combined circuit forms a voltage divider with the row being tested, so that if it is floating, there will be a known voltage value at the MCU pin, but if it is grounded, the row will still sample a voltage of zero.
There was an IDE developed as a companion to the physical hardware. Its primary purpose is to help identify problems with their circuits, if they do not behave as the IDE’s model expect. The IDE models hardware through the use of modules, where each module describes to the IDE what the component is and the kinds of errors it should check for.
There are known limitations with the Toasterboard as it was implemented. Hardware-wise, there are a limited number of ground and voltage rails, the maximum voltage on the voltage rail is fixed at 3.3V, there is a small amount of current leakage to ground while sampling each row, and the use of electrically conductive tape to connect the breadboard to the supporting circuitry means that the system is sensitive to being picked up. On the software/firmware side, the sampling resolution is limited by the MCU’s sampling hardware and sampling rate (trade-off between resolution and rate), the IDE module based checker can be confused with more complex circuits. The small current leakage likely means that this board will not be usable for extremely sensitive circuits, and the sampling resolution limits detecting subtle changes in voltages.
Personal thoughts
Having just left industry to study in academia, the very first thing that stood out was the use of electrically conductive tape to hold together the board to the sampling hardware. I mean, they were able to get it to work, but as they identified, it also means it can be unstable when being picked up and moved around. That said, if this were to be built for actual deployment, there are other ways to affix the boards together (it might be possible to solder everything together, or worst case scenario, use some kind of pressure harness to physically push the connecting parts together by force).
I really liked the cleverness of the design used to detect floating rows. That said, as far as I can tell, the more rows that could possibly be floating, the more time the MCU has to spend probing them, leading to a reduction in the overall sampling rate. I wonder if there is some way to do this comparison in parallel, or when not being sampled? This would require two parallel sets of multiplexers if using the current approach, though. Or would it? I’d have to think about it some more (if dealing with cascading multiplexers might be possible to reuse one of them so long as the other parallel process isn’t using one of the two in the cascade).
There was not a lot of information about the IDE on the paper, nor was I able to find a link to it or anything resembling it, so I was not able to see exactly what went into its function. From what I can tell, it allows users to drag and drop components on a virtual breadboard, which then tries to compare each module with error cases. For example, if a resistor has the same voltage on both ends, either it’s being shorted, it died, or one of its ends is floating, the IDE will report that specific error along with a suggested fix. The biggest problem I can see with the approach of attempting to enumerate what can go wrong is that it is difficult if not impossible to list ALL cases in which a component can be mis-wired or fail. As the paper also mentions in passing, false positives are also possible when someone builds a circuit exploiting a more obscure property of a component (the paper states using an LED as a Zenner diode would likely cause the IDE to throw a warning).
As far as I can tell, a lot of the hardware limitations are mostly engineering related. It should be possible to develop a power control system that can transform whatever input voltage is fed into the Vcc rail into whatever is necessary to run the actual MCU. I’m not terribly familiar, but I’d be surprised if there aren’t ICs available that can do the sampling for the MCU and handle a much wider range of voltages than what the MCU pins can. I am curious as to why they ended up cascading multiplexers– maybe they could not find or could not source multiplexers with enough channels? The paper also mentions in passing that the sampling system was meant to support more steady-state testing than analog… I wonder what kind of analog signal degradation or distortion happens as it goes through the multiplexer cascade? I’ve had to deal with this on personal projects for multiplexers designed for digital applications, although taking a look at their multiplexers (TI SN74HC4066), it looks like this isn’t a problem for frequencies below 30 MHz (if I’m interpreting the spec sheet properly).
As an addition, I wonder what it would take to also be able to measure current? This would be more difficult as it would require MITM’ing the signal, and depending on the underlying circuitry, this could introduce extra capacitance and resistance that might change the behavior or a sensitive circuit implementation.
This is more difficult, but I wonder if they considered integrating the IDE with Spice or some other circuit simulator to predict actual circuit behavior, instead of trying to detect predetermined errors.
Now that I’m thinking about it, it’s not clear how the Toastboard is communicating with the client computer, and who is hosting the web server that the client connects to. Is the MCU powerful enough to host a basic server while it is polling? Or is it sending information off to some other system which is actually serving the data? How is it connecting to other systems? Based on Figure 3 in the paper, I’m going to guess it’s connected to the network via the MCU devkit (looks like it has WiFi support) and it is hosting its own server that a client computer then connects to. No information is provided on what this server software is, and what is the OS running on the MCU, and anything related to latencies or realtime requirements of such an OS or applications running on the MCU.
I wish I had something like this when I was learning about electronics on my own, if nothing else being able to see the voltages would have been a godsend. I’m personally less interested in the IDE’s automatic fix suggestion, partially due to what it seems like could be a non-negligible rate of false positives for more complex circuits. For simple circuits as you’d find in educational settings, I think it’d be a great aid (I can even see it being used in classes with full warnings and error fixes during labs, and then only voltages being shown in a practicum).
Bibliography
- Daniel Drew, Julie L. Newcomb, William McGrath, Filip Maksimovic, David Mellis, and Björn Hartmann. 2016. The Toastboard: Ubiquitous Instrumentation and Automated Checking of Breadboarded Circuits. In Proceedings of the 29th Annual Symposium on User Interface Software and Technology (UIST ’16). Association for Computing Machinery, New York, NY, USA, 677–686. DOI:https://doi.org/10.1145/2984511.2984566