Fast Pic to pic messaging.

Started by holopoint.rm August 4, 2003
Hey guys.
I need to send one byte between two PICs very quickly and lots of
time per second. Whats the best way to do this ?
Parallel connection of two ports ?
Serial and UART ?
What do you think ?



parallel would definately be faster, you don't have to stream it (8 times faster not counting code overhead). As long as you have the pins to do it..
-----Original Message-----
From: holopoint.rm [mailto:h...@rocketmail.com]
Sent: Monday, August 04, 2003 9:44 AM
To: p...@yahoogroups.com
Subject: [piclist] Fast Pic to pic messaging.

Hey guys.
I need to send one byte between two PICs very quickly and lots of
time per second. Whats the best way to do this ?
Parallel connection of two ports ?
Serial and UART ?
What do you think ?


to unsubscribe, go to http://www.yahoogroups.com and follow the instructions

">Yahoo! Terms of Service.




> parallel would definately be faster, you don't have to stream it (8
times
> faster not counting code overhead). As long as you have the pins to
do it.. Ok, so here is what I plan. The sensor pic does its magic and comes
up with a number, a byte. this byte is smeared on one of it's ports,
thats connected parallel to the main PIC. The main PIC samples
this port whenever it feels like it. All is well.
Or is it ?
What happens if the main pic samples the port mid change ?
OR - when writing a byte to a port, are all the pins changed
at once, or is there a noticeable delay ?

Thanks.



On Tuesday 05 Aug 2003 7:16 am, holopoint.rm wrote:
> > parallel would definately be faster, you don't have to stream it (8
>
> times
>
> > faster not counting code overhead). As long as you have the pins to
>
> do it.. > Ok, so here is what I plan. The sensor pic does its magic and comes
> up with a number, a byte. this byte is smeared on one of it's ports,
> thats connected parallel to the main PIC. The main PIC samples
> this port whenever it feels like it. All is well.
> Or is it ?
> What happens if the main pic samples the port mid change ?
> OR - when writing a byte to a port, are all the pins changed
> at once, or is there a noticeable delay ?
>
There is a small but finite probability that the main PIC will receive corrupt
data. To avoid this, get it to take samples until it gets three in a row the
same.

Ian


"Been there - done that"

It "takes a ton" of programming to land this. You must ensure that data is complete, and handshake riguously, or there is a high risk of lost or corrupt data. This is - believe me -quite complex.

Add checksum, preferably allocate separate handshaking pins (/portA (?)) in both dierctions. /Sven
----- Original Message -----
From: Ian Bell <>
To: <>
Sent: Tuesday, August 05, 2003 10:12 AM
Subject: Re: [piclist] Re: Fast Pic to pic messaging. - How to sync ? > On Tuesday 05 Aug 2003 7:16 am, holopoint.rm wrote:
> > > parallel would definately be faster, you don't have to stream it (8
> >
> > times
> >
> > > faster not counting code overhead). As long as you have the pins to
> >
> > do it..
> >
> >
> > Ok, so here is what I plan. The sensor pic does its magic and comes
> > up with a number, a byte. this byte is smeared on one of it's ports,
> > thats connected parallel to the main PIC. The main PIC samples
> > this port whenever it feels like it. All is well.
> > Or is it ?
> > What happens if the main pic samples the port mid change ?
> > OR - when writing a byte to a port, are all the pins changed
> > at once, or is there a noticeable delay ?
> >
> There is a small but finite probability that the main PIC will receive corrupt
> data. To avoid this, get it to take samples until it gets three in a row the
> same.
>
> Ian >
> to unsubscribe, go to http://www.yahoogroups.com and follow the instructions
>
> ">http://docs.yahoo.com/info/terms/





> It "takes a ton" of programming to land this. You must ensure that
data is complete, and handshake riguously, or there is a high risk of
lost or corrupt data. This is - believe me -quite complex.
>
> Add checksum, preferably allocate separate handshaking pins (/portA
(?)) in both dierctions.
>

Thanks for the input.
I only need one direction, sub PIC to main PIC,
and I don't care about lost data, but corrupt data is a killer.
Checksum in an excellent idea.
Thanks,
Shachar.




