Electronic – RxTx communication with multiple slaves using a RaspberryPi

modbuspicpickitraspberry piserial

I am a programmer trying to build a circuit with limited EE knowledge. With so many options(at least being new to this), just want to make sure I am going down the right path.

What I am trying to build is a master device with a RaspberryPi and many plug and play slaves(relays and sensors with very small amounts of data transfer). Seems like using modbus/rs485/pic/75176(LTC485) would be the best solution.

Consumer device, so component costs matter and an off the shelf product won't work.
The more devices I can connect the better. (My understanding is Modbus can do 250 devices by default, but I can do a double register(16bit) to get 65k tho bandwidth will probably cut that in at least half which is fine)
Slaves can be repeated many times. ie 10 of the same temperature sensors. I'm understanding that I don't necesarily have to define the slave id in modbus and can define it on the fly. Please correct me if I am wrong since I can't ask a consumer to set the ID manually if there is more than 1.
I need the consumer (true end user no corporate) to just plug a device in and have the system recognize what it is and be able to uniquely identify it.
True real time is not needed, a few second delay isn't a big deal.
Everything will be a call from the master to get data from the slave. Nothing originating from the slaves.
Plan on using a standard rj45 cable with a max distance of 100m since that's what they are rated for (cheap simple standard).
Lastly, I do plan on having a wireless option in the future, so if any of it can mesh well, that's a bonus.

I found this example that seems like what I am looking for. Doing my code in c++, but should be easy to convert.
https://docs.google.com/document/d/1YN4BeXw4zrb2dlk9HcTDxd-E5vxNjVN8wcSF4Q86yz0/

Again, I have much to learn, but tired of going down a bunch of wrong paths, so any advice would be great.

Thanks ahead of time.

Best Answer

Consumer device, so component costs matter and an off the shelf product won't work.

When doesn't it matter in industry ;)

The more devices I can connect the better. (My understanding is Modbus can do 250 devices by default, but I can do a double register(16bit) to get 65k tho bandwidth will probably cut that in at least half which is fine)

Technically you can only give slaves address 1-247 as 248-250 are reserved. You could double the register address but then you wouldn't be compatible with any other Modbus device as you are no longer using Modbus Protocol.

Slaves can be repeated many times. ie 10 of the same temperature sensors. I'm understanding that I don't necesarily have to define the slave id in modbus and can define it on the fly. Please correct me if I am wrong since I can't ask a consumer to set the ID manually if there is more than 1.

What do you mean by "design on the fly"? If you are not going to allow your end user to define their own Slave IDs then I reccomend you initiate your own slave IDs to a higher number, like 150+. If your device is connected to a pre-existing Modbus network then you might run into the issue of pre-exsisting slaves already using addresses that you assigned. YIKES! Keep in mind that most end users will begin assigning devices at address 1 but that's not always the case!

I need the consumer (true end user no corporate) to just plug a device in and have the system recognize what it is and be able to uniquely identify it.

Very easy to do but as stated in bullet 3, if your hardcoded Slave ID already exists on their system you will have multiple devices communicating to the same master.

Everything else you stated looks like standard Modbus RTU specifications so you should be fine there. I would reccomend looking up Modbus TCP protocols for when you use wireless transmission. Here is a helpful link to a website that goes over all of the Modbus Protocols as well as indepth analysis on what Modbus Erros and Responses need to look like.

Simply Modbus

Related Solutions

USART communication with PIC16F688

You are enabling the "GO" bit, which performs one conversion of the ADC.

Once that conversion is complete the "GO" bit is turned off and the ADC does nothing else until the "GO" bit is turned on again.

You should have something more like this:

while (1)
{
    ADCON0.1=1;
    while(ADCON0.1==1);
    byte=ADRESH;
    TXREG=byte;
}

Or, a better format (compiler dependent):

while (1)
{
    ADCON0bits.GO=1;
    while(ADCON0bits.GO==1);
    byte=ADRESH;
    TXREG=byte;
}

And even better - check to see if it has changed and only send if it has:

unsigned char byte,old;

... setup code ...

while (1)
{
    ADCON0bits.GO=1;
    while(ADCON0bits.GO==1);
    byte=ADRESH;
    if(byte!=old)
    {
        old=byte;
        TXREG=byte;
    }
}

And you should really check to see if the transmit buffer is ready to receive a new byte:

unsigned char byte,old;

... setup code ...

while (1)
{
    ADCON0bits.GO=1;
    while(ADCON0bits.GO==1);
    byte=ADRESH;
    if(byte!=old)
    {
        old=byte;
        while(TCSTAbits.TRMT==0);
        TXREG=byte;
    }
}

Of course, I have just knocked this code together in the browser here, so I haven't tested it, but it should give you the idea.

Electronic – arduino – multiple arduino communication (1 master, n slaves)

As I understand it you want to send different data to each of the slaves, but the slaves don't have to send data back.

I2C is an addressed bus, so if you assign a different I2C address to each of the slaves you'll need only two wires to send the data. If needed you can ask data back as well. The Arduino's AVRs have an I2C compatible serial bus. And you can extend to more than 3 slaves without extra hardware, up to a maximum of 127.

UARTs don't have addressing, so you would need either 3 UARTs (which the AVR doesn't have), or add external logic to switch between UART lines (which costs money). Each additional slave means extra cost. Not recommended.
edit
Like Chris says you can use UART to create a multidrop bus. And then you'll have to add addressing, which makes your UART work a bit like I2C, but then asynchronous, and without address matching hardware like the I2C has. So still not really an advantage. end of edit

SPI also uses shared lines for data: a single MOSI, and the MISO lines connected. To address each slave individually you'll need one SS (Slave Select) line per slave. So that's at least 5 I/Os: MOSI, SCK, 3 \$\times\$ SS, and MISO if you also want to read data from the slaves. Each additional slave adds 1 I/O pin on the master.

enter image description here

I think the I2C is the best solution, requiring the least number of wires. The protocol is a bit more complex than UART or SPI, but since the AVR has the hardware for it, it should be easy to use.

Best Answer

Related Solutions

USART communication with PIC16F688

Electronic – arduino – multiple arduino communication (1 master, n slaves)

Related Topic