Losing characters on serE

Rabbit
1

Hi Guys,

RCM3700 DC 9.52

I’m using serial port E to communicate with another processor in a hardware subsystem. Baud rate is 57,600, format 8n1.

I want the speed for response times rather than throughput.

At this moment, despite short data strings, I’m losing data. Initially I thought this was likely a problem with the new subsystem, however getting a probe onto it and into HyperTerminal shown the data on the serial lines is OK:

&VER=0.1.0
&VER=0.1.0
&VER=0.1.0
&VER=0.1.0
&LAM.A=999nm
&LAM.B=999nm
&LAM.C=999nm
&LAM.D=999nm
&VER=0.1.0
&VER=0.1.0
&VER=0.1.0
&VER=0.1.0
&VER=0.1.0

The Rabbit however sees, typically:

&VER=0.1.0
&VER=0.1.0
&LAM.A=999nm
&LAM.B=999nm
&LAM.&VER=0.1.0
&VER=0.1.0
&VER=0.1.0
&VER=0.1.0
&VER=0.1.0

Initially I printed the received data using printf() right after the call to cof_serEgets(), later I set RS232_MONITOR_E and the diagnostic output from the .lib confirms the data.

A very short but relevant clip as I can’t cut and paste between two PCs and I have no desire to type it all.

RX-E : 26 4c 41 4d 2e 26 56 45 - &LAM.&VE
RX-E : 52 3d 30 2e 31 2e 30 - R=0.1.0

(Curious … I’ve just noticed that the \cr does not appear in that, though It’s definitely in the data stream and it appears in the TX-E prints … probably a bug in the diag printing)

BTW the same Rabbit also has another serial port mostly TXing at 57,600, TCP (no traffic right now), some SPI stuff and some ADCs.

I’m wondering, of course, if anyone has experience of this, a solution, or a suggestion.

Thanks,
Gordon.

2

Data format should read 8n2 not 8n1
No \cr is sensible as the routine does not return it.

3

Ah, OK.

This is largely down to the buffer size being too small for the rate at which the cof_serEgets() is fetching data from it.

EINBUFSIZE made more sensible for quicker data.

G.