I may have missed the part about which PIC but if you use the larger
devices such as the 16F877 there is a Parallel Slave Port. the
sensor PIC would put data on its PORTD (output) which would be wired
to the input PORTD of the 'master'. Then the sensor PIC would wiggle
the CS' and WR' signals of the master to clock the data into the
master. An interrupt is generated within the master.

See section 3.6 of the datasheet.

Looks straight forward to me.

--- In , "holopoint.rm" <holopoint@r...> wrote:
> > It "takes a ton" of programming to land this. You must ensure
that
> data is complete, and handshake riguously, or there is a high risk
of
> lost or corrupt data. This is - believe me -quite complex.
> >
> > Add checksum, preferably allocate separate handshaking pins
(/portA
> (?)) in both dierctions.
> >
>
> Thanks for the input.
> I only need one direction, sub PIC to main PIC,
> and I don't care about lost data, but corrupt data is a killer.
> Checksum in an excellent idea.
> Thanks,
> Shachar.





This is what I would do, someone might have a better idea.. shrug.
 
What you might want to do to avoid the chance of reading the port in the middle of an update to the port that is outputting is some sort of flow control. I would make it Master PIC dependant. While going to read the port the Master PIC outputs a "1" on a "read" pin. The sensor PIC will read that pin an ensure it doesn't write unless that pin is "0".. the master PIC would wait a couple NOP's after setting it's "read" pin so that if they updating of the port was already in progress it would be done by the time you read the data port.
 
If your shy on pins you could multiplex.. I use 74LS138 (or whatever variation suits your fancy) for multiplexing control pins like your "read" pin.. 3 pins become 8 but it takes a little bit more complex code (but its not to much, and its simple).. a trade off. code space and a little performance for more pins..    
 
Charles
-----Original Message-----
From: holopoint.rm [mailto:h...@rocketmail.com]
Sent: Tuesday, August 05, 2003 12:17 AM
To: p...@yahoogroups.com
Subject: [piclist] Re: Fast Pic to pic messaging. - How to sync ?


> parallel would definately be faster, you don't have to stream it (8
times
> faster not counting code overhead). As long as you have the pins to
do it..Ok, so here is what I plan. The sensor pic does its magic and comes
up with a number, a byte. this byte is smeared on one of it's ports,
thats connected parallel to the main PIC. The main PIC samples
this port whenever it feels like it. All is well.
Or is it ?
What happens if the main pic samples the port mid change ?
OR - when writing a byte to a port, are all the pins changed
at once, or is there a noticeable delay ?

Thanks.



to unsubscribe, go to http://www.yahoogroups.com and follow the instructions

">Yahoo! Terms of Service.


> I may have missed the part about which PIC but if you use the larger
> devices such as the 16F877 there is a Parallel Slave Port. the
> sensor PIC would put data on its PORTD (output) which would be wired
> to the input PORTD of the 'master'. Then the sensor PIC would wiggle
> the CS' and WR' signals of the master to clock the data into the
> master. An interrupt is generated within the master.

I'm using 18F452 chips.
Can this garentee data correctness ?
what if the sub pic changes the port while the main pic is
in the interrupt ?
Thanks.




Actually, only the strobe signals will have an effect on the master.
Once the data is latched changes at the source don't matter.

As to how to handle synchronization - well it all depends on how
fast "fast" is. Obviously you can't send data faster than the entire
process on the master - what would be the point? No matter how big
the queue, it would eventually overflow. Unless the data is in
bursts in which case the interrupt routine would simply fetch and
stuff - maybe a few microseconds per byte.

The master could set a bit for the sensor pic to look at when it was
ready for more data. No point in sending data that will flow into
the bit bucket.

So, how fast is "fast"? A couple of thousand times a second is
easily accomplished. A hundred thousand times a second might be a
little much. A million times a second is probably in the realm of
DSP and not PIC. Beyond that and you are on your own. --- In , "holopoint.rm" <holopoint@r...> wrote:
> > I may have missed the part about which PIC but if you use the
larger
> > devices such as the 16F877 there is a Parallel Slave Port. the
> > sensor PIC would put data on its PORTD (output) which would be
wired
> > to the input PORTD of the 'master'. Then the sensor PIC would
wiggle
> > the CS' and WR' signals of the master to clock the data into the
> > master. An interrupt is generated within the master.
>
> I'm using 18F452 chips.
> Can this garentee data correctness ?
> what if the sub pic changes the port while the main pic is
> in the interrupt ?
> Thanks.