From Diy_Efi-Owner  Thu May  5 20:12:36 1994
Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI)
	 id AA05271; Thu, 5 May 94 20:12:36 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@coulomb.eng.ohio-state.edu diy_efi-outgoing id AA05265; Thu, 5 May 94 16:12:35 -0400
Message-Id: <9405052012.AA05265@coulomb.eng.ohio-state.edu>
To: DIY_EFI
Cc: jsg
Subject: Re: Intro 
In-Reply-To: Your message of "Thu, 05 May 94 13:57:05 EDT."
             <940505135705.2dc04180@STDVAX.GSFC.NASA.GOV> 
Date: Thu, 05 May 94 16:12:34 -0400
From: John S Gwynne <jsg>
Sender: Diy_Efi-Owner
Precedence: bulk
Reply-To: DIY_EFI@coulomb.eng.ohio-state.edu

--------

   In message <940505135705.2dc04180@STDVAX.GSFC.NASA.GOV> , you write:
 
| A while ago I worked with a company called CUbit - they made, among other 
| things, an 80186 based, STD Bus board.  What I particularly enjoyed about 
| their set-up is that the on board ROMs would communicate with Borland's C 
| Remote debugger.   That means you write the code on a PC (all Borland), 
| compile and link it, and then down load it to the board - and you can step 
| through the code running on the remote CPU.  A breeze to debug.  Then you 
| link the code with a provided library and you can burn that code directly 

Yea, this can also be done with GNU's gcc and the GNU debugger gdb; a remote
serial interfaced debugger. That's why I've chosen to work with the 68000 and
a C cross-compiler. It would be nice if we all used the same CPU but I don't
think it's going to happen. A more reasonable goal would be to stick with an
ANSI-C language (available for PC's, 68HC11's, and about everything
else)(avoiding calls to the standard library functions) and have a common
interface bus that would let us share sensory interface designs. This way 
you could use the 80186, I could use a 68HC000, and ???? could use 
his 68HC11. We could all still share the software (with vary minor changes) 
and sensor interface designs.



                                       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  5 20:22:46 1994
Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI)
	 id AA05400; Thu, 5 May 94 20:22:46 GMT
Received: from cs.utexas.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@coulomb.eng.ohio-state.edu diy_efi-outgoing id AA05394; Thu, 5 May 94 16:22:44 -0400
Received: from needmore.cs.utexas.edu (haskett@needmore.cs.utexas.edu [128.83.138.122]) by cs.utexas.edu (8.6.9/8.6.9) with SMTP id PAA02120 for <DIY_EFI@coulomb.eng.ohio-state.edu>; Thu, 5 May 1994 15:21:58 -0500
Received: by needmore.cs.utexas.edu (5.64/Client-v1.4)
	id AA12998; Thu, 5 May 94 15:21:40 -0500
Date: Thu, 5 May 1994 15:21:37 -0500 (CDT)
From: Brian Scott Haskett <haskett@cs.utexas.edu>
Subject: Re: jai
To: DIY_EFI
In-Reply-To: <m0pz8Nt-000piUC@twisto.eng.hou.compaq.com>
Message-Id: <Pine.3.89.9405051522.A12926-0100000@needmore.cs.utexas.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Diy_Efi-Owner
Precedence: bulk
Reply-To: DIY_EFI@coulomb.eng.ohio-state.edu



On Thu, 5 May 1994 Steve=Ravet%Prj=Eng%PCPD=Hou@bangate.compaq.com wrote:

> I would like to make a suggestion:  I think the topic of electronically 
> controlled ignitions fits in well with efi, and would like to see that topic 
> covered here as well (mostly because that's the first thing I would like to 
> add to my car).  Please no flames, but perhaps a yea or nay response to see 
> what the general consensus is.

Sounds fine to me.

