I agree with Patrick.

It is totally feasible to do communications protocol byte by byte using a few instructions in an interrupt to buffer/unbuffer the data. The cost is very often on the order of a few percent of the total bandwidth of the microcontroller. The relatively low data bandwidth of communications that is being talked about here is precisely why a serial transport layer is often used becasue it is plenty fast enough and the support hardware is often built on-board the processor. Serial is also much much lower cost to implement in terms of additional hardware and connections needed over a parallel approach. If onboard serial is used it also provides the interrupt mechanisms to interface it to the software in a way to facilitate the low bandwidth type of support. In my opinion the use of the FIFOs that have been described for this application are totally unnecessary. I would only resort to a parallel approach for interface between two processors where speed of communications was paramount. And then I would use a DPM (dual ported memory) over a pair of FIFOs any day. The only times I have ever used FIFOs in an interface from a controller to some other device was where I needed an elastic store. For example where the controller can load data into the FIFO at an average rate faster than is needed but not at guarenteed rate. Then the other side of the FIFO can be unloaded at the precise rate needed. Do note that in my experience these FIFO applications have never been "processor to processor" but rather have been input to processor from hardware or output from processor to hardware.

Regarding the use of the supervisors. It is generally a good idea to equip a system or set of boards with a single global reset from a supervisor chip. Separate watchdog functions to ensure software reliability can also be useful but are not totally necessary. In most multiple controller designs I have done I have watchdog functionality on the master processor. I also routinely put the slave processors under reset control from the master processor. The global reset is implemented so that at reset the I/Os from the master processor that control the slave resets are forced into the "reset state". It is common practice to design the firmware of the slaves to that it interacts with the master in some way so that the master can see if the slave is still alive. This could be as simple as a once per second heart beat pulse from the slave to the master via an I/O pin. Alternately it can be as simple as a reasonable reply from the slave to some type of status request packet through the communications system. If the status packet is used however make sure that it is implemented in a way that the slave has to be running its main loop to respond (IE do not totally respond to packets of this type from an interrupt context only, similar to reasons why one does not tickle a watchdog timer in an interrupt). If the status poll from the slave ever fails to give expected results the master code should reset the slave via the software controlled I/O pin. I never allow the slave to ever have any control connection over this reset action such as the ability to disable it. On some designs I have a timeout function built into the master that is reset back to max time whenever a packet transaction takes place. A timer function in the master is used to send a status check packet say like once per second whenever the master is idle and not sending other packets to the slave.

Regarding the subject of packets with and without an acknowlwdgement. It is my opinion that in a simple and low bandwidth communications system like is being talked about here that the best protocol system is to use a fully handshaked system with a few simple rules. 1) Master always initiates every packet communication. 2) Every packet has a reply back from slave to master. 3) Slaves never initiate unsolicited transmissions. These rules lead to simple to make reliable communications implementations that are predictable. Anytime I have had to work with any standardized protocols that worked outside this simple set of rules there was always trouble of one sort or another (I'll reserve describing why to another discussion).

Respectfully,
Michael Karas