coldfire uart question

coldfire uart question

[Angelo Dureghello]

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.

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.

Since mcf54415 has a 4 slots RX fifo UART, i was wondering
if the mcf.c uart driver is not fast enough to read the data,
or, where the "linux" limitation could be.

Regards,
Angelo Dureghello

Re: coldfire uart question

[Finn Thain]

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 was wondering if the mcf.c uart driver is not fast enough to read the 
> data, or, where the "linux" limitation could be.
> 
> Regards,
> Angelo Dureghello
> -- 
> 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
> 

Re: coldfire uart question

[Greg Ungerer]

Hi Angelo,

On 16/10/17 03:28, 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.
> 
> 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).

Check if you are getting overruns on the port:

  cat /proc/tty/driver/mcf

Regards
Greg



> The same 1024 bytes transfer in u-boot (y-modem)
> always succeed.
> 
> Since mcf54415 has a 4 slots RX fifo UART, i was wondering
> if the mcf.c uart driver is not fast enough to read the data,
> or, where the "linux" limitation could be.
> 
> Regards,
> Angelo Dureghello
> -- 
> 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
> 

Re: coldfire uart question

[Angelo Dureghello]

Hi Greg and all,

On 16/10/2017 01:57, Greg Ungerer wrote:
> Hi Angelo,
> 
> On 16/10/17 03:28, 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.
>>
>> 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).
> 
> Check if you are getting overruns on the port:
> 
>    cat /proc/tty/driver/mcf

thanks, yes, you are right

/ # cat /proc/tty/driver/mcf
serinfo:1.0 driver revision:
0: uart:ColdFire UART mmio:0xFC060000 irq:90 tx:4047 rx:1057 oe:8 RTS|DTR|CD
1: uart:ColdFire UART mmio:0xFC064000 irq:91 tx:0 rx:0 CD
2: uart:ColdFire UART mmio:0xFC068000 irq:92 tx:0 rx:0 CD
3: uart:ColdFire UART mmio:0xFC06C000 irq:93 tx:0 rx:0 CD
/ #

I am at 115200,n,8,1 now.

I checked the u-boot driver and there is no interrupt handler,
only a coldfire_serial_getc checking USR_RXRDY.

Could the RxFIFO_Full interrupt flag be of any help ?



> 
> Regards
> Greg
> 
> 

Regards,
Angelo

> 
>> The same 1024 bytes transfer in u-boot (y-modem)
>> always succeed.
>>
>> Since mcf54415 has a 4 slots RX fifo UART, i was wondering
>> if the mcf.c uart driver is not fast enough to read the data,
>> or, where the "linux" limitation could be.
>>
>> Regards,
>> Angelo Dureghello
>> -- 
>> 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
>>
> 

Re: coldfire uart question

[Angelo Dureghello]

Hi Finn,

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.
> 

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.

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

Regards,
Angelo

Re: coldfire uart question

[Finn Thain]

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
> 
> 

Re: coldfire uart question

[Geert Uytterhoeven]

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

--
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

Re: coldfire uart question

[Angelo Dureghello]

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
> 

Re: coldfire uart question

[Greg Ungerer]

Hi Angelo,

On 18/10/17 07:18, 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.
>>
> 
> 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.
> 
> I am at 115200, will try to decrease, and also, will try zmodem in case.

Can you use hardware flow control (the "crtscts" stty setting)?
You will need to use a serial cable with RTS and CTS signals wired,
and also for the sending end to be set for it. The ColdFire UART
has hardware level support for automatically driving RTS/CTS when
FIFO is full.

Regards
Greg

Re: coldfire uart question

[Angelo Dureghello]

Hi Greg,

On 18/10/2017 09:12, Greg Ungerer wrote:
> Hi Angelo,
> 
> On 18/10/17 07:18, 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.
>>>
>>
>> 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.
>>
>> I am at 115200, will try to decrease, and also, will try zmodem in case.
> 
> Can you use hardware flow control (the "crtscts" stty setting)?
> You will need to use a serial cable with RTS and CTS signals wired,
> and also for the sending end to be set for it. The ColdFire UART
> has hardware level support for automatically driving RTS/CTS when
> FIFO is full.
> 

many thanks for the hint, well for stmark2 board unfortunately/stupidly i
didn't wired them out from the BGA package. But good to know.

> Regards
> Greg
>

  
Regards,
Angelo
> 
> 

Re: coldfire uart question

[Philippe De Muyter]

Hi all,

it seems that mcf54415 has uart DMA support (https://community.nxp.com/thread/304877)
could you use that ?

Philippe

On Wed, Oct 18, 2017 at 09:19:52AM +0200, Angelo Dureghello wrote:
> Hi Greg,
>
> On 18/10/2017 09:12, Greg Ungerer wrote:
>> Hi Angelo,
>> On 18/10/17 07:18, 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.
>>>>
>>>
>>> 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.
>>>
>>> I am at 115200, will try to decrease, and also, will try zmodem in case.
>> Can you use hardware flow control (the "crtscts" stty setting)?
>> You will need to use a serial cable with RTS and CTS signals wired,
>> and also for the sending end to be set for it. The ColdFire UART
>> has hardware level support for automatically driving RTS/CTS when
>> FIFO is full.
>
> many thanks for the hint, well for stmark2 board unfortunately/stupidly i
> didn't wired them out from the BGA package. But good to know.
>
>> Regards
>> Greg
>>
>
>  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

Re: coldfire uart question

[Finn Thain]

On Wed, 18 Oct 2017, Angelo Dureghello wrote:

> Ok will do some test, maybe also adding 1 stop bit

Adding a stop bit or two will marginally reduce the effective data rate 
but it could be that 115200 baud is unrealistic.

> or killing some processes may help ? I am already into initramfs, so the 
> write should not be that heavy.

I take it you mean storing into rootfs. So the latency is caused by some 
other interrupt source (not flash storage) with higher priority than the 
uart irq...

> Will try also zmodem in case.
> 

Keep in mind that a larger block size would mean a larger penalty for a 
single overrun, which can reduce throughput.

-- 

> Regards,
> Angelo
>