----------------------------------------
Date: Sun, 14 Aug 2011 16:25:35 +0200 From: albert.u.boot@aribaud.net To: programassem@hotmail.com CC: u-boot@lists.denx.de Subject: Re: [U-Boot] Question about interrupt-driven mode duart on MPC837xE-rdb board.(with the subject)
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. From the perspective of our manager, more things to handle, more possible to go wrong,
So, there is NO any OS, even real-time OS.
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.
Actually, not modifying but referencing, we have source code of our own written by ourself.
(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.
yeah, I agress with you. It's just an example to show what we do.
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.
Yes, this is the point. And you are right. For this question, I won't ask for answers or suggestions on the list again. I will try in another way to solve this question. Many thanks, anyway.
So many thanks for the help.
You're welcome. Sorry not to be able to get any further.
Amicalement,
Albert.