What would be the easiest way to have multiple 16C84's talk to the same
Max232?
I don't want to use PortB for this, so open drain configuration as
described in one of the Parallax Stamp application notes is out of the
question. At least as far as I can see.
It is crucial to use only one MAX232.
Would this work?
/--------------------+-----[ R2 ]---- VCC
|/c |
PortA.0 -----[ R1 ]-----| |
PIC 1 |\e |
------+-- Max 232 in |
| |
|/e |
Port A.0 ----[ R3 ]-----| |
|\c |
---------------+
>Hi.
>
>What would be the easiest way to have multiple 16C84's talk to the same
>Max232?
>I don't want to use PortB for this, so open drain configuration as
>described in one of the Parallax Stamp application notes is out of the
>question. At least as far as I can see.
>It is crucial to use only one MAX232.
>
>
>Would this work?
Maybe, but what about collision detection? If you have 2 processors
running asynchronously they may tx over one another. If you add a
control line between the networked parts, and tie all the outputs
together you can then have all devices configure their output as an
input, and when they want to send they pull the control line high
(nidicating to the other processors that the max232 is now busy),
switch the tx to an output and transmit, then switch back to an input
and bring the control line back low.
At 03:49 PM 12/9/96 GMT, you wrote:
>On Sun, 8 Dec 1996 20:31:34 +0100, you wrote:
>
>>Hi.
>>
>>What would be the easiest way to have multiple 16C84's talk to the same
>>Max232?
>>I don't want to use PortB for this, so open drain configuration as
>>described in one of the Parallax Stamp application notes is out of the
>>question. At least as far as I can see.
>>It is crucial to use only one MAX232.
>>
>>
>>Would this work?
I am working on a design using soemthing similar. In my application, there
is a master processor on the "network" who controls when each PIC can talk.
All PIC's listen all of the time. The master polls the PIC's for data and
when they have data, they answer within a time window. The plan is to use
one line as the data line and only allow half duplex comms. The PC fits
into my network just like one of the PIC's (it could be the master). Note
that the idle state of the serial port must be a logic high. This means an
inverter for the output and inputs to the serial port (if I remember
correctly). Each device pulls the line low as it sends the data. The
outputs must be open collector.
>Hi.
>
>What would be the easiest way to have multiple 16C84's talk to the same
>Max232?
>I don't want to use PortB for this, so open drain configuration as
>described in one of the Parallax Stamp application notes is out of the
>question. At least as far as I can see.
>It is crucial to use only one MAX232.
Why don't you use PORTA.4 (RA4) which is an "Open Collector" (I presume Open
Drain)? The only extra component required is a pull-up.
Loop
Set HshkOut ; Indicate that you want to Send
if ( HshkIn is Set ) ; Is the Other One Sending/Trying to Send
Reset HshkOut ; Stop the Request
Wait Random Time ; Wait a Random Amount of Time
goto Loop ; Start All Over
Send Character ; Send the Character
Reset HshkOut ; Finished, Release the Resources
This can be implemented easily in PIC assembler. The "Random Time" would be
decided by counting an ansynchronous time interval.
>
>
>Would this work?
> /--------------------+-----[ R2 ]---- VCC
> |/c |
>PortA.0 -----[ R1 ]-----| |
> PIC 1 |\e |
> ------+-- Max 232 in |
> | |
> |/e |
> Port A.0 ----[ R3 ]-----| |
> |\c |
> ---------------+
>
>etc.
>
>I am not good at this, so any help appreciated.
>
>yours,
>Ronald
>
>
Today, the commercial sector is advancing computer and communication
technology at a breakneck pace. In 1992, optical fiber was being installed
within the continental U.S. at rates approaching the speed of sound (if
computed as total miles of fiber divided by the number of seconds in the year).
Aviation Week and Space Technology, October 28, 1996
> On Sun, 8 Dec 1996 20:31:34 +0100, you wrote:
>
> >Hi.
> >
> >What would be the easiest way to have multiple 16C84's talk to the same
> >Max232?
> >I don't want to use PortB for this, so open drain configuration as
> >described in one of the Parallax Stamp application notes is out of the
> >question. At least as far as I can see.
i don't get the point about portB, I'd only like to point out that any
tri-state pin of the PIC can be set to 0, 1 or Hi-Z. Depending on how
you map 1's and 0's you can easily simulate open-drain or open-source
lines.
Luigi
-----------------------------+--------------------------------------
Luigi Rizzo | Dip. di Ingegneria dell'Informazione
email: .....luigiKILLspam@spam@iet.unipi.it | Universita' di Pisa
tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/
_____________________________|______________________________________
>
> On Sun, 8 Dec 1996 20:31:34 +0100, you wrote:
>
> >Hi.
> >
> >What would be the easiest way to have multiple 16C84's talk to the same
> >Max232?
> >I don't want to use PortB for this, so open drain configuration as
> >described in one of the Parallax Stamp application notes is out of the
> >question. At least as far as I can see.
> >It is crucial to use only one MAX232.
> >
> >
> >Would this work?
>
> Maybe, but what about collision detection? If you have 2 processors
> running asynchronously they may tx over one another. If you add a
> control line between the networked parts, and tie all the outputs
> together you can then have all devices configure their output as an
> input, and when they want to send they pull the control line high
> (nidicating to the other processors that the max232 is now busy),
> switch the tx to an output and transmit, then switch back to an input
> and bring the control line back low.
>
IIC Multi Master mode (Look in the Embedded controller handbook)
--
Friendly Regards
Tjaart van der Walt
______________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
|WASP International GSM vehicle tracking and datacomm solutions|
|+27-(0)11-622-8686 | http://wasp.co.za | tjaartKILLspamwasp.co.za |
|______________________________________________________________|
In a message dated 96-12-09 12:03:43 EST, Norm writes:
<< [SNIP] I am working on a design using soemthing similar. In my
application, there is a master processor on the "network" who controls when
each PIC can talk.
All PIC's listen all of the time. The master polls the PIC's for data and
when they have data, they answer within a time window. The plan is to use
one line as the data line and only allow half duplex comms. The PC fits
into my network just like one of the PIC's (it could be the master). Note
that the idle state of the serial port must be a logic high. This means an
inverter for the output and inputs to the serial port (if I remember
correctly). Each device pulls the line low as it sends the data. The
outputs must be open collector.
>>
I've been using the RS-485 protocol for this. For the PICs it works great!!
But---using Visual Basic for Windows, my PC end is problematic as far as
timing goes. I encounter very variable delays - up to 250 msec.) in getting
the PC to respond to the bus. Have you found a good technique for getting a
narrower time window?
At 03:08 AM 12/10/96 -0500, you wrote:
>In a message dated 96-12-09 12:03:43 EST, Norm writes:
>
><< [SNIP] I am working on a design using soemthing similar.
>
>I've been using the RS-485 protocol for this. For the PICs it works great!!
> But---using Visual Basic for Windows, my PC end is problematic as far as
>timing goes. I encounter very variable delays - up to 250 msec.) in getting
>the PC to respond to the bus. Have you found a good technique for getting a
>narrower time window?
I haven't gotten to that point yet. 250 msec sounds very long. Have you
tried other languages other than VB? It's been awhile since I did any VB
programming and never did serial comms. I will be using Visual C++ for the
PC end of the network I'll let you know what delay I end up with.
> In a message dated 96-12-09 12:03:43 EST, Norm writes:
>
> << [SNIP] I am working on a design using soemthing similar. In my
> application, there is a master processor on the "network" who controls when
> each PIC can talk.
> All PIC's listen all of the time. The master polls the PIC's for data and
> when they have data, they answer within a time window. The plan is to use
> one line as the data line and only allow half duplex comms. The PC fits
> into my network just like one of the PIC's (it could be the master). Note
> that the idle state of the serial port must be a logic high. This means an
> inverter for the output and inputs to the serial port (if I remember
> correctly). Each device pulls the line low as it sends the data. The
> outputs must be open collector.
> >>
>
> I've been using the RS-485 protocol for this. For the PICs it works great!!
> But---using Visual Basic for Windows, my PC end is problematic as far as
> timing goes. I encounter very variable delays - up to 250 msec.) in getting
> the PC to respond to the bus. Have you found a good technique for getting a
> narrower time window?
Visual BASIC isn't a proper compiled language, and might be a bit slow.
Also, Windoze 3.1 and 95 are somewhat indeterminate in terms of timing,
I've heard. We are using Windoze NT at work for this reason.
Leon
--
Leon Heller, G1HSM | "Do not adjust your mind, there is
E-mail leonspam_OUTlfheller.demon.co.uk | a fault in reality": on a wall
Phone: +44 (0)118 9471424 | many years ago in Oxford.
eskimo.com http://www.eskimo.com/~nexus
