What is the distance. If it is over a few meters use someting like RS485/Modbus. I see others have mentioned this.
I2C was designed for inside TVs. Probably the most common bus on the planet. (I think there are more TVs than cars.) NXP does make bus drivers for some distance although there are latency issues involved using them.
I have not been following some of this as closely as I would like. I did look at the neopixels to see if they might work as diagnostics on my pipe organ shift registers. (I got the player working on the second instrument yesterday, and should be working on that code at this instant ...)
In skimming through the above post I am not quite sure why you are so locked into so many ardiuno outputs. I can see that the neopixels have timing requirements, which do not lend themselves to pre-emptave operating systems.
Such jitter effects is why I like bit banging AVRs too. Although I favor assembly over library management. Were I implementing this I would probably use 74*595 shift registers which are serial to parallel converters. I test my pipe organ drivers using small pea bulb lights or LEDs before dealing with the power through the coils.
On the other hand, It looks like the neopixels already are shift registers so an I/O expander might be too much extra guff to add. My cursory overview is that basically this is just really low resolution video, with similar timing constraints.
I keep thinking I want to look at my copy of "The art of Digital audio." to see if there is a better way to do this. Most compression is based on a DCT, which is a close cousin to FFT. Since the compression is already finding the spectrum of frequencies to mask, Would it not make sense to tap into this. Of course one would need an Arm processor, with custom drivers for the neopixel shift registers. Still if one can blink a led at high frequency, then one can bit bang the pixels the same way.
Since the Arduino display driving task is so finiky, I think that you need to have the Arduino as master no matter how you implement the interface.
With either I2C or SPI, the way to do it would be to have a data buffer in the other device already populated with the last set of results so it wouldn't have to take time to gather the results but just sends them off and goes hapily back to it's calculations. I don't know if the Duo has hardware support for I2c or SPI slave mode but a lot of processors have that. This would bring any interruption to the calculations to a minimum.
Of course it would be useful for the Arduino to know if the new data is ready before going to the bother of getting it. You can do that with a "ready" output on the other device that the Arduino can read at it's leisure.
The custom interface you describe should work as well but might be more work if there are already libraries availabel for the standard protocols.
So, that's what I'm thinking at the moment. What do you think? Is a custom interface the way to go -- (have you created one yourself?) -- or would you always try to stick with a standard protocol?
As betamax pointed out earlier, there is the UART option. I have created several protocols of my own (sometimes you just have to- I did a blog on that on MCC. Maybe it's time to resuscitate it.) as well as implemented other protocols like Modbus. (Look for my article in Circuit Cellar on creating a Modbus Master (CC Issue 200/201- March& April 2007) and creating a Modbus Slave (CC issue 216 July 2008).
My vote is for a UART for the following reasons, although I2C may meet some of this as well (I am not that familiar with it).
1. You can have duplex communication
2. You can detect framing, parity and overrun errors in hardware.
3. Each byte is self synchornising.
4. If you use the 9 bit Intel protocol you can establish an easy way to synchronise the message as a whole. (Some micros do not have the 9 bit mode but it can be added with a little software manipulation- see my app note for Cypress AN2269)
You could also utilize SPI, but use it in your own custom way.
First, wire it all up as though it were an SPI, but don't put the Arduino Mega or ChipKIT pins into SPI mode. You can use the pins as GPIO for your handshaking.
The ChipKIT can set one of the lines to indicate data is ready. The Mega can poll that line when it has spare cycles. Then after the handshaking indicates everything is ready, switch the pins on both sides to be SPI and transfer the data. Switch back after the transfer.
I noticed in this blog and your Golden Ratio blog you mention an alternative to Bodacious Acoustic Diagnostic Astoundingly Superior Spectromatic (BADASS)dislay, the BIGASS display. What do these letters represent?
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.