full duplex serial questions and serial communication

science_geek

i am·reading the book "making things talk", i am looking at the serial communication part that talks about handshaking·protocol, i would like to learn·more about this with the prop because i am looking at reading several sensors and stuff with multiple props. I was·wondering if the full duplex serial object has a serial buffer, and how often should i check it. my biggest·thing that i dont understand is how to know when to use a serial.rx command to read incoming data so that i·know data is coming in to the prop.·

Mike Green

The FullDuplexSerial object does have a buffer. It comes set up for 16 bytes in each direction, but can be easily increased to any power of 2 up to 256. The FullDuplexSerialPlus version comes with a 128 byte buffer for each direction and can be easily changed.

There's also a 4 port serial driver in the Object Exchange ("Multiple Serial Port Driver"). Download it and have a look at the description in the comments. It has some provisions for automatic handshaking.

There are several receive calls like RX, RXCHECK, RXTIME. RXCHECK returns a -1 if there's no character available in the buffer (or the received character). RXTIME does the same thing, but waits up to a specified time (in milliseconds) before giving up.

StefanL38

Hello Science_geek,

the buffers of FullduplexSerial and FullduplexSerial are FIFO-Buffers. This means first in first out
Whenever a byte is sended to the propeller the byte will be stored in the receivebuffer.
If the buffer is full the oldest byte will be overwritten by the newest byte that comes in.

example

a 16 byte-buffer has received ABCDEFGHIJKLMNOP
and you did NOT read out the buffer yet.

now a "1" is sended to the prop
after receiving the "1" the buffer looks like this 1BCDEFGHIJKLMNOP

now a "2" is sended to the prop
after receiving the "2" the buffer looks like this 12CDEFGHIJKLMNOP

whenever you READOUT a byte from the buffer the buffer gets emptier

a 16 byte-buffer has received ABCDEFGHIJKLMNOP
and you did NOT read out the buffer yet.

If you read out ONE byte by calling .rx the buffer contains still ABCDEFGHIJKLMNOP
but as you have readout the "A" there is one byte place for a new byte to receive

if a "1" is sended it is stored here 1BCDEFGHIJKLMNOP
but as you already read out the "A" it doesn't matter anymore that the "A" in the buffer gets overwritten by the "1"

You can experiment yourself with this if you add a method READOUT_rx_buffer to the Fullduplexserial-object

then send some bytes readout bytes by using READOUT_rx_buffer call .rx and read out bytes again by using READOUT_rx_buffer to see what changes are made to the buffer

If you don't know how to do that make a first try on your own or ask a concrete question here.
Concrete questions about a detail are MUCH easier to answer then global questions.

And to answer on concrete questions about a detail are MUCH MORE FUN than global questions.

best regards

Stefan

Nick Mueller

> the buffers of FullduplexSerial and FullduplexSerial are FIFO-Buffers.

It actually is a circular buffer!


Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

science_geek

in the example that stefan should, i have one more question in response to nick, you say circular so does that mean that instead of 1bcdefghijklmnop it would actually be bcdefghijklmnop1

<insert aggregate>

·

Mike Green

Circular just means that the subscripts wrap around. If you make the buffer 8 bytes long, the subscripts go 0,1,2,3,4,5,6,7,0,1,2,3,... The code is written so there's a pointer that tells where to insert the next byte and there's another pointer that tells where to remove the next byte and both wrap around. The code makes sure that the "remove" pointer never passes the "insert" pointer. When the two pointers are the same, the buffer is empty.