> In article <1gc6-pr@dixie.com> hotrod@dixie.com writes:
> >[The EFI system is pretty simple.  A dallas semi DS5000 hybrid supplies 
> >all the smarts.  This is a pretty amazing part.  It contains an
> >8052-like processor, ram, "rom" (battery-backed ram), timers, watchdog
> >timer and some other goodies in a double height 40 pin dip.  It has
> >3 8 bit I/O ports and a serial port.  Best of all, you program it
> >records into the serial port.  when the END record is received,
> >the chip reboots and starts running the program as if it were in
> >ROM.
> 
> The main advantage I see here is that no eprom programmer is required.  In 
> fact, if you have a laptop of some sort, you can compile/reprogram without 
> ever leaving the car.  The built-in I/O ports are nice too.  And there are 
> plenty of 8052 compilers/assemblers out there.

That sounds good-- the part about no eprom programmer.  Many of us don't have
access to all kind of fancy electrical stuff, and the cheaper we can keep the
whole thing the better.  I like the idea of being able to change the program
on the fly without having to burn chips and such.  I would like to do some
data analysis with a laptop, though, and I think that whatever hardware we
chose should allow for easy transfer of collected data via serial port.   I
don't know a whole lot about the hardware side of this, but is that a genuine
concern?   

The main reason that I mentioned a laptop in an earlier post is because
	1) they are readily available
	2) parts are cheap
	3) used laptops are cheap
	4) it's very easy to find an modify software on a laptop

Of course, using a laptop to control the EFI would not be desireable once
the system is completely set up and everything is running good.  Telling the
passenger to be careful of the box under his feet isn't too practical. :)

-Brian

From Diy_Efi-Owner  Thu May  5 21:01:13 1994
Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI)
	 id AA05682; Thu, 5 May 94 21:01:13 GMT
Received: by coulomb.eng.ohio-state.edu (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@coulomb.eng.ohio-state.edu diy_efi-outgoing id AA05676; Thu, 5 May 94 17:01:11 -0400
Date: Thu, 5 May 94 17:01:11 -0400
From: jsg (John S Gwynne)
Message-Id: <9405052101.AA05676@coulomb.eng.ohio-state.edu>
Apparently-To: DIY_EFI
Sender: Diy_Efi-Owner
Precedence: bulk
Reply-To: DIY_EFI@coulomb.eng.ohio-state.edu

(Message jsg:105)
Received: from [192.105.104.3] by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI)
	for /usr/local/lib/mh/slocal -user jsg id AA05611; Thu, 5 May 94 16:52:31 -0400
Received: from  by system3.lcs.gov.bc.ca with SMTP
	(1.37.109.6/16.2) id AA12110; Thu, 5 May 94 13:54:03 -0700
From: Evernden_Wes_A/lcs_system3@system3.lcs.gov.bc.ca
X-Openmail-Hops: 1
Date: Thu, 5 May 94 13:53:45 -0700
Message-Id: <CAB18029@MHS>
Subject: Re: Which CPU?
To: Diy_Efi-Owner, jsg

I should say that although I have started with a 68HC11 I would be 
happy to change to a different CPU if it was easier to program. I just 
picked the 68HC11 because that what we used  in school and I could buy 
EVB cheap. I don't really keep up with what other MCU's are available 
and presumably the newer ones are easier to program so maybe someone 
would like to make a recommendation.

Wes Evernden
----------
From: Diy.Efi-Owner; jsg
To: DIY.EFI
Cc: jsg
Subject: Re: Intro
Date: Thursday, May 05, 1994 1:12PM

<<File Attachment: REINTRO.TXT>>
--------

   In message <940505135705.2dc04180@STDVAX.GSFC.NASA.GOV> , you write:

| A while ago I worked with a company called CUbit - they made, among other
| things, an 80186 based, STD Bus board.  What I particularly enjoyed about
| their set-up is that the on board ROMs would communicate with Borland's C
| Remote debugger.   That means you write the code on a PC (all Borland),
| compile and link it, and then down load it to the board - and you can step
| through the code running on the remote CPU.  A breeze to debug.  Then you
| link the code with a provided library and you can burn that code directly

Yea, this can also be done with GNU's gcc and the GNU debugger gdb; a remote
serial interfaced debugger. That's why I've chosen to work with the 68000 and
a C cross-compiler. It would be nice if we all used the same CPU but I don't
think it's going to happen. A more reasonable goal would be to stick with an
ANSI-C language (available for PC's, 68HC11's, and about everything
else)(avoiding calls to the standard library functions) and have a common
interface bus that would let us share sensory interface designs. This way
you could use the 80186, I could use a 68HC000, and ???? could use
his 68HC11. We could all still share the software (with vary minor changes)
and sensor interface designs.



                                       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  5 21:15:23 1994
Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI)
	 id AA05768; Thu, 5 May 94 21:15:23 GMT
Received: from nic.hookup.net 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@coulomb.eng.ohio-state.edu diy_efi-outgoing id AA05753; Thu, 5 May 94 17:15:14 -0400
Received: from ndigital.UUCP (ndigital@localhost) by nic.hookup.net (8.6.9/1.155) with UUCP id RAA08542; Thu, 5 May 1994 17:14:28 -0400
Received: by ndigital.com (1.64/waf)
	via UUCP; Thu, 05 May 94 16:58:24 EDT
	for DIY_EFI@coulomb.eng.ohio-state.edu
