Effectiveness of RAM induction? (AFM replacement)

[Diehl, Jeffrey]

Well, I bought a book on PIC programming.  Man!  Am I sold!  I thought a
microcontroller would be complex and difficult to design around.  I was
wrong.  I'll be using a PIC-based circuit for my AFM replacement.

I'm still kinda foggy on how these devices get programmed.  There is lots of
talk about using a PC's parallel port, but I can't see how and I've not seen
any schematics.

Still looking...

Thanx,
Mike Diehl.

-----Original Message-----
From: Brian Dessent
To: diy_efi at diy-efi.org; Diehl, Jeffrey
Sent: 10/15/2001 6:54 AM
Subject: Re: Effectiveness of RAM induction? (AFM replacement)

"Diehl, Jeffrey" wrote:

> 1. Initial complexity and improved versitility in the fomr of the
PIC-driven
> circuit.
> 
> 2. Simple circuit and lots of trial and error.
> 
> That's a tough call.
> 
> I am a programmer by trade.  I do mostly perl, but I can do BASIC, C,
68K
> and i386 code.  I could probably learn to program a PIC.  <grin>
> 
> Stamp Basic...  Sounds almost turn-key.  Is it really that easy?  I
have
> built simple descrete logic circuits.  Which would be easier, PIC or
Stamp?

The Basic Stamp has the advantage that it is very easy to get it up and
running, so strictly speaking it's the easier choice, but you are
limited in several ways.  You have very limited choice of the
architecture, since there are only a handfull of different stamp
modules, the most popular of which is the Basic Stamp 2 (BS2.)  I know
the BS2 has a PWM output but I'm not sure if it's fast enough for your
application.  Although, you don't really need very high bandwidth, I
would say less than tens of Hz.  I don't think the response rate of a
vane type flow sensor is really all that good.  However, now that I
think of it, I seem to recall that they are underdamped and upon
acceleration they overshoot, and some ECUs watch for this spike followed
by a decay to add accel enrichment.  I don't know if this is relevant
for your application, but if you want to model this property you might
need more than tens of Hz BW.

The BS2 is also quite slower than a PIC, because it's interpreting your
PBASIC code in real time.  The BS2 runs internally at 20MHz [every pic
instruction takes one clock cycle, except for program branch, I think]
but it only executes 4000 instructions of PBASIC per second.  The BS2
has 32 bytes of ram and 2k program+data (about 500 lines of PBASIC)
which is usually enough for a lot of stuff.  But I have a feeling your
program might be a very long series of "if ... then" statements to
implement your lookup table, so depending on how much granularity you
want you may run out of room.  The most logical way of course would be
to simply hardcode the lookup table and use indirect addressing but I
don't think PBASIC has this ability, so you would probably be stuck
doing it the hard way.  PBASIC very quickly becomes annoying as it
really isn't much of a "real man's" language.  Note however that if you
wanted to do it based on an equation rather than lookup table (i.e. a
polynomial fit or something) then PBASIC would be much easier since
doing math is relatively easy (e.g. x = x * 10)... but no floating point
so if you wanted to go this route you might have to get creative with
fixed point math.

Also I don't think any of the stamps have onboard a/d, so that would
probably have to be an external part, which adds a bit more complexity.


With a pic on the other hand, you get a very wide choice of
architecture, so you could definitely get something with built in a/d,
and sufficient storage and speed.  You'd be coding assembly and I'm
pretty sure you could implement your lookup table the sane way with
indirect addressing.  The pics use a different architecture than most
cpus (code is 14 bits wide [or 12, or 16, depending on the device] and
data is 8 bits wide, they are separate address spaces) which might make
it a tad harder to do a lookup table.  What I mean is this: the lookup
values cannot be directly stored with the code since you can't "read"
program data.  You could get around this several ways: one would be to
write your program such that it copies the lookup table data to RAM on
startup and then use indirect addressing; alternatively you could code
your table as a series of RETLW instructions and then "jump into" the
appropriate instruction; there are other ways I'm sure.  Or you could
choose a PIC with enough data EEPROM (as opposed to code EEPROM) so that
you could just load your table there once and then not worry about it
again.  I recommend not using a reduced size table with interpolation,
doing any sort of multiply will really get slow and complicated (there
is no hardware multiply or divide, but I believe libraries are available
for free from microchip both floating and fixed point arithmatic.) 
Besides, I think 8 bits resolution is fine, and so 256 bytes of lookup
table is certainly manageable.

As for the analog output, I think you could get by with the PWM outputs,
just low-pass filter it.  You can get the equivalent of a 10-bit d/a
output this way, but I don't know how fast your output can vary (i.e.,
bandwidth.) If that's not fast enough you can use an external d/a
converter, all of the pics can easily interface with a serial d/a.

Here are some links.

There's a blurb about lookup tables and PICs here:
http://www.tinaja.com/glib/muse109.pdf

Microchip's PIC documentation: (their site has bunches of info!)
http://www.microchip.com/10/lit/pline/picmicro/index.htm

Download MPLAB, the free development environ (includes a simulator so
you can write/test your code without a pic at all):
http://www.microchip.com/10/tools/picmicro/devenv/mplabi/index.htm

Parallax makes the basic stamp line of products:
http://www.parallaxinc.com


Brian

----------------------------------------------------------------------------
To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org