Need advice on Serial Communication project

Reposting my question to more relevant forum.

Hi Friends,
I am new to this community, adriuno as well as to the whole world electronics and very recently started learning ardiuno and electronics out of interest to developing some fun projects, I hope you wouldn't mind answering my silli questions, I am looking forward to your help.

Project:
I am looking to control multiple device (motors) with one master (ATmega328P) and multiple slave (Attiny85) by using serial communication, I do not want to get into too much of complexity but still want to stay with minimal components.

I am thinking of using using multiples Attiny85 as slaves (with Softwareserial library) which would receive a messages (e.g some id) , if this ID belongs to a particular slave, only that slave would react (in my project It would then pass high to a motor driver to drive a motor) i am looking to share the same mesage (id) to all Attiny85 connected with a single bus (like one to many broadcast message) and only one of them would recognise that message. (I am thinking to avoid using RS485 or adding multiples of MAX485 with each Attiny85 )

Do you think it is possible (without any voltage drop) to send the same serial messge to 20 Or more slaves with a 20 meter wire, or is there any better approach, IC or library.

Please also suggest if any other low cost microcontroller available which supports hardware Tx, Rx pins and also suggest if any cheap motor driver could be used which could be programmed or support RS485 communication.

Thanks in advance.

Regards,
Manish

It's all possible and has been done many times. But, how much time and effort are you going to put into learning and testing?

Is this a hobby or a full time project?

Paul

There is a concept in digital electronics called fan-out IIRC. It describes how many digital inputs can be fed from a single digital output. I don't have any numbers in my head but, clearly, you cannot expect the signal quality to be maintained if there are too may inputs drawing on a single output. Somebody else might know. I think the number may also be affected by the speed at which the signals change - higher speeds meaning a smaller fan-out. Longer wires will also degrade the signal.

In other words, some experimentation will be required.

For at least two reasons an Arduino Mega would be better than an Uno because it has 3 spare HardwareSerial ports.

First, having the 3 spare ports allows you to leave Serial for debug messages and uploading programs

Second, you don't have to connect all the Attiny's to the same HardwareSerial port.

Have a look at the examples in Serial Input Basics - simple reliable ways to receive data. There is also a parse example to illustrate how to extract numbers from the received text.

The technique in the 3rd example will be the most reliable. It is what I use for Arduino to Arduino communication.

You can send data in a compatible format with code like this (or the equivalent in any other programming language)

Serial.print('<'); // start marker
Serial.print(value1);
Serial.print(','); // comma separator
Serial.print(value2);
Serial.println('>'); // end marker

...R

Do the tinyies need to send any information back to the master?

If you are only sending a single command like motor position or speed then you can drive them like servos.

MODBUS is one option for adressable slaves.

With proper cabling and termination, the RS422/485 standard supports 32 nodes with approximately 300 meters total cable length.

I have done large scale projects with as many as 85 nodes over 100 meters without difficulty. Proper cabling, termination and grounding are critical for any multi-node network to function correctly.

I would consider using RS422 for the physical layer. Wire the Tinys in a multi-drop config with the RS422 termination at the last, receiver, furthest from the transmitter (which has a termination as well.)

Then I'd implement a simple but robust serial protocol using a header, payload and checksum.

The header would contain message alignment, message length, destination address and command bytes, the payload field would be a flexible length, depending on the command and the checksum would be, to keep it simple, just a sum (rather than, say, a more robust but more complex CRC.)

Each Tiny would need to be programmed with with a unique address (or, if you have enough free I/O pins, strap the pins uniquely and derive an address from that.)

qualityking:
Reposting my question to more relevant forum.

Report to moderator would have been a better choice.

Do not cross-post. Other thread removed.

Paul_KD7HB:
Is this a hobby or a full time project?

Hi Paul, I am putting 2 hours a day on an avg to learn electronics, currently its a learning project but if this works I have a commercial idea to make it a full time project. I can surly hire some freelance professional to a practical implementation but I would loose my own learning aspects.

Hi Robin
Thanks for sharing the code snippets, I had the similar thought of implementing with marker, I would surely look at fan-out IIRC and update my findings

MorganS:
Do the tinyies need to send any information back to the master?

If you are only sending a single command like motor position or speed then you can drive them like servos.

MODBUS is one option for adressable slaves.

Hi Morgan,
As of now I am looking only for one side communication, but if this works 2 way should be similar I guess.
I have looked into modbus, but I think we need an additional hardware btween uno and tiny which support modbus protocol. (Please correct me)

WattsThat:
With proper cabling and termination, the RS422/485 standard supports 32 nodes with approximately 300 meters total cable length.

I have done large scale projects with as many as 85 nodes over 100 meters without difficulty. Proper cabling, termination and grounding are critical for any multi-node network to function correctly.

Hi whattsThat,
Can you please share the component which all used to make the communication and wire type which has been used, I am sure that would be really helpful.