From: Mpalmer@ndigital.com (Mike Palmer)
Message-Id: <18741@ndigital.com>
Date: Thu, 5 May 94 16:58:22 EDT
Organization: Northern Digital Inc.  Waterloo, Ontario, Canada
To: DIY_EFI
Subject: Thots cont'd
Sender: Diy_Efi-Owner
Precedence: bulk
Reply-To: DIY_EFI@coulomb.eng.ohio-state.edu

Somebody wrote :-)...

>> 02 sensors react relatively slow - maybe 10 readings a sec? 
>> TPS - sensors - at least 10 readings a second if not more
>> Temp sensors - 1 reading a second
>> RPM sensor - at 10,000rpm (why not?) - that 600,000 degrees per second.  4 
>> bumps on the crank shaft (ie - crank triggered ignition) would mean less 
>> than 1000 per second...
>> MAP or MAF sensor - 1 per second - maybe  more... 10?
>     
>For temp, intake air temp would also be good.
	 
For rates-of-computation, I think the P4 in my Z24 does portions of
it's fuel calcs once every 12mS (80+ times per second).

BTW, it's 60,000 degrees per second, not 600,000 :-)

For speed/density systems MAT is not "good" it's mandatory. Air
temp is an important player in the S/D equation. 

>> The system would have to work at:
>> Startup
>> Idle
>> part throotle cruise
>> WOT
>> anything else?
>     
>How about deceleration fuel cut.
	 
It may be necessary to also consider wall-wetting constants to
prevent lean-out and flat-spots on post-decel tip-ins.

>One thing I have noticed that has been missed so far is battery voltage.  
>You need to measure this to correct the pulse width sent to the injector.  
>Perhaps there are some new injector driver circuits out there that do this?
>
>I have been using the MC 3334 form Motorola.  

Yep. It will be necessary also to scale battery volts into the
fuel delivery. One way to establish a crude correction table would be 
to have an injector fire into a measuring crucible for a specified
number of pulses at a constant fuel pressure and pulse-width. For
various battery volts from 6.0 to 17.0, measure the quantity
delivered and then apply a scale factor to the applied pulse width
based on the battery voltage to achieve constant deliveries.

Don't forget too that injector operation takes time (i.e. for the 
solenoid to actually pull the injector open). At higher engine speeds
this may become a factor as far as timing goes. This is why
I like PFI systems conceptually over SFI systems - they are
less timing sensitive. (Some of the injectors on my 2.8 fire
onto the backs of closed intake valves...).

>My experiments so far are probably a little crude to what I have read.  I 
>have been using a PC parallel port connected to a A/D converter and then 
>used a lookup table to calculate the pulse width.  To date the system has 
>idled the car, but fails to accelerate properly ( engine stumbles and dies 
>).

Crude? Not at all! Actually sounds cool! 

I know nothing of your system, but can I suggest a few ideas?

1) Filter your TPS and MAP readings using a first order low pass
algorithm. It's a little esoteric but it will make the system less
susceptible to transients.

2) You'll need to have a process that monitors the delta-MAP and 
delta-TPS values (i.e. delta = filt(value_now) - filt(value_last_loop)). 
You can use these delta's to adjust the value of an asynchronous 
fuel accumulator (AFA). The AFA would be used to adjust injector on-time
to mimic an accelerator pump. Your system probably already
increases fuel-pressure automatically as a function of manifold
vacuum so a look-up table may be necessary to scale the delta
contributions accordingly. The AFA would normally add 0mS to the
injector on-time when del-MAP and del-TPS are low or zero but
when the AFA is adjusted by higher deltas, it would add *or subtract*
on-time accordingly. Subtract? Yes, to account for lift-throttle
conditions. Pretty complicated no doubt.
	 


--

- Mike 

From Diy_Efi-Owner  Thu May  5 21:16:41 1994
Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI)
	 id AA05787; Thu, 5 May 94 21:16:41 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@coulomb.eng.ohio-state.edu diy_efi-outgoing id AA05781; Thu, 5 May 94 17:16:40 -0400
Message-Id: <9405052116.AA05781@coulomb.eng.ohio-state.edu>
To: DIY_EFI
Cc: jsg
Subject: Re: Some thoughts and questions on EFI 
In-Reply-To: Your message of "Thu, 05 May 94 15:11:36 CDT."
             <m0pz9lg-000AVPC@knuth.mtsu.edu> 
