Controller Questions

Tom Cloud cloud at peaches.ph.utexas.edu
Wed Aug 13 14:37:00 GMT 1997


>Questions for this list:
>
>I'm sorta new to electronics.  I'm in it partially out of interest, and
>partly out of necessity. (I have a gizmo that I want to build, but it is
>UNWIELDY, and I need a computer to keep it in check.)  Because the
>project I'm working on borrows heavily from the technologies discussed
>in this group, I learn a lot by hanging out.  My only problem is that
>I''m not exactly a microcontroller whiz.  I tried to ease into the area

        [ snip ]

>1.  If you had to pick a controller to learn on, which one would it be?

        [ snip s'more ]


>2.  (After I have learned a bit more)  If you had to pick a controller
>to monitor temperature and pressure, and vary an ignition and a fuel
>injection firing pattern at the same time, which controller would you
>use?  Do you use multiple controllers for all these tasks, or is your
>code multi-threaded?  Or, are these microcontrollers so fast that the
>interference with the firing sequences is negligible?

I've not done any micro-controller coding or process control
coding (same enchilada with efi) in over 20 years (though I do
teach it) .... but I'll throw out a few thoughts

  - BASIC (not VB) is not a bad language to learn on (but it's
politically incorrect in many circles) ... problem here is that
I don't know if anyone currently puts out a version that's as simple
as GW-BASIC or the earlier versions and with primitive I/O like PEEK,
POKE, IN and OUT to access memory and I/O directly but that's not
necessarily bad.  The advantage of BASIC, IMHO, is it lets you develop
a high-level algorithm in a fairly readable format (the complaint
about BASIC's lack of structure is totally up to the programmer -- and
I think there's more power in having the choice of being structured
or not rather than being fenced into a structure {forgive the
temporary tirade} ).  After the basic (pun) algorithm is completed,
then coding in assembler or C is simpler (IMO) -- in fact, the
earlier BASIC compilers would print out the corresponding assembly
code ..... one could take that skeletal structure and flesh
it out in a shorter time than starting with assembler initially.
When I want to do a quick check of something I still fire up GW-BASIC.

 - regarding your multiple controller question, I'd say there's
two schools
 1 - let the (main) controller do everything
 2 - have high-level hardware ("controllers") take over the repetitive
or easily defined tasks (like a controller for disk I/O or for keyboard,
etc)

WRT (1) above, the disadvantage to that is what you've already
said -- you can get into tight timing constraints and develop
severe indigestion and/or migraines trying to manage all the
interrupt processing you'll be doing.  The processor can
be used to scan a keyboard, light pixels on a screen, act as
a timer, run the A-D convertor (control the integrator switches,
count the discharge time, etc), but I doubt very many still do
that, so the question is how far to take the external control
concept.

WRT (2), it costs a little more to buy the extra chips to
control the various functions -- it also locks you into doing
the control a certain way -- can't rewrite code to change it,
have to redesign a PCB.  The obvious advantages are that the
coding becomes easier with less concern for timing (note that
I said that I've not done any coding for efi, so someone else
will have to tell you just how much of a problem the timing
is -- my last *real* programming was on the 8085 and Z80).

It would seem to me that the injector pulse width would be
determined by a counter/timer chip (or on-chip to the processor)
with the trigger coming either from the processor or, mo-bettah
IMO, from the ignition pulse.  Then all the processor would have
to do would be to load the counter -- and then reload it only when
the value changed more than a certain amount.  Same thing for the
ignition timing -- load a counter with a value that relates
to the advance and let the counter be triggered from the ignition
TDC pulse.

>3.  Are there any other mailing-lists you monitor besides this list that
>deal specifically with microcontroller topics?  Are there any mailing
>lists that deal with metal working / machining / CNC stuff?

there's newsgroups (I don't participate in those so can't help there)

>Jason Walters

Tom Cloud



More information about the Diy_efi mailing list