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