Date: Thu, 05 May 94 17:16:39 -0400
From: John S Gwynne <jsg>
Sender: Diy_Efi-Owner
Precedence: bulk
Reply-To: DIY_EFI@coulomb.eng.ohio-state.edu

--------

   In message <m0pz9lg-000AVPC@knuth.mtsu.edu> , you write:
 
| In case anyone hasn't seen it before (i've seen it posted to r.a.t),
| this is the basic equation GM uses for its speed density systems:
| 
| OT = (BPC * F/A * VE * BLC * DFCO * DE)/2 + AE
| where OT = Injector On Time
|      BPC = Base pulse constant
|      F/A = 1/(desired AF ratio)
|       VE = Volumetric efficiency
|      BLC = Block learn multiplier/128
|     DFCO = Deceleration fuel cutoff
|       DE = Deceleration enleanment
|       AE = Acceleration enrichment

Can we get a good description of these terms and qualities such as
how much enrichment etc...


                                       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  5 22:25:06 1994
Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI)
	 id AA06275; Thu, 5 May 94 22:25:06 GMT
Received: from Rosie.UH.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@coulomb.eng.ohio-state.edu diy_efi-outgoing id AA06269; Thu, 5 May 94 18:25:03 -0400
Received: from Jetson.UH.EDU by Jetson.UH.EDU (PMDF V4.2-11 #5185) id
 <01HBZKUNEQIG8ZEEMH@Jetson.UH.EDU>; Thu, 5 May 1994 17:23:42 CDT
Date: Thu, 05 May 1994 17:23:40 -0500 (CDT)
From: ST3XD@Jetson.UH.EDU
Subject: Work from START - - - - - > FINISH
To: DIY_EFI
Message-Id: <01HBZKUNEQII8ZEEMH@Jetson.UH.EDU>
X-Vms-To: IN%"DIY_EFI@coulomb.eng.ohio-state.edu"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Sender: Diy_Efi-Owner
Precedence: bulk
Reply-To: DIY_EFI@coulomb.eng.ohio-state.edu


Before we hammer out software and control algorithyms we really
need to figure out what kind of hardware setup we are going to use.
 
Is it 8048, 8051, 8086, 80186, 6800, 6500, 68000, or what?
 
It would be a good idea to keep the price down!  Considering a
8048 costs 75 cents and a 68000 will be less than $5, its
hard to justify a specialized microprocessor that costs $700
(even thought it comes with RAM, ROM, etc.)
 
Just like John said, lets keep this streamlined.  If we all use
different setups, we won't accomplish anything except piss each
other off while lobbying for "our" setup.
 
And to those out there who hate EPROMs.  Don't worry- just buy an
EPROM emulator.  Or if we really want to be high tech, lets use
flash ROM (RAM).  Then we won't need anything but a parallel
interface to our computer, (DOS computer that is).
 
We really need a parallel interface anyway while we optimize
the setup by logging data and making modifications.


Later,
Jeff

From Diy_Efi-Owner  Fri May  6 01:44:19 1994
Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI)
	 id AA08042; Fri, 6 May 94 01:44:19 GMT
Received: by coulomb.eng.ohio-state.edu (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@coulomb.eng.ohio-state.edu diy_efi-outgoing id AA08036; Thu, 5 May 94 21:44:17 -0400
Date: Thu, 5 May 94 21:44:17 -0400
From: jsg (John S Gwynne)
Message-Id: <9405060144.AA08036@coulomb.eng.ohio-state.edu>
Apparently-To: DIY_EFI
Sender: Diy_Efi-Owner
Precedence: bulk
Reply-To: DIY_EFI@coulomb.eng.ohio-state.edu

(Message jsg:108)
Received: from wotan.compaq.com by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI)
	for /usr/local/lib/mh/slocal -user jsg id AA06328; Thu, 5 May 94 18:49:33 -0400
