View previous topic :: View next topic |
Author |
Message |
MotoDan
Joined: 30 Dec 2011 Posts: 55
|
Multi-Slave RS232 |
Posted: Thu Aug 02, 2012 3:01 pm |
|
|
I have multiple slave PICs connected to a single master via the RX/TX UART lines. I'm using the hardware UART and not the soft UART - mainly for the ability to capture master commands via the RDA interrupt. My problem is in floating the slave TX lines. I've tried forcing them off via the TRIS register. I've also tried using the OUTPUT_FLOAT command - neither one will tri-state the TX line. I tried using the FLOAT_HIGH option in the #USE RS232 directive, the compiler won't let you use this option when the hardware UART is selected. My compiler version is 4.132 and the slaves are PIC12F1822's.
TIA,
MotoDan |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Thu Aug 02, 2012 6:40 pm |
|
|
If you use TTL connections:
The MASTER TX can fan out to many, MANY pic RX inputs thru a 5k resistor - to each. This will work well with up to a dozen or so pics.
So long as the slave pics don't speak unless spoken to:
The SLAVES can all have their TX lines joined via a multi stage ( cascaded set of ) positive logic ( 74hct08 /hct21 etc ) AND gate(s) whose final summation output feeds the RX inlet of the MASTER pic. I've done this with 8 slaves, in a 16 way closed loop peristaltic pump controller system where the distances between pics was on the order of a few feet and the baud was 57600. |
|
|
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Fri Aug 03, 2012 1:23 am |
|
|
Its an unconventional use of serial comms. There are transmission standards, RS485 immediately springs to mind, that allow mutli-drop and multi-node comms using serial ports. They require the use of another IO bit or two to select comms direction, but they are designed to work that way, the serial port at TTL levels isn't.
RF Developer |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Fri Aug 03, 2012 2:54 am |
|
|
RF_Developer wrote: | Its an unconventional use of serial comms. There are transmission standards, RS485 immediately springs to mind, that allow mutli-drop and multi-node comms using serial ports. They require the use of another IO bit or two to select comms direction, but they are designed to work that way, the serial port at TTL levels isn't.
|
I'm with RF Dev on this one... RS485 was meant for this... _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Fri Aug 03, 2012 7:50 am |
|
|
re : unconventional ?
GUILTY as charged.
IMB, convention is what you fall back on when creativity fails you.
What I suggested works w/o problems in a shipping product.
If all the circuity is powered in common - in the same cabinet- and - connected via SHORT interconnects cable runs - it works as advertised.
And very well at that - with MINIMAL cost .
RS-485 - is fine if you need mutlti drop connection over considerable distance - but even unit addressing is pretty simple w/o 485 - if you stop and think for a moment. I had no problem implementing it with what i described .
If I was bothered by violating "convention", I would have taken up religion as my main endeavor years ago.
+++++++++++++++++++++
asmboy,
Do not interpret technical observations as personal attacks.
Do not use CCS forum to pontificate.
It's a help forum - treat it as such.
-Forum Moderator
+++++++++++++++++++++
|
|
|
MotoDan
Joined: 30 Dec 2011 Posts: 55
|
|
Posted: Fri Aug 03, 2012 9:46 am |
|
|
Thanks asmboy. Glad to see your out-of-the-box support!
I agree with the others in that RS-485 (among others) is the "conventional" way of master/slave communications. In my case, all of the slave PICs are within 24" of the master so there is no need for transceivers or drivers. I have a total of 10 slaves and there doesn't seem to be a problem having this many TX lines connected together.
Each slave has a unique address and only speaks when spoken to. They simply enable their TX pin when transmitting and disable it when done.
My original post was to seek help in disabling the hardware UART's TX pin. It turns out that you can't do this with a TRIS change. You must also change the state of the TXEN and SPEN registers.
It is also necessary to have a pull-up resistor on the common TX lines to keep things from floating when all slaves are quiet.
Thanks to everyone for their replies.
MotoDan |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Fri Aug 03, 2012 10:00 am |
|
|
MotoDan wrote: |
Each slave has a unique address and only speaks when spoken to. They simply enable their TX pin when transmitting and disable it when done.
My original post was to seek help in disabling the hardware UART's TX pin. It turns out that you can't do this with a TRIS change. You must also change the state of the TXEN and SPEN registers.
It is also necessary to have a pull-up resistor on the common TX lines to keep things from floating when all slaves are quiet.
|
If you're doing addressing over a common bus, why not use I2C then? It's faster than RS232, supported in hardware and already made to do exactly the kind of thing you're doing?
If you stick with RS232, you can change the whole system to an open-drain mode by inserting schottky diodes with the cathode towards the device and then pullups in the middle where you have a single set of R's to pull up to Vcc. That would eliminated all the 74hct08 /hct21 ASMboy mentioned.
The only time the bus drops "low" is when a device pulls it low -- when that device is active high - the diode blocks it from supplying current when another device asserts the bus.
Cheers,
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
MotoDan
Joined: 30 Dec 2011 Posts: 55
|
|
Posted: Fri Aug 03, 2012 10:08 am |
|
|
I2C would have also worked. There are a couple of advantages to using the UART - easy of monitoring and the ability to manually send commands - both done with a simple connection to the PC and the use of a terminal emulator program such as HyperTerm.
I have used the diode method on previous projects, but don't really see then need since the slaves can be turned on/off in software. I tend to prefer the minimal hardware approach whenever possible.
Regards,
MotoDan |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Fri Aug 03, 2012 10:24 am |
|
|
Quote: |
inserting schottky diodes
|
I would not suggest this - as the connection that is left at the receiver input is a Hi-Z node (with some capacitance usually as a bonus).
The cluster of nice HF capable diodes ++ the incoming lead wires ++ a local AM radio station can make trouble of the most random sort.
Diodes offer a nice rectifier for AM radio signals and a swell way to convert radiated interference into conducted EMI on the wiring.
The "and" gates nicely resolve the pullup - disable issue etc
|
|
|
gpsmikey
Joined: 16 Nov 2010 Posts: 588 Location: Kirkland, WA
|
|
Posted: Fri Aug 03, 2012 12:13 pm |
|
|
While you indicate that they are all within 24 inches of each other, in my experience, things never end as they started and you will find someone (or you) needs to add (or move something) that is in another cabinet. I would vote for RS-485 now so that expansion is easy when it happens. TTL over any distance (or around any EMI) is going to be an issue - especially if you are trying to run at any speed.
mikey _________________ mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3 |
|
|
|