Communicating between pics

[poohbear]

Hi
I am hoping someone can help me. My colleague is a model train enthusiast and he is wanting to put lots of sensors on his train layout( switching points as well as position of train) there will be around 192 sensors in all, each sensor will be either on or off, he then wants this information to be sent to a led display board ( individual LED's). this could do this by just connecting each sensor to an LED but the amount of wiring is enormous and any future faults would be hard to find. I was wondering if it would be possible to use multiple pic's along with the I2C or similar ( to reduce wiring)

If anyone has any ideas I would be grateful also examples as I have not had much experience of communication between pic's

Regards

Gary

[Benj]

Hi Gary,

I2C is certainly an option as is a serial UART maybe with RS485 to help reduce noise and allow multiple slaves to sit on the bus.

Here is a project where I use TTL UART Serial daisy chained together.
https://www.instructables.com/RGB-LED-P ... ing-Table/

RS485 makes things a bit easier but you have the added expense of the driver IC.

This might help with an overview to I2C.
https://www.matrixtsl.com/blog/simplifi ... c-and-spi/

Here we have an I2C slave example, note it might not work on all devices.
https://www.matrixtsl.com/blog/i2c-slave-coming-soon/

[poohbear]

Hi Ben
Thanks for the reply much appreciated

Gary

[Steve]

With so many on/off sensors, I'd suggest having multiple "slave" chips each directly connected to 8 or 16 sensors. Then connect these slaves to a single "master" chip via a serial bus. Only 2 programs need to be developed - 1 for the master and 1 for the slaves - with all slaves running the same code (but having a different address on the bus). The master would request data from each slave in turn.

If this data is being transmitted to individual LEDs, you could use the same master chip to send the info to another set of slaves which each connect directly to 8 or 16 LEDs. You'd need to create another program for these slaves (again, with different addresses).

I2C is a good option as most chips have the appropriate hardware and it's easy to bitbang if not, and it also scales well. However, the length of the bus cabling could be a limiting factor (I2C is designed for chips communicating within the same PCB), but can be enhanced using a driver.

1-wire is another option. It's slower, but allows for longer cables.

As Ben suggests, RS485 is another option. I'd also consider CAN. Both require external driver chips, but cable length won't be a concern. RS485 is cheaper, but I think you'd need to create your own addressing system. Like I2C and 1-wire, CAN incorporates addressing in its protocol.

Sounds like an interesting project. Hopefully others on this forum have experience or ideas to share...

[LeighM]

Similar to Ben and Steve, a two wire RS485 or single wire-or'd (open collector driver) if data rates are slow.
As a very simple protocol ..
If you connect to an 8 bit UART you have 256 codes or addresses for the slaves
If you reserve 2 codes for on/off you could then use the master to poll each slave address in turn and expect an on or off reply.
A no reply timeout would indicate a disconnected slave.

[Steve001]

Hi Gary

Have a look at Mega points controller's website they have all sorts of devices to do what you wanting to do.
They have lots of documentation i think they communicate via i2C or can bus from memory when i had a nosey at an exhibition

https://megapointscontrollers.co.uk/?v=79cba1185463

Hope this gives you some idea's

Steve

[poohbear]

Hi
Thanks to everybody for the replies it is really appreciated.
I have written a transmit and a receive program which works in a way but it doesn't appear to receive in the order that it is being transmitted. Can someone take a look at the programs and give me some ideas.

Thanks

Gary