Aftermarket ECU & RT OS

[Pat Ford]

 Get a cheap used laptop, and use that as your starting point, then chose 
os's. I did that, and made a digital dash as well.

Previously, you (DIY_EFI Digest) wrote:
{ 
{ DIY_EFI Digest        Wednesday, March 29 2000        Volume 05 : Number 129
{ 
{ 
{ 
{ In this issue:
{ 

{ 	Re: Aftermarket ECU & RT OS
{ 	RE: aftermarket ecu etc...
{ 	Re: aftermarket ecu etc...
{ 	Re: aftermarket ecu etc...

{ 
{ Date: Wed, 29 Mar 2000 08:58:55 -0800
{ From: Randall <randallyoung at earthlink.net>
{ Subject: Re: Aftermarket ECU & RT OS
{ 
{ Hi Paul :
{ 
{ No, but I have looked at other UNIX variants with "real time
{ extensions".

 Have you looked at QNX?

{  For what I do (which has nothing to do with EFI or engine
{ management), they are just way too slow,

Hmm you didn't look at qnx!

{ and take too much processor. 

386, 2M flash( or 1.44M floppy) 6M ram

{ It's possible that Linux would make sense, for a "one of a kind"
{ homebrew, but you'd want to see some hard figures on worst-case
{ interrupt latency, task switch, etc.  

 Linux wouldn't be my choice there are priority inversion problems

eg
 serial port driver ( running at a low priority)
  -> higher priority process wants to write(or read) to serial and blocks
  a 3rd process that has a priority somewhere between the two gets to run
 as it's priority is higher then the serial driver that the highest priority
 process is blocked on. 

{ 
{ Part of the issue is that "real-time" means different things to
{ different people.  Most of the UNIX enhancements I've seen concentrate
{ on things like adding task priorities (which is certainly important),
{ but do little to address things like worst-case task switch.  Whether
{ you can live with that depends a lot on what your requirements are.

 design issues the rt-linux extension runs the os(kernal) as a task
and the rt stuff behind the back of the kernal, works fine UNTIL an rt
task needs a kernal call, then you are back to regular linux performance

{ 
{ Frankly, IMO a complex operating system always adds complexity to the
{ project.

 Or can simplify it, a true microkernal os is easier to use then setting up
an mmu, task switchers... and is small ( ~34K for QNX4.25)

{  If you don't need that complexity (and I don't see it as being
{ required for engine management/EFI),

 protected mode programming is almost always worth the extra thought 

{ why bother ?

reliability, testing, and with QNX posix api's

{  To put it another
{ way, there's a lot to be said for the KISS (Keep It Simple, Stupid)
{ principle <g>

 true BUT an rtos doesn't need to add complexity, if properly chosen
it should sheild you from complexity

{ 
{ Cheers
{ Randall
{ 
{ Corner Paul wrote:
{ > 
{ > Hi Randall
{ > 
{ > Have you looked at Linux - there are Real Time patches available.

 I have, its almost as good as RT-NT or embedded NT ( 64Mb ram for an 
embedded system, yea right!)

{ > 
{ > Regards, Paul


{ 
{ Date: Wed, 29 Mar 2000 11:44:00 -0500
{ From: dave.williams at chaos.lrk.ar.us (Dave Williams)
{ Subject: RE: aftermarket ecu etc...
{ 
{ - -> There is also no reason you can't "roll yer own" : use DOS (or
{ - -> equivalent) to load your program image into memory, then grab all the
{ - -> interrupts and the machine is yours.
{ 
{  Tom Wagner's CTASK multitasking library for C does polled and
{ pre-emptive tasking under DOS.  Very small, more features than you can
{ shake a register at, thoroughly documented and debugged, widely used,
{ and free.  What more could you ask?

cool url please?



--
Pat Ford                           email: pford at qnx.com
QNX Software Systems, Ltd.           WWW: http://www.qnx.com
(613) 591-0931      (voice)         mail: 175 Terence Matthews          
(613) 591-3579      (fax)                 Kanata, Ontario, Canada K2M 1W8

----------------------------------------------------------------------------
To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org