From Diy_Efi-Owner Wed May 18 23:06:39 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA19427; Wed, 18 May 94 23:06:39 GMT Received: from grolsch-2.cs.ubc.ca by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo/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 AA19421; Wed, 18 May 94 19:06:34 -0400 Received: by grolsch.cs.ubc.ca id AA27307 (5.65c/IDA-1.3.5 for DIY_EFI@coulomb.eng.ohio-state.edu); Wed, 18 May 1994 16:06:32 -0700 X400-Received: by mta cs.ubc.ca in /PRMD=/ADMD=/C=/; Relayed; Wed, 18 May 1994 16:06:29 UTC-0700 X400-Received: by /PRMD=ca/ADMD=/C=/; Relayed; Wed, 18 May 1994 16:06:29 UTC-0700 Date: Wed, 18 May 1994 16:06:29 UTC-0700 X400-Originator: rodb@cs.ubc.ca X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-Mts-Identifier: [/PRMD=ca/ADMD=/C=/;940518160629] Content-Identifier: 1291 Conversion: Prohibited From: Rod Barman To: DIY_EFI In-Reply-To: <9405181404.AA08020@ohura.cca.rockwell.com> Message-Id: <"1291*rodb@cs.ubc.ca"@MHS> Subject: The Miniboard Again ... Mime-Version: 1.0 (Generated by Ean X.400 to MIME gateway) Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI Well yes I know the miniboard ONLY has 2K of EEPROM and 256 bytes of RAM, but guess what??? Bosch Motronic 1.0 is implemented in 4K of ROM and 128 bytes of RAM and that system contains a bunch of extra maps and goop and it uses a pathetic processor. You see, this is in part why I suggested we do the ignition controller first. This will easily fit in 2K of EEPROM. Everybody can write code and download it from there PC, MAC, Unix box. Yes, we should write stuff in assembler cause some dummies (Hi Jim!!!) don't know C and besides, there really isn't much code to write it just is very difficult to write it and get it correct. Sure we can use a fancy processor, sure we can have a fancy development system, sure we can plan a nifty built in alarm system that controls the windshield wipers, sure we can spend days getting our WWW home page just right ;-), but I think most people want to get out there and fiddle with their cars and write code and not spend a lot of money. Anyway, that's how I see (especially since I've got two extra minboards I don't know what to do with :-). --rod. -- Rod Barman, IRIS NCE @ Laboratory for Computational Intelligence, University of British Columbia rodb@cs.ubc.ca From Diy_Efi-Owner Thu May 19 00:07:04 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA19729; Thu, 19 May 94 00:07:04 GMT Received: from knuth.mtsu.edu by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo/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 AA19723; Wed, 18 May 94 20:06:57 -0400 Received: by knuth.mtsu.edu (Smail3.1.28.1 #17) id m0q3vdQ-000AWJC; Wed, 18 May 94 19:06 CDT Message-Id: From: lusky@knuth.mtsu.edu (Jonathan R. Lusky) Subject: Re: The Miniboard Again ... To: DIY_EFI Date: Wed, 18 May 1994 19:06:48 -0500 (CDT) In-Reply-To: <"1291*rodb@cs.ubc.ca"@MHS> from "Rod Barman" at May 18, 94 04:06:29 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1951 Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI Rod Barman writes: > Well yes I know the miniboard ONLY has 2K of EEPROM and 256 bytes of > RAM, but guess what??? Bosch Motronic 1.0 is implemented in 4K of > ROM and 128 bytes of RAM and that system contains a bunch of extra > maps and goop and it uses a pathetic processor. I know I can't even fit the lookup tables I'd like to have in 2K. > You see, this is in part why I suggested we do the ignition controller > first. This will easily fit in 2K of EEPROM. Everybody can write > code and download it from there PC, MAC, Unix box. Yes, we should > write stuff in assembler cause some dummies (Hi Jim!!!) don't know > C and besides, there really isn't much code to write it just is > very difficult to write it and get it correct. A good exercise, but it not a good idea to start development with something that is clearly going to be inadequate. > Sure we can use a fancy processor, sure we can have a fancy development > system, sure we can plan a nifty built in alarm system that controls the > windshield wipers, sure we can spend days getting our WWW home page just > right ;-), but I think most people want to get out there and fiddle with > their cars and write code and not spend a lot of money. > > Anyway, that's how I see (especially since I've got two extra minboards > I don't know what to do with :-). From what I understand, there are other single board systems available in the same price range that are much more suitable to this application. From what I gather about the miniboard, it 1) doesn't have enough memory, 2) doesn't have adequate inputs, 3) the motor drivers included with it are useless in this application. I do believe that a 68HC11 is the way to go, I just don't think the miniboard is well suited to this application. -- Jonathan R. Lusky -- lusky@knuth.mtsu.edu "Turbos are nice but I'd rather be blown!" 89 Jeep Wrangler - 258 / For Sale: $8000 obo 80 Toyota Celica - 20R / 5spd From Diy_Efi-Owner Thu May 19 00:17:06 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA19794; Thu, 19 May 94 00:17:06 GMT Received: from us.dynix.com by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo/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 AA19788; Wed, 18 May 94 20:17:01 -0400 Received: from cpu.us.dynix.com by dnxjcit.us.dynix.com with SMTP id AA26174 (5.65c/IDA-1.4.4 for ); Wed, 18 May 1994 18:16:01 -0600 Received: by cpu.us.dynix.com (AIX 3.2/UCB 5.64/4.03) id AA29268; Wed, 18 May 1994 18:16:39 -0600 Date: Wed, 18 May 1994 18:13:20 -700 (MDT) From: Jim Conforti Subject: Re: The Miniboard Again ... To: "Jonathan R. Lusky" Cc: DIY_EFI In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI On Wed, 18 May 1994, Jonathan R. Lusky wrote: > I know I can't even fit the lookup tables I'd like to have in 2K. How many MAP and RPM sites are you looking at? Even a 30 x 30 map is just 900 bytes and that's WAY too large a map to use .. 15 x 20 is reasonable .. with 15 rpm and 20 MAP gradations ... If this isn't enough, rethink your design! BMW is making over 120bhp/liter normally aspirated with this! Jim Conforti From Diy_Efi-Owner Thu May 19 01:02:47 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA20061; Thu, 19 May 94 01:02:47 GMT Received: from grolsch-2.cs.ubc.ca by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo/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 AA20052; Wed, 18 May 94 21:02:42 -0400 Received: by grolsch.cs.ubc.ca id AA29602 (5.65c/IDA-1.3.5 for DIY_EFI@coulomb.eng.ohio-state.edu); Wed, 18 May 1994 18:02:39 -0700 X400-Received: by mta cs.ubc.ca in /PRMD=/ADMD=/C=/; Relayed; Wed, 18 May 1994 18:02:37 UTC-0700 X400-Received: by /PRMD=ca/ADMD=/C=/; Relayed; Wed, 18 May 1994 18:02:37 UTC-0700 Date: Wed, 18 May 1994 18:02:37 UTC-0700 X400-Originator: rodb@cs.ubc.ca X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-Mts-Identifier: [/PRMD=ca/ADMD=/C=/;940518180237] Content-Identifier: 1293 Conversion: Prohibited From: Rod Barman To: DIY_EFI In-Reply-To: Message-Id: <"1293*rodb@cs.ubc.ca"@MHS> Subject: Re: The Miniboard Again ... Mime-Version: 1.0 (Generated by Ean X.400 to MIME gateway) Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI On Wed, 18 May 1994, Jonathan R. Lusky wrote: > From what I understand, there are other single board systems available > in the same price range that are much more suitable to this application. > From what I gather about the miniboard, it 1) doesn't have enough > memory, 2) doesn't have adequate inputs, 3) the motor drivers included > with it are useless in this application. I do believe that a 68HC11 > is the way to go, I just don't think the miniboard is well suited to > this application. 1) I agree 2K seems tiny in todays 64 meg world but when you are writing in assembler it's pretty big. It's big enough for an ignition controller, but I agree it would be too small for full blown engine management. There are hc11s with more EPROM space (8K) but the download run cycle would be slower. 2) Has almost all the 'hc11 I/O pins brought out to headers (this is alot of I/O when the 'hc11 is operated in single chip mode). 3) Well, you just don't buy them or put them on the board. These can be used as generic high/low side drivers so they may still find a use. In summary, I suggest we start with a miniboad ignition controller where the coil driver/s and other extra goo is on a little protoboard, get that working and then design a PCB that has everything we want on it for an ECU. Of course, I very pleased that Jonathan has agreed that the 'hc11 is the way to go :-). I would not cry too much if we went with the F1 board or something like it. --rod. -- Rod Barman, IRIS NCE @ Laboratory for Computational Intelligence, University of British Columbia rodb@cs.ubc.ca From Diy_Efi-Owner Thu May 19 01:33:15 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA20222; Thu, 19 May 94 01:33:15 GMT Received: from slopoke.mlb.semi.harris.com by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo/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 AA20216; Wed, 18 May 94 21:33:11 -0400 Received: from billy.mlb.semi.harris.com by slopoke.mlb.semi.harris.com (4.0/SMI-4.0) id AA18698; Wed, 18 May 94 21:33:08 EDT Received: by billy.mlb.semi.harris.com (4.1/SMI-4.1-jmb) id AA15995; Wed, 18 May 94 21:33:07 EDT Date: Wed, 18 May 94 21:33:07 EDT From: jws@mlb.semi.harris.com (James W. Swonger) Message-Id: <9405190133.AA15995@billy.mlb.semi.harris.com> To: DIY_EFI Subject: Re: 6811 for me Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI The isue of modularity is key to making the things we develop usable by others. I would love to see a system take shape which has its functions and components partitioned so that any given project might be able to get about 90% of its function from existing, worked-out modules, leaving only the really powertrain-specific functions to be massaged. To do this the control unit would have to be a pretty general-purpose machine, but the interface to it well defined. I think the processing should be separate from the sensors and the effectors. I envision a set of building blocks, made on standard forms for a standard "EFIbus". I tend to prefer hardware over software. I think that a system with well defined, uniform signal values would be ideal. What I mean by this is that, for example, all analog signals would be processed from whatever their raw form might be to a standard range (e.g. 0-5V) so that they can be digitized uniformly. All sensor inputs would be proccessed by a sensor module, and this module would be fairly generic (so that, for example, simple modifications would permit adaptation to 4,6,8,... cylinder engines, of different firing patterns, with slightly different air, temp, ... sensors, but retain the primary function, to present a consistent, platform independent set of engine status signals for the controller. On the other end, a injector and spark driver module could likewise unburden the controller, and also make the control function less platform dependent, if it were desiged to accept a minimal set of inputs which are sufficient to define the fuel delivery/timing and spark. This might consist of a pulse width variable, a pulse offset variable (from a bussed index pulse clock), and an ignition offset from master. The rest is counters and timers, which would vary somewhat from engine/make to engine/make, but again could be pretty strappable. This leaves the computer core to do only the calculation of optimum operating point, without so much real-time programming burden. The cycle-by-cycle management could be almost negligible in steady- state if the effectors are designed to latch the control data. A once- per-cycle recalculation of state would probably suffice at worst. Would this group try to assign an address space for system variables, and standards for a workable EFIbus, and the ideal partitioning of hardware and software? Is such a definition something that can become consensus, or are needs too disparate? From Diy_Efi-Owner Thu May 19 01:54:50 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA20354; Thu, 19 May 94 01:54:50 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/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 AA20348; Wed, 18 May 94 21:54:46 -0400 Message-Id: <9405190154.AA20348@coulomb.eng.ohio-state.edu> To: DIY_EFI Subject: Re: 6811 for me In-Reply-To: Your message of "Wed, 18 May 94 21:33:07 EDT." <9405190133.AA15995@billy.mlb.semi.harris.com> Date: Wed, 18 May 94 21:54:46 -0400 From: John S Gwynne Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI -------- In message <9405190133.AA15995@billy.mlb.semi.harris.com> , you write: | Would this group try to assign an address space for system variables, | and standards for a workable EFIbus, and the ideal partitioning of | hardware and software? Is such a definition something that can become | consensus, or are needs too disparate? I support the idea of an 'EFIbus'; but rather than define an address space, I would prefer to see something more like: !DS0, !DS1..., A0, A1, A2, A3. Here, each !DSx would be device select lines that mapped into an address space of 16 (through the address lines A0-A3). Each CPU design could map the !DSx lines into any locations. The hardware would not care where in the CPU memory map (or I/O map) that it was located; just that it was selected. 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 Diy_Efi-Owner Thu May 19 04:16:32 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA22582; Thu, 19 May 94 04:16:32 GMT Received: from eigen.ee.ualberta.ca by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo/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 AA22576; Thu, 19 May 94 00:16:27 -0400 Message-Id: <9405190416.AA22576@coulomb.eng.ohio-state.edu> Received: by eigen.ee.ualberta.ca (1.37.109.4/15.6) id AA06009; Wed, 18 May 94 22:16:24 -0600 From: Dale Ulan Subject: Re: The Miniboard Again ... To: DIY_EFI Date: Wed, 18 May 94 22:16:22 MDT In-Reply-To: <"1293*rodb@cs.ubc.ca"@MHS>; from "Rod Barman" at May 18, 94 6:02 pm Mailer: Elm [revision: 70.85] Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI > > > On Wed, 18 May 1994, Jonathan R. Lusky wrote: > > > memory, 2) doesn't have adequate inputs, 3) the motor drivers included > > with it are useless in this application. I do believe that a 68HC11 > > is the way to go, I just don't think the miniboard is well suited to > > this application. > > There are hc11s with more EPROM space (8K) but the download run cycle > would be slower. The simplest way to go is with an external EPROM or EEPROM. HC11's with more than 2k of on-chip non-volatile memory are ceramic EPROMs or plastic OTPROMs. Except the 811A8, which Motorola doesn't seem to even admit to ever having. I used the 68HC11F1 with great success. I managed to port over a complete 6801-based engine controller with hardware-based controls (with the CPU doing only calculations) to a completely software-based system. I even have about 65% CPU idle time with my 8 ms loop time and running a 4-cyl at 25000 RPM. Of course, the engine doesn't actually run that fast... > 3) Well, you just don't buy them or put them on the board. These can > be used as generic high/low side drivers so they may still find a use. All drivers for a car with the exception of idle speed motor and ignition drivers should be low-side drivers. I like the MTP3055EL logic-level MOSFET from Motorola. I drive them directly off of a 74HC574 latch for my power outputs. They work great! Just have to put about a 40V zener across them to absorb switching spikes. > Of course, I very pleased that Jonathan has agreed that the 'hc11 is the way > to go :-). I would not cry too much if we went with the F1 board or something > like it. The 68HC11F1 is probably the best HC11 member for this application. Unless you want to pay $50 to $100 for a single chip mode HC711K1 or E9 with a window, an external memory device works great. Also, the F1 runs at 4 MHz instead of 2, which makes software easier, since time constraints are not so big. You *can* do fuel injection and spark in the E2, but when I did it, there were no diagnostics, and so little free space that I doubled interrupt vectors as instructions. That is *NOT* the correct way to write software for engine control applications. ....car manufacturer reference deleted.... ... likes to use 17x17 tables, which take up a lot of space. One for spark, one for fuel, then add accel enrichment, accel temp comp, decel cutoff, decel temp comp, a choke system (usually five or so tables), and cold engine spark advance. This amount of code takes just 2200 bytes, with about 300 bytes of that reserved for interrupts, etc. Tables on top of that, too. My approach is to use software to accomplish something until it hurts too much. Then I change to hardware. Actually, more often than not, I throw in another processor and continue doing it in software... because software does not require a PC board re-design at the last minute when you're about to start shipping your product... My plans for my F1 board include changing it to a 711K4 in the near future, using OTPROM. In this configuration, there will be only one real 'chip' on the board. But this is after a couple years of software development. The application is for use on motorcycle engines. My next project is to port that over to the 68332 processor, and move the product over to a 68F333, if I could ever get them... -Dale From Diy_Efi-Owner Thu May 19 15:16:06 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA24123; Thu, 19 May 94 15:16:06 GMT Received: from [192.105.104.3] by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo/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 AA24117; Thu, 19 May 94 11:16:01 -0400 Received: from by system3.lcs.gov.bc.ca with SMTP (1.37.109.6/16.2) id AA17421; Thu, 19 May 94 08:17:37 -0700 From: Evernden_Wes_A/lcs_system3@system3.lcs.gov.bc.ca X-Openmail-Hops: 1 Date: Thu, 19 May 94 08:17:15 -0700 Message-Id: <0C40DCBF@MHS> Subject: RE: 6811 for me To: DIY_EFI Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI I think you must mean the MC68HC811A8. MC68HC11A8: EEPROM=512,RAM=256,COMMENT=Family Built Around this Device MC68HC811A8:EEPROM=8K+512,RAM=256,COMMENT=EEPROM Emulator for 'A8 I happen to have the HC11 Ref. Man. here at work. Wes Evernden ---------- From: Diy.Efi-Owner; ST3XD To: DIY.EFI Subject: 6811 for me Date: Wednesday, May 18, 1994 3:50PM <> After a more carefull examination of the miniboard, and examining Motorola's M68HC11 Reference Manual. I'm going to go with the 6811. There is no way any of us will be able to throw together a complete EFI system. I like the idea of "modularity I'm going to make a board just to monitor everything first. When that is done, I'll go for ignition and then fuel. The MC68HC11A8 has 8k of EEPROM which will be enough to handle monitoring things. When I'm ready to add the next module (ignition) I'll use another one, and network them through SPI! Jeff From Diy_Efi-Owner Thu May 19 18:57:40 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA24926; Thu, 19 May 94 18:57:40 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/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 AA24920; Thu, 19 May 94 14:57:36 -0400 Message-Id: <9405191857.AA24920@coulomb.eng.ohio-state.edu> To: DIY_EFI Subject: 68HC11F1 In-Reply-To: Your message of "Wed, 18 May 94 22:16:22 MDT." <9405190416.AA22576@coulomb.eng.ohio-state.edu> Date: Thu, 19 May 94 14:57:35 -0400 From: John S Gwynne Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI In message <9405190416.AA22576@coulomb.eng.ohio-state.edu> , you write: | I used the 68HC11F1 with great success. I managed to port over a complete | 6801-based engine controller with hardware-based controls (with the CPU | doing only calculations) to a completely software-based system. I even | have about 65% CPU idle time with my 8 ms loop time and running a 4-cyl | at 25000 RPM. Of course, the engine doesn't actually run that fast... 65%... I'm impressed. Do you think there is enough "head room" (extra memory and CPU cycles) to write all the software in C? | My approach is to use software to accomplish something until it hurts too | much. Then I change to hardware. Actually, more often than not, I throw Could you share with us your general I/O configuration? | -Dale 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 -------------------------------------------------------------------------------