I am starting a new project where some microcontrollers create a MIDI clock via classic MIDI connectors and USB depending on packets that are received through an ethernet connection.
As a MIDI clock is a rather time sensitive task, I decided to us two separate ATMEGA MCUs, one for MIDI and one for handling the packet analysis. As the time of arrival of the ethernet packets is also important, I want to use an interrupt on the 32U4 which will be triggered by the 328p whenever a packet arrives.
The MCUs I want to use are: ATMEGA32U4 (Micro) for the MIDI clock, as it supports MIDI-USB ATMEGA328p (Nano) for the packet analysis and communication with the Wiznet W5100 as ethernet controller
So the 328 and the W5100 must be connected via SPI, and the 328 and the 32U4 must have a way to talk to each other, too.
Unfortunately, the TX pin on the 32U4 is reserved for MIDI out, so I can't use RX/TX for direct communication between 328 and 32U4. But this enables me to use the RX pin as interrupt and still have I2C if necessary.
Furthermore, I want to be able to update the software on both MCUs via the USB port that is connected to the 32U4.
So the 32U4 must be connected to the 328p in a way that does not use RX/TX, but enables to program the 328p via the 32U4. 328p and W5100 are connected via SPI.
I am looking for a permanent solution without rewiring, as I want to design my own PCB. If possible, the user should not have to set jumpers / press buttons to be able to update the software on both MCUs.
So how do I connect those three ICs, the interrupt and the MIDI port?
As for the updating process itself, I was thinking about letting the 32U4 check if there's an updater running on the PC after being connected to USB, then flash a software to program the 328p, program the 328p and then flash the updated software on the 32U4.
As the time of arrival of the ethernet packets is also important,
There is no guaranteed time of arrival for Ethernet packages, it is not a real time interface.
Also it is rare that anything requires two processors, the added complication of talking between the two makes it, as you have found, much more complicated than simply coding it correctly in the first place.
So how do I connect those three ICs, the interrupt and the MIDI port?
You can use SPI because it is a bus and many things can be connected at the same time.
You can use SPI and bit bang the protocol on any set of pins you like.
You could use I2C.
You could use software serial.
I do know that Ethernet is not an real time interface, but the protocol I want to communicate with is proprietary and I can't change it, so I have to rely on it.
Besides, we're talking music here, so as long as it's about 1ms in sync, that's fine.
Communication between the two MCUs should also be minimal (a few bytes every 100ms or something as data, and an interrupt now and then).
That was the whole point of using two MCUs, so every MCU can do their job indepently...
For software prototyping I recommend you start with an Ethernet Shield on an Arduino Leonardo. Under $8 combined for inexpensive clones so buy a few. For your custom board you can combine the Leonardo and Ethernet Shield schematics and removing any parts you don't need.
johnwasser:
For software prototyping I recommend you start with an Ethernet Shield on an Arduino Leonardo. Under $8 combined for inexpensive clones so buy a few. For your custom board you can combine the Leonardo and Ethernet Shield schematics and removing any parts you don't need.
That's what I'm doing right now... I just want to get the wiring right from the start.
As for the use of two MCUs: The problem is that there is a third device in the equation that doesn't care about my timing concerns. So when I want to have an exact MIDI clock without jitter and still be able to communicate with this third device (that replies once whenever it wants), I need to split the work on two processors, as one can't be bothered with waiting for replies, as it has to give out a MIDI clock.
Arduinos have this cool feature called "interrupts" including "timer interrupts". Such a clock signal is a simple fire-and-forget feature: you set the timer, and it'll call your ISR right on time, even if you're doing something else. All the timer presumably has to do is change a pin status from HIGH to LOW and vice versa, as it's a clock signal.
The same for picking up communications from this third device. Serial, SPI, I2C, etc. all use interrupts to not miss incoming communications. Data is stored in a buffer, and at your schedule you get to handle it.