[U-Boot] Question about interrupt-driven mode duart on MPC837xE-rdb board.(with the subject)

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Le 14/08/2011 05:10, shawn Bai a ?crit :

>   >Hi Shawn,
>   >Le 13/08/2011 17:33, shawn Bai a ?crit :
>   >>
>   >>
>   >>  Hello, guys.
>   >>
>   >>  I have 2 questions about duart on MPC837xE-rdb board.
>   >>
>   >>  1. why not implement duart driver in interrupt-driven mode, in addition to polling-mode?
>   >>
>   >>  from the existing implementation of uboot, I find there is only polling-mode duart driver.
> 
>   >Well, why would interrupts be needed for? Remember that U-Boot is not a
>   >multi-tasking OS, but a single-thread bootloader, so we tend to use
>   >interrupts only if there is a good case for it as far as bootloading is
>   >concerned.
> 
>   Well, I see. This is the answer I wanna know for a period of time.
> 
>   Speaking of interrupt-driven mode DUART, it depens on the requirement from upper application.
> 
>   DUART is used in redundant communication. Each end on DUART has no idea when the data from the other
> 
>   end will come. and the cpu time cannot be wasted on waiting, even a little. So interrupt-driven mode
> 
>   DUART is what we want.

Well... If you cannot waste even a little CPU time on waiting for the
UART, that pretty much amounts to saying you cannot work from inside a
bootloader; you need a real-time OS. That's the reason they exist.

>   Actually, not directly based on u-boot, which is referenced often.
> 
>   But the process is very very similar.
> 
>   There is a mainloop in uboot code. Accordingly, in our project, after the boot process, the main()
> 
>   function will also be entered, and cannot return.
> 
>   There is no any OS, and just a while(1){...} loop in the main() function.
> 
>   things are done in the while loop.

This is *even worse* than using a standalone application, because a)
you're heavily modifying U-Boot in a way that it was not designed for,
whereas you could do it with a standalone app, which is the documented
way of doing that kind of thing in U-Boot.

>   >(oh God. Does your code really have this line as you show it?)
> 
>   yes,
> 
>   to reference duart peripheral in mpc837xe-rdb board, structure duart83xx_t defined by uboot is used.
> [...]

I did not mean to doubt the *functionality* of the code, but the
programming style: it uses direct volatile accesses, which are not
welcome in U-Boot where such accesses are provided for with macros; it
uses base+offset style whereas U-Boot mandates C structs; and it uses
magic constants.

>   ensured, which is that do not waste cpu time, and is as real-time as possible.

That in itself is in contradiction with using U-Boot. U-Boot has *no*
reason to be real-time, and even less to provide real-time support to
U-Boot standalone applications.

>   OS is out of our consideration now, and it is not determined by myself.

If it is a question of physical resources, there are real-time OSes out
there with limited footprint. If it is a question of price, there are
free ones too. But one thing is sure: U-Boot is not what you want if you
are required to have real-time -- or you'll have to add the real-time
capabilities yourself, but then, you won't be able to ask for help on
this list, which is devoted to the U-Boot mainline code.

>   So many thanks for the help.

You're welcome. Sorry not to be able to get any further.

Amicalement,
-- 
Albert.