Shop OBEX P1 Docs P2 Docs Learn Events
Full Dup Object help needed — Parallax Forums

Full Dup Object help needed

T ChapT Chap Posts: 4,198
edited 2006-09-04 01:41 in Propeller 1
I am trying to understand the concept behind the Full Duplex Object. I am able to transmit and receive a byte or string on the same chip, but there are questions remaining regarding buffering. In speaking with Chris yesterday at Tech Support, he explained that the buffer is a 16 byte buffer, and that once its full it doesn't receive anymore until it is "read", thereby moving the head and tail pointers. Well, that all sounds nice, but doesn't compute at all in my dense brain. He said that once you get the byte, it moves the pointers, and that it was a circular buffer.

Here is what I am getting at: I want to send a single byte from a device, maybe another Propeller or an SX chip, and receive it with a Propeller. My receiviung end program is to always be in a "ready state" to receive a byte, as I understand the Full Dup Object already accomplishes. When it receives the byte, the program needs to act on it, interpret it and do something based on the info. Here is an example of the task:

1. if it receives the byte 00000001, the Prop sends out a parallel 4 bit pin assignment(P0-P3) of 0000, and after a pause of 4 ms, it sends out a 10 mS positive going pulse on P4, then resets P4 to 0.

2. if it receives the byte 00000011, the Prop sends out a parallel 4 bit pin assignment(P0-P3) of 0001, and after a pause of 4 ms, it sends out a 10 mS positive going pulse on P4, then resets P4 to 0.

I intend to receive the bytes with the 433 receiver from Parallax, and without having one yet due to backordered status, I belive it will do what I want.

To achieve this task, would my main program have to be constantly looping a test for the RecByte with an if statement like this:

repeat
recbyte := ser.rx
if RecByte := 00000001
outa(0) := 0
outa(1) := 0
outa(2) := 0
outa(3) := 0
waitcnt(cnt + 100000)
outa(4) := 1
waitcnt(cnt + 100000)
outa(4) := 0

if RecByte := 00000011
outa(0) := 0
outa(1) := 0
outa(2) := 0
outa(3) := 1
waitcnt(cnt + 100000)
outa(4) := 1
waitcnt(cnt + 100000)
outa(4) := 0


(Chris suggested a checksum, but that will have to come after I get this much down)

So if this idea is workable, what I need to understand is, if 1 byte comes into a buffer, does the code above retrieve the most recent byte only since it is a 16 byte buffer? Likewise, if I were receiving a string, would the getstring always get the most recent string.

I know this is vague but its the best way I can describe how I perceive what is happening. Hoepfully it will make sense and someone can turn a light on for me.

I'd be happy to pay someone to straighten this out.

Thanks

ps I am aware the formatting got lost in upload.

Comments

  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-09-01 20:16
    Hello,

    ·· For clarification the Full Duplex Serial Object has a 16 byte receive buffer as well as a 16 byte transmit buffer.· Data coming into the receive buffer is added into the buffer at no particular place...The pointers in the serial object keep track of head and tail pointers.· The end-user doesn't need to worry about where the data is as there's a mthod to call for retrieving the data.· What the end-user does need to be aware of is that if data is not retrieved from the buffer before it is full, once it fills additional bytes will be discarded.

    ·· The dynamics of how the buffer works were briefly discussed.· Essentially at anytime the buffer is not full the write routine will add data at the current position of the head pointer...It will then update the position of the head pointer.· Reads from the buffer will update the tail pointer.· But that has no effect on your application.

    ·· I did not understand the need to send an address serially and then send a bit to tell the receiving system that it is okay to use that address at that time or activate something.· If you can control that timing then you should be able to simply send the address or command at the designated time.

    ·· The checksum had to do with the fact that you're referring to a one-way RF system.· The receiver could potentially (and most likely will) receive noise (garbage) and think that it is your address or command data.· You should implement some kind of preamble and/or checksum so that the data receives is known to be valid.· I hope this clarifies what I said.· Take care.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • T ChapT Chap Posts: 4,198
    edited 2006-09-02 06:51
    Well I made some good progress tonight sending and receiving on the same chip, trying to simulate two different systems talking in one direction. I have a test set up with two buttons, and when one is pressed, it sends the byte %00000001, and but2 sends %00000011. These get received back in no problem, and I can use the tv terminal to view the results.

    Update:

    Here is the latest code that works fine for receiving the byte and taking an action based on its value. Pretty simple to most, but I am excited to get it to work.

    Post Edited (originator99) : 9/2/2006 8:33:47 AM GMT
  • T ChapT Chap Posts: 4,198
    edited 2006-09-03 11:30
    Chris

    I have successfully gotten everything to work when sending a byte from the SX to the Propeller using Full Duplex Serial. There is one snag that I can't solve yet:

    repeat
    outa[noparse][[/noparse]Strt] := 1 ' an led test to check if block is looping
    waitcnt(cnt + 400000)
    outa[noparse][[/noparse]Strt] := 0
    getrx 'programs halts here until a byte is rec'd
    term.out($0D)
    if recbyte == %00000001

    As noted the program stops dead at the getrx until I send a byte from the SX. I can send as many bytes as I want and it will loop only as it receives each new byte. If the program didn;t need to do anything else this would not matter, but it would be great to have the program continue looping doing other things as well.

    Thanks for any advice on this

    Todd
  • T ChapT Chap Posts: 4,198
    edited 2006-09-04 01:41
    A little reading inside the Full Dup Object answered my question.
    
    PUB rxcheck : rxbyte
    '' Check if byte received (never waits)        <<<<<<<<<<  Never waits!!
    '' returns -1 if no byte, $00..$FF if byte
    
      rxbyte--
      if rx_tail <> rx_head
        rxbyte := rx_buffer[noparse][[/noparse]rx_tail]
        rx_tail := (rx_tail + 1) & $F
    
    
    PUB rx : rxbyte
    
    '' Receive byte (may wait for byte)        <<<<<< Does wait!  thats why it was stalling
    '' returns $00..$FF
    
      repeat until (rxbyte := rxcheck) => 0
    
    
Sign In or Register to comment.