I got an offline question along the lines of "that looks good, but what does it do?" and it reminded me that such a device is for a certain audience. If you've just bought you first Arduino and are trying to get the LED to blink you do not need something like this.
If you're experienced you probably do but you also probably have a lot of tools already. Still maybe this will consolidate them while providing a few extras. Either way it has to be easier than connecting 15 wires from 3 different tools.
If you're somewhere in the middle and you're happy with serial.print()s and staring at the chip wondering what it's thinking then it's not for you either.
But for intermediate to advanced developers who are not happy with chip staring I think this could be a good tool.
The following is an expanded version of my response email.
The Quadd plugs onto the Arduino headers, in general it does not “use” any pins and can coexist with any other shield. Your Arduino is totally separate in the sense that your current Arduino interface and programming method doesn’t change, however if the Quadd is configured appropriately you can easily view what your program is doing rather than staring at the chip and scratching your head.
As an example I though I’d try to illustrate a typical scenario, getting your Arduino working with another chip over ISP, let’s say the other chip is an IO port expander.
Firstly, after uploading your code you can view the SPI registers (with the inbuilt AVRmon program) on the Arduino to ensure they are correctly set. If not you can change them in situ without having to do a compile and upload.
You can do a timing analysis on the SPI signals to see if the bits are wiggling as expected, then when the fundamentals are working and you want to look at the data flow between chips you do a protocol analysis to see the traffic of bytes on the MISO and MOSI signals.
The only real difference between the two is that timing shows waveforms and state shows data, however with a suitably-written GUI the two display styles would merge to a large degree.
If things seem to be working but not quite, let’s say you get data from the IO expander but your serial.print() is reporting the wrong value, you can trigger on an IO expander input changing state and see what data was sent. If it is correct on the SPI lines then the Arduino code has a problem, of not then there’s an issue with the IO expander.
Another option is to let the Quadd take over the SPI lines. In this case you can disconnect the Arduino’s processor (the Quadd does this by holding the chip in a reset state so no need to do anything physical) and manually (or using pre-canned data) read and write the chip.
Accessing Arduino program debugging data
You don’t need to use serial.print() and open/close a serial monitor all the time. There will be a few ways for the Quadd to read data from the Arduino’s program.
• Newsoftserial. Pick any spare pin and transmit data, will work but overkill if all you want is some debug output.
• Debug serial. A very simple and small transmit-only serial function.
• Shiftout. Use the standard library function.
• SPI. Use the hardware SPI port.
• IPC RAM. If you don’t have a single spare pin the Arduino and the Quadd can agree on the location of a section of RAM (IPC, Inter Processor Communications) and both can read/write from/to this RAM. So if you organise your code to use this RAM for some variables then you don’t have to do anything on the target, the AVRmon monitor program will extract the values and display them. The RAM is simply an array in the Arduino memory.
Whichever method is used the data can be displayed in a permanently-open watch window.
Rob