Communication with multiple hot swapable peripherals

Thread Starter

David Fowler

Joined Feb 11, 2016
25
Morning Gents, first off let me apologise if coming here with a question on my first post is bad form.

I'm looking for some advice. I'm working on a little project where I'm building a device that will need to speak to a number of hot swapable peripherals. These peripherals could be anything from a sensor, a controller or a display. The idea is that these peripherals can be swapped and changed at will. There're all proprietary devices so I've got complete control over how they communicate but there's the question.

The design requires me to be able to talk to up to eight devices although the solution should be scaleble enough to cope with any number.

All devices are using a 16F690 (no real reason other than that I've got a ton of the little blighters kicking around). The original idea was to use UART and a DEMUX on both TX and RX lines. That works to a point but the line seems to bounce around too much and making it unreliable.

Using a bus based protocol isn't going to work because, as I said these devices are all proprietary and if this project takes off, will be mass produced. I don't really have a way of burning an address into each one individually.

So what are my options? I'm currently thinking of using a 1-wire protocol, connected to each device individually in a star topography. An alternative would be to use a 1-wire bus and a chip select line running to each individual device but I don't really see any advantage to this over the star. But is there a better way to do this?

Things you probably need to know,

  • A number of the peripheral devices have already been built and tested so I would rather not have to make any changes to the physical design if possible although firmware changes are fine.
  • The devices are connected using USB cables so after power, that's 2 lines to play with going to the PICs' UART Tx and Rx pins.
  • All peripheral devices are slaves and like all good children, wont speak unless spoken to.
  • Data transfer rates can all be fairly slow and the kit I'm working on at the moment isn't much more than a hub and doesn't do much else than throw data around so I'm happy to bit bang.
So put your thinking cap on folks, any advice or suggestions for a way forward would be greatly appreciated. And if anyone's got any ideas on having the devices generate a random address on startup so that I can use a bus or some kind of token ring, I've love to hear it.

Thanks all...
 

ericgibbs

Joined Jan 29, 2010
18,766
Using a bus based protocol isn't going to work because, as I said these devices are all proprietary and if this project takes off, will be mass produced. I don't really have a way of burning an address into each one individually.
hi Dave,
Do you have 4 free pins on each 16F690.? , if yes you could use a 4 pole Bit switch to to set the address for that PIC.

E
 

Papabravo

Joined Feb 24, 2006
21,159
You can use a parallel load shift register to read a user configurable number that you can use to establish the devices identity. We did this on DeviceNet all the time. The advantage of a visible switch is that it can be readily verifiable by the plant electrician, and we had a duplicate identifier protocol that allowed an easy fix if that situation ever occurred. Even better, after the shift register was read and disabled the pins could be reused for other purposes. Hot swapping is no problem as long as each device executes the duplicate ID detection protocol on power up or reset.
 

Thread Starter

David Fowler

Joined Feb 11, 2016
25
Thanks guys.

I did think about the DIP switch idea early on but this is going to 'hopefully' end up being released commercially so DIP switch on the peripheral device isn't really going to be an option. Also it would mean a hardware change on the peripherals, which I'm trying to avoid.

Papabravo, you might have just nudged my mind down an interesting new avenue. I like the shift register and was thinking about how to implement it when I came up with a new thought. I've got two data wires going from the hub to the peripheral, one will be on the 1-wire bus the other is going spare at the moment.

So.... the devices are all going to be plugging into a USB slot. So why am I trying to address the devices, themselves, would I not be better addressing the slot? With a spare wire, I could just hook that up to something that will provide the fixed address of the port that it's plugged into on, a cheap PIC would do the job. That way there's no danger of duplicate addresses and the main controller wouldn't need to do any sort of discovery routine. Periodically polling the ports with an 'anyone out there?' message would deal with the hot swapping.
 

JohnInTX

Joined Jun 26, 2012
4,787
So.... the devices are all going to be plugging into a USB slot. So why am I trying to address the devices, themselves, would I not be better addressing the slot? With a spare wire, I could just hook that up to something that will provide the fixed address of the port that it's plugged into on, a cheap PIC would do the job. That way there's no danger of duplicate addresses and the main controller wouldn't need to do any sort of discovery routine. Periodically polling the ports with an 'anyone out there?' message would deal with the hot swapping.
You might also look at something like a 1-wire EEPROM on each slot that identifies the slot. Something like the Microchip 1AA010. Make part of the production test load the EEPROM with the slot number and any other info you might need. The slot number becomes part of the module's address.

You can also make each PIC unique using the SQTP feature on the programmer. Combine that with the slot number and some ID info describing the type of module and each module can be unique.

I've done something like this using an I2C backbone that took unique info about the plug in modules, built a database and assigned addressed dynamically. The SQTP serial number became part of the ID string for address arbitration. But it sounds like you have the comms already? so that may or may not be useful. At any rate, the I2C worked very well using the SSP slave on the PICs. They also waited to be polled by a bus manager.

If you are going to hot-swap, make sure your connector is such that ground / DC common is picked up first (longer pin etc.).

Have fun!
 
Last edited:

Thread Starter

David Fowler

Joined Feb 11, 2016
25
Cheers JohnInTX, that EEPROM would be perfect, much cleaner than using a PIC to provide the address. I've ordered myself a couple of samples to test out.

Comms is going to be using the dallas 1-wire protocol, it's simple and fits my needs nicely.

Great tip on making sure that ground and common connecting first too, that's the reason that I'm using USB connectors.
 

NorthGuy

Joined Jun 28, 2014
611
If these devices are PICs, it'll cost you nothing to insert a unique id into them while programing, because you need to program them anyway.

It is also possible for the devices to negotiate temporary id's when they get connected to network, as, for example, many flavours of CAN networks do.

It is logically impossible for a new device connected to a network to announce itself if it cannot speak unless it's first spoken to. How do you deal with that?

You can, however, let all devices speak at the same time if you use open-drain configuration, such as with I2C or your Dallas 1-wire.

I wouldn't surrender the second line if I already had one. This would bring you to two open-drain lines with pull-ups, which is exactly what you need for I2C. Many PICs have hardware support for I2C, so you could use it.

If your network spans any distance, any protocol based on logic levels will be both slow and unreliable. Differential approach, such as RS-485 or CAN will work much better, although you will have to change your hardware.
 

Thread Starter

David Fowler

Joined Feb 11, 2016
25
Some good thoughts NorthGuy.

I might well look into burning some sort of address into the PICs during programming but I do quite like the idea of addressing the slots, it just seems to make things simpler. The big bonus of having the PICs individually addressed would be that any scaling up of the number of device slots in the future would be dead easy and wouldn't need much of a firmware change.

To deal with adding and removing devices, at the moment I'm thinking of having the master poll each of the slots periodically. With the spec as it is at the moment, that's 8 slots so that wouldn't be a big issue. Although I am trying to accommodate additional slots in the future, I can't see that ever going over, say 20 max.

Cable runs are probably too long for I2C, I want to aim for a max of around about 10m each for the 8 devices although in the real world they're unlikely to go over 5m at most and will probably be mainly between 1m and 2m. If I go with a pre-programmed address on the chip then I'll have a second wire to play with which would open more options and something like RS485 would give me pretty much limitless (at least far more than I'm ever going to get close to with this project) cable runs.
 
Top