Hello all,
I am considering designing a generic user interface using a color TFT and a
modern processor to replace a series of analog and first generation
microcontroller instruments, and am considering the pros and cons of uClinux.
The application is networked sensing, and is as such not very complicated.
However, one of the reasons for moving up to new technology is to be able to
support new field busses (and the nice look and feel, of course).
Ethernet-based stuff is fairly easy to do using the TCP/IP-stack on Linux, and
the framebuffer support for the ColdFire TFT-interface could also be a
timesaver. I have done userland and small embedded processors for 5 years, but
have no experience in kernelhacking. Also, I have not yet invested in a
ColdFire-board.
My main doubt is that I need to support an RS422-based "old-school" fieldbus,
too, for which the system will have to start answering within a fairly small
window of 143-380 us after the last byte of the request has been received. The
best figure for latency I have been able to find is 5-8 us using RTAI on
ColdFire, but a lot more - up to tens of milliseconds - on kernel 2.4.
I am aware that this is of course heavily dependent on the system configuration
and on which features are enabled in the kernel (seemingly with IDE one of the
worst offenders), but can anyone give a handwaving answer of what is possible?
One of the selling points for the generic 2.6 kernel is that it is more
pre-emptable, which would make this situation lots better.
I have been able to find several approaches to the problem in the archives and
on the net. In September 2004, there was a discussion of this on the list where
a guy had some problems with buffer overruns in the UARTs. The solution brought
forward by Greg Ungerer was to implement a high-priority interrupt which
bypassed Linux and the scheduler completely. It would probably solve the
problem, but if it is already solved in 2.6 such that everything can be done in
userspace (on a lightly loaded system), it would be really nice. RTAI also
seems to be able to solve the problem, but ColdFire (or uClinux, for that
matter) is not on the list of supported stuff on their homepage, and I am
unsure how to approach that problem. Finally, I have the option of using a
small dedicated communication coprocessor, but that would be giving up,
wouldn't it ;-)
Can anyone help me figure out how much hacking is needed to keep interrupt
latency below, say, 40 microseconds for the vast majority of serial character
interrupts?
Best Regards,
/Niels Holmgård Andersen
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
