From bernie at innovative.iinet.net.au Mon Oct 1 02:16:28 2007 From: bernie at innovative.iinet.net.au (Bernd Felsche) Date: Mon, 1 Oct 2007 15:16:28 +0800 Subject: [Bulk] Re: [Diy_efi] Modular approach to EFI controllers In-Reply-To: <1191201618.10850.64.camel@wopr.donegan.org> References: <46FFFE2D.3000307@earthlink.net> <1191191551.30658.6.camel@wirenth> <1191201618.10850.64.camel@wopr.donegan.org> Message-ID: <200710011516.28189@innovative.eye-eye.net> On Mon, 1 Oct 2007 09:20, Steven P. Donegan wrote: > On Sun, 2007-09-30 at 23:32 +0100, ian wrote: > > On Sun, 2007-09-30 at 15:51 -0400, Curtis Richards wrote: > > > In looking for an 'engine' for your design have you considered > > > something like the TiniARM from New micros? > > Our basic design will be a low speed/power ARM doing the houskeeping > > and feeding of an FPGA 'timing controller'. > > the FPGA will handle all the events like spakrk timing etc. as well as > > control over an ADC for the gathering of ion sensing data. > > the ARM will control the parameters fed to the FPGA and process the ion > > sense data read back from it. > As Ian says this is indeed our design - I'm simply looking for a proper > automotive temperature rated MCU at this point. One with a 'lot' of A/D > would be nice we'd like to do more than one channel of ion sensing - > that requires fast A/D converters. These may not be fast enough on their ADC to do it on their own... http://www.atmel.com/products/avr/auto/ Atmel have a new line (AVR32) with on-chip DSP at least in some versions. But I don't know if they're automotive-tolerant. The datasheets are mostly marked "preliminary". http://www.atmel.com/products/AVR32/ You'd probably be more interested in the UC3B microcontroller with DSP than the SP7 kitchen sink. -- /"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | The object of life is not to be on the side of X against HTML mail | the majority but to escape finding oneself in / \ and postings | the ranks of the insane. -- Marcus Aurelius From bill.washington at nec.com.au Mon Oct 1 02:34:53 2007 From: bill.washington at nec.com.au (Bill Washington) Date: Mon, 01 Oct 2007 17:34:53 +1000 Subject: [Diy_efi] Re: Diy_efi Digest, Vol 31, Issue 29 In-Reply-To: <20070929011048.3AC7C7FC9D@ns2.nec.com.au> References: <20070929011048.3AC7C7FC9D@ns2.nec.com.au> Message-ID: <4700A31D.6050801@nec.com.au> Buck, Good on you, a little contentment with what we have achieved can often save a lot of pain ....... and expense! Happy motoring! Back to diesels..... The latest generation of diesels gain their economy and the potential to produce a lot more power because of the ultra high (dangerous) pressure common rail/ electronic injection. This produces much finer atomisation, and thus much more complete burning - ie burning much more of the fuel and spitting less of it out the exhaust. Ian, did you say you were wanting to incorporate this into your 'new' engine intended to get the 'works'? - that would be an extremely interesting project - I would love to add common rail injection to my old 2.3l and 2.5l Peugeot diesels - unfortunately they are indirect injection engines - ie there is a spherical combustion chamber set into the head, and this contains the glowplug and injection point. The piston at TDC comes within a gnat's whisker of the head - the only thing that stops them hitting is the head gasket - the piston (flat top) protrudes above the top of the block at TDC and the head is dead flat ..... valve timing, therefore, is also critical to avoid piston and valves meeting, and making expensive noises! .... but still it would be nice to add common rail.... if only I could afford it and source the parts, including the computer to drive it! ... I'll dream on! Bill >> >> Subject: >> RE: [Diy_efi] water injection >> From: >> Buck Williams >> Date: >> Fri, 28 Sep 2007 18:08:19 -0700 >> To: >> >> >> To: >> >> >> >> yes it can helppp , the rulessss areant hard and fast,, if your engine is capable of makiang more power but your up against ,, the temp limit,,, 1250,1300 and u keep making boostt, you will sortly get to sbe able to see the inside of your engine,somethning all these engines are allergic to, is sunshine,,, let it in, show the internals some sonshine and patooiee,,,,, itsll spsit some of it,, engine parts out where u can look at them,thats why water injectiaon is used, if your pushing powerr,, use a proportionate ammaout of waater to keep the exhaust temps beloww the majic limit, and just maybe u can keeapt feetidning it fuel and air and push it some more,if the engineee has sthe mechanical strangth to coantain the horse beiang made, jsut maybe it wont shsow so much of its ddleeicate internal stuff to the nasy ole shsunshsine,, all thisngs in proportian, not too much air,,,,, not too macuh sfuel,, not too much water,,, look aaroaund,, ask the people whos dioing it,, ask um,,, andangit,,, harold kieernan at mcclure equipmeant in bakersfield calif,,, he and his partnerss are posting a vw pickup to salt flats, industrail diesel engine, 2000 2200 i thaink in rabbit pickup at sloome ungodly speed, i know the basics of how to do it,,, but im more moderateeee builderr, i driveee somsetimess wiwth my littel 250 260 o horse 5.9 and wathc them guys with money run 750, 800 horse multi whoop di do 5,9 with propane,,,, nitroaus poslished, super high coampressiaon gas capped 8 , 10 inches boom tubed,,,,, then i drive home,,,,doesnt mean i dont know hwo they do it,, means i choose not to do it tooo mine,im not knowkding thnose who want more power,, or more fun doing it,,,,,my data plaate says im got 215 horse,,,,, but the dyno siayswith the minor changesss ive done, im making about 255,60, i have the fuel plate for 285, , its still lp htenre onmy shelf, im having too much fun with the 260 i have,again im not knowcking those who are seachaing for more,,, but its like when i came back fraomm biet nam, i quit hunting, now some hve poked fun or gottten angry at me sfor stating this and the usual come back is do i eat hamburger ro protk chops,,, of coaurse ido,, i just dont hunt,, i like the taste of the meant,, i just choose not to climb into a pen full of bulls witha ball peen hammer and try to get my own,, since my straoke imnot sure i make senseeee andy moree,,, hope i didnt get tooo far sastray,, buck, oh i am sometimes interested in pushing some limitss to learn,,,,,, i jsut dont want to push so many limits to learn sometnhng that i thaink i already in my gut a i already know the answer tooo,,,i apologize now if i have been perhaps misunderstood, didnt mean too,,,,or offfended anyoane, buck >> >> >>> Subject: RE: [Diy_efi] water injection> From: spyro at f2s.com> To: diy_efi at diy-efi.org> Date: Sat, 29 Sep 2007 01:10:48 +0100> > On Fri, 2007-09-28 at 16:55 -0700, Klaus Allmendinger wrote:> > Which brings back the original question: Does WI help on a diesel?> > I did some more research on that and also talked to some buddies at> > diesel injection development at Bosch (after all, these guys should> > know> > :) ). All sources agree, WI on a small diesel, especially if its> > introduced in the intake, LOWERS output power> > you _did_ mention that its a turbo diesel though?> > cooler air = more density = more air in the cylinders> > more air + more fuel = more bang> > _______________________________________________> Diy_efi mailing list> Diy_efi at diy-efi.org> Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi> Main WWW page: http://www.diy-efi.org/diy_efi >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Diy_efi mailing list >>> Diy_efi at diy-efi.org >>> http://lists.diy-efi.org/mailman/listinfo/diy_efi >>> From spyro at f2s.com Mon Oct 1 04:30:10 2007 From: spyro at f2s.com (ian) Date: Mon, 01 Oct 2007 10:30:10 +0100 Subject: [Bulk] Re: [Diy_efi] Modular approach to EFI controllers In-Reply-To: <7.0.1.0.0.20071001104735.027ec850@iinet.net.au>> References: <46FFFE2D.3000307@earthlink.net> <1191191551.30658.6.camel@wirenth> <1191201618.10850.64.camel@wopr.donegan.org> <7.0.1.0.0.20071001104735.027ec850@iinet.net.au>> Message-ID: <1191231010.30658.17.camel@wirenth> On Mon, 2007-10-01 at 10:49 +0800, Mike wrote: > > Is the FPGA that necessary, I mean, with a fast enough processor > and the appropriate software it should be a chince, even if you had > a second CPU doing nothing but the timing and ion sensing etc, > you are not going to have the spark events coincident so surely > with a CPU even doing 4Mhz there is enough time, these beasts > are cheap have good a/d and run 20Mhz etc... Oh yes. very necessary. ok, so we overspecc'd it a bit so it can handle (in theory) a W16 engine configuration with twin spark and twin injector multiport injection, but still. the math worked out upwards of 90,000 events per second at redline. you *could* handle all that on a 20Mz CPU perhaps, but then if theres one error in that and you lean out at 15,000 RPM or so its bye-bye engine. much better to have a nice simple state machine do the job predictably and without bothering the CPU. if you actually want to _do_ anything with the ion sense data you're looking at doing thousands of FFTs per second, which starts to really rack up the amount of CPU grunt you need - and with heavy processing would come high latency, or the need to design _very_ tight real time processing. Much easier to have the FPGA do the critical stuff and simply pass data to the ARM for analysis and receive feedback to modify its controll tables. From spyro at f2s.com Mon Oct 1 04:42:12 2007 From: spyro at f2s.com (ian) Date: Mon, 01 Oct 2007 10:42:12 +0100 Subject: [Diy_efi] Re: Diy_efi Digest, Vol 31, Issue 29 In-Reply-To: <4700A31D.6050801@nec.com.au> References: <20070929011048.3AC7C7FC9D@ns2.nec.com.au> <4700A31D.6050801@nec.com.au> Message-ID: <1191231732.30658.29.camel@wirenth> On Mon, 2007-10-01 at 17:34 +1000, Bill Washington wrote: > Buck, > Good on you, a little contentment with what we have achieved can > often save a lot of pain ....... and expense! Happy motoring! :-) > Back to diesels..... > The latest generation of diesels gain their economy and the > potential to produce a lot more power because of the ultra high > (dangerous) pressure common rail/ electronic injection. This produces > much finer atomisation, and thus much more complete burning - ie burning > much more of the fuel and spitting less of it out the exhaust. I *somewhat* would dispute that. My little diesel is indirect, and manages better economy than many of the production common rails that are 20 years its junior. The key is that whilst the new diesels get similar or slightly worse MPG figures, they are a HELL of a lot more powerful. > Ian, did you say you were wanting to incorporate this into your > 'new' engine intended to get the 'works'? I'd love to but... > - that would be an extremely > interesting project - I would love to add common rail injection to my > old 2.3l and 2.5l Peugeot diesels - unfortunately they are indirect > injection engines - ie there is a spherical combustion chamber set into > the head, and this contains the glowplug and injection point. And that is the problem - I've spoken to some experts on this and the biggest problems are: 1) There isnt a (modern) common rail injector on gods green earth thats even remotely similar in size/shape to the old types 2) Common rail injectors have a very wide (almost 180 degree) spray pattern, more a fan than a cone. Im informed that putting this into a combustion chamber would very quickly erode away the combustion chamber insert walls, then followed by the head. And then... > The piston > at TDC comes within a gnat's whisker of the head - the only thing that > stops them hitting is the head gasket - the piston (flat top) protrudes > above the top of the block at TDC and the head is dead flat Yes, same on mine - pistons rise above the deck. the tolerance is miniscule. I suppose thats the one thing thats easily fixed, you could install shorter rods, or pistons with higher wrists or something. I suppose technically, one could do that and machine up 'fake' combustion chamber inserts (or fill the holes with weld) so that a DI injector would go through and poke out into the combustion chamber... Actually, that sounds like a scarily simple way to do it. You bastard, I though I had this project all worked out ;-) I'll have to do some thinking on this now :) That said, Im still gonna be stuck with a non-crossflow SOHC head and it kinda detracts from the 'charm' of the engine... > ..... valve > timing, therefore, is also critical to avoid piston and valves meeting, > and making expensive noises! .... but still it would be nice to add > common rail.... if only I could afford it and source the parts, > including the computer to drive it! ... I'll dream on! I wouldnt have thought the computer would be hard to build - after all, it would probably run with a single pulse at TDC, although granted that wouldnt be optimal... you could just trigger it with a hall effect sensor and a A/B/G timing type setup... From niche at iinet.net.au Mon Oct 1 05:20:12 2007 From: niche at iinet.net.au (Mike) Date: Mon, 01 Oct 2007 18:20:12 +0800 Subject: [Bulk] Re: [Diy_efi] Modular approach to EFI controllers In-Reply-To: <1191231010.30658.17.camel@wirenth> References: <46FFFE2D.3000307@earthlink.net> <1191191551.30658.6.camel@wirenth> <1191201618.10850.64.camel@wopr.donegan.org> <7.0.1.0.0.20071001104735.027ec850@iinet.net.au> <1191231010.30658.17.camel@wirenth> Message-ID: <7.0.1.0.0.20071001181705.027f0e40@iinet.net.au>> Ian, This raises more questions that it answers ;-) Do you have a base data flow analysis ah la work schedule type format sequence of events as very little of what goes on is anywhere near coincident even on a W16 - I do but hazard a guess ? Eg. How many V12's have coincident ignition or sequential fueling and even then an interrupt condition properly prioritized looks after just so much... BTW: Curious, does the W16 have a coincident firing event ? Regards Mike At 05:30 PM 10/1/07, you wrote: >On Mon, 2007-10-01 at 10:49 +0800, Mike wrote: >> >> Is the FPGA that necessary, I mean, with a fast enough processor >> and the appropriate software it should be a chince, even if you had >> a second CPU doing nothing but the timing and ion sensing etc, >> you are not going to have the spark events coincident so surely >> with a CPU even doing 4Mhz there is enough time, these beasts >> are cheap have good a/d and run 20Mhz etc... > >Oh yes. very necessary. > >ok, so we overspecc'd it a bit so it can handle (in theory) a W16 engine >configuration with twin spark and twin injector multiport injection, but >still. > >the math worked out upwards of 90,000 events per second at redline. > >you *could* handle all that on a 20Mz CPU perhaps, but then if theres >one error in that and you lean out at 15,000 RPM or so its bye-bye >engine. much better to have a nice simple state machine do the job >predictably and without bothering the CPU. > >if you actually want to _do_ anything with the ion sense data you're >looking at doing thousands of FFTs per second, which starts to really >rack up the amount of CPU grunt you need - and with heavy processing >would come high latency, or the need to design _very_ tight real time >processing. > >Much easier to have the FPGA do the critical stuff and simply pass data >to the ARM for analysis and receive feedback to modify its controll >tables. > >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi Regards from Mike Perth, Western Australia VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed ! Twin tyres for most sedans, trikes and motorcycle sidecars http://niche.iinet.net.au From spyro at f2s.com Mon Oct 1 06:18:59 2007 From: spyro at f2s.com (ian) Date: Mon, 01 Oct 2007 12:18:59 +0100 Subject: [Bulk] Re: [Diy_efi] Modular approach to EFI controllers In-Reply-To: <7.0.1.0.0.20071001181705.027f0e40@iinet.net.au>> References: <46FFFE2D.3000307@earthlink.net> <1191191551.30658.6.camel@wirenth> <1191201618.10850.64.camel@wopr.donegan.org> <7.0.1.0.0.20071001104735.027ec850@iinet.net.au> <1191231010.30658.17.camel@wirenth> <7.0.1.0.0.20071001181705.027f0e40@iinet.net.au>> Message-ID: <1191237539.30658.48.camel@wirenth> On Mon, 2007-10-01 at 18:20 +0800, Mike wrote: > Ian, > BTW: Curious, does the W16 have a coincident firing event ? I actually dont know. I speccd up a bit of overkill really but it never hurts. I designed the FPGA so that it can handle timing the reading of up to four ADCs at once and driving 2x spark and 2x injectors for up to 16 cylinders. My personal application will be a inline 6 with single spark and *maybe* dual injectors per port (more likely single) but thats the nice thing about FPGAs - you can scale the design up or down to suit - *IF* the original design is good enough. the idea is that no matter how 'full fat' you make the FPGA, as long as it follows the register spec I wrote, it'll work with the same software running on the ARM as any other FPGA running any other 'fattness' of the design would. (even so, theres a lot of events...) for one cylinder: (2xspark, 2x injectors) 10k RPM = 166 RPS so thats potentially: 42 TDC interrupts (84 if you dont ignore the TDC on compression) 84 spark events 84 injection events 42 ion sense 'data ready' interrupts. total 252 events multiply by 16 cylinders... 4032 events. but thats not the whole story because if you werent using the FPGA you'd have to handle some kind of bus for the ion sense ADCs, along with thousands of interrupts per event, and also the injection needs to be started and stopped, which means you need precise, uS grade timing from the ARM and _no_ latency, whilst its doing all that other stuff like calculating FFTs of the ion sense data etc. not to mention that the FPGA can happily handle things like generating fraction-of-a-degree interpolation of the crank angle without any need for intervention from the ARM. basically it makes sense to have the system split into a timing controller thats bullet proof and has no other requirements but to calculate crank angle and injection / spark timing, and let the ARM handle feeding it instructions, which can be done on a much more leisurely basis - and if the ARM freezes, the TC can simply call a stop to things before your engine fries (hard watchdog). From niche at iinet.net.au Mon Oct 1 07:37:59 2007 From: niche at iinet.net.au (Mike) Date: Mon, 01 Oct 2007 20:37:59 +0800 Subject: [Bulk] Re: [Diy_efi] Modular approach to EFI controllers In-Reply-To: <1191237539.30658.48.camel@wirenth> References: <46FFFE2D.3000307@earthlink.net> <1191191551.30658.6.camel@wirenth> <1191201618.10850.64.camel@wopr.donegan.org> <7.0.1.0.0.20071001104735.027ec850@iinet.net.au> <1191231010.30658.17.camel@wirenth> <7.0.1.0.0.20071001181705.027f0e40@iinet.net.au> <1191237539.30658.48.camel@wirenth> Message-ID: <7.0.1.0.0.20071001202642.0275db10@iinet.net.au>> Sorry Ian, Something doesnt quite gel in all those calcs, when I do a back of the envelope event schedule I get a far easier less tortuous branch path. I'm not saying an FPGA inst good to have to off load the CPU but having done very short int ack routines and state logic I dont feel its that necessary. btw: Have you had the chance to draw a 16 line (W16 type) event schedule and factor in the perishable nature of the data set and fact you wont need sequential ion samples from all cycles at that 10K rpm rate ? But, sure once you do a FPGA to handle a W16 then it will of course be backwards compatible with other engines no problem given a scalable register/inst set etc. And good to have it as a redundant timer in event cpu fails, btw: What sort of amortised cost does one end up with for such an FPGA, just broad brush estimates at this stage and the hard outgoings to get it up to a spec ? Regards Mike At 07:18 PM 10/1/07, you wrote: >On Mon, 2007-10-01 at 18:20 +0800, Mike wrote: >> Ian, > >> BTW: Curious, does the W16 have a coincident firing event ? > >I actually dont know. > >I speccd up a bit of overkill really but it never hurts. > >I designed the FPGA so that it can handle timing the reading of up to >four ADCs at once and driving 2x spark and 2x injectors for up to 16 >cylinders. > >My personal application will be a inline 6 with single spark and *maybe* >dual injectors per port (more likely single) > >but thats the nice thing about FPGAs - you can scale the design up or >down to suit - *IF* the original design is good enough. > >the idea is that no matter how 'full fat' you make the FPGA, as long as >it follows the register spec I wrote, it'll work with the same software >running on the ARM as any other FPGA running any other 'fattness' of the >design would. > >(even so, theres a lot of events...) > >for one cylinder: (2xspark, 2x injectors) > >10k RPM = 166 RPS > >so thats potentially: > >42 TDC interrupts (84 if you dont ignore the TDC on compression) >84 spark events >84 injection events >42 ion sense 'data ready' interrupts. > >total 252 events > >multiply by 16 cylinders... > >4032 events. > >but thats not the whole story because if you werent using the FPGA you'd >have to handle some kind of bus for the ion sense ADCs, along with >thousands of interrupts per event, and also the injection needs to be >started and stopped, which means you need precise, uS grade timing from >the ARM and _no_ latency, whilst its doing all that other stuff like >calculating FFTs of the ion sense data etc. > >not to mention that the FPGA can happily handle things like generating >fraction-of-a-degree interpolation of the crank angle without any need >for intervention from the ARM. > >basically it makes sense to have the system split into a timing >controller thats bullet proof and has no other requirements but to >calculate crank angle and injection / spark timing, and let the ARM >handle feeding it instructions, which can be done on a much more >leisurely basis - and if the ARM freezes, the TC can simply call a stop >to things before your engine fries (hard watchdog). > >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi Regards from Mike Perth, Western Australia VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed ! Twin tyres for most sedans, trikes and motorcycle sidecars http://niche.iinet.net.au From spyro at f2s.com Mon Oct 1 10:47:04 2007 From: spyro at f2s.com (ian) Date: Mon, 01 Oct 2007 16:47:04 +0100 Subject: [Bulk] Re: [Diy_efi] Modular approach to EFI controllers In-Reply-To: <7.0.1.0.0.20071001202642.0275db10@iinet.net.au>> References: <46FFFE2D.3000307@earthlink.net> <1191191551.30658.6.camel@wirenth> <1191201618.10850.64.camel@wopr.donegan.org> <7.0.1.0.0.20071001104735.027ec850@iinet.net.au> <1191231010.30658.17.camel@wirenth> <7.0.1.0.0.20071001181705.027f0e40@iinet.net.au> <1191237539.30658.48.camel@wirenth> <7.0.1.0.0.20071001202642.0275db10@iinet.net.au>> Message-ID: <1191253624.30658.64.camel@wirenth> On Mon, 2007-10-01 at 20:37 +0800, Mike wrote: > > Something doesnt quite gel in all those calcs, when I do a back of the > envelope event schedule I get a far easier less tortuous branch path. Do share... > I'm not saying an FPGA inst good to have to off load the CPU but > having done very short int ack routines and state logic I dont feel > its that necessary. Well spark timing and so on could be done, but I want to run a proper OS on the CPU, and thats going to muck up interrupt latency unless I waste a lot of time going RT. Im sure it *can* be done, I just dont want to and dont feel that doing it all on the CPU gives as neat or robust a design. besides, for the W16 twinspark twininjector engine, the timing controller needs about 90-odd pins of output, and finding nice small CPU packages that arent hard to solder with THAT much GPIO (before you add anything else into the mix!) is not so easy. > btw: Have you had the chance to draw a 16 line (W16 type) event > schedule and factor in the perishable nature of the data set and fact > you wont need sequential ion samples from all cycles at that 10K rpm > rate ? well with the exception of ion sensing, the 'overlapping' nature of which depends on the exact engine configuration, all the other events happen that often, per cylinder, per cycle. You could lose a lot of spark events with a wasted-spark system but that just doesnt fit my idea of 'neat'. The ion sensing I've gone as far as to allow four 'cylinder banks' - IOW four cylinders (on seperate banks) can fire at once. Obviously, if your engine doesnt have more than one bank, you only fit one ADC to the board. > But, sure once you do a FPGA to handle a W16 then it will of course be > backwards compatible with other engines no problem given a scalable > register/inst set etc. And good to have it as a redundant timer in > event cpu fails, :-) > btw: What sort of amortised cost does one end up with for such an > FPGA, just broad brush estimates at this stage and the hard outgoings > to get it up to a spec ? To be honest, I expect that the timing generator will fit easily into a CPLD, FPGA is probably overkill (I have a habit of calling all field programmable logic stuff FPGAs, my bad. CPLDs are cheap. That said, whilst cheap is good, I prefer maintainable / clean / robust, since this is a more or less non commercial project... From niche at iinet.net.au Mon Oct 1 13:10:47 2007 From: niche at iinet.net.au (Mike) Date: Tue, 02 Oct 2007 02:10:47 +0800 Subject: [Bulk] Re: [Diy_efi] Modular approach to EFI controllers In-Reply-To: <1191253624.30658.64.camel@wirenth> References: <46FFFE2D.3000307@earthlink.net> <1191191551.30658.6.camel@wirenth> <1191201618.10850.64.camel@wopr.donegan.org> <7.0.1.0.0.20071001104735.027ec850@iinet.net.au> <1191231010.30658.17.camel@wirenth> <7.0.1.0.0.20071001181705.027f0e40@iinet.net.au> <1191237539.30658.48.camel@wirenth> <7.0.1.0.0.20071001202642.0275db10@iinet.net.au> <1191253624.30658.64.camel@wirenth> Message-ID: <7.0.1.0.0.20071002015616.02b34590@iinet.net.au>> At 11:47 PM 10/1/07, you wrote: >On Mon, 2007-10-01 at 20:37 +0800, Mike wrote: >> >> Something doesnt quite gel in all those calcs, when I do a back of the >> envelope event schedule I get a far easier less tortuous branch path. > >Do share... Well its predicated upon s/w starting the event and int finishing it and very little has the immediacy of coincidence, in between the inititation and the microsec or so of int and flag tidy the ECU can do a few other things, ah lah state machine fashtion... >> I'm not saying an FPGA inst good to have to off load the CPU but >> having done very short int ack routines and state logic I dont feel >> its that necessary. > >Well spark timing and so on could be done, but I want to run a proper OS >on the CPU, and thats going to muck up interrupt latency unless I waste >a lot of time going RT. Im sure it *can* be done, I just dont want to >and dont feel that doing it all on the CPU gives as neat or robust a >design. When you say a "proper OS" what does that mean ? My thesis back in 1982 was running the CP/M OS on a Z80 at 4MHz, when the ignition trigger came in it switched the whole eprom/ram over to another bank from the NMI for the CPU, that little bit was done by two chips in hardware. The only problem I had was to run the floppy drive if the engine was on. So if I needed to dump stuff to floppy I'd kill the engine, minor thing in those days as there wasnt that much data to save... So by "proper OS", you can run anything but might need to be a bit creative re what the CPU expects to find in memory and preload alternate "banks" in RAM with things like stack return addresses... What sort of OS ? >besides, for the W16 twinspark twininjector engine, the timing >controller needs about 90-odd pins of output, and finding nice small CPU >packages that arent hard to solder with THAT much GPIO (before you add >anything else into the mix!) is not so easy. If you are worried about ECU size as a result of hand soldering then there are piggy back boards for a few, but you can do hand soldering of the finest ECU's with a little care, you just need a little extra flux because trying to rely on the amount in the solder will result in blobs, also some extra flux is a great way to force the extra solder to bead up and suck off, escp if it happens to bridge a couple of chip smt pins etc >> btw: Have you had the chance to draw a 16 line (W16 type) event >> schedule and factor in the perishable nature of the data set and fact >> you wont need sequential ion samples from all cycles at that 10K rpm >> rate ? > >well with the exception of ion sensing, the 'overlapping' nature of >which depends on the exact engine configuration, all the other events >happen that often, per cylinder, per cycle. You could lose a lot of >spark events with a wasted-spark system but that just doesnt fit my idea >of 'neat'. Not sure I understand how to reply to this one, um, even a V12 has not much overlapping in terms of CPU having to do stuff, if it is able to initiate an event such as a injector turn on then use the timer to turn things off via int. Same for the dwell time for ignition, if a int for dwell happens at same time as int for injector then give injector priority, as one uS of variance for dwell isnt going to do much... >The ion sensing I've gone as far as to allow four 'cylinder banks' - IOW >four cylinders (on seperate banks) can fire at once. Isnt the time slice for the ion sense to be pretty short upon spark initiation ? Whats your estimate of required sample rate and over what period, 10 bit A/D for that event would be sufficient are you thinking you need more bits too ? >Obviously, if your engine doesnt have more than one bank, you only fit >one ADC to the board. mmmm, Depending on what period of time you need data, one ADC per side (bank of 6) for a V12 might be ample, but if you can pin down the ion sense period criticality then if the sample window is short you can probably get away with one ADC muxed for a full V12... (maybe just ;-) Regards Mike >> But, sure once you do a FPGA to handle a W16 then it will of course be >> backwards compatible with other engines no problem given a scalable >> register/inst set etc. And good to have it as a redundant timer in >> event cpu fails, > >:-) > >> btw: What sort of amortised cost does one end up with for such an >> FPGA, just broad brush estimates at this stage and the hard outgoings >> to get it up to a spec ? > >To be honest, I expect that the timing generator will fit easily into a >CPLD, FPGA is probably overkill (I have a habit of calling all field >programmable logic stuff FPGAs, my bad. > >CPLDs are cheap. > >That said, whilst cheap is good, I prefer maintainable / clean / robust, >since this is a more or less non commercial project... > >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi Regards from Mike Perth, Western Australia VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed ! Twin tyres for most sedans, trikes and motorcycle sidecars http://niche.iinet.net.au From spyro at f2s.com Mon Oct 1 16:15:01 2007 From: spyro at f2s.com (ian) Date: Mon, 01 Oct 2007 22:15:01 +0100 Subject: [Bulk] Re: [Diy_efi] Modular approach to EFI controllers In-Reply-To: <7.0.1.0.0.20071002015616.02b34590@iinet.net.au>> References: <46FFFE2D.3000307@earthlink.net> <1191191551.30658.6.camel@wirenth> <1191201618.10850.64.camel@wopr.donegan.org> <7.0.1.0.0.20071001104735.027ec850@iinet.net.au> <1191231010.30658.17.camel@wirenth> <7.0.1.0.0.20071001181705.027f0e40@iinet.net.au> <1191237539.30658.48.camel@wirenth> <7.0.1.0.0.20071001202642.0275db10@iinet.net.au> <1191253624.30658.64.camel@wirenth> <7.0.1.0.0.20071002015616.02b34590@iinet.net.au>> Message-ID: <1191273301.30658.86.camel@wirenth> On Tue, 2007-10-02 at 02:10 +0800, Mike wrote: > At 11:47 PM 10/1/07, you wrote: > >On Mon, 2007-10-01 at 20:37 +0800, Mike wrote: > When you say a "proper OS" what does that mean ? Personally, I'd like to run RT linux or something on the thing. but really, anything that has a nice civilised way to uinterface to a terminal or PC will do. its more what CAN be done now - we're not restricted to tiny CPUs with miniscule RAM and ROM nowadays. eg. the FFT for the ion sense can be farmed off to an entire process of its own, etc. > My thesis back in 1982 was running the CP/M OS on a Z80 at 4MHz, > when the ignition trigger came in it switched the whole eprom/ram over to > another bank from the NMI for the CPU, that little bit was done by two > chips in hardware. The only problem I had was to run the floppy drive > if the engine was on. So if I needed to dump stuff to floppy I'd kill > the engine, minor thing in those days as there wasnt that much data > to save... Heh. the Archimedes had a problem with floppy virtual DMA and very high res video - there just wasnt enough bus bandwidth... > So by "proper OS", you can run anything but might need to be a bit creative > re what the CPU expects to find in memory and preload alternate "banks" > in RAM with things like stack return addresses... I'd rather avoid such hardware hacks - they just shouldnt be needed nowadays. (I do like them, indeed I like 'tiny' code, which is part of the reason I rewrote the bootloader on my ADSL modem :-) ) > If you are worried about ECU size as a result of hand soldering Not really. > then there > are piggy back boards for a few, but you can do hand soldering of the finest > ECU's with a little care, you just need a little extra flux because trying to > rely on the amount in the solder will result in blobs, also some extra flux > is a great way to force the extra solder to bead up and suck off, escp if it > happens to bridge a couple of chip smt pins etc Yup. I've soldered some pretty tiny surface mount stuff before now. > Not sure I understand how to reply to this one, um, even a V12 has not > much overlapping in terms of CPU having to do stuff, if it is able to > initiate an event such as a injector turn on then use the timer to turn things > off via int. Same for the dwell time for ignition, if a int for dwell happens > at same time as int for injector then give injector priority, as one uS of > variance for dwell isnt going to do much... at 10k RPM thats 0.6 of a degree. some bike engines will hit 25kRPM now. thats 0.15 degrees. and if you stack the latency for (say) 5 concurrent (but sequentially fired as the CPU may well have to process them one by one) events, the last event is going to happen 3/4 of a degree out from the first one. Im not so sure about a petrol engine but for some diesels that do multiple injections per cycle, that kind of resolution would be useless. > >The ion sensing I've gone as far as to allow four 'cylinder banks' - IOW > >four cylinders (on seperate banks) can fire at once. > > Isnt the time slice for the ion sense to be pretty short upon spark initiation ? in theory you could watch each cylinder the whole time bar the actual spark event. in practice, 10 degrees either side of ignition should suffice. probably. > Whats your estimate of required sample rate and over what period, 10 bit > A/D for that event would be sufficient are you thinking you need more bits too ? its high. we're looking in the realm of 20 degrees or so, and we'd like to try to get a full samplebuffer (256) each cycle to make the FFT easy to optimise. At 10kRPM that gives only 0.0012 seconds to take 256 samples, or 214k samples per second. 20 degrees might be too long too, so we might need to talk in terms of half or possibly a tenth of that time - so we could be looking at 2M samples/sec. Experimentation required. > >Obviously, if your engine doesnt have more than one bank, you only fit > >one ADC to the board. > > mmmm, Depending on what period of time you need data, one ADC per > side (bank of 6) for a V12 might be ample, but if you can pin down the ion > sense period criticality then if the sample window is short you can probably > get away with one ADC muxed for a full V12... (maybe just ;-) I dunno. I'd imagine that you can have a V12 with 2 cyclinders firing simultaneously, or one where each cylinder fires sequentially. both would need different treatment (possibly) From g_alan_e at yahoo.com Tue Oct 2 02:37:03 2007 From: g_alan_e at yahoo.com (Gregg Eshelman) Date: Tue, 2 Oct 2007 00:37:03 -0700 (PDT) Subject: [Bulk] Re: [Diy_efi] Modular approach to EFI controllers In-Reply-To: <1191237539.30658.48.camel@wirenth> Message-ID: <653426.67570.qm@web50302.mail.re2.yahoo.com> --- ian wrote: > leisurely basis - and if the ARM freezes, the TC can > simply call a stop > to things before your engine fries (hard watchdog). How about having it reset the ARM? Give it a bit of logic so that it'll shut down if it has to reset the ARM too many times in a specific time period- which would indicate a problem. ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC From niche at iinet.net.au Tue Oct 2 03:06:45 2007 From: niche at iinet.net.au (Mike) Date: Tue, 02 Oct 2007 16:06:45 +0800 Subject: [Bulk] Re: [Diy_efi] Modular approach to EFI controllers In-Reply-To: <653426.67570.qm@web50302.mail.re2.yahoo.com> References: <1191237539.30658.48.camel@wirenth> <653426.67570.qm@web50302.mail.re2.yahoo.com> Message-ID: <7.0.1.0.0.20071002160434.02b31900@iinet.net.au>> yes good point, having things like that built in are quite handy and if you set up a website to sell the CPLD as a general purpose timing controller for all sorts of semi-industrial projects you could do quite well, few other things you can add like a inspection port to display/acquire status etc regards mike ps: sounds like featuritis virus might get a hold ;-) At 03:37 PM 10/2/07, you wrote: >--- ian wrote: > >> leisurely basis - and if the ARM freezes, the TC can >> simply call a stop >> to things before your engine fries (hard watchdog). > >How about having it reset the ARM? Give it a bit of >logic so that it'll shut down if it has to reset the >ARM too many times in a specific time period- which >would indicate a problem. > > > >____________________________________________________________________________________ >Yahoo! oneSearch: Finally, mobile search >that gives answers, not web links. >http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi Regards from Mike Perth, Western Australia VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed ! Twin tyres for most sedans, trikes and motorcycle sidecars http://niche.iinet.net.au From spyro at f2s.com Tue Oct 2 03:32:51 2007 From: spyro at f2s.com (ian) Date: Tue, 02 Oct 2007 09:32:51 +0100 Subject: [Bulk] Re: [Diy_efi] Modular approach to EFI controllers In-Reply-To: <653426.67570.qm@web50302.mail.re2.yahoo.com> References: <653426.67570.qm@web50302.mail.re2.yahoo.com> Message-ID: <1191313971.5732.0.camel@wirenth> On Tue, 2007-10-02 at 00:37 -0700, Gregg Eshelman wrote: > > leisurely basis - and if the ARM freezes, the TC can > > simply call a stop > > to things before your engine fries (hard watchdog). > > How about having it reset the ARM? Sure, btu the priority is for it to save the engine, not convienience :-) (It can do both, of course) From spyro at f2s.com Tue Oct 2 03:33:57 2007 From: spyro at f2s.com (ian) Date: Tue, 02 Oct 2007 09:33:57 +0100 Subject: [Bulk] Re: [Diy_efi] Modular approach to EFI controllers In-Reply-To: <7.0.1.0.0.20071002160434.02b31900@iinet.net.au>> References: <1191237539.30658.48.camel@wirenth> <653426.67570.qm@web50302.mail.re2.yahoo.com> <7.0.1.0.0.20071002160434.02b31900@iinet.net.au>> Message-ID: <1191314037.5732.2.camel@wirenth> On Tue, 2007-10-02 at 16:06 +0800, Mike wrote: > yes good point, having things like that built in are quite > handy and if you set up a website to sell the CPLD as a > general purpose timing controller for all sorts of semi-industrial > projects you could do quite well, few other things you can > add like a inspection port to display/acquire status etc Actually it already has registers for that,e g. read interpolated crank angle, etc. From niche at iinet.net.au Tue Oct 2 03:42:30 2007 From: niche at iinet.net.au (Mike) Date: Tue, 02 Oct 2007 16:42:30 +0800 Subject: [Bulk] Re: [Diy_efi] Modular approach to EFI controllers In-Reply-To: <1191314037.5732.2.camel@wirenth> References: <1191237539.30658.48.camel@wirenth> <653426.67570.qm@web50302.mail.re2.yahoo.com> <7.0.1.0.0.20071002160434.02b31900@iinet.net.au> <1191314037.5732.2.camel@wirenth> Message-ID: <7.0.1.0.0.20071002164153.02b38b10@iinet.net.au>> At 04:33 PM 10/2/07, you wrote: >On Tue, 2007-10-02 at 16:06 +0800, Mike wrote: >> yes good point, having things like that built in are quite >> handy and if you set up a website to sell the CPLD as a >> general purpose timing controller for all sorts of semi-industrial >> projects you could do quite well, few other things you can >> add like a inspection port to display/acquire status etc > >Actually it already has registers for that,e g. read interpolated crank >angle, etc. Neato, is that from a parallel load on an 8 bit bus or some serial spi, i2c etc ? Regards from Mike Perth, Western Australia VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed ! Twin tyres for most sedans, trikes and motorcycle sidecars http://niche.iinet.net.au From spyro at f2s.com Tue Oct 2 03:51:24 2007 From: spyro at f2s.com (ian) Date: Tue, 02 Oct 2007 09:51:24 +0100 Subject: [Bulk] Re: [Diy_efi] Modular approach to EFI controllers In-Reply-To: <7.0.1.0.0.20071002164153.02b38b10@iinet.net.au>> References: <1191237539.30658.48.camel@wirenth> <653426.67570.qm@web50302.mail.re2.yahoo.com> <7.0.1.0.0.20071002160434.02b31900@iinet.net.au> <1191314037.5732.2.camel@wirenth> <7.0.1.0.0.20071002164153.02b38b10@iinet.net.au>> Message-ID: <1191315084.5732.8.camel@wirenth> On Tue, 2007-10-02 at 16:42 +0800, Mike wrote: > > Neato, is that from a parallel load on an 8 bit bus or some serial > spi, i2c etc ? Most likely both - I2C or SPI wont really be very sensible for ion sense data, but it'll be sueful for making simple (say, pic based) ECUs / debugging on a laptop. For high speed access it'll be memory mapped. its got a 16 bit address space (not all used) and data bus width would be as wide as possible given CPLD/FPGA/board/ARM pinout / routing requirements.