[U-Boot-Users] API for serial functions

[Mike Frysinger <vapier@gentoo.org>]

On Monday 01 October 2007, Stefan Roese wrote:
> Hi Mike,
>
> On Monday 01 October 2007, Mike Frysinger wrote:
> > > While it's not a strict requirement, I would  expect  that  you  wait
> > > until the charatcer has been sent. You have toi add some wait anway -
> > > either  at  the  start  or  at  the end of the function, and from the
> > > debugging point of view it makes more sense to  wait  for  completion
> > > before  continuing.  Performancewise  there  will be no difference, I
> > > think.
> >
> > the optimal performance method would be at the start of serial_putc(),
> > spin until a byte has opened up in the hardware fifo, and then queue it
> > up and return ... in the normal path, the leading spin would probably not
> > execute even once as the hardware can go faster than people can type :)
> >
> > then in the serial_setbrg() function (what does "brg" stand for
> > anyways?), spin until both the fifo and the transmit register are empty
> > so that you dont go changing the baud rate while a character is in the
> > middle of transmission ...
> >
> > the current Blackfin serial driver posts a character into the fifo and
> > then spins until both the fifo and the transmit register is empty ... if
> > there is no higher level API dictacting the requirement (and my quick
> > tests here seem to back that up), then i'll just scrub the code and gain
> > a little bit of speed and lose a few bytes in code size :)
>
> I doubt that you will increase the "performance" notably by removing this
> check in the serial_putc routine. Please keep in mind that U-Boot is a
> bootloader, and while executing "printf" the CPU has nothing else to do.

i'm not claiming this is going to turn a 100mhz proc into 1000mhz proc or 
something, but in the tail end of writing to the UART, you would free up the 
CPU to continue ... and the processor tends to be a lot faster than the speed 
of a UART, so it could chew through a sizable chunk of code before the UART 
finishes shifting out a single byte ... and depending on the hardware, you 
could be talking about 1 byte, 5 bytes, or more

> But you will loose some debug functionality when removing this check, since
> you can't use printf anymore for debugging and really be sure, that the
> received output in your terminal program matches the CPU state.

maybe ... you'd have to mess up the processor pretty bad such that it breaks 
the peripherals ... the UART in a Blackfin acts independently of the core

> So I vote for not removing this transmitter empty check.

i'd note that this is pretty inconsistent across different ports ...

so when do you return ?  after making sure the byte has moved from the core to 
the peripheral hardware ?  after making sure the byte has started to be 
shifted out from the peripheral onto the line ?  after making sure the byte 
has been completed shifted onto the line ?  the current Blackfin serial 
driver exhibits the last -- it waits until the whole byte has gone through 
the whole process, from core through the line
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20071001/29ad1fbc/attachment.pgp