peteruithoven
commented
8 years ago After fixing the Half duplex software serial issue and learning how to directly read pins we've made great strides in the Low level pre-check approach. See the following experiment: https://github.com/knopjesmuseum/resilient-network/tree/master/experiments/SoftwareSerial/3%20multi-read-precheck Part B resends what it receives from normal serial to 3 half duplex software serial ports. Part A reads all it's software serial ports and and per port toggles a led when it receives messages. It seems to work 100%. Next we should also try sending and maybe adding another node.
Solution 3. Simultaneous receive, still is a very interesting approach, but requires writing a different SoftwareSerial library.
Currently the blocking issue is making the node’s listen to 3 (software serial) ports at the same time. In the SoftwareSerialWithHalfDuplex-experiments folder the 3th experiment almost always fails, sometimes a message get’s received (indicated by the led), but it’s never echoed back to the sender.
1. Low level pre-check One solution might be to add a very fast, but low lever pre-check, when one of the porst is pulled high we start listening to that port with the softwareserial library. With this approach it’s imperative that the library responds quick enough without losing data. A slower baud rate might help. Starting the communication with a pulse hopefully enables the code to start listening on time to the actual communication. Sending a pulse that's longer (out of band) than normal serial communication and only switching on longer pulses prevents switching to a message that is already "halfway".
2. Send queue Another solution would be to create a send buffer and acknowledgment system. The sending party would attempt to send a message and waits (with timeout) to receive an acknowledgment. When this isn't received it should try again after a random timeout. Because it might have attempted to send another message in the mean time, a queue might be necessary. The old Resilient Network code contained a lot of this logic, but it wasn't very successful in the end.
3. Simultaneous receive The regular SoftwareSerial library can only handle one rx/tx pair at the same time. This is because it starts listening to changes on all pins using pin change interrupts and when triggered samples the rx pin 8 times with delays in between. This makes it blocking. Maybe we can, possibly on a time interrupt, try to sample all the rx pins, without delays. If we do this with 3x the communication baud-rate we can sample, theoretically, in the middle of the bits. This would actually allow us to listen to multiple ports at the same time. One thing that worries me is that this idea was suggested to me by 2 people, but I haven't found libraries that try this.
4. Other library There is at least one other library that should do the same, maybe it has a better solution? http://hackaday.com/2014/01/13/software-half-duplex-uart-for-avrs/ http://nerdralph.blogspot.ca/2014/01/avr-half-duplex-software-uart.html https://github.com/nerdralph/nerdralph/blob/master/avr/libs/bbuart/ AltSoftSerial won't work, it can only have one instance.
5. Other IC (hardware) The regular Atmega 328p (also used in Arduino Uno) has (only) two interrupt pins. Having 3 or more would significantly simplify the problem. There are other Arduino projects with more interrupts pins, like the ATmega2560 (Arduino mega) and ATmega32u4 (Arduino Micro), see: https://www.arduino.cc/en/Reference/AttachInterrupt. The Teensy 3.2 has interrupts on all ports, I can't find information on interrupts for the Teensy LC. What about STM32 (stm32 interrupts)?
6. Adding ATtiny's per port We could add a dedicated ATtiny per communication port. These could then buffer incoming messages, possibly send acknowledgments, buffer outgoing messages etc. The main IC can then, at his own convenience, poll the ATtiny's one by one.