Full Duplex Serial object with >256 byte buffer?

Bobb Fwed

I'm looking for a serial object with a buffer of more than 256 bytes. I've been using FullDuplexSerial_rr004 which said it could do 512 bytes when I downloaded it, though the OBEX now [correctly] says it can't. I only need 9600 baud, though it needs to be able to run at 5MHz, so I'm not sure if a SPIN object could handle that.

Mike Green

Use the 4-port serial driver from the OBEX. It's tested with 4 115K ports with a 6MHz crystal so it should do just fine with a single port and a 5MHz crystal. You can easily change the buffer sizes for each of the 4 possible ports. There's a single equate for the size of each ports' RX and TX buffer. Read the comments in the source for details.

Bobb Fwed

Mike Green wrote: »

Use the 4-port serial driver from the OBEX. It's tested with 4 115K ports with a 6MHz crystal so it should do just fine with a single port and a 5MHz crystal. You can easily change the buffer sizes for each of the 4 possible ports. There's a single equate for the size of each ports' RX and TX buffer. Read the comments in the source for details.

Thank you. I will give that one a try!

Mike Green

I reread the comments in the source. The 4x115K with 6MHz crystal is with a 96MHz system clock (PLL=16x). The maximum Baud with an 80MHz system clock is 750K for a single port. You want to use a 5MHz system clock to save power. 80MHz / 5MHz = 16 so you should be able to get 750K / 16 = 46K (roughly) which is well in excess of what you need. Phil's driver also has handshake options and less jitter than the "standard" FullDuplexSerial.

Bobb Fwed

Thanks. I'm probably going to strip the object down a fair bit too. I only need one port, and the 2.7kb price tag is a bit high for our application.

Tracy Allen

If you want to continue with FullDuplexSerial_rr004, I think it is not too much effort to modify that so it can support whatever buffer size you need. Easier than messing with the 4-port object. It doesn't appear that you need the flow control options.

In FullDuplexSerial_rr004, in the pasm code, change two lines.
line 250 is now,

and     t2,#bufmsk

change to

cmpsub     t2,#bufsiz

same thing for line 272, now

and     t3,#bufmsk

change to

cmpsub     t3,#bufsiz

Then in the spin code, change all 3 instances of

& bufmsk

to

// bufsiz

That is in lines 93 (rxcheck) , and lines 117 and 119 (tx(txbyte))
Note that bufmsk is no longer used.
Change bufsiz to whatever value you want. It does not have to be a power of two. As written, the rx and tx buffers are the same size.
The magic is performed by the cmpsub operator, conditional subtract that wraps the pointer back to the start of the buffer.

Bobb Fwed

Tracy Allen wrote: »

If you want to continue with FullDuplexSerial_rr004, I think it is not too much effort to modify that so it can support whatever buffer size you need.

Thanks! Worked like a charm. The new limit with these changes is 511 bytes, but that's fine for what I'm doing. I'll further modify it to separate the buffer sizes, because my tx buffer can be tiny. I only need the larger buffer for incoming messages.

Tracy Allen

If you want to grab a larger chuck of free memory, the cmpsub instructions would have to reference a register rather than a literal constant.
not... cmpsub t3,#BUFSIZ
but... cmpsub t3,bufsiz ' where bufsiz is a register that has been initialized with a value

Can also easily have separate rx and tx buffers. One way to do it,

'snippets...
CON
  BUFSIZRX = 1000     ' for example
  BUFSIZTX = 20

DAT
  rxsize long BUFSIZRX     ' these are default buffer sizes from the CONstants
  txsize long BUFSIZTX     ' loaded into the pasm cog
  ' then follow with the res variables 
  t1 res 1
  ' etc.

' In the PASM ...
line 204...  add     txbuff,rxsize     ' was add txbuff,#bufsiz, note that txbuffer follows immediately after the rx buffer in the hub
line 250...  cmpsub     t2,rxsize     ' value in a register can exceed 511
line 272...   cmpsub     t3,txsize

and the obvious changes to the spin code in lines 93, 117 and 119.

edited.