Experiences of serial interfaces
- Thread starter AnWa
- Start date
Well, I'm planning a thing where I need a lot of micro controllers to control LEDs, with a PC delivering updates to the micro controllers. Each controller would receive a message, and change its outputs according to a built-in table. The LED would be lit, softly-flashing or off. (If it wasn't for the flashing, I would just have used shift registers.)
There's not a lot of room and the budget doesn't allow for specialized off the shelf-hardware, so I will have to build it.
There's not a lot of room and the budget doesn't allow for specialized off the shelf-hardware, so I will have to build it.
hippy
Ex-Staff (retired)
Most PC's don't support I2C or SPI which leaves RS232/UART serial, either directly or using a USB-to-serial adapter.
PICAXE chips can easily receive RS232 or UART serial and even up to quite high baud rates. The best to use would be the X2 devices which have Scratchpad memory which allows the serial to be received in the background while the PICAXE is doing something else, such as fading or softly flashing a LED.
PICAXE chips can easily receive RS232 or UART serial and even up to quite high baud rates. The best to use would be the X2 devices which have Scratchpad memory which allows the serial to be received in the background while the PICAXE is doing something else, such as fading or softly flashing a LED.
Buzby
Senior Member
Let the PC talk simple serial to a 'master' chip, then the master sends high level commands via I2C to the slaves.
The X2's have a very clever trick, they can act as I2C slaves. This means the slave PICAXE doesn't need any coms code at all, it just reads data in RAM.
This means the slave PICAXE can be doing whatever flashing and fading its told to, without needing to keep an eye out for incoming commands.
( It is also possible to get a USB-to-I2C dongle, which would let the PC talk I2C directly to the slaves, but I've never tried one, so can't comment on how they work. )
Cheers,
Buzby
The X2's have a very clever trick, they can act as I2C slaves. This means the slave PICAXE doesn't need any coms code at all, it just reads data in RAM.
This means the slave PICAXE can be doing whatever flashing and fading its told to, without needing to keep an eye out for incoming commands.
( It is also possible to get a USB-to-I2C dongle, which would let the PC talk I2C directly to the slaves, but I've never tried one, so can't comment on how they work. )
Cheers,
Buzby
inglewoodpete
Senior Member
Back is 2010, before the PICAXE X2 chips became available, I built a network of 35 PICAXEs. The network was connected to the internet via a PC with an asynchronous serial link to a 40X1. The 40X1 drove a pair of 28X1s via a parallel bus and the 28X1s, in turn, mastered two i2c busses. Each i2c bus hosted 16 28x1 i2c slaves. If built today using PICAXE X2 chips, the job would be slightly simpler.
If you need two-way communication between the master and slaves, then you will not be able to use PICAXE's SPI implementation. It can either read or write with SPI but not both at once. The PICAXE's i2c can read and write to any slave.
The standard i2c bus has a reliability limiation of about 1.2 metres. By using i2c bus extender chips, I was able to have i2c busses up to 14 metres long.
If you need two-way communication between the master and slaves, then you will not be able to use PICAXE's SPI implementation. It can either read or write with SPI but not both at once. The PICAXE's i2c can read and write to any slave.
The standard i2c bus has a reliability limiation of about 1.2 metres. By using i2c bus extender chips, I was able to have i2c busses up to 14 metres long.
AnWa, How many microcontrollers do you plan to have flashing the LEDs and what will be the longest distance between any two of these microcontollers?
lbenson
Senior Member
You might want to check out Kranenborg's "SerialPower" true two-wire data+power network thread. (There might be an updated thread, so I'd search on "SerialPower" with author "Kranenborg".
kranenborg
Senior Member
In your application SerialPower I (two bytes / 16 bits for data) would be perfect, and a 3-wire interface (2 lines for power - as many leds apparently are involved, plus 1 line for serial communications). The 16 bits in the two bytes would provide ample room to identify each led and the action associated with it, and you could use the CalledID byte as well to identify (a group of) leds for even more resolution options. I would suggest to have a look (and test for your self) the examples on the website. I am most willing to help if needed.
The above link in Ibenson's post is the relevant one, in the first item you will find the "official" link to SerialPower I & II: https://www.kranenborg.org/ee/picaxe/twowirenetwork.htm , the page is updated.
I am still curious about more cheezy details on the application though ...
The SerialPower concept is really about a distributed processing system based on Picaxes coupled through a simple serial line. You could easily add sensors to your system as well.
/Jurjen
Last edited: