Re: coldfire uart question

[Angelo Dureghello <angelo@sysam.it>]

Hi Geert and Finn,

On 18/10/2017 08:37, Geert Uytterhoeven wrote:
> On Wed, Oct 18, 2017 at 2:06 AM, Finn Thain <fthain@telegraphics.com.au> wrote:
>> On Tue, 17 Oct 2017, Angelo Dureghello wrote:
>>> On 16/10/2017 01:08, Finn Thain wrote:
>>>> On Sun, 15 Oct 2017, Angelo Dureghello wrote:
>>>>> i was trying a file transfer with xmodem-1k and uClinux "rx" on the
>>>>> mcf54415 stnmark2 board side.
>>>>>
>>>>> This using a recent mainline kernel:
>>>>> / # cat /proc/version
>>>>> uClinux version 4.14.0-rc4stmark2-001-00118-g811fdbb62a9d
>>>>> / #
>>>>>
>>>>> So, as per xmodem-1k, i send 3 bytes header, a 1024 bytes block, and
>>>>> 2 bytes crc16. But "rx" timeouts waiting the block.
>>>>>
>>>>
>>>> What is the fastest baud rate that will work?
>>>>
>>>>> Adding some traces to "rx", it timeouts since some bytes (5 to 10)
>>>>> randomly positioned in the block are not received. Of course they
>>>>> have been sent (scope checked).
>>>>>
>>>>> The same 1024 bytes transfer in u-boot (y-modem) always succeed.
>>>>>
>>>>
>>>> Does u-boot need to do any retransmissions? (If it polls the UART, it
>>>> could probably avoid any fifo overflow.)
>>>>
>>>> You may also want to try lrzsz.
>>>>
>>>>> Since mcf54415 has a 4 slots RX fifo UART,
>>>>
>>>> Ouch. At 115200 baud, that FIFO overflows after about 347
>>>> microseconds. If the kernel takes one interrupt per 4 bytes, you're
>>>> looking at thousands of interrupts per second. Add a little unexpected
>>>> interrupt latency (say, 50 microseconds) and the next byte gets lost.
>>
>> I should have said "86 microseconds", to guarantee an overflow, but the
>> margin is lower than that even on an idle system, because time is lost in
>> interrupt dispatch. This margin is the same whether the interrupt happens
>> after one byte or four bytes.
>>
>>> thanks for explaining this.
>>>
>>> Well, if i understand properly, this mcf54415 CPU has 2 interrupts flags
>>> that can be checked: RXRDY, for one or more character received (current
>>> mcf.c seems to use this flag) and FFULL, for all 4 fifo slots full.
>>>
>>> So we probably have even more interrupts per second right now.
>>
>> Even if you can reach 4 bytes per interrupt, the payoff is probably a
>> reduction in CPU overhead due to interrupt load rather than a reduction in
>> FIFO overflows.
> 
> In addition, if you already have FIFO overflows (of the remaining 3 entries)
> in between the issuing of the interrupt and the actual interrupt handling,
> you will have them for sure if you make the hardware issue an interrupt
> only when the FIFO is already full.
> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 

Ok, many thanks for the clarifications, so mainly this is a linux limitation
and seems i have to live whit it. Ok will do some test, maybe also adding 1
stop bit or killing some processes may help ? I am already
into initramfs, so the write should not be that heavy.
Will try also zmodem in case.

Regards,
Angelo


  

> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds
>