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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
