I have an application that needs three serial connections, including serial to at least two other Nanos. (Clones of same Nano).
What I need is to daisy chain Nanos, with a signal passing from one Nano to another, to another, etc. To N number of nanos running the same software. The signal will change from one to another, "a" to "b" to 'C' etc, starting with the Nano that has a trigger event. And, the data needs to flow in two directions.
9600 baud or less is fine.
And, I need the USB serial for debugging.
So far it looks like serial is the best solution, but if you have a better solution, let me know. (No external hardware please.)
It has been over 20 years since I was down in the bits, bytes, and edge detectors, so I do not care about pulse width, or latency discussions with tachyon polarity. Just how do I set up to send/receive two extra serial connections.
I have been reading about SoftSerail, and AltSerial, but they all talk about Arduino Uno. NOT Nano. Is the Nano so new the docs do not mention Nano, but it works, or does Nano not have the support for these libraries?
Also, they seem to be locked to specific ports. Are these the same ports (pins) on the Nano?
A Nano is essentially a smaller version of an Uno - it has the same 328 processor.
SoftwareSerial is not nearly as good as HardwareSerial. If you need to transmit a lot of data quickly it may not be suitable. It can only transmit or receive - not both at the same time, and only in one instance at a time.
You could try SPI or I2C both of which allow several devices to be connected to the same bus.
You can, with a bit of effort, use serial in a master-slave configuration where one serial port on the master connects to a number of slaves. All the slaves can listen but the master advises each slave when it can talk.
The Arduino Micro is small version of the Arduino Leonardo. They have a spare hardware serial port. With the hardware serial port, you can daisy-chain hundreds without any loss.
Peter_n:
The Arduino Micro is small version of the Arduino Leonardo. They have a spare hardware serial port. With the hardware serial port, you can daisy-chain hundreds without any loss.
I can envisage how you connect MicroA to MicroB. But how do you "daisy chain" MicroB to MicroC ?
The TX to the RX of the next module. The very last TX to the RX of the first one, to be able to read something from a module. The rest is up to the protocol, how to identify the modules, which one is the Master and so on.
If one module stops working, or the wires break, then everything falls apart and nothing is working anymore.
I guess you are only thinking of a one-way data flow ?
Unless there are reasons of distance that necessitate connecting A to B to C etc. the programming would be simpler if the Tx of the Master is connected to the Rx of all slaves.
The Nanos would be up to 10 feet apart.
The Daisy chain would be A TX to B RX, B TX to C RX,.... Z TX to A RX.
The reverse chain would be A TX2 to Z Rx2, Z TX2... C RX2, C tx2 to B RX2,
Data can flow in two directions.
Maybe better as list of requirements:
uses Nano.
Minimum external hardware.
All Nanos running same sketch.
Each Nano can pass data to USB connection for debugging
Each nano shall send data bytes to two other Nanos.
(Two tx/rx pairs plus USB)
Baud rate may be 9600 or less.
Message will be encoded as High, Medium, Low, Off. (Or equivalent. One char may be complete message.)
May implement heart beat, with current data value resend on regular schedule. (Will mostly be OFF)
Must have at least 1 pin for input, 3 digital output pins, one analog output pin.
I thought to do the signaling in hardware, but my EE friend said I could not do that.
I can do ACK protocol to validate sent data is received, in case data is missed while busy sending or receiving.
A needs to do different action based on state of B,C,D and of Z, Y, X.
B needs to take action based on state of A, Z, y, and C,D,E.
etc.
There is no main controller, no Master, no central unit ? Then extra care should be taken that the communication will not be a big mess.
Data in two directions, that means listening to two RX ports.
The Nano use the hardware serial port for the communication via usb to the computer. So you must use SoftwareSerial (can listen to just one port, can not listen while transmitting) or a combination of SoftwareSerial and AltsoftSerial. https://www.pjrc.com/teensy/td_libs_AltSoftSerial.html
Every module has to remember the data of all the other modules ? That should be no problem.
How does module 'A' know that it is 'A' ? Or initiate them all by pressing a button on a module ?
Does every module have for example a serial number stored in EEPROM ? Or are there always exactly 26 modules ? If the number of modules is variable, and no serial number is stored in the EEPROM, then the communication protocol has to add a counter (and probably more).
A software acknowledge can always be added.
I like the idea of a heartbeat. When there is nothing to do, send a heartbeat down the daisy chain.
I suggest to start with three Arduino Nano boards, and try to make it work. If you want, I can try to think of a protocol with acknowledge. But then I have to know if the modules should send their status or received commands, and so on. It might be possible to send 26 bytes (26 messages) around and around, encapsulated by and . Every module just reads/writes its own byte. Or a command to set an output, and another command to read an input.
Why do I need a central controller?
Any module (nano) could be A or B or K. I only care what triggers are within three or maybe 4 hops. 5, 25, or 444 modules, makes no difference.
I 'could' do this direct, connect pins direct and read values, but that would use up 7 or 9 pins, depending on the number of hops.
Example, Pin 3 is signal pin, Connected to pin 4 of B, pin 5 of C, Pin 6 of D. In the other direction, pin 7 of Z, pin 8 of Y, Pin 9 of X.
Signal pin goes high, and the other 6 Nanos know that A is triggered, and how far they are from the trigger.
If I cannot get two serial connections (4 pins) working I may have to just do the direct connect.
With your system any intermediate Nano will have to listen to all incoming messages and re-transmit most of them.
If the data involves control from a "master" then the Nanos nearest your master will be receiving a huge number of messages that have nothing to do with it but will have to re-transmit them all. The burden will increase as the chain gets longer.
You have not told us how many bytes of data need to be passed in a single message or how many messages per minute will need to be passed.
I don't think identification of the Nanos is a problem. Each Nano just needs to know its own ID (which can be as simple as const byte myID = 12; If it receives a message that is not addressed to it, it just re-transmits it. It does not need to check anything else. Obviously something needs to know the IDs of each Nano so it can address the messages for the correct device.
Okay, only reading the neighbour modules (4 or 5 hops), so a module doesn't have to know if it is module 'A' or 'B'.
I would add a counter to the protocol, and every module increases the counter. After the counter is 5 or 7, the module does no longer have to pass on that message, since it is too far away. That way everything is relative to each other. No longer an ID, like module 'A' or 'B', but more like : "this is a message of a module that is 3 hops further".
The moment to send a message is tricky. There has to be very strict rules about the time to wait, the timeouts, when a modules starts sending messages, and so on.
First of all, a communication between two modules should be written. Preferably with an acknowledge, because of the two software serial ports. If that works, the rest of the protocol can be put on top of that.
I would start with a combination of SoftwareSerial and AltsoftSerial.
Using the 7 or 9 trigger pins will work. You could do a small test with that, and meanwhile work on the serial communication. Then at least you have something to fall back to, in case the serial communication doesn't work very well.
Is it only reading the other modules, or also writing a command ?
The problem with the serial libraries I know about is, they are locked to specific pins. Without editing the source, I cannot change what pins they use.
And they all use the same pins.
I am unclear if this is a programming choice (No one will ever need more than this) or a hardware restriction (Only works with these pins).
Mclae:
I am unclear if this is a programming choice (No one will ever need more than this) or a hardware restriction (Only works with these pins).
On an Uno, for example, the choice of pins 0 and 1 for HardwareSerial is linked to their connection to the Serial to USB converter that allows it to talk to a PC.
Similarly on a Mega the hardware USARTs are physically connected to the relevant pins.
SoftwareSerial allows the option to use other pins but is a lot less capable and can conflict with other Arduino libraries.
Have you considered using a wireless system - such as with NRF24xx 2.4GHz transceivers. It would be a little more expensive but probably a great deal easier to implement. I have a 2.4GHz system in which a master (connected to my PC) sends commands that are heard by several slaves in model trains. When a slave receives a message with its ID number it replies to the master.
Actually, I am trying for signal system logic.
Occupancy detect current block, set red in current block, yellow on adjacent, maybe Lunar Yellow on next block, and green for all other blocks.
This is for the club, so expense is a factor. We may need about 40 of these, 20 per main line. (have not counted blocks yet.)
I could do this with JMRI and DCC stationary decoders, but I am looking for an independent system.
And, I will be sharing the solution with the NMRA local group. Some of which do not use DCC.
On a side note, how well does the DCC library work on Nanos? That might be the last out. Turn a Nano into a DCC device.
Mclae:
Actually, I am trying for signal system logic.
Occupancy detect current block, set red in current block, yellow on adjacent, maybe Lunar Yellow on next block, and green for all other blocks.
I had no idea you were working on a model railway project. You should have told us that in your first post. See the XY Problem
A single Mega should be able to do all that you require. You can extend the number of I/O pins with shift registers if you need to.
Adding several Arduinos will just complicate the project.
Are you trying to make a stand-alone system or will your signalling system be controlled by a PC (which would be my preference) ?
