From owner-diy_efi Thu Oct 27 01:20:36 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA00771; Thu, 27 Oct 94 01:20:36 GMT Received: from knuth.mtsu.edu by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA00766; Wed, 26 Oct 94 21:20:33 -0400 Received: by knuth.mtsu.edu (Smail3.1.28.1 #21) id m0r0JVe-000CuVC; Wed, 26 Oct 94 20:20 CDT Message-Id: From: lusky@knuth.mtsu.edu (Jonathan R. Lusky) Subject: Re: Various comments To: DIY_EFI Date: Wed, 26 Oct 1994 20:20:06 -0500 (CDT) In-Reply-To: <9410261753.AA29109@coulomb.eng.ohio-state.edu> from "John S Gwynne" at Oct 26, 94 01:53:38 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1979 Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI John S Gwynne writes: > | be getting Linux in a couple of weeks time. So John, please let me know > | what to do to get gcc running and emitting 68000 code that I can use > | for a simple embedded system. And what do I use for libraries? > > gcc and 68000 -- This is worth the effort to build. I used "m68k-sun-sunos4" > as the target, but I think most people use os3. Let me now when you're ready, > and I can put together some things like libgcc.a. Cool, I built an m68k-sun-sunos4.0.3 crosscompiler (gcc 2.6.0) on my SS2/4.1.3 a few weeks ago (needed to compile ncsa httpd for a customer, they didn't have enough disk space to build gcc). I didn't have any trouble, but I had all of the sun3's include files, and was able to run the float.h builder on the sun3 itself. > libraries -- glibc-1.08.8 (a pre-release) has embedded system support. The > main release is expected after one or two more pre-releases (not out yet). > RTEMS also has the C-library in it, but it's configured for the 68020. (it's > a modified glibc and (I believe) parallels the new glibc embedded support; > its author had a hand in the GNU version). I am porting RTEMS to the 68000 > and what I now call the EFI68k (my 68000 board). I'm about half way through > it (maybe ???). This is a real multi-tasking kernel that I also strongly > recommend. There are some *.ps files on this mail server that describe it. > I hope to have the port finished in a month or so. I tried crosscompiling glibc and threw in the towel. Whats the secret? Of course, I wasn't trying to do an embedded systems version, I was just doing the normal glibc. I ended up stealing the functions 4.0.3's libc.a was missing from a 4.1.1 libc.a "patch". -- Jonathan R. Lusky lusky@knuth.mtsu.edu http://frank.mtsu.edu:8001/~lusky/ (615) 455-9915 ------------------------------------- ------------------------------ 68 Camaro Convertible - 350 / TH350 \_/ 80 Toyota Celica - 20R / 5spd From owner-diy_efi Thu Oct 27 01:29:29 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA00801; Thu, 27 Oct 94 01:29:29 GMT Received: from knuth.mtsu.edu by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA00796; Wed, 26 Oct 94 21:29:18 -0400 Received: by knuth.mtsu.edu (Smail3.1.28.1 #21) id m0r0Je7-000CuNC; Wed, 26 Oct 94 20:28 CDT Message-Id: From: lusky@knuth.mtsu.edu (Jonathan R. Lusky) Subject: Re: Various comments To: DIY_EFI Date: Wed, 26 Oct 1994 20:28:51 -0500 (CDT) In-Reply-To: <9410270116.AA00706@coulomb.eng.ohio-state.edu> from "John S Gwynne" at Oct 26, 94 09:16:34 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1305 Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI John S Gwynne writes: > > -------- > > In message , you write: > > | I'm not sure where mine came from. I know Omega makes some. The are > | just normal K-type thermocouples encased in a thin 12" stainless steel > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > | probe. I'm not sure how much they cost. > ^^^^^ > This doesn't sound like the "pictures" I've seen with bosses welded onto the > manifold holding the thermocouples. Would you elaborate... 12" - why so long? > Is this something you just hold against the manifold to make a measurement? 12" was really excessive, but it was the only size the supplier we bought them from had, and they were a heckuva lot cheaper than Omega. :) We had bosses welded to our headers that were tapped for 1/8" NPT. The probes were about 1/16 diameter and came with compression fittings the screwed into 1/8" NPT. Looks just like the pictures you see in most magazines, except our probes were longer than most peoples :). -- Jonathan R. Lusky lusky@knuth.mtsu.edu http://frank.mtsu.edu:8001/~lusky/ (615) 455-9915 ------------------------------------- ------------------------------ 68 Camaro Convertible - 350 / TH350 \_/ 80 Toyota Celica - 20R / 5spd From owner-diy_efi Thu Oct 27 02:51:38 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA02976; Thu, 27 Oct 94 02:51:38 GMT Received: from localhost.eng.ohio-state.edu by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA02971; Wed, 26 Oct 94 22:51:35 -0400 Message-Id: <9410270251.AA02971@coulomb.eng.ohio-state.edu> To: DIY_EFI Subject: Re: Various comments In-Reply-To: Your message of "Wed, 26 Oct 94 20:20:06 CDT." Date: Wed, 26 Oct 94 22:51:35 -0400 From: John S Gwynne Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI -------- In message , you write: | John S Gwynne writes: | Cool, I built an m68k-sun-sunos4.0.3 crosscompiler (gcc 2.6.0) on my | SS2/4.1.3 a few weeks ago (needed to compile ncsa httpd for a customer, | they didn't have enough disk space to build gcc). I didn't have any | trouble, but I had all of the sun3's include files, and was able to run | the float.h builder on the sun3 itself. ah, but did that system have a mc68881/2 coprocessor? (I bet it did.) If so you would need a soft floating point libgcc.a. Its been a long time since work stations were made without math coprocessors. No big-deal though. Either way you could program the EFI68k over the serial port right now with only three or four more files (loader script, front end stub, ...). | I tried crosscompiling glibc and threw in the towel. Whats the secret? | Of course, I wasn't trying to do an embedded systems version, I was just | doing the normal glibc. I ended up stealing the functions 4.0.3's | libc.a was missing from a 4.1.1 libc.a "patch". secret.... stop working only to eat, drink, and sleep for about four days straight (note: no smilely face). I've compiled it for os4 but ended up with almost every function having a kernel call for things like error handling and heap space allocation. I went back through and extracted only the functions I needed (not many) and removed all the kernel calls. Porting the library in RTEMS looks like the way to go now... I'll let you know. John S Gwynne Gwynne.1@osu.edu _______________________________________________________________________________ T h e O h i o - S t a t e U n i v e r s i t y ElectroScience Laboratory, 1320 Kinnear Road, Columbus, Ohio 43212, USA Telephone: (614) 292-7981 * Fax: (614) 292-7292 ------------------------------------------------------------------------------- From owner-diy_efi Thu Oct 27 03:55:20 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA03545; Thu, 27 Oct 94 03:55:20 GMT Received: from localhost.eng.ohio-state.edu by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA03540; Wed, 26 Oct 94 23:55:17 -0400 Message-Id: <9410270355.AA03540@coulomb.eng.ohio-state.edu> To: DIY_EFI Subject: Answer to: What is a kernel? In-Reply-To: Your message of "Wed, 26 Oct 94 23:48:23 EDT." <9410270348.AA03472@coulomb.eng.ohio-state.edu> Date: Wed, 26 Oct 94 23:55:17 -0400 From: John S Gwynne Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI | Question: what is a kernel? It's like an operating system. It dispatches and organizes the execution of various tasks (a scheduler). It provides a mean for inter-task communication and task isolation. For example, the task controlling injector duration does not need to know how to measure, say, the coolant temp. The kernel periodically runs a task that does that and communicates that value to the injector duration task. It provides a higher degree of isolation and structure to the problem. It also organizes competing task for things like hardware. By the use of semaphores, the resource of an ADC can be allocated to the coolant measurement task, air temp measurement task, O2 sensor measurement task, etc. All of which can run at different rates and be unaware of the others. Bottom line: a large problem like EFI can be broken up into several smaller tasks that may only need a few lines of C-code! It's an alternative to writing one long "loop" of software that must keep track of timing and on which loops to measure what and when to do this or that. The kernel will do all that for you. Ok... It's a luxury... :) John S Gwynne Gwynne.1@osu.edu _______________________________________________________________________________ T h e O h i o - S t a t e U n i v e r s i t y ElectroScience Laboratory, 1320 Kinnear Road, Columbus, Ohio 43212, USA Telephone: (614) 292-7981 * Fax: (614) 292-7292 ------------------------------------------------------------------------------- From owner-diy_efi Thu Oct 27 03:59:05 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA03561; Thu, 27 Oct 94 03:59:05 GMT Received: from fsa.cpsc.ucalgary.ca by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA03555; Wed, 26 Oct 94 23:59:03 -0400 Received: from aa.cpsc.ucalgary.ca (aa.cpsc.ucalgary.ca [136.159.4.5]) by fsa.cpsc.ucalgary.ca (1.8) id ; Wed, 26 Oct 1994 21:58:05 -0600 From: fridman@cpsc.ucalgary.ca (Robert Fridman) Received: by aa.cpsc.ucalgary.ca (1.2; from fridman@localhost) id ; Wed, 26 Oct 1994 21:58:05 -0600 Date: Wed, 26 Oct 1994 21:58:05 -0600 Message-Id: <199410270358.VAA23424@aa.cpsc.ucalgary.ca> To: DIY_EFI In-Reply-To: Wouter de Waal's message of Tue, 25 Oct 1994 10:29:03 +0200 (SAT) Subject: 68HC000 Schematic Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI All the info (hopefully) for John's 68K project is now on our WWW page under projects. For our new members: The diy_efi list has a WWW server located at http://www.cpsc.ucalgary.ca/~fridman/diy_efi. Let me know is you need help getting at it (or if you don't know what WWW is;). I have to say that the hacked PostScript to generate the schematic in multiple pages is way trick;) Enjoy! RF. ------------------------------------------------------------------------- 83 R100 DoD 749 Robert Fridman 71 Super Beetle fridman@cpsc.ucalgary.ca 84 320i From owner-diy_efi Thu Oct 27 06:01:41 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA04457; Thu, 27 Oct 94 06:01:41 GMT Received: from shiva.trl.OZ.AU by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA04452; Thu, 27 Oct 94 02:01:31 -0400 Received: by shiva.trl.OZ.AU id AA02259 (5.65c/IDA-1.4.4 for DIY_EFI@coulomb.eng.ohio-state.edu); Thu, 27 Oct 1994 16:01:18 +1000 From: Craig Pugsley Message-Id: <199410270601.AA02259@shiva.trl.OZ.AU> Subject: Re: EGO clogging. To: DIY_EFI Date: Thu, 27 Oct 1994 16:01:17 +1000 (EST) In-Reply-To: from "Jonathan R. Lusky" at Oct 26, 94 07:58:41 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 702 Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Hi there, > You can do it, for maybe a 100 miles or so before the EGO's are totally > shot. Is this because the sensor gets 'coated' with lead like a catcon, and can take a tank of leaded every now and again without damage, or is it a cumulative effect? Also, two more EGO sensor questions: i/ We all know the 'characteristic curve' of an O2 sensor, but how much effect does the actual exhaust temperature have on it's accuracy, and also does a HEGO have some way of regulating it's temperature? ii/ What about electrical effects changing the sensor's voltage? eg thermocouple effects between the exhaust and the engine. Should the sensor be used in a 'balanced' set-up. Craig. From owner-diy_efi Thu Oct 27 07:14:33 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA04545; Thu, 27 Oct 94 07:14:33 GMT Received: from aztec.co.za by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA04540; Thu, 27 Oct 94 03:14:29 -0400 Received: by aztec.co.za (Smail3.1.28.1 #5) id m0r0P26-000KdmC; Thu, 27 Oct 94 09:13 EET Date: Thu, 27 Oct 1994 09:13:58 +0200 (SAT) From: Wouter de Waal Subject: Re: Various comments To: DIY_EFI In-Reply-To: <9410261753.AA29109@coulomb.eng.ohio-state.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI On Wed, 26 Oct 1994, John S Gwynne wrote: > > | My requirements are that I can use the system at home to play with, as > | well as in the car. This means that I have some widely separate requirements, > | such as an IDE interface and possibly VGA, at least Hercules display, and > | a PC keyboard port. And DRAM. On the other hand I want battery backed up > > Does this mean you will buy, say, a 'PC' video card and plug it into your > board? If so, I've heard this can be fairly difficult to do if your are not > using a 80x86 variant since all 'PC' cards (such as the video card) carries > its own boot-rom. One must read, decode, then re-write a new boot > routine. Most people find it easier to just buy the video chip set and make > their own board. (maybe that's what you meant) (If you do either, I would > like to know.) Apparently Cyliax (If you havn't heard of him, he's a guy that built a 68030 workstation that uses PC VGA & IDE cards, & dram) had problems with DMA and VGA. Yes, you have to rewrite the BIOS. But you have to do that for the "buy a chipset" solution too, and its cheaper to buy a generic VGA card, not to mention the free PCB. But, as you know, I'm a masochist. > > I would agree with Dirk, "Go with a serial port..." If you need more, I would > think about having a 'PC' communicating to the controller (IMHO). Oh, and > don't forget gdb can be configured to work as a remote debugger over the > serial port. No need for the Borland stuff :). Maybe you're right there. gosub Think_Hard_And_Long. But I still want IDE and floppy support, IDE is just a buffer, maybe I should look out for an easy 68K floppy controller circuit. Thanks Wouter From owner-diy_efi Thu Oct 27 12:55:19 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA04881; Thu, 27 Oct 94 12:55:19 GMT Received: from knuth.mtsu.edu by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA04876; Thu, 27 Oct 94 08:55:12 -0400 Received: by knuth.mtsu.edu (Smail3.1.28.1 #21) id m0r0ULp-000CwuC; Thu, 27 Oct 94 07:54 CDT Message-Id: From: lusky@knuth.mtsu.edu (Jonathan R. Lusky) Subject: Re: Answer to: What is a kernel? To: DIY_EFI Date: Thu, 27 Oct 1994 07:54:41 -0500 (CDT) In-Reply-To: <9410270355.AA03540@coulomb.eng.ohio-state.edu> from "John S Gwynne" at Oct 26, 94 11:55:17 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1228 Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI John S Gwynne writes: > hardware. By the use of semaphores, the resource of an ADC can be > allocated to the coolant measurement task, air temp measurement task, O2 > sensor measurement task, etc. All of which can run at different rates and be > unaware of the others. Bottom line: a large problem like EFI can be broken up > into several smaller tasks that may only need a few lines of C-code! > > It's an alternative to writing one long "loop" of software that must keep > track of timing and on which loops to measure what and when to do this or > that. The kernel will do all that for you. Ok... It's a luxury... :) I'm taking Operating Systems right now, just went over semaphores a few weeks ago. We were "told" that semaphore operations (P & V) are pretty expensive respect to cpu cycles. Is that a problem in the real world, or is it insiginificant compred to the number of spare CPU cycles we've got nowadays (with respect to EFI controllers :)? -- Jonathan R. Lusky lusky@knuth.mtsu.edu http://frank.mtsu.edu:8001/~lusky/ (615) 455-9915 ------------------------------------- ------------------------------ 68 Camaro Convertible - 350 / TH350 \_/ 80 Toyota Celica - 20R / 5spd From owner-diy_efi Thu Oct 27 13:42:40 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA05124; Thu, 27 Oct 94 13:42:40 GMT Received: from eigen.ee.ualberta.ca by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA05119; Thu, 27 Oct 94 09:42:37 -0400 Message-Id: <9410271342.AA05119@coulomb.eng.ohio-state.edu> Received: by eigen.ee.ualberta.ca (1.37.109.4/15.6) id AA03434; Thu, 27 Oct 94 07:42:34 -0600 From: Dale Ulan Subject: Re: EGO clogging. To: DIY_EFI Date: Thu, 27 Oct 94 7:42:34 MDT In-Reply-To: <199410270601.AA02259@shiva.trl.OZ.AU>; from "Craig Pugsley" at Oct 27, 94 4:01 pm Mailer: Elm [revision: 70.85] Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI > > i/ We all know the 'characteristic curve' of an O2 sensor, but how much > effect does the actual exhaust temperature have on it's accuracy, > and also does a HEGO have some way of regulating it's temperature? Most HEGO's I've seen hook up to +12v, and they use the positive temperature coefficient of the heating element to regulate the temperature. EGO sensors aren't affected by temperature much for its real 'trip point', but temperature is the largest contributor to voltage variations in the sensor. GM tends to use the voltage level out of the sensor for more than just 'RICH/LEAN', so they use various compensations to predict the O2 sensor temperature. > ii/ What about electrical effects changing the sensor's voltage? eg > thermocouple effects between the exhaust and the engine. Should > the sensor be used in a 'balanced' set-up. Normally, between the block and manifold there's little difference. GM attaches one end of the diff amp (- end) to the engine ground. The other end goes to the O2 sensor. The - end should go to a good engine block ground. The LM1964 is an amplifier designed especially for amplifying O2 sensor signals. It's in National's special purpose devices book (Linear 3). -Dale From owner-diy_efi Thu Oct 27 14:46:30 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA05278; Thu, 27 Oct 94 14:46:30 GMT Received: from abacus.gsfc.nasa.gov by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA05256; Thu, 27 Oct 94 10:46:25 -0400 Date: Thu, 27 Oct 1994 10:52:40 -0400 (EDT) From: Dirk Broer To: DIY_EFI Message-Id: <941027105240.1430@abacus.gsfc.nasa.gov> Subject: Re: Answer to: What is a kernel? Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI I'm going to add my .02... >| Question: what is a kernel? > >It's like an operating system. It dispatches and organizes the execution of >various tasks (a scheduler). It provides a mean for inter-task communication Kernals can be far less - only if its multi-tasking would it have a scheduler. But the question would be "why bother?" if it wasn't multitasking. >and task isolation. For example, the task controlling injector duration >does not need to know how to measure, say, the coolant temp. The kernel >periodically runs a task that does that and communicates that value to the >injector duration task. It provides a higher degree of isolation and >structure to the problem. It also organizes competing task for things like It could also cause the program to be larger and slower - something to be looked at. >hardware. By the use of semaphores, the resource of an ADC can be >allocated to the coolant measurement task, air temp measurement task, O2 >sensor measurement task, etc. All of which can run at different rates and be One thing you can do - you can write your own kernel - very easily in fact. Might I suggest rather than semaphores you go with drivers that have exclusive control over a resource. Less chance of a programming error (did you remember to check and lock and then unlock the resource? What if an interrupt happened at just the wrong time and another string of code tried to lock etc.) >unaware of the others. Bottom line: a large problem like EFI can be broken up >into several smaller tasks that may only need a few lines of C-code! > >It's an alternative to writing one long "loop" of software that must keep >track of timing and on which loops to measure what and when to do this or >that. The kernel will do all that for you. Ok... It's a luxury... :) One big thing to look at is the timing available. Some commercially available kernals don't have provisions for very accurate timing. There are more than a few that say they guarrantee + or - .05 seconds or resolution to 1/10 of a second - maybe not good enough. The problem is the kenel gets an interrupt every lets say 1/10 of a second - it then suspends the current task and then selects the next task to run - and then returns from the interrupt. The question becomes "How many interrupts per second can the hardware support without significantly affecting the task execution?" You'll have to look at your hardware and decide what kind of load it can take. If you have hardware - like a separate chip - that handle ignition timing. And this chip required only a number for timing advance - and the chip controled the spark - then yes telling it every 1/10 of a second will be O.K. Now if your processor can handle 1000 interrupts a second (there will be a spec on how long it takes to service and interrupt) you might make this work without the special chip. All things to consider... Dirk