Sign in
Search piclist
Subscribe to piclist
piclist by Keywords
12F675 | 16F628 | 16F84 | 16f877 | 16F877A | 16F88 | 18F458 | ADC | AVR | Bootloader | CAN | CCS | CRC | EAGLE | EEPROM | ICD | ICSP | IDE | JDM | LED | Macros | Microchip | MPLAB | PCB-CAD | PIC10F | Pic12f675 | PIC16F84 | PIC16F84A | PIC16F877 | PIC18 | PIC18F452 | PicBasic | PICC | PICSTART | PWM | RS-485 | RS232 | SMT | SPI | UART | USART | USB | Wireless | Wisp628 | Xilinx
Ads
Discussion Groups
Discussion Groups | Piclist | Fast Pic to pic messaging.
A discussion group for the PICMicro microcontroller. Also called the Microchip PIC, this list is dedicated to the use and abuse of this fine, simple, microcontroller. Close to topic posts are welcome, ie. general electronics.
Fast Pic to pic messaging. - holopoint.rm - Aug 4 10:43:00 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 ? |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
RE: Fast Pic to pic messaging. - Charles Douvier - Aug 4 11:00:00 2003
|
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..
|
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Fast Pic to pic messaging. - How to sync ? - holopoint.rm - Aug 5 1:16:00 2003
|
> 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. |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: Fast Pic to pic messaging. - How to sync ? - Ian Bell - Aug 5 3:12:00 2003
|
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 |
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
RE: Re: Fast Pic to pic messaging. - How to sync ? - Charles Douvier - Aug 5 9:56:00 2003
|
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
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: Fast Pic to pic messaging. - How to sync ? - Bert Drake - Aug 5 16:27:00 2003
|
Your handshake needs to be a little better than
that...
The slave (sensor PIC) needs to raise a "ready" pin, to
show it has set data on the other pins. This is raised after the data port is set,
in order to allow the pins to "settle". Then the master raises a "reading" pin, to
indicate it is reading. The slave can't lower the "ready" until the master has
raised the "reading". When the slave sees "reading" it lowers "ready" to indicate
that it saw the "reading", and then the master reads the data. The slave cannot
change the ports until the master lowers "reading", and cannot re-raise "reading" until
the new data is written and the pins settled. Settle time can usually be as little
as one clock cycle.
This "interlocked" signaling cycle insures not only that
the slave doesn't change the data while the server is reading, but that the server doesn't
start a read just as the slave is already dropping the "ready" pin to put more data out
there, resulting in a bad read.
----- Original Message -----
|
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Fast Pic to pic messaging. - How to sync ? - holopoint.rm - Aug 6 1:50:00 2003
|
Good idea, but there is a catch, I don't want the sensor pic to wait for the main PIC to read the data. Old sensor data is worse than bad data (you can detect bad data, sometimes), like I said, missing data is not a problem, but it does need to be up to date. Thats why I liked the simpler shake procedure, the sensor PIC waits only when the main PIC is reading, or even better, it simply aborts writing the data and goes back to work calculating a new magic number. Thanks ! Shachar. > The slave (sensor PIC) needs to raise a "ready" pin, to show it has set data on the other pins. This is raised after the data port is set, in order to allow the pins to "settle". Then the master raises a "reading" pin, to indicate it is reading. The slave can't lower the "ready" until the master has raised the "reading". When the slave sees "reading" it lowers "ready" to indicate that it saw the "reading", and then the master reads the data. The slave cannot change the ports until the master lowers "reading", and cannot re-raise "reading" until the new data is written and the pins settled. Settle time can usually be as little as one clock cycle. > > This "interlocked" signaling cycle insures not only that the slave doesn't change the data while the server is reading, but that the server doesn't start a read just as the slave is already dropping the "ready" pin to put more data out there, resulting in a bad read. |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: Fast Pic to pic messaging. - How to sync ? - Vasile Surducan - Aug 6 2:35:00 2003
|
Using an independent reading-writting buffer (if you want, a fifo, but an ordinary register is enough) the mother pic will read the sensor pic via buffer. The readings will be "noniterlaced" at mother pic reading speed. If the sensor-pic is much faster, then some readings will be lost, if the sensor-pic is much slower than mother-pic, then some values will be readed twice. I think Joe Colquete have something like this on his site. Of course any paralel transmision is pin consumer, so I preffer serial schemes even there are slowest. top 10 wishes, Vasile http://surducan.netfirms.com On Wed, 6 Aug 2003, holopoint.rm wrote: > Good idea, but there is a catch, > I don't want the sensor pic to wait for the main PIC to read the data. > Old sensor data is worse than bad data (you can detect bad data, sometimes), like I said, missing data is not a problem, > but it does need to be up to date. > Thats why I liked the simpler shake procedure, > the sensor PIC waits only when the main PIC is reading, > or even better, it simply aborts writing the data and > goes back to work calculating a new magic number. > > Thanks ! > Shachar. > > > The slave (sensor PIC) needs to raise a "ready" pin, to show it has set data on the other pins. This is raised after the data port is set, in order to allow the pins to "settle". Then the master raises a "reading" pin, to indicate it is reading. The slave can't lower the "ready" until the master has raised the "reading". When the slave sees "reading" it lowers "ready" to indicate that it saw the "reading", and then the master reads the data. The slave cannot change the ports until the master lowers "reading", and cannot re-raise "reading" until the new data is written and the pins settled. Settle time can usually be as little as one clock cycle. > > > > This "interlocked" signaling cycle insures not only that the slave doesn't change the data while the server is reading, but that the server doesn't start a read just as the slave is already dropping the "ready" pin to put more data out there, resulting in a bad read. > > > to unsubscribe, go to http://www.yahoogroups.com and follow the instructions |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Fast Pic to pic messaging. - Will Serial do the trick ? - holopoint.rm - Aug 6 4:20:00 2003
|
> Using an independent reading-writting buffer (if you want, a fifo, but an > ordinary register is enough) the mother pic will read the sensor pic via > buffer. The readings will be "noniterlaced" at mother pic reading speed. > If the sensor-pic is much faster, then some readings will be lost, if the > sensor-pic is much slower than mother-pic, then some values will be readed > twice. I think Joe Colquete have something like this on his site. > Of course any paralel transmision is pin consumer, so I preffer serial > schemes even there are slowest. Can this be done in serial ? I need the sensor pic to send bytes to the main pic. but I don't want these byte to accumulat in the UART old data is bad news for me. Is there a way to control the size of the UART buffer ? but even that wont do it. I don't want a buffer at all. When the main PIC does a getc() I want it to get the last byte sent. Is this even possible ? Thanks. PS. Do you have Joe's site URL ? |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
RE: Re: Fast Pic to pic messaging. - Will Serial do the trick ? - Wouter van Ooijen - Aug 6 4:39:00 2003
|
> I need the sensor pic to send bytes to the main pic. > but I don't want these byte to accumulat in the UART > old data is bad news for me. Is there a way to control > the size of the UART buffer ? but even that wont do it. > I don't want a buffer at all. When the main PIC does a getc() > I want it to get the last byte sent. Is this even possible ? loop until there is nothing left in the buffer? Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Fast Pic to pic messaging. - Will Serial do the trick ? - rtstofer - Aug 6 7:22:00 2003
|
Again, look at the parallel slave port. It does everything you ask, the data is always atomic (no partial reads), a buffer overflow is detectable (even if you don't care), the sensor PIC doesn't need to query the master at all since skipped samples are unimportant and, so long as the master only reads the port once during the processing of the data, it will always use the latest and greatest as of the time the data is read. This widget was MADE to do what you are proposing. --- In , "Wouter van Ooijen" <wouter@v...> wrote: > > I need the sensor pic to send bytes to the main pic. > > but I don't want these byte to accumulat in the UART > > old data is bad news for me. Is there a way to control > > the size of the UART buffer ? but even that wont do it. > > I don't want a buffer at all. When the main PIC does a getc() > > I want it to get the last byte sent. Is this even possible ? > > loop until there is nothing left in the buffer? > > Wouter van Ooijen > > -- ------------------------------------------- > Van Ooijen Technische Informatica: www.voti.nl > consultancy, development, PICmicro products |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Fast Pic to pic messaging. - Will Serial do the trick ? - holopoint.rm - Aug 6 7:49:00 2003
|
> Again, look at the parallel slave port. It does everything you ask, > the data is always atomic (no partial reads), a buffer overflow is > detectable (even if you don't care), the sensor PIC doesn't need to > query the master at all since skipped samples are unimportant and, so > long as the master only reads the port once during the processing of > the data, it will always use the latest and greatest as of the time > the data is read. > > This widget was MADE to do what you are proposing. This is definitely the first option to investigate, I still don't understand how it works, what buffer ? Time to breakout the docsheet. |
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: Fast Pic to pic messaging. - amg amg - Aug 6 8:22:00 2003
|
That sounds like conflicting info to me.
Old data is bad, yet if you miss some (new) data that's no problem?
amg
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: Fast Pic to pic messaging. - Will Serial do the trick ? - Vasile Surducan - Aug 7 6:34:00 2003
|
On Wed, 6 Aug 2003, holopoint.rm wrote: > > Using an independent reading-writting buffer (if you want, a fifo, but an > > ordinary register is enough) the mother pic will read the sensor pic via > > buffer. The readings will be "noniterlaced" at mother pic reading speed. > > If the sensor-pic is much faster, then some readings will be lost, if the > > sensor-pic is much slower than mother-pic, then some values will be readed > > twice. I think Joe Colquete have something like this on his site. > > Of course any paralel transmision is pin consumer, so I preffer serial > > schemes even there are slowest. > > Can this be done in serial ? > I need the sensor pic to send bytes to the main pic. > but I don't want these byte to accumulat in the UART > old data is bad news for me. Is there a way to control > the size of the UART buffer ? but even that wont do it. > I don't want a buffer at all. When the main PIC does a getc() > I want it to get the last byte sent. Is this even possible ? > > Thanks. > PS. Do you have Joe's site URL ? This one ? Actually PIC - Scenix, but would work with 2 x PIC http://home.clear.net/nz/pages/joecolquitt/452+573.html |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: Fast Pic to pic messaging. - Will Serial do the trick ? - Vasile Surducan - Aug 7 6:43:00 2003
|
> On Wed, 6 Aug 2003, holopoint.rm wrote: > > > > Using an independent reading-writting buffer (if you want, a fifo, but an > > > ordinary register is enough) the mother pic will read the sensor pic via > > > buffer. The readings will be "noniterlaced" at mother pic reading speed. > > > If the sensor-pic is much faster, then some readings will be lost, if the > > > sensor-pic is much slower than mother-pic, then some values will be readed > > > twice. I think Joe Colquete have something like this on his site. > > > Of course any paralel transmision is pin consumer, so I preffer serial > > > schemes even there are slowest. > > > > Can this be done in serial ? > > I need the sensor pic to send bytes to the main pic. > > but I don't want these byte to accumulat in the UART > > old data is bad news for me. Is there a way to control > > the size of the UART buffer ? but even that wont do it. > > I don't want a buffer at all. When the main PIC does a getc() > > I want it to get the last byte sent. Is this even possible ? > > > > Thanks. > > PS. Do you have Joe's site URL ? > > > > This one ? Actually PIC - Scenix, but would work with 2 x PIC > > http://home.clear.net/nz/pages/joecolquitt/452+573.html iacs! the real one is: http://home.clear.net.nz/pages/joecolquitt/452+573.html |
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: Fast Pic to pic messaging. - How to sync ? - John Remington - Aug 7 10:47:00 2003
|
why have the reading pic wait while the sensor pic is writing? The read will either be one or the other. Even if the bit flips during the read, the reading chip will see it as either a one or a zero. I would just update the ports on the fly, scan the ports when-ever, and get what I get. No hand-shaking required. --- "holopoint.rm" <> wrote: > Good idea, but there is a catch, > I don't want the sensor pic to wait for the main PIC to read the > data. > Old sensor data is worse than bad data (you can detect bad data, > sometimes), like I said, missing data is not a problem, > but it does need to be up to date. > Thats why I liked the simpler shake procedure, > the sensor PIC waits only when the main PIC is reading, > or even better, it simply aborts writing the data and > goes back to work calculating a new magic number. > > Thanks ! > Shachar. > > > The slave (sensor PIC) needs to raise a "ready" pin, to show it has > set data on the other pins. This is raised after the data port is > set, in order to allow the pins to "settle". Then the master raises > a "reading" pin, to indicate it is reading. The slave can't lower > the "ready" until the master has raised the "reading". When the > slave sees "reading" it lowers "ready" to indicate that it saw the > "reading", and then the master reads the data. The slave cannot > change the ports until the master lowers "reading", and cannot > re-raise "reading" until the new data is written and the pins > settled. Settle time can usually be as little as one clock cycle. > > > > This "interlocked" signaling cycle insures not only that the slave > doesn't change the data while the server is reading, but that the > server doesn't start a read just as the slave is already dropping the > "ready" pin to put more data out there, resulting in a bad read. __________________________________ |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
RE: Re: Fast Pic to pic messaging. - How to sync ? - Charles Douvier - Aug 7 11:11:00 2003
|
He is
reading a full byte and doesn't want old or corrupt data. One bit up near MSB makes a lot
of difference.
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: Fast Pic to pic messaging. - Will Serial do the trick ? - Ian Bell - Aug 7 11:15:00 2003
|
On Wednesday 06 Aug 2003 10:20 am, holopoint.rm wrote: > > Using an independent reading-writting buffer (if you want, a fifo, but an > > ordinary register is enough) the mother pic will read the sensor pic via > > buffer. The readings will be "noniterlaced" at mother pic reading speed. > > If the sensor-pic is much faster, then some readings will be lost, if the > > sensor-pic is much slower than mother-pic, then some values will be > > readed twice. I think Joe Colquete have something like this on his site. > > Of course any paralel transmision is pin consumer, so I preffer serial > > schemes even there are slowest. > > Can this be done in serial ? > I need the sensor pic to send bytes to the main pic. > but I don't want these byte to accumulat in the UART > old data is bad news for me. Is there a way to control > the size of the UART buffer ? but even that wont do it. > I don't want a buffer at all. When the main PIC does a getc() > I want it to get the last byte sent. Is this even possible ? You really do need to think in a bit more depth about exactly what performance you expect from this set up before anyone can make a sensible answer to this sort of question. We really need some idea of the rate at which the sensor pic will send data and also some idea of what the main pic needs to do with it. In general you seem to have a sensor pic that will produce data at some variable rate and a main pic that needs to receive it and presumably act upon it. A classic solution to this problem is to have a circular buffer at each end. At the sensor pic, new data is simply added to a circular buffer. An interrupt routine extracts data from this buffer on a regular basis and sends it to the main pic. The main pic has an interrupt routine triggered by data received whcih just places the data in another cicular buffer. The main pic main application takes this data out of the buffer when it needs it. Provided in the long term the main pic can keep up with the sensor pic and the buffers are large enough, no data will be lost. Ian |
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )