PIC and multiple serial devices - Electronic Circuits Projects Diagrams Free

Oznog · 25th May 2005, 05:33 PM

Is there a good way to do multiple PIC devices on a serial bus? They're devices I'd design, so I have an ability to do some nonstandard things.

I assume one PIC could transmit to multiple devices in parallel, and each device would just look for a byte string that tells it the stream is intended for that device or not. Correct?

Now on the other issue is some devices will need to return data. Of course there cannot be two on the bus at the same time. Can the PIC put just its transmitter in tristate and later switch to driving the line while not affecting the receiving portion, without any glitches?

Is this practical?

EdwardM · 25th May 2005, 06:15 PM

Hi Oznog

I've done something along the lines of what you're thinking...

This was with multiple 16F84's (20 of em) where I used RS232 comms from a PC, all the PICs were identical except each had a 'personality' byte numbered from 0 upwards. So each command from the PC addressed a particular PIC which would then respond with a multibyte string. Since the PC was the master and all PICs slaves there was never any contention.

You may want to look at I2C enabled devices which will I think do exactly what you require and a similar scheme to that above could be easily implemented.

Best of Luck

Ed

Oznog · 25th May 2005, 07:35 PM

Thanks, I've actually been using I2C but the cable length is long and will get longer if I add more devices. The PIC has a lot higher current sink capability than the I2C spec requires and thus can drive longer than spec cable lengths, but I'm still pushing it, and can't put an I2C EEPROM on there because it can't sink enough current to meet timing on that cable length.

**Jay.slovak** · 25th May 2005, 08:01 PM

Quote:

Originally Posted by Oznog

Thanks, I've actually been using I2C but the cable length is long and will get longer if I add more devices. The PIC has a lot higher current sink capability than the I2C spec requires and thus can drive longer than spec cable lengths, but I'm still pushing it, and can't put an I2C EEPROM on there because it can't sink enough current to meet timing on that cable length.

What is your planed length of cable? Also do you think that it's not enaugh if PIC is sinking 20mA?

**Nigel Goodwin** · 25th May 2005, 08:56 PM

You could try looking for "PICNET USB", a PIC networking scheme which uses USB, which also includes an older system that uses serial connections.

The link I have here doesn't work at the moment though?.

**Jay.slovak** · 25th May 2005, 09:05 PM

Quote:

Originally Posted by Nigel Goodwin

You could try looking for "PICNET USB", a PIC networking scheme which uses USB, which also includes an older system that uses serial connections.

The link I have here doesn't work at the moment though?.

Uff, USB for 16F84... sounds complicated :lol:

**Nigel Goodwin** · 25th May 2005, 09:12 PM

Quote:

Originally Posted by Jay.slovak

The link I have here doesn't work at the moment though?.

Uff, USB for 16F84... sounds complicated :lol:[/quote]

It's not for the 84, the USB section uses the 16C745 USB PIC, but the older serial version is fine with the 84.

**Jay.slovak** · 25th May 2005, 09:19 PM

Quote:

Originally Posted by Nigel Goodwin

Quote:

Originally Posted by Jay.slovak

Quote:

The link I have here doesn't work at the moment though?.

Uff, USB for 16F84... sounds complicated :lol:

It's not for the 84, the USB section uses the 16C745 USB PIC, but the older serial version is fine with the 84.

OK, that's much better! But isn't that 16C745 an old PIC?

LOL USB and 16F84... :shock:

EdwardM · 25th May 2005, 10:01 PM

Hi Y'all

really it all comes down to the data rate necessary to solve the original problem, if it's simply a matter of taking in data from multiple, slow speed sensors then the data rate can be equally slow. If however, there are a number of subsystems which require action *NOW* then the bandwidth requirement is that much greater and requires every part of the system to be fast or faster. Bearing in mind that PIC's generally have a max clock of a fairly pedestrian 20MHz, let's lay back and smell the coffee

Ed 8)

**Jay.slovak** · 25th May 2005, 10:05 PM

Quote:

Originally Posted by EdwardM

Hi Y'all

really it all comes down to the data rate necessary to solve the original problem, if it's simply a matter of taking in data from multiple, slow speed sensors then the data rate can be equally slow. If however, there are a number of subsystems which require action *NOW* then the bandwidth requirement is that much greater and requires every part of the system to be fast or faster. Bearing in mind that PIC's generally have a max clock of a fairly pedestrian 20MHz, let's lay back and smell the coffee

Ed 8)

What, you think that's slow? That's enaugh for 1Mbit SPI bus... What are the sensors sensing, that it requieres so much bandwidth?

EdwardM · 25th May 2005, 10:10 PM

Hi

Quote:

What, you think that's slow? That's enaugh for 1Mbit SPI bus... What are the sensors sensing, that it requieres so much bandwidth?

Ptah!

I should know already, ask Oznog. But I guess he has a datarate/distance problem

:lol:

Ed

**Jay.slovak** · 25th May 2005, 10:13 PM

Quote:

Originally Posted by EdwardM

Hi

Quote:

What, you think that's slow? That's enaugh for 1Mbit SPI bus... What are the sensors sensing, that it requieres so much bandwidth?

Ptah!

