> Has anyone used the interupt driven RS232 comms
> program in microchip AN555 on the 16C84?
>
> From what I can see, it is for the 16C71.
I have used a modified version to work on different pins. Since I couldn't use
the interrupt for the
Receive I used the timer Interrupt (TMR0) to check for Receive Data.
I actually implemented mine fully in the ISR where you simply set a flag when
you have transmit data
available and a flag is set when receive data is available.
I had very little problems making the modifications and getting it to work.
If you have any problems implementing it, let me know and I will see what I can
do to help.
Alan,
Perhaps some more detail would make an interesting thread. I have
been trying various serial protocols to get two PICs (16C84) talking and
am wondering what is the 'best' way. Some of the issues I faced, and I
suppose anyone doing this must face are:
1) How few pins can I get away with?
2) How fast can I go?
3) What is the interrupt mechanism?
My, final design (amatuerish at best), involved timer interrupts, and
flags, perhaps similar to your own. I would be very interested in hearing
what the experts have to say, and also would be interested in any
references for relevent reading material.
Matt
On Mon, 18 Aug 1997, Alan G. Smith wrote:
> > Has anyone used the interupt driven RS232 comms
> > program in microchip AN555 on the 16C84?
> >
> > From what I can see, it is for the 16C71.
> I have used a modified version to work on different pins. Since I couldn't
use
> the interrupt for the
> Receive I used the timer Interrupt (TMR0) to check for Receive Data.
> I actually implemented mine fully in the ISR where you simply set a flag when
> you have transmit data
> available and a flag is set when receive data is available.
> I had very little problems making the modifications and getting it to work.
>
> If you have any problems implementing it, let me know and I will see what I
can {Quote hidden}
Alan,
Have you concidered connection the chips by a one wire serial bus like
the dallas buttons use.
Its very easy to do in code and because only one chip clocks the data
you dont get any suprises while you are doing other things.
You could poll the outer chips in turn to see if they have any thing to
say.
>
> Alan,
> Perhaps some more detail would make an interesting thread. I have
> been trying various serial protocols to get two PICs (16C84) talking and
> am wondering what is the 'best' way. Some of the issues I faced, and I
> suppose anyone doing this must face are:
>
> 1) How few pins can I get away with?
> 2) How fast can I go?
> 3) What is the interrupt mechanism?
>
> My, final design (amatuerish at best), involved timer interrupts, and
> flags, perhaps similar to your own. I would be very interested in hearing
> what the experts have to say, and also would be interested in any
> references for relevent reading material.
>
> Matt
>
> On Mon, 18 Aug 1997, Alan G. Smith wrote:
>
> > > Has anyone used the interupt driven RS232 comms
> > > program in microchip AN555 on the 16C84?
> > >
> > > From what I can see, it is for the 16C71.
> > I have used a modified version to work on different pins. Since I couldn't
> use
> > the interrupt for the
> > Receive I used the timer Interrupt (TMR0) to check for Receive Data.
> > I actually implemented mine fully in the ISR where you simply set a flag
> > you have transmit data
> > available and a flag is set when receive data is available.
> > I had very little problems making the modifications and getting it to work.
> >
> > If you have any problems implementing it, let me know and I will see what I
> can
> > do to help.
> >
> > Good luck!
> >
> > Alan G. Smith
> > +---------------------------------------------------------
> > | Alan G. Smith
> > | agsKILLspampoboxes.com
> > | http://www.innovatus.com/ags
> >
>
> /*****************************************/
> /* Matt Calder, Dept. of Statistics, CSU */
> /* http://www.stat.colostate.edu/~calder */
> /*****************************************/
> I have been trying various serial protocols to get two PICs (16C84)
> talking and am wondering what is the 'best' way. Some of the issues
> I faced, and I suppose anyone doing this must face are:
>
> 1) How few pins can I get away with?
Matt:
Depending on what you're doing, you can get away with
ZERO I/O pins.
For example:
Your Master PIC controls the Slave PIC's MCLR line. The Master
normally keeps the Slave's MCLR line high (out of reset). When
the Master wants to send a message, it pulls the Slave's MCLR
line low, then pulls it high for a short time before pulling it
low, then high again.
The "message" is the time between MCLR-low pulses.
I've glossed over the details, but if you're only sending
messages in one direction, and if your Master only needs to send
a small number of unique messages to the Slave, and if you don't
need the messages to be sent very quickly, this technique can
work real well.
> 2) How fast can I go?
In general, you can trade speed for pins; a one-wire bus, like
the one that Dallas uses in their Touch Memories, is pretty slow
(and complicated when you want to communicate in both
directions).
Two-wire asynchronous protocols allow easy communication in both
directions, but they're slow and (if you don't have any
interrupts) they make it tricky to implement full-duplex
communications.
Two-wire synchronous methods, like I2C, can be relatively fast,
but they don't allow full-duplex bi-directional communications
without a complicated token-passing protocol or something.
Three-wire systems with a clock generated by a Master and data
sent synchronously by each PIC on the other two pins, or a
two-wire system in which the two PICs take turns transmitting
one bit at a time on one data line, can be very fast, but don't
allow the Slave to transmit until the Master gives it a clock.
A system with a clock and data line for each PIC is fast and
allows easy full-duplex operation, but (of course) requires four
pins on each side.
What I'm saying, I guess, is that there IS no "best" way; the
protocol you choose is highly dependent upon the needs of your
application.
=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to: listservspam_OUTmitvma.mit.edu
> Perhaps some more detail would make an interesting thread.
Here is the basic idea that I have:
TMR0 interrupt - set for baud/2
On Interrupt -
Are we in the middle of receiving? - If yes, get next bit. Set TMR0 interrupt
for baud
Else
Are we in the middle of transmitting? - If yes, send next bit. Set TMR0
interrupt for baud
Else
Does the receive pin have a start bit on it? - If yes, set receiving flag.
Set TMR0 interrupt for
baud
Else
Is the TxDataAvail flag set? If yes, send start bit. Set TMR0 interrupt
for baud.
After we finish sending or receiving, we set TMR0 back to baud/2.
In my design, I am using one PIC (the master) to communicate with a PC using
Serial. That allows me to
store "program sequences" in the EEPROM that I have on an I2C bus. The PIC then
can be transitioned
into a "Run" mode with a command over the serial port. At that point, it
interprets the tokens in the
EEPROM and sends commands to the "slave" PICs via I2C. I have found that I2C
works very well for a
slave/master relationship. However, if your slave ever needs to interrupt the
master, then you need to
use additional wires. (If you used one of the PICs with hardware start and stop
bit detection, then
you could do a multi-master scheme.)
I prefer the I2C to have the two processors talk because then I don't have to
worry as much about one
of them being out of synch. Also, I can slow the communications up and down.
> Have you concidered connection the chips by a one wire serial bus like
> the dallas buttons use.
> Its very easy to do in code and because only one chip clocks the data
> you dont get any suprises while you are doing other things.
> You could poll the outer chips in turn to see if they have any thing to
> say.
I actually think the 2 wire protocol is easier, because it isn't as timing
dependent.
And you have the same benefit/drawback where only the master can clock the data.
At 10:23 PM 8/18/97 -0400, Alan G. Smith wrote:
> From what I can see, it is for the 16C71.
>I have used a modified version to work on different pins. Since I
couldn't use
> the interrupt for the
>Receive I used the timer Interrupt (TMR0) to check for Receive Data.
>I actually implemented mine fully in the ISR where you simply set a flag when
> you have transmit data
>available and a flag is set when receive data is available.
>I had very little problems making the modifications and getting it to work.
>
>If you have any problems implementing it, let me know and I will see what
I can
> do to help.
>
>Good luck!
Why couldn't you use the interrupt to check for data received? I've also
been having trouble with RS232/RS485 communications on a 16C74A. It seems
to always send 0x0 when it's not specifically sending something else.
At 04:41 AM 8/19/97 -0800, you wrote:
>> 1) How few pins can I get away with?
>
> For example:
>
> Your Master PIC controls the Slave PIC's MCLR line. The Master
> normally keeps the Slave's MCLR line high (out of reset). When
> the Master wants to send a message, it pulls the Slave's MCLR
> line low, then pulls it high for a short time before pulling it
> low, then high again.
>
> The "message" is the time between MCLR-low pulses.
OK, that's got me interested.. the SLAVE's second job out of reset is to
increment a register, so that next time it comes out of reset, the first
job it has is testing that same register for the message sent to it... So
far so good. What's the approved method of determining if it's a valid
message, or just random powerup garbage?
> Perhaps some more detail would make an interesting thread. I have
> been trying various serial protocols to get two PICs (16C84) talking and
> am wondering what is the 'best' way. Some of the issues I faced, and I
> suppose anyone doing this must face are:
>
> 1) How few pins can I get away with?
> 2) How fast can I go?
> 3) What is the interrupt mechanism?
I'd go with one pin if you can share the oscillator of the PICs! The code
of each PIC can then take the other one into account!
The sender of data should pull down the comm line for a short period of
time to indicate its wish to send. When it releases the bus, the receiver
can ack after few commands for a very short time. If the ack is too long
or is detected _right_after_ the sender released the bus, the receiver is
probably also trying to send something (collision detection).
If the ACK is ok, you can start sending the data. Both PICs are in sync
(the share the same clock), so you can send _very_ fast.
> >> 1) How few pins can I get away with?
> >
> > For example:
> >
> > Your Master PIC controls the Slave PIC's MCLR line. The Master
> > normally keeps the Slave's MCLR line high (out of reset). When
> > the Master wants to send a message, it pulls the Slave's MCLR
> > line low, then pulls it high for a short time before pulling it
> > low, then high again.
> >
> > The "message" is the time between MCLR-low pulses.
>
> OK, that's got me interested.. the SLAVE's second job out of reset is to
> increment a register, so that next time it comes out of reset, the first
> job it has is testing that same register for the message sent to it... So
> far so good. What's the approved method of determining if it's a valid
> message, or just random powerup garbage?
This method sounds dangerously exciting. I guess, glitches and
power up garbage can be filtered by the value of timer.
That is data only valid if the timer is between N1 and N2.
> > Your Master PIC controls the Slave PIC's MCLR line. The Master
> > normally keeps the Slave's MCLR line high (out of reset). When
> > the Master wants to send a message, it pulls the Slave's MCLR
> > line low, then pulls it high for a short time before pulling it
> > low, then high again.
> >
> > The "message" is the time between MCLR-low pulses.
> OK, that's got me interested.. the SLAVE's second job out of reset
> is to increment a register, so that next time it comes out of
> reset, the first job it has is testing that same register for the
> message sent to it... So far so good. What's the approved method of
> determining if it's a valid message, or just random powerup
> garbage?
Bob:
You can do it just as you would with any other communications
protocol... Any of the following techniques, for example, will work:
1. Redundancy: Send the message two or more times and
require that the Slave see consecutive, identical messages
before acting on them.
2. Parity: Send your message, then follow it with a "parity"
message that brings the total time-between-MCLR-low-pulses
time to some constant value.
For example, let's say that your Master only sends one of
two possible messages: One's a 100-millisecond pulse and
the other's a 200-millisecond pulse.
Send your message, then send another pulse whose length is
equal to, say, 300 milliseconds minus the length of the
"message" pulse. The Slave doesn't accept the message
unless it receives two consecutive pulses whose combined
duration is 300 milliseconds.
3. Framing: Send a unique-length "start of message" pulse, then
your message pulse, then a unique-length "end of message"
pulse. The Slave doesn't accept the message unless it sees
the "start" and "end" pulses around it.
=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to: RemoveMElistservTakeThisOuTmitvma.mit.edu
> Can you please help me by tagging a simple RS232 from p.c. to PIC program.??
For anyone who needs SIMPLE Asynchronous Serial I/O look at App Note 510.
Especially at Figure 3 and Figure 4 which have the code snippets that you need.
If you have problems getting this to work, let me know.
Bob Blick wrote:
>
> At 04:41 AM 8/19/97 -0800, you wrote:
> >> 1) How few pins can I get away with?
> >
> > For example:
> >
> > Your Master PIC controls the Slave PIC's MCLR line. The Master
> > normally keeps the Slave's MCLR line high (out of reset). When
> > the Master wants to send a message, it pulls the Slave's MCLR
> > line low, then pulls it high for a short time before pulling it
> > low, then high again.
> >
> > The "message" is the time between MCLR-low pulses.
>
> OK, that's got me interested.. the SLAVE's second job out of reset is to
> increment a register, so that next time it comes out of reset, the first
> job it has is testing that same register for the message sent to it... So
> far so good. What's the approved method of determining if it's a valid
> message, or just random powerup garbage?
I'm interested too! How do you insure that the register does not get
corrupted? Do you save it in EEPROM?
--
Friendly Regards
Tjaart van der Walt EraseMEtjaartwasp.co.za
________________________________________________________
| WASP International http://wasp.co.za |
| R&D Engineer : GSM peripheral services development |
|Vehicle tracking | Telemetry systems | GSM data transfer|
|Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8973 |
| WGS-84 : 26010.52'S 28006.19'E |
|________________________________________________________|
=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to: RemoveMElistservTakeThisOuTspammitvma.mit.edu
> I'd go with one pin if you can share the oscillator of the PICs!
> The code of each PIC can then take the other one into account!
>
> ....
>
> Both PICs are in sync (the share the same clock), so you can send
> _very_ fast.
Marc:
Actually, sharing the oscillator doesn't buy you any speed; you can
go just as fast with separate clocks as you can with a single clock.
=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to: listservSTOPspamspam_OUTmitvma.mit.edu
On 16 Sep 97 at 9:46, unknown667 wrote:
^^^^^^^^
Hey, Unknown667, can you adjust your clock to reality? My mailer is
too stupid to compensate for this time warp. Alternatively, could
you check the Australian papers for this weekend's (23rd August 97,
if its still available) OZ-Lotto numbers. - and post them here I
wouldn't mind sharing the 16million with the other oz members of
piclist... <g>
MikeS
<spamBeGonemikesmith_ozSTOPspamEraseMErelaymail.net>
=== For PICLIST help (including "unsubscribe" instructions),
=== send an e-mail containing the single phrase "help piclist"
=== to: KILLspamlistservspamBeGonemitvma.mit.edu
> Actually, sharing the oscillator doesn't buy you any speed; you can
> go just as fast with separate clocks as you can with a single clock.
Sure it buys you speed. Once you've gotten the two PICs synchronized,
they can exchange unlimitted amounts of data, bidirectionally, at a rate
of 1 byte per 17 clocks (if the ports are located favorably). By
contrast, if you use non-synchronized clocks you couldn't do better than 3
clocks/bit, and even then you'd have to resync yourself at most every 30
bits or so.
> Sure it buys you speed. Once you've gotten the two PICs
> synchronized, they can exchange unlimitted amounts of data,
> bidirectionally, at a rate of 1 byte per 17 clocks (if the ports are
> located favorably). By contrast, if you use non-synchronized clocks
> you couldn't do better than 3 clocks/bit, and even then you'd have
> to resync yourself at most every 30 bits or so.
John:
You can synchronize two PICs to within one instruction-clock cycle of
each other WHETHER OR NOT they share an oscillator.
While a shared oscillator obviates the need for resynchronization, a
two-oscillator system can also do without (frequent) resyncs so long
as the two oscillators are closely matched in frequency.
I assume that your "17-cycle" code (I count 18 cycles, but
that includes the load/store) looks something like this:
BSF STATUS,RP0 ;Setup to send data.
CLRF TRISB^080H ;
RRF PORTB ;Receive a byte and store it in W.
RRF PORTB ;
RRF PORTB ;
RRF PORTB ;
RRF PORTB ;
RRF PORTB ;
RRF PORTB ;
RRF PORTB,W ;
Is that correct? If so, there's a faster way: Since the "favorable"
arrangement of the ports requires that the PORTB0-6 pins be unused
outputs (or outputs that are tied to devices that don't care whether
they're madly toggled whenever you receive a byte, and how common is
THAT?), you might as well dedicate the ENTIRE port to data transfer.
If you do that, your "transfer a byte in each direction" code
becomes:
BSF STATUS,RP0 ;Setup to send data.
CLRF TRISB^080H ;
....
MOVWF PORTB ;Send a byte.
COMF TRISB^080H ;Setup to receive data.
MOVF PORTB,W ;Receive a byte.
=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to: spamBeGonelistservKILLspammitvma.mit.edu
> > I assume that your "17-cycle" code (I count 18 cycles, but
> > that includes the load/store) looks something like this:
>
> Nope. Like this [assuming RB0 is output on each device, RB7 is
> 'the' input, and RB's 1-6 are either unused or are inputs:
>
> rlf Data0,w ; Get C flag
> rlf PORTB
> rlf Data0
> rlf PORTB
> rlf Data0
> rlf PORTB
> rlf Data0
> rlf PORTB
> rlf Data0
> rlf PORTB
> rlf Data0
> rlf PORTB
> rlf Data0
> rlf PORTB
> rlf Data0
> rlf PORTB
> rlf Data0
Ah... I see, John. I misread your message and thought that you
were saying that you could transfer TWO bytes (one in each
direction) in 17 cycles.
Sharing the clock still doesn't give any speed advantage, though.
=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to: TakeThisOuTlistservKILLspamspammitvma.mit.edu
=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to: TakeThisOuTlistservspammitvma.mit.edu
> > > Actually, sharing the oscillator doesn't buy you any speed; you can
> > > go just as fast with separate clocks as you can with a single clock.
>
> and Marc 'Nepomuk' Heuler <RemoveMEPICLISTEraseMEspam_OUTMITVMA.MIT.EDU> replied:
>
> > You need start/stop bits then, or a dedicated clock line.
>
> No, you don't.
How do you want to keep them in sync? The pic speeds may drift.
> No, you don't [need start/stop bits to do very fast (one bit per
> instruction cycle) one-wire data transmission between two PICs,
> each of which is running on its own oscillator].
> How do you want to keep them in sync? The pic speeds may drift.
Marc:
To be fair, the "drift" issue doesn't have anything to do with the
fact that each PIC has its own oscillator; if both oscillators are
highly accurate, drift isn't (much of) a problem.
Just for the sake of argument, though, let's assume that the two
oscillators DO drift, so one PIC can gain or lose a cycle relative to
the other. Is that any different from the situation in which both
PICs share a SINGLE oscillator?
I don't think so... Here's why: If you have two PICs with a single
shared oscillator, you can synchronize them to within one INSTRUCTION
cycle, but you can't sync them to within one OSCILLATOR cycle. Since
one PIC could be starting its "write" quarter-cycle just as the
other's starting its "read" quarter-cycle, a tiny bit of jitter can
cause the two PICs to lose synchronization EVEN THOUGH they share an
oscillator.
=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to: @spam@listservspam_OUT.....mitvma.mit.edu
poboxes.com
