Difference between FullDuplexSerial and JDCogSerial
fmaurer
Posts: 4
Hey everyone,
Is there a difference in the rxcheck function of JDCogSerial and FullDuplexSerial?
I need more performance in communicating with my propeller over USB and read that JDCogSerial could do up to 345600 Baud. Since my code only needs to use rxcheck and JDCogSerial implements it, I thought I could simply comment out FDSerial and replace it with JDCogSerial:
Here is FDSerials implementation:
...and this is JDCogSerial's:
However, the prop works fine when using FDSerial but not JDCog. I'm stumped, any ideas? (Note that when I switch between the two, I'm careful to pass the correct amount of arguments eg. FDSerial.Start takes 4 while JD.Start takes 3).
I'm using an FTDI chip to send serial over to the propeller, where the first byte tells the propeller how many bytes to fill the first buffer, then it switches buffers and fills the second one. It continues to switch the pointer like this while a modified DMXout cog converts the filled buffer into DMX signals.
Is there a difference in the rxcheck function of JDCogSerial and FullDuplexSerial?
I need more performance in communicating with my propeller over USB and read that JDCogSerial could do up to 345600 Baud. Since my code only needs to use rxcheck and JDCogSerial implements it, I thought I could simply comment out FDSerial and replace it with JDCogSerial:
'Comm : "Extended_FDSerial" Comm : "JDCogSerial"
Here is FDSerials implementation:
PUB rxcheck : rxbyte
'' Check if byte received (never waits)
'' returns -1 if no byte received, $00..$FF if byte
rxbyte--
if rx_tail <> rx_head
rxbyte := rx_buffer[rx_tail]
rx_tail := (rx_tail + 1) & $F
...and this is JDCogSerial's:
PUB rxcheck : rxbyte
{ Check if byte received (never waits)
returns < 0 if no byte received, $00..$FF if byte }
if (rxbyte := rx1_buf) => 0
rx1_buf := -1
However, the prop works fine when using FDSerial but not JDCog. I'm stumped, any ideas? (Note that when I switch between the two, I'm careful to pass the correct amount of arguments eg. FDSerial.Start takes 4 while JD.Start takes 3).
I'm using an FTDI chip to send serial over to the propeller, where the first byte tells the propeller how many bytes to fill the first buffer, then it switches buffers and fills the second one. It continues to switch the pointer like this while a modified DMXout cog converts the filled buffer into DMX signals.
Comments
OBJ 'Comm : "Extended_FDSerial" Comm : "pcFullDuplexSerial4FC" PUB Main 'Comm.start(31,30, 0, 57600) 'AddPort(port,rxpin,txpin,ctspin,rtspin,rtsthreshold,mode,baudrate) Comm.AddPort(0,31,30,-1,-1,0,0,57600) Comm.Start repeat recByte := Comm.RxCheck(0) if(recByte <> -1) '... save into buffer etc. codeIt seems so straightforward. I'm thinking it has to do with the way rxcheck is working where it doesn't have access to another cog's memory with this new driver?
Here's the complete archive:
USBComm7-bst-archive-110512-222720.zip
I thought it just involves putting a slash in front of some assignment to invert the logic.
I am using FullDuplexSerial_RR04 running at 40Mhz but for some reason I can only achieve around 57600 baud.
This works for me:
CON _clkmode = XTAL1|PLL16X _xinfreq = 5_000_000 OBJ serial: "JDCogSerial" PUB null | c serial.start([COLOR="red"]|<[/COLOR] 31, [COLOR="red"]|<[/COLOR] 30, 115200) ' use pin [COLOR="red"]mask[/COLOR] instead of pin number waitcnt(clkfreq*3 + cnt) repeat repeat while (c := serial.rxcheck) < 0 serial.tx(c) DATOther question: I was talking to a guy at work and he told me that I need to check for parity after I receive a byte. I thought this was handled by the FTDI chip. Is what he's saying that after I do rxcheck I need to check for the parity bit as well? Is there a function in FDSerial for this? This would imply I also need to check framing too...so confused now :frown: