Sorry, this got long... This looks very interesting as a 'simple' communications protocol, and it would be great to have one available for simple multi-master

Sorry, this got long... This looks very interesting as a 'simple' communications protocol, and it would be great to have one available for simple multi-master applications. This one is very close, most of the major things are there. I think you should look at some things from other common protocols to increase the robustness. Especially CAN (especially single-wire CAN J2411), RS-485 multi-master, and 1-Wire. Here are some thoughts: - Increased Synchronization / Sampling: Async serial protocols usually sample at 16x the bit rate to determine the sampling point (CAN is 8x?.) You should increase the number of samples taken during synchronization. Clocks nowadays are much better than they were, especially using a crystal oscillator all the time, but you should still try communication +/- a few percent and make sure it is still robust. Look at this article for more information: https://www.maximintegrated.com/en/app-notes/index.mvp/id/2141 https://www.maximintegrated.com/en/app-notes/index.mvp/id/21... Also, a some implementations will 'vote' on the majority value before determining the 0 or 1, i.e. sample 8 times during the bit and return the majority value. This helps with noise resistance. - Use of timers and interrupt-on-change: This one might turn out to be a lot of work, but it would be nice to see an implementation that uses the timers and GPIO interrupts instead of using delayMicroseconds(). This will give you much better timing accuracy for sending and receiving, and frees up the processor to run an OS or other code in the background without having time taken out to watch the network and spin in delays. Also it doesn't necessarily ruin the timing when other interrupts are running at the same time. I have not done a lot of Arduino work though so I don't know how closely this would fit into the ecosystem... can you configure the timer/interrupt priority to use? Do all pins support interrupt-on-change? - Better CRC/checksum: XOR CRC is not the best, as it is not as resistant to multiple bit errors. There are good, free algorithms for CRC checking. Look into pycrc which writes all the C code for you. https://pycrc.org https://pycrc.org - Physical layer: add a small capacitor to simulate a long bus or many connected nodes. Simulate some bus faults. You should definitely look into getting an oscilloscope for this one, it can be very illuminating. Can you detect faults, by reading from the input while driving, to make sure the line is really what you want it to be? I'm not very familiar with AVRs but I know PICs could do it. - Some way of auto-addressing: it is a pain to address things on the bus manually, to reprogram devices every time you want to add some more. Look into some sort of addressing scheme (similar to how 1-Wire handles addressing.) Maybe just a 64-bit random identifier and some sort of bus enumeration? Especially since there is no way to detect address collisions on the bus. - At least wait 10 bit-times of zeros before returning with no collisions, since you can send 9 zeros normally (10 00000000)