Received: from twisto.eng.hou.compaq.com by wotan.compaq.com with smtp
	(Smail3.1.28.1 #6) id m0pzCBP-0002fAC; Thu, 5 May 94 17:46 CDT
Received: from bangate.compaq.com by twisto.eng.hou.compaq.com with smtp
	(Smail3.1.28.1 #8) id m0pzCBO-000peJC; Thu, 5 May 94 17:46 CDT
Message-Id: <m0pzCBO-000peJC@twisto.eng.hou.compaq.com>
Received: by bangate.compaq.com with VINES ; Thu,  5 May 94 17:46:17 CDT
Date: Thu,  5 May 94 17:42:55 CDT
From: Steve=Ravet%Prj=Eng%PCPD=Hou@bangate.compaq.com
Subject: re: Thots cont'd
To: twisto.eng.hou.compaq.com!wotan!coulomb.eng.ohio-state.edu!Diy_Efi-Owner
Cc: 

Mpalmer@ndigital.com (Mike Palmer) Wrote:

| >One thing I have noticed that has been missed so far is battery 
| voltage.  
| >You need to measure this to correct the pulse width sent to the 
| injector.  
| >Perhaps there are some new injector driver circuits out there 
| that do this?
| >
| >I have been using the MC 3334 form Motorola.  
| 
| Yep. It will be necessary also to scale battery volts into the
| fuel delivery. One way to establish a crude correction table 
| would be 
| to have an injector fire into a measuring crucible for a specified
| number of pulses at a constant fuel pressure and pulse-width. For
| various battery volts from 6.0 to 17.0, measure the quantity
| delivered and then apply a scale factor to the applied pulse width
| based on the battery voltage to achieve constant deliveries.

What voltage does an injector need to open?  If it is an electro-magnetic
device like a solenoid then voltage isn't really important, as long as
there is plenty of current.  If the voltage level is important, then it
would be simpler to use a regulator to keep the voltage constant at, say,
10 volts.  If battery voltage drops below that, the car isn't going to run
well anyway, regardless of what the injectors are doing.

From Diy_Efi-Owner  Fri May  6 01:45:15 1994
Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI)
	 id AA08141; Fri, 6 May 94 01:45:15 GMT
Received: by coulomb.eng.ohio-state.edu (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@coulomb.eng.ohio-state.edu diy_efi-outgoing id AA08135; Thu, 5 May 94 21:45:14 -0400
Date: Thu, 5 May 94 21:45:14 -0400
From: jsg (John S Gwynne)
Message-Id: <9405060145.AA08135@coulomb.eng.ohio-state.edu>
Apparently-To: DIY_EFI
Sender: Diy_Efi-Owner
Precedence: bulk
Reply-To: DIY_EFI@coulomb.eng.ohio-state.edu

(Message jsg:109)
Received: from wotan.compaq.com by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI)
	for /usr/local/lib/mh/slocal -user jsg id AA06394; Thu, 5 May 94 19:04:18 -0400
Received: from twisto.eng.hou.compaq.com by wotan.compaq.com with smtp
	(Smail3.1.28.1 #6) id m0pzCOF-0002cBC; Thu, 5 May 94 17:59 CDT
Received: from bangate.compaq.com by twisto.eng.hou.compaq.com with smtp
	(Smail3.1.28.1 #8) id m0pzCOE-000pe6C; Thu, 5 May 94 17:59 CDT
Message-Id: <m0pzCOE-000pe6C@twisto.eng.hou.compaq.com>
Received: by bangate.compaq.com with VINES ; Thu,  5 May 94 17:59:33 CDT
Date: Thu,  5 May 94 17:47:27 CDT
From: Steve=Ravet%Prj=Eng%PCPD=Hou@bangate.compaq.com
Subject: re: Work from START - - - - - > FINISH
To: twisto.eng.hou.compaq.com!wotan!coulomb.eng.ohio-state.edu!Diy_Efi-Owner
Cc: 

ST3XD@Jetson.UH.EDU Wrote:
| Before we hammer out software and control algorithyms we really
| need to figure out what kind of hardware setup we are going to 
| use.
|  
| Is it 8048, 8051, 8086, 80186, 6800, 6500, 68000, or what?
|  

Lets keep all the discussions going.  I am personally more interested in
the control algorithms than the hardware itself, but the hardware issues
need to be resolved also.  We have two basic choices:
microcontroller (8052, 6811, etc). and CPU (80x86, 680x0).  I would say
that in the interests of cheapness and simplicity the microcontroller
provides the best solution, but that is IMO.  Maybe we should bat ideas
around for a week or so, then have a vote.  we are probably still picking 
up new people who have valuable opinions, so no need to rush things.  I'm
enjoying just reading what has been posted so far.

also, if anyone has access to things we are likely to need like pcb routing
and etching, compilers for whatever processor we decide on, etc., they
should speak up.  Hardly anyone will have all the
resources to do all this, but between us we should be able to put all the
pieces together.

--steve



