[LEDE-DEV] Serial data getting lost - bug or a feature?
valent at otvorenamreza.org
Fri Oct 27 00:45:51 PDT 2017
Thanks Jay for very detailed answer.
You reminded me about Ymodem and Zmodem that I used when I was a
studetn to tranfer apps to my HP48+ calculator, but which I still own!
We do have our own protocol that does block transfers of 30 lines at a
time, and it has crc check for each line so it is not an issue for us,
but more a curiosity.
But to now we were using OpenWrt CC and didn't have any issues in
serial transfer, not we are starting to deploy devices with Lede we
noticed this issue with wifi causing serial communication issues.
So I'm really interested in getting to root cause of this.
> ---------- Forwarded message ----------
> From: Jay Carlson <nop at nop.com>
> To: Valent Turkovic <valent at otvorenamreza.org>
> Cc: Piotr Dymacz <pepe2k at gmail.com>, LEDE Development List <lede-dev at lists.infradead.org>
> Date: Fri, 20 Oct 2017 11:09:27 -0400
> Subject: Re: [LEDE-DEV] Serial data getting lost - bug or a feature?
> On 2017-10-18 Wed, at 06:32, Valent Turkovic <valent at otvorenamreza.org> wrote:
>> So if wifi is active, in sta mode but not associated to AP then serial
>> communication is having issues and is loosing characters when
>> receiving them.
> Regardless of this poor behavior, I think you're going to regret it eventually if you don't have some kind of checksum and retransmit logic--implying you're also doing framing. Async serial lines can be tricky, and have non-zero bit error rates. And the framing mechanism needs to be resilient against incomplete packets (meaning, bytes dropped between transmitter and receiver).
> Newline-separated ASCII records with a hex CRC are not the worst idea, but you need to deal with the situation where a newline gets lost, or you get trash or fewer bytes than you needed. I've used YMODEM before for bulk data.
> Note that the Arduino Yún uses packets.
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
More information about the Lede-dev