----------------------------------------
> Date: Sun, 14 Aug 2011 16:25:35 +0200
> From: albert.u.b...@aribaud.net
> To: programas...@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.
> > >>
> > >> 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.
>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.
                                          
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to