RS-232 performance

[jonpio]

implemented a serial interface using fcm, as per [url]https://forum.sierrawireless.com/t/simple-uart-echo-program/4739/1] (thanks josepvr) the AT command version in the examples was

I then buffer the uart receive events data in a buffer. this is then read by a timer event running at max rate 18ms.

If I run at 9600bd I expected to see ~18 bytes per timer period, however I seem to see bursts of precisely 56 bytes at random intervals.

If I then change to 115kbd seem to see bursts of precisely 56 bytes at random intervals.

Is this normal ?

[awneil]

@jonpio

Is this normal ?

Yes:

Q2686 UART receive buffer size is limit only 56?

Obviously (well, it should be obvious), the first thing you need to determine is whether the external device is actually transmitting the junk, or if there’s a bug in your software that’s causing the junk to appear. How, exactly, did you obtain those traces? Is the “junk” always at the end of the “good” data like that? It’s not a limitation of the Q26 buffer - it’s just how FCM works. Maybe there’s a bug in your software implementation? Maybe there’s a bug or fault in your hardware - eg,…

FCM and WIP

No, that is not a valid assumption at all. FCM does not know what constitutes a “message” according to your rules - so it cannot tell where you think the message should end. It therefore gathers bytes according to its own rules - which are the only ones it can know - and it tells you how many bytes it has collected. It is up to you to interpret those “chunks” according to your own message rules. No - not necessarily. The FCM data handler tells you precisely how many characters it is passi…

Q2686 UART Buffer size

Where, exactly, in the ADL USer Guide did you read that? I think you are confusing the UART (hardware) with the Flow Control Manager (FCM) - an ADL service? This has nothing to do with the UART hardware - it is in the nature of how FCM gathers received bytes to be delivered to the Data Handler. It would be very inefficient if FCM were to make a Data Handler call on every single received byte…! No, you do not need to - and you can’t, anyhow! You must write your code to receive the data in …

FCM Newby

In fact, it is very much like dealing with a UART with a built-in FIFO - you get an Event when the FIFO is “full”, or when some bytes have been received and it’s not full, but there’s been a sufficient delay with no further characters received.

What's a "block"?

Hi awneil, Sorry for the delayed reply. The block that is received by FCM is nothing but the data that is received over the FCM flow. For instance, if you have subscribed to FCM flow for V24 and have switched the flow to data mode, then whatever your external application (eg. hyperterminal) sends to the module in one go constitutes one block. When the external application sends something to the module, that is received in the UART FIFO buffers. This leads to the generation of an interrupt. No…

[jonpio]

No cigar awneil, I did read the manual

It seems I have 2 devices behaving differently

The one receives 56 bytes at a time significantly slower than the incoming rate, it also often loses first byte & mis behaves at adl_fcmSubscribe()

The other device receives 120 bytes at more or less incoming rate reliably

So it seems to be a firmware issue

Both seem to have some logic going whereby they only pass incoming data when either the buffer is full or some undisclosed inter character timeout.

[awneil]

@jonpio

seem to have some logic going whereby they only pass incoming data when either the buffer is full or some undisclosed inter character timeout.

Yes, I think that is the logic.

[jonpio]

Problem is I need to implement exactly the same logic on my side, however I now need to compensate for the fact that they are doing it.

This means my timeout time must be > than the character time of the full buffer ~ 56ms for a 56 buffer & 120ms for a 120 buffer @ 9600 & any future changes / baud changes

ooh the joys of programming someone else’s API

[awneil]

@jonpio

Problem is I need to implement exactly the same logic on my side

Why?

Can’t you just have FCM writing to a buffer using whatever logic it likes, and your side reading from that buffer using whatever logic it likes?

On of the key uses of “buffers” is to be “elastic” enough to take up the slack like this…