Blackfin:
I would consider using RS422 for the physical layer. Wire the Tinys in a multi-drop config with the RS422 termination at the last, receiver, furthest from the transmitter (which has a termination as well.)

Then I'd implement a simple but robust serial protocol using a header, payload and checksum.

The header would contain message alignment, message length, destination address and command bytes, the payload field would be a flexible length, depending on the command and the checksum would be, to keep it simple, just a sum (rather than, say, a more robust but more complex CRC.)

Each Tiny would need to be programmed with with a unique address (or, if you have enough free I/O pins, strap the pins uniquely and derive an address from that.)

Hi Blackfin,
This is the great suggestion and the same way have often used in many standard messaging protocol implementation, I would look at RS422.
Can you please elaborate more on how I can uniquely derive address with free I/O pins at tiny.
Any reference document or video link would be a great help.

Thanks everyone for such an overwhelming response every reply would be of a great help.
I must say this is one of the great community I have ever interacted with.

Regards,
Manish

qualityking:
This is the great suggestion and the same way have often used in many standard messaging protocol implementation, I would look at RS422.
Can you please elaborate more on how I can uniquely derive address with free I/O pins at tiny.
Any reference document or video link would be a great help.

The problem with the '85 is that it has virtually no spare pins :slight_smile:

If you wanted to have 20 (or more) slaves, you would need 20 or more unique addresses. For a binary number you'd need at least 5 free pins (giving 32 possible values from 0 to 31). If you set such pins as INPUT_PULLUPs and then grounded selected ones on each ATTiny you could give each one that unique address. Again, the problem with the 85 is lack of physical pins.

If you have a free analog input you could do the same idea with that pin, using two external resistors to program a specific voltage to each device. If each window was 30 counts wide, you could set 32 unique addresses and not run out of bits with a 10-bit ADC. Address 0 would be any ADC count between 0 and 29. Address 1 would be between 30 and 59, Address 2 between 60 and 89 etc.

If the Tiny has EEPROM you could also program each with the same code but have a reserved command, say, 0x00, that carries a single databyte and is recognized by all regardless of address. That byte would be the unique address for a given Tiny to be burned into EEPROM. When setting up, you'd run a quick program from your master with only one tiny on the bus at a time that sends that command and a unique data byte/address to the tiny. It burns that into its EEPROM and from that point on that is its address.

There's a few ways to approach this. The last is probably the cleanest and most practical.

Blackfin:
When setting up, you'd run a quick program from your master with only one tiny on the bus at a time that sends that command and a unique data byte/address to the tiny. It burns that into its EEPROM and from that point on that is its address.

I understand how that would work. However IMHO for the relatively small number of devices the OP is proposing to use it would be just as easy to build the ID into the program code before it is uploaded.

...R

This is what is I was thinking,

Master would connect to 8 tinys in series (8 in columns- since fan-out should go upto 10 slaves) and each tiny would connect to another tiny Tx to Rx. (8 in rows)

this would like a 8x8 matrix and support 64 motors.

so if master pass id as B3 (2nd column 3rd tiny) asking to rotate the motor , this message would be passed to all 8 sibling tiny connected directly with master, and then each they would keep on passing the same message to its next child in a row, until it would find right deserving slave.

will share the program tomorrow for your revirew.

please find the attachement of simple diagram.

OP's image:

Unless you need true peer-to-peer messaging, a ring topology with token/message passing will be horribly slow using serial communications. You'll want to use a star (or parallel) topology and provide the slave node ID's in the messaging. The non-addressed slaves ignore the message.

Even with peer-to-peer, this can be handled by making the master a gateway and the slave sends the message to everyone and the master ignores it but makes sure it makes it to the destination and initiates the retry if necessary.

RS-485 with a two-wire system is the simplest solution but since you've not provided any details of the message timing required so it's impossible to provide hardware guidance until the details are known.

qualityking:
this would like a 8x8 matrix and support 64 motors.

I had no idea you were thinking of as many as 64 motors.

You need to tell us exactly what is the range of things that any one motor must be instructed to do and the acceptable lag between the master formulating a command and the motor executing it.

My guess is that Serial will be too slow - but it's only a guess until you provide the data.

And using an Attiny as a relay for serial data will just add slowness. Much better just to use some dumb logic chips to boost the signals. And cheaper. And need no programming.

...R

MODBUS will work just fine without additional hardware. It is usually used in an industrial context with RS485 or somesuch for long runs resistant to interference but direct TTL Serial actually makes it easier.

The trick is that while all slaves can listen all the time, only one can transmit back to the master at a time. All the others must release the data line. Otherwise one transmitting a HIGH is crushed by all the others idling at LOW.

If you just want to start with unidirectional comms with the option to go bidirectional later, something based on MODBUS would be good.

Part of the speed issue can be overcome by sending individual commands to the slaves followed by a broadcast "start" instruction so they all start simultaneously.