From owner-diy_efi Mon Nov 14 21:15:46 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA29886; Mon, 14 Nov 94 21:15:46 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 AA29881; Mon, 14 Nov 94 16:15:42 -0500 Message-Id: <9411142115.AA29881@coulomb.eng.ohio-state.edu> Received: by eigen.ee.ualberta.ca (1.37.109.4/15.6) id AA13294; Mon, 14 Nov 94 14:15:40 -0700 From: Dale Ulan Subject: Re: Questions about our design To: DIY_EFI Date: Mon, 14 Nov 94 14:15:38 MST In-Reply-To: ; from "Jason Borkowsky" at Nov 14, 94 3:02 pm Mailer: Elm [revision: 70.85] Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI > 1. Since the car is dual exhaust, is there ANY advantage to using dual > oxygen sensors? (If we were to use two, we would just alternate > reading each sensor, as opposed to reading each sensor every cycle > and taking an average). Not really. Only for stringent emission control. For this, you normally have two integrators and two block-learns, etc. etc., one for each side. > 2. Timing control. Have other DIY implemented this in a fuel control > and then release the energy into the coil after a certain delay. > This is an oversimplistic view of how it works, but is the basics > of it). I did timing control.... I just used a stock GM HEI coil amp and driver. It also has a hardware bypass mode built in. After the engine is running smoothly, you feed pulses to the module and flip the bypass line high. At this point the computer takes over timing. > 4. How heavily can we depend on the oxygen sensor? Originally we were > planning to use the oxygen sensor as our main source in determining > the fuel needs (along with references to a MAF and MAP sensor), but > it seems this may not be such a great idea. Any comments? O2 is a very slow sensor, relative to airflow. It also measures the state of things after the burn, when you really need a feed-forward compensation, not feed-back. Feedback is used to fine tuning the rest of the system. In fact, the rest of the system should be tuned properly first, then turn the feedback on. I've been working on my system... first by simulation... and with feedback, many other tuning problems can be hidden... or made worse... by the presence of feedback. > 5. Inlet air temperature: Do we need one, or will the combination of > oxygen sensor and MAF sensor be enough to take care of air temp > differences? (The underlying idea we are trying to achieve is > simplicity, yet cutting edge). MAF takes care of air temperature's effect on density. It may be useful to know air temp for acceleration enrichment and for feed- forward compensation of the MAF sensor's response times. > > 6. All along we have been assuming that a MAF sensor would be easier > to use as opposed to speed density. Before we totally commit > ourselves to MAF, does anybody have any convincing arguments as > to why we should consider speed density? Speed density is cheaper but more of a pain to set up properly. On the other hand, you need to carefully consider the MAF sensor filtering system because airflow pulsates much more strongly than MAP. Theoretically, speed-density is ideal for MP injection (batch or sequential), and MAF for TBI, but compensation can be made for either. > > 7. We are gravitating towards either using the 68HC11 or 68HC16 as the > microcontroller for our system. I know this might seem to processor > timing, and possibly a knock sensor. And as stated, the output will > be a batch injection system). ... I like the 68332, but.... the 68HC11 can be made to run just fine for this application. You may run into problems if you try to filter the MAF signal digitally with the HC11... processing power may be maxed out, but I haven't tried it. I found I ran out of timers on the HC11 too easily, but batch injection only requires one or two timer outputs. One for spark, too. I may try a 45-degree event-based averaging system this week on the HC11, and see if it drowns out the processor. This system samples the MAF system quite often, and comes up with a phase-independant MAF value. > 8. Does a home brew system need an IAC, or is this really used for > stringent emission control? (As I said, we want SIMPLE!). That's how I do fast idle. Normally, I just open the IAC to a position and wind it down as the engine warms up. This is rough but works fine. It's easier than having to warm up the car with your foot on the pedal until it's hot. Feedback control isn't really necessary, but an upper idle speed limit is a good idea. If the engine is idling more than 2000 rpm, close the IAC a bit until it's below 1800 or so. Whether you use it or not... it's your call. I would, though. -Dale From owner-diy_efi Wed Nov 16 06:03:45 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA04030; Wed, 16 Nov 94 06:03:45 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 AA04025; Wed, 16 Nov 94 01:03:33 -0500 Received: by shiva.trl.OZ.AU id AA25730 (5.65c/IDA-1.4.4 for DIY_EFI@coulomb.eng.ohio-state.edu); Wed, 16 Nov 1994 17:03:14 +1100 From: Craig Pugsley Message-Id: <199411160603.AA25730@shiva.trl.OZ.AU> Subject: 67F687 / CSP3000 To: DIY_EFI Date: Wed, 16 Nov 1994 17:03:12 +1100 (EST) Cc: X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2247 Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Hi there, I went looking on our CD rom data sheet system today for the 67F687 engine peripheral interface. I also went looking for other related stuff, but for some reason it will only search for keywords that describe the general class (The 67F687 is listed under Linear special application interface peripherals.. I couldn't find it by doing a search for the word 'engine' or 'car' etc..) It seems to be a RISC microcontroller with a few engine related inputs/outputs. It doesn't look like it has as good features as the 67F687 for timing control though. Anyway, here is the description of the device. I could find no data sheets for it, but it's made by ITT: The Car Signal Processor (CSP3000) is a signal processor designed for use in automotive applications. 24 analog inputs and 8 PWM outputs represent the interfaces with the analog world. The digital, 12 bits wide I/O port and two serial bus interfaces permit the exchange of digital data within the application or between processors. The 24 analog inputs are switched via an autoscan logic with a programmable sampling time to a 10 bit a-d convertor. The data is made available to the fast processor (FP) via a register file. This RISC processor has a word length of 12 bits and processes up to 32 MIPS. Quasi-analog outputs can be made through the FP via the 8 PWM outputs - each with 16 bits resolution and with selectable repetition rate and clock pulse frequency. The switch-on and switch-off times are seperately adjustable for each output, which avoids possible interferance of the vehicle electrical system due to switching on all PWMS at the same time. For safety reasons, two reset systems are available. A processor reset (eg by watchdog) does not alter the PWM settings, therefore. FEATURES OF THE CSP: - 12 Bit RISC processor (FP) - 256 words of internal RAM (12 bit) - 2048 works of internal ROM (20 bit) - internal clock generator - 12 Bidirectional IO lines - 2 serial ports - up to 24 analog inputs - 8 PWM outputs - up to 24 digital inputs - all digital inputs with hysteresis - 2 independant RESET pins for FP and PWM system - PLCC 68 package - EMU version available in 132 pin LLCC package Craig. PS Any other references to good peripheral chips out there? From owner-diy_efi Wed Nov 16 15:42:31 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA06001; Wed, 16 Nov 94 15:42:31 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 AA05996; Wed, 16 Nov 94 10:42:29 -0500 Message-Id: <9411161542.AA05996@coulomb.eng.ohio-state.edu> To: diy_efi Subject: new 68k embeded controllers Date: Wed, 16 Nov 94 10:42:28 -0500 From: John S Gwynne Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI I'm forwarding this... (Louis, please send posts to diy_efi; not owner-diy_efi. Thanks) =========================== cut here ============================ Hi! Dose anone have any information on the Motorola 68k serise embeded controllers. like the 68300 (?) I am particularly interested in cheap monitor/debuggers. I was assuming that -maby- Motorola povides a PC-BUG type $cheap$ development tool. I am currently building a 68000 based controller, but , the 683xx embeded serise would save me lots of wire wrapping. I also assume that the BDM port would allow for cheap development tools.. --- Louis Faustini From owner-diy_efi Fri Nov 18 00:56:17 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA02536; Fri, 18 Nov 94 00:56:17 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 AA02531; Thu, 17 Nov 94 19:56:11 -0500 Received: by shiva.trl.OZ.AU id AA23645 (5.65c/IDA-1.4.4 for DIY_EFI@coulomb.eng.ohio-state.edu); Fri, 18 Nov 1994 11:56:04 +1100 From: Craig Pugsley Message-Id: <199411180056.AA23645@shiva.trl.OZ.AU> Subject: FYI: 8051 assemblers / programming To: DIY_EFI Date: Fri, 18 Nov 1994 11:56:03 +1100 (EST) X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3790 Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Hi there, While I know I'm one of only a handfull (the only one?) on this list using an 8051 family processor, I thought I'd post this anyway: ******************************************************************* A few weeks back I was asking about assemblers to suit the 8051 series of processors that worked on a PC, as I bought a CEIBO DS750 development kit and it had no assembler with it. (Well, it has an 'on-line' assembler to fix bugs etc, but this is not suitable for writing code) The DS750 kit is a development system for 8xC750, 8xC751, 8xC752 processors (x= eprom or OTP), which are an 'entry level' 8051 based microcontroller (which means it has on chip EPROM, RAM, a timer, I/O ports - enough to make it a single chip micro), with a few extra useful functions (In this case A-D and PWM for the 87C752, an example of which is below). In any case, after reading Russ Hersh's 8051 FAQ, I got the file ML-ASM51.ZIP , which is a product of MetaLink corporation in the US. I am not sure what the licensing arrangement with this product is, as it had several warnings in the documentation files about being copyright etc, but as it is available by FTP from multiple sites I presume it is there for evaluation purposes only. (IE you have to pay for it in some manner if you wish to continue to use it) I picked this one as it suits my current needs (Ie I didn't want C source code that I had to compile for my PC blah blah blah, just something that will turn machine code into hex) This product will take a text file with assembler code mnemonics (*.ASM), and produce a listing file with the mnemonics plus the machine code (*.LST), as well as code for programming Eproms etc (*.HEX) These are the steps I followed to test it's working: i/ I got the Philips application notes book which contained several code examples. I picked one which is to demonstrate the 5 channel A-D, PWM and emulated UART (Tx only) functions of the 87C752 (Eprom version supplied w/ceibo kit) ii/ I copied a sample .asm file supplied with the compiler and deleted all of the code, with the exception of the initial assembler directives (which are to set up options such as printing of errors, etc.) About the only thing I had to change here was to include a 'descriptor file' for the'752 iii/ I typed in all of the code as listed in the book into the file. iv/ I ran ASM51.EXE (the compiler which is contained in ML-ASM51.ZIP) and it asked me for the name of the file I wanted to compile (which was TEST.ASM) v/ After fixing 1 or 2 minor spelling mistakes in the code that I made, the file compiled properly, creating TEST.LST and TEST.HEX vi/ I plugged in the DS750 (To power and the PC com port), inserted the 87C752 in the ZIF socket, selected program from one of the menus, and it asked me for the name of the file (which was TEST.HEX). The Ceibo DS750 automatically detects what type of processor you have put into it, and proceeded to program the device. vii/ I lashed up (on a breadboard) a curcuit to test it. This program does an A-D conversion on all of the A-D inputs, and outputs in Hex form the readings to the RS232 'pin', as well as controlling the PWM so it matches the voltage present on A-D port0. viii/End result: The curcuit worked, as expected, first time. The numbers appearing on the terminal represented the voltage on each of the ADC pins, and the PWM pin (when connected to a voltmeter) showed the same voltage as the applied voltage on ADC pin 0. Conclusion: It was a lot easier to do than I thought it would be! If someone showed me how to do all this it would have taken about 10 minutes instead of several hours. Craig. pugsley@trl.oz.au From owner-diy_efi Mon Nov 21 07:00:23 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA16377; Mon, 21 Nov 94 07:00:23 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 AA16372; Mon, 21 Nov 94 02:00:18 -0500 Received: by shiva.trl.OZ.AU id AA23086 (5.65c/IDA-1.4.4 for DIY_EFI@coulomb.eng.ohio-state.edu); Mon, 21 Nov 1994 18:00:12 +1100 From: Craig Pugsley Message-Id: <199411210700.AA23086@shiva.trl.OZ.AU> Subject: How much memory? To: DIY_EFI Date: Mon, 21 Nov 1994 18:00:10 +1100 (EST) X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1177 Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Hi there, I am wondering what the general concensus out there about how much memory would be required to house a good EFI system. The reason I ask this is there are several options for processor choice: 8k on chip eprom 16k on chip eprom 32k on chip flash eeprom, with boot rom to download code. (not sure if available yet) The main reason I want on-chip eprom is that (if) the design proves successful, I'd like to market it to a few freinds/acquaintances, but I don't want some @#$@#$! stealing all my hard work. Unfortuantely, the (e)eprom capacities are not all available for a particular chip series (So, I can't start w/8k and then migrate up :-( My guess is that 8k would be enough, even with a backup set of tables (main tables stored in battery backed SRAM). Obviously feeprom has the advantage of just hooking up the laptop to download the latest version of code (plus being able to store fuel/ign maps in there plus keeping external components to a mimimum.) Also, is there such a thing as a socket for a 'quad flat pack' SMD IC. I can find them for PLCC packages but not QFP, and QFPs are pretty hard to wire wrap :-/ Any ideas?. Craig. pugsley@trl.oz.au From owner-diy_efi Mon Nov 21 13:49:43 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA17019; Mon, 21 Nov 94 13:49:43 GMT Received: from hwking.cca.rockwell.com 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 AA17014; Mon, 21 Nov 94 08:49:39 -0500 Received: by hwking.cca.rockwell.com (5.65/DEC-Ultrix/4.3) id AA04973; Mon, 21 Nov 1994 07:49:32 -0600 Received: by star.cca.rockwell.com (5.65/DEC-Ultrix/4.3) id AA12167; Mon, 21 Nov 1994 07:49:32 -0600 Message-Id: <9411211349.AA12167@star.cca.rockwell.com> To: DIY_EFI Subject: Re: How much memory? In-Reply-To: Your message of "Mon, 21 Nov 94 18:00:10 +1100." <199411210700.AA23086@shiva.trl.OZ.AU> Date: Mon, 21 Nov 94 07:49:25 -0600 From: sdbartho@cca.rockwell.com X-Mts: smtp Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI >Also, is there such a thing as a socket for a 'quad flat pack' SMD IC. >I can find them for PLCC packages but not QFP, and QFPs are pretty hard >to wire wrap :-/ Any ideas?. Depends on what size you need. 3M makes PQFP sockets in 84, 100, 132, 164, and 196 pin counts. I believe AMP makess a line too, but I don't have their catalog handy. The 3M ones use a staggered pin layout, so you really couldn't use them on standard perf board. Dig sdbartho@hwking.cca.rockwell.com From owner-diy_efi Mon Nov 21 19:00:31 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA19558; Mon, 21 Nov 94 19:00:31 GMT Received: from maunakea-ppp.Data-IO.com 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 AA19482; Mon, 21 Nov 94 13:58:12 -0500 Received: from bethe.Dataio (bethe.Data-IO.com) by Data-IO.COM (4.1/SMI-4.1mk3) id AA21616; Mon, 21 Nov 94 10:57:28 PST Received: by bethe.Dataio (5.0/SMI-SVR4) id AA16921; Mon, 21 Nov 1994 11:01:12 +0800 Date: Mon, 21 Nov 1994 11:01:12 +0800 From: tilden@kea.Data-IO.COM (John Tilden) Message-Id: <9411211901.AA16921@bethe.Dataio> To: DIY_EFI Subject: Re: How much memory? X-Sun-Charset: US-ASCII Content-Length: 547 Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Craig Pugsley writes: > > Also, is there such a thing as a socket for a 'quad flat pack' SMD IC. > I can find them for PLCC packages but not QFP, and QFPs are pretty hard > to wire wrap :-/ Any ideas?. SAMTEC makes QFP to PGC Adapter boards for a variety of QFP Packages. Chip Specific Adapters "SPEC" for a variety of Motorola and Intel Chips, As well as Chip Generic Adaptor "GEN" for various lead count JEDEC and EIAJ QFPs. Simply solder down, and Plug in to a PGA socket! SAMTEC phn 800 726-8329. John Tilden tilden@data-io.com From owner-diy_efi Mon Nov 21 19:42:30 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA19876; Mon, 21 Nov 94 19:42:30 GMT Received: from tomcat.al.noaa.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 AA19871; Mon, 21 Nov 94 14:42:25 -0500 Received: from aztec.al.noaa.gov by tomcat.al.noaa.gov with SMTP id AA15692 (5.65c/IDA-1.4.4 for ); Mon, 21 Nov 1994 12:49:22 -0700 Message-Id: <199411211949.AA15692@tomcat.al.noaa.gov> Date: 21 Nov 1994 12:41:31 -0700 From: "Ciciora Steve" Subject: FW: How much memory? To: DIY_EFI Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI My solution to your delima is to use a chip that can be configured in single chip mode or expanded mode (8051 family, 6811, etc). With something as complicated as this project, don't fool yourself that you will only build one. If you try to limit yourself to hardware that will be the development system and the final product, it could be so unpleasent to work with that it will loose it's fun. I have a development system that is 10 times as big as necessary, 10 times as much memoy, 10 times as much power supply, etc. I have a 6811 in expanded mode with a 32k ram chip (I debug most of my code out of ram, when it works, transfer it to eprom) and 32k eprom. For power, I have a 12vdc -> 120vac power inverter (paid $69 for 200 watts) and my bench supply consisting of lambda switchers of 5V and +/- 15V. I also don't have a good laptop, so I drive around w/ an old '286 on the floor plugged into the 120V power inverter (I run from floppies; don't think that old ST-251 would take the bumps). Now I guess that most of you can't do this with your daily driver, and neither can I. I have a 'free' '72 volvo that came fuel injected stock (analog computer). No passenger seat, the dash is ripped out and a big breakout box (of all the computer wires) is put in it's place. With thermocouple wires and sensor wires all over the place, and a computer where the passenger seat was, it gets quite a few stairs when I bring it in to get the emmissions checked! Oh, ya. If (when) I get something that I consider working enough to put into my '66 mustang, then I'll shrink it down to a single board computer (single chip mode If I care to). Until then, I'm having enough trouble finding time to write some code instead of trying to make my code as small as possible to fit in single chip mode, and also to put up with the burn/run/crash/erase/repeat cycle. - Steven Ciciora ________________________________________________________ Hi there, I am wondering what the general concensus out there about how much memory would be required to house a good EFI system. The reason I ask this is there are several options for processor choice: 8k on chip eprom 16k on chip eprom 32k on chip flash eeprom, with boot rom to download code. (not sure if available yet) The main reason I want on-chip eprom is that (if) the design proves successful, I'd like to market it to a few freinds/acquaintances, but I don't want some @#$@#$! stealing all my hard work. (rest deleted)