BB_FullDuplexSerial

TomS

What function does the·random seed·play in the repeat loops?· The original version of FDS doesn't use them and seems to work fine.· For example:

repeat while (rxbyte := rxcheck) < 0
     ?long[noparse][[/noparse]def#randomSeed]

It also seems I've found a bug.· Shouldn't the fixed mask in the tx method also vary depending on the size of the buffer?· Mike's code is:

PUB tx(txbyte)
'' Send byte (may wait for room in buffer)
  repeat until (tx_tail <> (tx_head + 1) & $F)
     ?long[noparse][[/noparse]def#randomSeed]
  tx_buffer[noparse][[/noparse]tx_head] := txbyte
  tx_head := (tx_head + 1) & def#txPtrMask
  if rxtx_mode & %1000
    rx

I'm specifically referring to the $F in the repeat loop.



Tom

Mike Green

Tom,
You can leave out the random seed. FemtoBasic has a random function. Both FDS and the keyboard input routines "stir" the seed when waiting to add some randomness to the value.

Thanks for the bug find. I had found and fixed it in my working copies, but I haven't updated the Object Exchange version since February. I'll do it this weekend.

TomS

Mike,

I found what I would call a limitation rather than another bug. The rx buffer size is limited to 32 bytes or smaller (rxBufSize = 1 << 5).· It seems to affect the tx portion of the code.· I haven't attempted to find the problem as I'm not sure it's worth the trouble.· I just thought I'd let you know.· You might want to put a comment in the code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom

Mike Green

Tom,
What are the symptoms? I'm not aware of a problem with the rx buffer size. It should work for any buffer size up to 256 bytes.
Mike

Post Edited (Mike Green) : 4/25/2008 4:03:34 PM GMT

TomS

Mike,
The transmitted stream gets out of order. It looks like the end is transmitted before the beginning.· Actually it looks like the buffer isn't being flushed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom

Post Edited (TomS) : 4/25/2008 4:06:40 PM GMT

Mike Green

Tom,
This is an error in the FullDuplexSerial driver in general. In the transmit assembly code, there's a comparison between tx_head and tx_tail, but the code is actually comparing tx_head and rx_tail. It's strange why this hasn't shown up earlier. I'll fix it in my versions and change my code to support arbitrary sized buffers as well and post the fixes to my versions tonight or tomorrow. You might try fixing it yourself and see if it works better for you.
Mike

TomS

Mike,

Maybe I'm the only one pushing it. I really don't need a large rx buffer but thought I would "kick the tires" so to speak. As in any software project its difficult to test for all possibilties. I'll look for your fixes this weekend.

Thanks

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom

Mike Green

Looking at the FullDuplexSerial code again ... it is correct in the transmit routine. Maybe when I correct the error in the Spin routine, I'll add a comment to clarify what's going on.

Chuck Rice

Mike whatever became of this? I am having troubles with what looks like the tx buffer being overwritten. I was wondering if this was related?

Mike Green

See if this helps ...

Chuck Rice

Thanks Mike. I do not understand the following code:

                        add     t1,#4                 'get buffer_ptr
                        rdlong  rxbuff,t1
                        mov     txbuff,rxbuff         'offset to rx buffer
                        add     txbuff,rxPtrWrap
                        add     txbuff,#1

Is this calculating the address of the tx buffer based on the start and length of the rx buffer?

Mike Green

Yes, it's calculating the address of the tx buffer. I happened to have the mask on hand for the receive buffer and this is the length of the buffer minus one. I could have added another constant that was the actual size of the buffer or I could do this (add size - 1, then add 1).