Effectiveness of RAM induction? (AFM replacement)

[Tom Sharpe]

Get a pic programmer hardware/software kit.. Cheap and a good diy project.  TWS

"Diehl, Jeffrey" wrote:

> 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

----------------------------------------------------------------------------
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