I should know already, ask Oznog. But I guess he has a datarate/distance problem

:lol:

Ed

You know, that the greater distance, the slower datarates are available?

bryan1 · 25th May 2005, 11:38 PM

Hiya Oznog,
Eh mate have ya thought of going wireless? Those 433mhz devices are getting pretty cheap like over here in Oz there only $8 each and there's a heap of info out there to get started. Once I get me shed finished I'll finally be able to start a few projects that are on the back burner and 1 of them a is a wireless system for checking the tank levels for my water storage tanks.( it's too far to walk now knowing I can make sumthing to keep me in front of the footy game and still be working hahaha)

Cheers Bryan

Oznog · 26th May 2005, 07:42 AM

I guess the harness is around 6 ft right now, if I added more devices, it could easily double. I've had it running on I2C for awhile now with some relatively low ohm pullup resistors.

I'm keeping this low power in sleep mode, there is no "off" switch and the bus should be able to wake the part up. I2C line driver chips would probably present a problem here, plus there's just no room on the board. The power consumption when running is not such an issue though.

I can't add the I2C EEPROM with the bus loaded with so much more capacitance than spec though. It's unlikely the EEPROM has enough driving capability that its response would meet the timing spec.

So I was toying with the idea of serial again, which generally should have been the logical choice.

Bandwidth requirement is not so great, I already set it at a lower speed.

**Nigel Goodwin** · 26th May 2005, 08:18 AM

Quote:

Originally Posted by Jay.slovak

OK, that's much better! But isn't that 16C745 an old PIC?

The 17C745 series WERE the only USB PIC's available, although MicroChip have very recently brought out some new 18F FLASH ones.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

25th May 2005, 05:33 PM	(permalink)
Oznog	PIC and multiple serial devices Is there a good way to do multiple PIC devices on a serial bus? They're devices I'd design, so I have an ability to do some nonstandard things. I assume one PIC could transmit to multiple devices in parallel, and each device would just look for a byte string that tells it the stream is intended for that device or not. Correct? Now on the other issue is some devices will need to return data. Of course there cannot be two on the bus at the same time. Can the PIC put just its transmitter in tristate and later switch to driving the line while not affecting the receiving portion, without any glitches? Is this practical?

25th May 2005, 06:15 PM	(permalink)
EdwardM	Hi Oznog I've done something along the lines of what you're thinking... This was with multiple 16F84's (20 of em) where I used RS232 comms from a PC, all the PICs were identical except each had a 'personality' byte numbered from 0 upwards. So each command from the PC addressed a particular PIC which would then respond with a multibyte string. Since the PC was the master and all PICs slaves there was never any contention. You may want to look at I2C enabled devices which will I think do exactly what you require and a similar scheme to that above could be easily implemented. Best of Luck Ed

25th May 2005, 07:35 PM	(permalink)
Oznog	Thanks, I've actually been using I2C but the cable length is long and will get longer if I add more devices. The PIC has a lot higher current sink capability than the I2C spec requires and thus can drive longer than spec cable lengths, but I'm still pushing it, and can't put an I2C EEPROM on there because it can't sink enough current to meet timing on that cable length.

25th May 2005, 08:56 PM	(permalink)
Nigel Goodwin	You could try looking for "PICNET USB", a PIC networking scheme which uses USB, which also includes an older system that uses serial connections. The link I have here doesn't work at the moment though?. __________________ PIC programmer software, and PIC Tutorials at: http://www.winpicprog.co.uk

25th May 2005, 10:01 PM	(permalink)
EdwardM	Hi Y'all really it all comes down to the data rate necessary to solve the original problem, if it's simply a matter of taking in data from multiple, slow speed sensors then the data rate can be equally slow. If however, there are a number of subsystems which require action NOW then the bandwidth requirement is that much greater and requires every part of the system to be fast or faster. Bearing in mind that PIC's generally have a max clock of a fairly pedestrian 20MHz, let's lay back and smell the coffee Ed 8)

25th May 2005, 11:38 PM	(permalink)
bryan1	Hiya Oznog, Eh mate have ya thought of going wireless? Those 433mhz devices are getting pretty cheap like over here in Oz there only $8 each and there's a heap of info out there to get started. Once I get me shed finished I'll finally be able to start a few projects that are on the back burner and 1 of them a is a wireless system for checking the tank levels for my water storage tanks.( it's too far to walk now knowing I can make sumthing to keep me in front of the footy game and still be working hahaha) Cheers Bryan __________________ " The only way to avoid human error is to avoid the use of humans"

26th May 2005, 07:42 AM	(permalink)
Oznog	I guess the harness is around 6 ft right now, if I added more devices, it could easily double. I've had it running on I2C for awhile now with some relatively low ohm pullup resistors. I'm keeping this low power in sleep mode, there is no "off" switch and the bus should be able to wake the part up. I2C line driver chips would probably present a problem here, plus there's just no room on the board. The power consumption when running is not such an issue though. I can't add the I2C EEPROM with the bus loaded with so much more capacitance than spec though. It's unlikely the EEPROM has enough driving capability that its response would meet the timing spec. So I was toying with the idea of serial again, which generally should have been the logical choice. Bandwidth requirement is not so great, I already set it at a lower speed.