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