Re: coldfire uart question

[Finn Thain <fthain@telegraphics.com.au>]

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:
> > 
> > > Hi all,
> > >
> > > 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.

There seems to be too much interrupt latency to support the line rate. 
(Was that x-modem file transfer going to a storage device? Perhaps try 
sending it to tmpfs or /dev/null.) A line rate of 38400 or 57600 baud is 
probably more realistic.

> I am at 115200, will try to decrease, and also, will try zmodem in case.
> 

You could try transmitting a large number of bytes at full speed, counting 
them at the receiving end, and counting the number of interrupts from IRQ 
source 90 using /proc/interrupts. The bytes per interrupt ratio may 
already exceed 1, so the benefit from adopting the FFULL interrupt may not 
be what you expect.

-- 

> Regards,
> Angelo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
>