Searching \ for '[PIC] Looking for a PIC with ADC, DAC, and UART...' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=adc
Search entire site for: 'Looking for a PIC with ADC, DAC, and UART...'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Looking for a PIC with ADC, DAC, and UART...'
2005\07\15@234046 by David de Regt

flavicon
face
First post, and hopefully I've done enough background research and forum
searching to avoid this being a dupe...


I've been looking around for the past few days trying to find a PIC with
all three of the above: ADC (4 channel minimum), DAC, and UART on-chip.
Unfortunately, the closest I can come is the PIC16C781/2 which don't
have UART on-chip.  So, it's looking like I'm going to have to code it
somewhat blind, not having a good way of outputting debug info back to
my computer.  That's not to say it'll be impossible to code, just
annoying since I'll have to use GPIO pins as debug flags...


So, hoping to avoid doing that, has anyone found a PIC hiding somewhere
that actually has all of these components built in?  Even after hours of
trolling microchip's PIC lists, I've come up empty-handed.


The only caveat I have is that it has to come in a DIP package so that I
can actually solder it by hand (also so it's flashable in a cheap
device... looks like I'm going to probably get the ISP-PRO.)  LQFP is
just a wee bit tiny for me...


Thanks,

David

2005\07\16@013006 by Byron A Jeff

face picon face
On Fri, Jul 15, 2005 at 08:46:27PM -0700, David de Regt wrote:
> First post, and hopefully I've done enough background research and forum
> searching to avoid this being a dupe...

Welcome.

> I've been looking around for the past few days trying to find a PIC with
> all three of the above: ADC (4 channel minimum), DAC, and UART on-chip.

The DAC is the fuzzy one with PICs.

> Unfortunately, the closest I can come is the PIC16C781/2 which don't
> have UART on-chip.

And it isn't flash! OUCH!

>  So, it's looking like I'm going to have to code it
> somewhat blind, not having a good way of outputting debug info back to
> my computer.

Bit banging the UART is a common activity.

> So, hoping to avoid doing that, has anyone found a PIC hiding somewhere
> that actually has all of these components built in?  Even after hours of
> trolling microchip's PIC lists, I've come up empty-handed.

Like I said, the DAC is fuzzy. It's the task that you should be looking to
substitute.

The purpose of a DAC is to output an analog voltage proportional to the given
digital value. Most PICs don't do that directly. However many PICs have a
module that perform that same activity: the PWM module.

PWM outputs a precisely timed square wave that when filtered gives a
proportional analog voltage. AppNote 538 outlines the process. You can
find it here:

http://ww1.microchip.com/downloads/en/AppNotes/00538c.pdf

Essentially with a resistor, a cap, and some programming, you get virtually
the same effect as a DAC. In fact with 10 bit PWM you actually get finer
voltage control. Note that the opamp follower shown in Figure 4 of the
AppNote is there to ensure that the user of the analog output doesn't load
the PIC down.

The PWM module is the reason that you don't find many PICs with built in
DACs. They are the substitute. And like the UART, they can be implemented
in software too if necessary.

> The only caveat I have is that it has to come in a DIP package so that I
> can actually solder it by hand (also so it's flashable in a cheap
> device... looks like I'm going to probably get the ISP-PRO.)  LQFP is
> just a wee bit tiny for me...

Not a problem. A 16F88 would meet all of your needs in a 18 pin DIP
package.

Hope this helps,

BAJ

2005\07\16@013900 by David de Regt

flavicon
face
> > Unfortunately, the closest I can come is the PIC16C781/2 which don't
> > have UART on-chip.
> And it isn't flash! OUCH!
I'm still new to this game - does no flash mean it's OTP or something?
I definitely need something erasable...

> >  So, it's looking like I'm going to have to code it
> > somewhat blind, not having a good way of outputting debug info back
to
> > my computer.
> Bit banging the UART is a common activity.
I was contemplating doing that.  I definitely haven't eliminated the
possibility. :)

> The purpose of a DAC is to output an analog voltage proportional to
the
> given digital value. Most PICs don't do that directly. However many
PICs
> have a module that perform that same activity: the PWM module.
I saw that app note, as well as a few notes about it around the piclist.
The only problem I have with that is that it's still going to have some
ripple in it, even after being filtered.  The output I'm using will be
into an engine ECU, so any ripple or anything like that will cause some
horrible fluctuations in the drivability of the car.  So, that's my
worry there, and why I like just using a normal plain jane DAC...

I've also looked at using a PIC with a serial interface to talk to a MAX
serial interface DAC, but that's less clean than just having everything
on the same chip.  So, I'm a little stuck.  I'd also really like 10 bits
of precision on the ADC and DAC, though I _think_ 8 will work for my
application.

I'm jumping over from the ARM world mostly, so this is all a little new
to me.  Having to buy programmers to program my chip for me is a bit
foreign.  I'm used to just jumping 2 pins which sets a boot loader and
then programming with RS232.  :)

I'm also incredibly concerned about how I'm going to implement a pow()
function given the very limited PIC instruction set.  I'm hoping not
have to do a table lookup, though that wouldn't be the worst case
scenario.  I'd just need to eat 512 bytes of flash to do it...

-David

2005\07\16@083538 by John J. McDonough

flavicon
face
----- Original Message -----
From: "David de Regt" <spam_OUTakillaTakeThisOuTspamakilla.net>
Subject: RE: [PIC] Looking for a PIC with ADC, DAC, and UART...


> I'm still new to this game - does no flash mean it's OTP or something?
> I definitely need something erasable...

the C means it's OTP.

> I was contemplating doing that.  I definitely haven't eliminated the
> possibility. :)

You can break down and buy an ICD for debugging.  Not really all that bad of
a choice, actually.

>> have a module that perform that same activity: the PWM module.
> I saw that app note, as well as a few notes about it around the piclist.
> The only problem I have with that is that it's still going to have some
> ripple in it, even after being filtered.  The output I'm using will be
> into an engine ECU, so any ripple or anything like that will cause some
> horrible fluctuations in the drivability of the car.  So, that's my
> worry there, and why I like just using a normal plain jane DAC...

I doubt that the ripple needs to have any visible effect.  The PWM output
can have quite a high frequency, very easy to filter.  And even if it wasn't
well filtered, there is no behavior of a car that can respond in the kHz
range.

> I've also looked at using a PIC with a serial interface to talk to a MAX
> serial interface DAC, but that's less clean than just having everything
> on the same chip.  So, I'm a little stuck.  I'd also really like 10 bits
> of precision on the ADC and DAC, though I _think_ 8 will work for my
> application.

Some of the PICs actually have a D/A of sorts.  Unfortunately you have to
fish through the datasheets, but some of the newer parts have a programmable
A/D reference voltage that can be taken off chip to use as a D/A.  It tends
to be pretty crude, however, so it really isn't useful in most situations.
External serial DACs are pretty easy to deal with, although they tend to be
a little pricey.

> I'm jumping over from the ARM world mostly, so this is all a little new
> to me.  Having to buy programmers to program my chip for me is a bit
> foreign.  I'm used to just jumping 2 pins which sets a boot loader and
> then programming with RS232.  :)

It really isn't that big of a deal. All that is really happening is some
level shifting, so a few transistors does the trick.  However, something
like the ICD2 not only programs the part in-circuit, but also allows you to
peek inside while it's running your app.  OK, it's not free, but in a
commercial environment it's hard to imagine that you wouldn't spring for
one.  Coupled with MPLAB it really is pretty nice.

> I'm also incredibly concerned about how I'm going to implement a pow()
> function given the very limited PIC instruction set.  I'm hoping not
> have to do a table lookup, though that wouldn't be the worst case
> scenario.  I'd just need to eat 512 bytes of flash to do it...

No need to be "incredibly concerned".  There's lots of sources for
algorithms, including the PIClist archives, and none of this stuff is rocket
science.  Oh yeah, and the way tables work, that's probably 512 WORDS, not
bytes.  But you won't need a table lookup anyway, although it might turn out
to be faster if that gets to be an issue.

--McD

2005\07\16@092048 by olin piclist
face picon face
David de Regt wrote:
> I've been looking around for the past few days trying to find a PIC
> with all three of the above: ADC (4 channel minimum), DAC, and UART
> on-chip.

There are many many PICs that meet your requirements.  Since you are
mentioning manual soldering I'll assume this is for a one off or low volume
project.  My choice would be the 30F3013, which is available in 28 pin DIP.
It has 12 bit A/Ds where other choices only have 10 bit.  It's also faster
and therefore the "DAC" output via PWM has a higher bandwidth.

However you didn't give bandwidth spec for the D/A, so that can be done in
software.  If you know what you're doing and can live with the constraints,
the UART can be done in software too, but I don't recommend that.

The smallest PIC to suite your needs is the 16F688 which comes in a 14 pin
DIP.  That's half the size of the 30F3013.  Again, there are many choices in
between.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\16@094710 by olin piclist

face picon face
David de Regt wrote:
> The only problem I have with that is that it's still going
> to have some ripple in it, even after being filtered.

You need to stop waving your hands and provide some real specs.  Zero noise
on the analog ouptut signal is of course impossible.  How much can you
tolerate?  What will this analog signal be used for inside the ECU?  PWM
lets you trade off resolution, bandwidth, and noise nicely.  Without a real
spec there is no way to know whether there is a workable tradeoff available
via PWM.

> so any ripple or anything like that
> will cause some horrible fluctuations in the drivability of the car.

*Any* ripple!!?  Then forget about this project.  Time to go home.

<rant>
Requirements like "zero noise", "exact" analog values and the like are silly
and have no place in engineering.  Good specification is the first part of
any project.  Problems posted here are often more due to vague specs than
issues with PICs.
</rant>

> I'm also incredibly concerned about how I'm going to implement a pow()
> function given the very limited PIC instruction set.  I'm hoping not
> have to do a table lookup, though that wouldn't be the worst case
> scenario.  I'd just need to eat 512 bytes of flash to do it...

So?  How big is the rest of your program?  What exactly does it need to do?
Unless you are contemplating something very complicated, I doubt you'll be
anywhere close to filling up the 16K x 16 bit program space of a 18F2520, or
the 16K x 24 bit program space of a 30F4012.  (I mentioned the 30F4012
instead of the 30F3013 because you seem to care more about program space
than 12 versus 10 bit A/Ds.)


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\16@170753 by David de Regt

flavicon
face
> > The only problem I have with that is that it's still going
> > to have some ripple in it, even after being filtered.

> You need to stop waving your hands and provide some real specs.  Zero
noise
> on the analog ouptut signal is of course impossible.  How much can you
> tolerate?  What will this analog signal be used for inside the ECU?
PWM
> lets you trade off resolution, bandwidth, and noise nicely.  Without a
real
> spec there is no way to know whether there is a workable tradeoff
available
> via PWM.

Well, the real question I suppose, is that if it's in the kHz range,
what is going to be the magnitude of the ripple?  If it's oscillating
back and forth in the microvolt range, that'll be fine.  However, I
suspect anything greater than a few millivolts is going to cause an
issue.  I'm being vague because I don't actually _know_ what will be an
issue or not.  I haven't actually tried throwing filtered PWM output at
the ECU yet, so I don't know.

Does anyone have a good digital oscilloscope trace from some filtered
high kHz PWM output so we can see exactly what the ripple really is?
I'll be able to look at it at school, I'm just wondering ahead of time
so that I can only buy equipment once. :)

> > I'm also incredibly concerned about how I'm going to implement a
pow()
> > function given the very limited PIC instruction set.  I'm hoping not
> > have to do a table lookup, though that wouldn't be the worst case
> > scenario.  I'd just need to eat 512 bytes of flash to do it...

> So?  How big is the rest of your program?  What exactly does it need
to do?
> Unless you are contemplating something very complicated, I doubt
you'll be
> anywhere close to filling up the 16K x 16 bit program space of a
18F2520, or
> the 16K x 24 bit program space of a 30F4012.  (I mentioned the 30F4012
> instead of the 30F3013 because you seem to care more about program
space
> than 12 versus 10 bit A/Ds.)

Well, on the chip I was mentioning, it had 2k WORD program space.  Last
I used a C library on an ARM, as soon as I touched a floating point op,
the compiler immediately pulled in ~20k of library code.  While I
realize it could be done much simpler in raw assembly, it still seems
likely I'm going to have some issue with space.  If I switch to a bigger
chip, it's obviously less of a problem, and it sounds like I'm going to
have to switch to a bigger chip anyway.

-David

2005\07\16@180354 by olin piclist

face picon face
David de Regt wrote:
>> How much
>> can you tolerate?  What will this analog signal be used for inside the
>> ECU? PWM lets you trade off resolution, bandwidth, and noise nicely.
>
> Well, the real question I suppose, is that if it's in the kHz range,
> what is going to be the magnitude of the ripple?

No, the real question is how much noise can you tolerate, what bandwidth
does the signal require, and how much resolution do you need.

> However, I
> suspect anything greater than a few millivolts is going to cause an
> issue.

OK, so we've at least got the start of a spec.  Let's say you want less than
5mV p-p noise on a 0-5V signal with 1KHz bandwidth (what in an ECU requires
1KHz control signal?) and 8 bit resolution.  The AC component of the 0-5V
digital pulse train therefore needs to be attenuated by about 1000.  a
30F4012 can do 8 bit PWM at 30MHz / 255 = 118KHz.  That means a simple
single pole RC filter with a 1KHz -3dB rollof point will attenuate the
digital AC by over 100, which isn't good enough.  A two pole filter will
therefore do over 10,000, which is 10 times more than you need.  That gives
you room to increase bandwidth and/or resolution.  If you really need 1KHz
output bandwidth, it will be better if the filters have their -3dB rolloff
point at 2KHz.  That eats up a factor of 4.  You can add another bit of
resolution to get 9 bits at a cost of another factor of 2.

So, you can comfortably do 9 bit PWM with 1KHz bandwidth and no more than
5mV p-p noise on a 0-5V signal.

> I'm being vague because I don't actually _know_ what will be an
> issue or not.  I haven't actually tried throwing filtered PWM output at
> the ECU yet, so I don't know.

What signal in the ECU will your analog output be controlling?

> Does anyone have a good digital oscilloscope trace from some filtered
> high kHz PWM output so we can see exactly what the ripple really is?

That's silly.  Do the math instead.  Once you've built it, you can use a
scope to verify that it's operating as expected.

> Well, on the chip I was mentioning, it had 2k WORD program space.  Last
> I used a C library on an ARM, as soon as I touched a floating point op,
> the compiler immediately pulled in ~20k of library code.

PICs aren't ARMs.

> While I
> realize it could be done much simpler in raw assembly, it still seems
> likely I'm going to have some issue with space.  If I switch to a bigger
> chip, it's obviously less of a problem, and it sounds like I'm going to
> have to switch to a bigger chip anyway.

You will probably have plenty of space, although you haven't answered what
exactly the PIC is supposed to be doing.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\16@182019 by David de Regt

flavicon
face
> No, the real question is how much noise can you tolerate, what
bandwidth
> does the signal require, and how much resolution do you need.
I'm not sure what you mean by bandwidth.  If you mean current, I can
just throw it through an opamp so the input current doesn't matter.

> OK, so we've at least got the start of a spec.  Let's say you want
less than
> 5mV p-p noise on a 0-5V signal with 1KHz bandwidth (what in an ECU
requires
> 1KHz control signal?) and 8 bit resolution.  The AC component of the
0-5V
> digital pulse train therefore needs to be attenuated by about 1000.  a
> 30F4012 can do 8 bit PWM at 30MHz / 255 = 118KHz.  That means a simple
> single pole RC filter with a 1KHz -3dB rollof point will attenuate the
> digital AC by over 100, which isn't good enough.  A two pole filter
will
> therefore do over 10,000, which is 10 times more than you need.  That
gives
> you room to increase bandwidth and/or resolution.  If you really need
1KHz
> output bandwidth, it will be better if the filters have their -3dB
rolloff
> point at 2KHz.  That eats up a factor of 4.  You can add another bit
of
> resolution to get 9 bits at a cost of another factor of 2.

> So, you can comfortably do 9 bit PWM with 1KHz bandwidth and no more
than
> 5mV p-p noise on a 0-5V signal.

Again, I guess I'm not sure what you mean by bandwidth.  For precision,
8 bits might be good enough, but 9 or 10 bit would be better, and the
signal will be updated to the ECU hopefully upwards of 100 times per
second.  The more updates, the smoother the drive, so there's no real
"requirement", it's just the more the better.

Also, in theory, thinking about it, 5mV ripple really might be too much.
In the lower end of my signal, rippling at 5mV might cause an
oscillation of up to 5 horsepower in either direction (10hp swing).
Although, I think the ARM unit I'm using for this right now has a fairly
imprecise DAC that was moving around at up to 10 mV, so I guess we can
work with 5mV and if it's not good enough drop another (RC pole filter?)
on it.

> What signal in the ECU will your analog output be controlling?

The air counter.  Wrong signal or significant oscillation (again, I
can't quantify "significant", but it's closer to the 1-10 Hz range)
sends the car into violent and dangerous bucking.

Thanks,
-David

2005\07\16@183203 by Jinx

face picon face
> Also, in theory, thinking about it, 5mV ripple really might be too
> much. In the lower end of my signal, rippling at 5mV might cause
> an oscillation of up to 5 horsepower in either direction (10hp swing).

At 1kHz ? Wow, that's some kind of switching response

2005\07\16@183357 by David de Regt

flavicon
face
> > Also, in theory, thinking about it, 5mV ripple really might be too
> > much. In the lower end of my signal, rippling at 5mV might cause
> > an oscillation of up to 5 horsepower in either direction (10hp
swing).

> At 1kHz ? Wow, that's some kind of switching response

I thought the way most ADCs worked was to lock the signal at a certain
time, and then successive approximation it.  So, it could lock the
signal at any point in the ripple, in theory, right?

-David

2005\07\17@074819 by olin piclist

face picon face
David de Regt wrote:
> I'm not sure what you mean by bandwidth.

Bandwidth is the frequency width over which your signal must be correct.  In
your case, "bandwidth" is the same as "maximum frequency".  Bandwidth is an
essential concept when messing with filters.

> Again, I guess I'm not sure what you mean by bandwidth.  For precision,
> 8 bits might be good enough, but 9 or 10 bit would be better, and the
> signal will be updated to the ECU hopefully upwards of 100 times per
> second.

If you are updating the D/A output value only 100 times per second (100Hz),
it can't possibly contain meaninful information above 50Hz.  This is a
fundamental theorum in digital sampling.  Look up "Nyquist" if you don't
believe me.

> The more updates, the smoother the drive, so there's no real
> "requirement", it's just the more the better.

Now you're waving your hands again.  Note that your statement above gives a
spec of inifinite frequency, which is both silly and useless.  You've
already implied that 100 times per second is pretty good.  Maybe 200Hz is
better, but somewhere it will stop making a measurable difference, or the
difference is too small to matter.  It will be impossible to design your
system without finding the requirements first.

> Also, in theory, thinking about it, 5mV ripple really might be too much.
> In the lower end of my signal, rippling at 5mV might cause an
> oscillation of up to 5 horsepower in either direction (10hp swing).
> Although, I think the ARM unit I'm using for this right now has a fairly
> imprecise DAC that was moving around at up to 10 mV, so I guess we can
> work with 5mV and if it's not good enough drop another (RC pole filter?)
> on it.

Huh?  First you say that 5mV ripple would cause unacceptable oscillation,
but then you say the existing system has 10mV noise and it's apparently
working.

Again, you need to characterize the engine and ECU before you're ready to
design your system around it.

>> What signal in the ECU will your analog output be controlling?
>
> The air counter.

Air counter sounds like something measuring air flow from discrete events,
so why do you need an analog output signal?  Doesn't the existing ECU take
this signal into account already?  I've asked several times, and you still
have explained very little about your overall system.  I'm going to wait for
a decent explanation before talking any more about PWM, filtering, etc.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\17@101130 by Mauricio Jancic

flavicon
face
David
       Hi, I don't want to be rude, ok, but please try to understand this
the right way. I'm just trying to help you here.

       You are trying to design a system and then connect it to the ECU
*before* you know what you really need. This is complicated in 2 ways. First
you will make software and hardware to perform operations that you don't
really need, second, you are not helping the people that is trying to help
you.
       I can understand the concept that you are trying to imply, by doing
everything with the highest standard and then it will certainly work, that
right. But there are other issues to contemplate:

1st. You will be working more than you really need
2nd. your hardware will cost much more than it needs to

So, how would someone proceed?
Well, firs you must characterize de response of the system that you are
controlling. Doing that, will allow you to know how the control signal must
be.

Then, (and only then) when you already know (quantitatively) what you need
to control and how to control it, you can start to think how to generate
such signals.

So, to end this rant, please tell us what the "air counter" does, how is
actually controlled, what is it controlling or whatever information you have
around.

Kind regards,

Mauricio Jancic
Janso Desarrollos - Microchip Consultants Program Member
.....infoKILLspamspam@spam@janso.com.ar
http://www.janso.com.ar
(54) 11 - 4542 - 3519

2005\07\17@165708 by David de Regt

flavicon
face
> > Again, I guess I'm not sure what you mean by bandwidth.  For
precision,
> > 8 bits might be good enough, but 9 or 10 bit would be better, and
the
> > signal will be updated to the ECU hopefully upwards of 100 times per
> > second.

> If you are updating the D/A output value only 100 times per second
(100Hz),
> it can't possibly contain meaninful information above 50Hz.  This is a
> fundamental theorum in digital sampling.  Look up "Nyquist" if you
don't
> believe me.

So by that are you saying that I might as well only update at 50 Hz, or
just that any ripple at over 50 Hz won't be noticed?  So, basically,
each analog sample by the ECU will be averaged over enough of a length
that any ripple over half the sampling frequency won't affect it?

> > The more updates, the smoother the drive, so there's no real
> > "requirement", it's just the more the better.

> Now you're waving your hands again.  Note that your statement above
gives a
> spec of inifinite frequency, which is both silly and useless.  You've
> already implied that 100 times per second is pretty good.  Maybe 200Hz
is
> better, but somewhere it will stop making a measurable difference, or
the
> difference is too small to matter.  It will be impossible to design
your
> system without finding the requirements first.

Well, the point is that I don't _know_ what the point of diminishing
returns is.  In my very first test system with limited equipment, I was
updating at 3-4 Hz, and that was vastly too slow.  In my current ARM
setup, I'm updating at a few hundred Hz (no idea exactly how many,
there's some weirdness in the serial output system and the timer that's
making it hard to tell) and that seems to be well more than enough.  So,
I'm interpolating that 100 Hz is _probably_ a good target.  I don't
actually know.  Also, at 6000 RPMs, starting to get near to redline, it
means that the engine is doing 100 revolutions per second, so 200 firing
events per second, so updating the ECU as to the status of the air
counter for every 2 firing events is probably good enough.  200 Hz would
be even better, because that'd be just about 1 firing event per update.
However, I'm guessing that doesn't actually matter and that 100 Hz is
somewhere well into the point of diminishing returns.  For all I truly
know, 10-15 Hz may be usable, I only know that 3-4 Hz wasn't good
enough.  Would it be significantly easier to go as low as 10 or 20 Hz?

However, I have to toss in a caveat that the ECU may do unknown
filtering on the input signal, so this all may be out the window.  The
problem is, it's impossible to tell, so I'm looking for as flexible a
solution as possible.  I'm basically taking a generated signal and
throwing it at a black box with unknown contents that's performing
unknown processing on it.  My job is to get enough equipment that I need
to mess with the signal and the function that generates the signal until
the car responds properly.

> > Also, in theory, thinking about it, 5mV ripple really might be too
much.
> > In the lower end of my signal, rippling at 5mV might cause an
> > oscillation of up to 5 horsepower in either direction (10hp swing).
> > Although, I think the ARM unit I'm using for this right now has a
fairly
> > imprecise DAC that was moving around at up to 10 mV, so I guess we
can
> > work with 5mV and if it's not good enough drop another (RC pole
filter?)
> > on it.

> Huh?  First you say that 5mV ripple would cause unacceptable
oscillation,
> but then you say the existing system has 10mV noise and it's
apparently
> working.

Given that I don't have access to an oscilloscope in the car, the best I
can do is, unfortunately, look at my handy-dandy radio shack 10$
multimeter while the output is happening, and it's usually moving around
by 10mV or so.  However, it's entirely as likely that it's actually
supposed to be moving around that much, because the signal's changing
constantly depending on tiny fluctuations in the airflow.

The 5mV ripple that I'm trying to interpolate for is that I know what
the airflow -> voltage function approximately looks like.  So, looking
at this, 5mV is the airflow for 3-5bhp in the upper end of things.  So,
while this is still at or above 200bhp, so it _hopefully_ is completely
masked, it's still something to keep in consideration.  This is why I
say "let's try 5mV", because I don't _know_ what it will do.  I'm saying
it's likely it will have minimal effect, so that's what I want to start
with.  To get lower I just need to keep tossing caps on anyway, so I can
always get more precise.

> Again, you need to characterize the engine and ECU before you're ready
to
> design your system around it.

As I mentioned above, the problem is it's really a black box.  So, the
only characterization I really have is that I've messed with it a lot,
and I have a lot of gut feelings from what I've tried inputting into it
and what its felt effects upon the car were.

>> What signal in the ECU will your analog output be controlling?
>
> The air counter.

> Air counter sounds like something measuring air flow from discrete
events,
> so why do you need an analog output signal?  Doesn't the existing ECU
take
> this signal into account already?  I've asked several times, and you
still
> have explained very little about your overall system.  I'm going to
wait for
> a decent explanation before talking any more about PWM, filtering,
etc.

Well, then allow me to expound a bit on what I'm trying to do.

The stock air counter (also known as an AFM) measures how much air is
entering the system.  It's basically the most important signal the ECU
sees.  When it knows how much air is entering the system, it then knows
how much fuel it should dump into the cylinder each detonation event to
hit a target air:fuel ratio for optimum power and engine safety.  So,
the air counter is constantly outputting a 0-5V signal for how much air
is flowing into the engine, and the ECU is constantly reading this and
adjusting the fuel injector duty cycles appropriately.

I'm trying to get rid of my stock AFM and switch to a different system
of monitoring air that's a combination of other sensors.  So, basically,
I'm taking input off a few other 0-5V analog devices (hence needing the
ADCs,) doing processing on the values according to some tables,
functions, and general logic (hence needing a pretty fast processor, and
my need for a pow(x,y) function,) and then outputting a new generated
analog signal (hence the need for a DAC of some sort) for the ECU to
read.

It's basically far and away the most important sensor signal that the
ECU reads and is what is totally dependent upon if the car makes any
power, no power, lots of power, drives smoothly or roughly, keeps the
car from flooding, flooding it, grenading under boost, etc.

If you need more specifics about any part of the system, just ask.

-David

2005\07\17@171032 by Dave VanHorn

flavicon
face

>
>So by that are you saying that I might as well only update at 50 Hz, or
>just that any ripple at over 50 Hz won't be noticed?  So, basically,
>each analog sample by the ECU will be averaged over enough of a length
>that any ripple over half the sampling frequency won't affect it?

There's a fundamental difference between a sampling ADC and an integrating ADC.
A sampling ADC will easily alias.

Let's say that you're sampling at 50 Hz, but for whatever reason,
there's some significant variation in the input that happens at 51 Hz.
What you'll see, is a replica of that signal, as a 1 Hz waveform that
does not exist.
If you then make decisions based on that, it could get pretty amusing.

With an integrating ADC, or a good filter in front of a sampling ADC,
this effect is minimized.

2005\07\17@174941 by olin piclist

face picon face
David de Regt wrote:
>> If you are updating the D/A output value only 100 times per second
>> (100Hz), it can't possibly contain meaninful information above 50Hz.
>> This is a fundamental theorum in digital sampling.  Look up "Nyquist"
>> if you don't believe me.
>
> So by that are you saying that I might as well only update at 50 Hz, or
> just that any ripple at over 50 Hz won't be noticed?  So, basically,
> each analog sample by the ECU will be averaged over enough of a length
> that any ripple over half the sampling frequency won't affect it?

No, this wasn't what I was saying at all.  Go look up Nyquist.

An analog signal updated to a new level at 100Hz can't contain meaninful
information past 50Hz.  But that says nothing about what the ECU requires,
only what is in your signal should you chose to update it 100 times per
second.

{Quote hidden}

Sounds like 200Hz bandwidth is a good spec for this purpose.  From an
earlier post you should be able to see that the PWM output of a 30F4012 can
easily achieve this with sufficiently low ripple and sufficiently high
resolution.

> However, I have to toss in a caveat that the ECU may do unknown
> filtering on the input signal, so this all may be out the window.

It probably does.  But it also sounds like its not filtering it any higher
than 200Hz, so that is a good spec to aim at from your end.

> Given that I don't have access to an oscilloscope in the car, the best I
> can do is, unfortunately, look at my handy-dandy radio shack 10$
> multimeter while the output is happening, and it's usually moving around
> by 10mV or so.

That tells you nothing about frequency content over a few Hz due to the
mechanical damping of the meter movement.  Even if you had 1 volt ripple at
50Hz, you'd never see it on the meter.

> So,
> the air counter is constantly outputting a 0-5V signal for how much air
> is flowing into the engine,

So why is it called an air *counter*?  The word counter implies discrete
events.  If so, it would be better to catch these directly by using an input
capture module than to convert them to analog, then back to digital again in
the PIC, then back to analog again to the ECU.

> I'm trying to get rid of my stock AFM and switch to a different system
> of monitoring air that's a combination of other sensors.

Why?  These systems were carefully designed.  I wouldn't mess with them
unless you really really know what you're doing.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\17@191229 by Jinx

face picon face
> > > an oscillation of up to 5 horsepower in either direction (10hp
> swing).
>
> > At 1kHz ? Wow, that's some kind of switching response
>
> I thought the way most ADCs worked was to lock the signal at a
> certain time, and then successive approximation it.  So, it could
> lock the signal at any point in the ripple, in theory, right?

Yes, 1kHz is no problem for ADC sampling, but the inference I
took was that the ECU could make the motor's output go up or
down by 5hp @ 1kHz. Even if it could direct the motor to do this,
surely mechanical inertia would prevent it happening

2005\07\17@193953 by David de Regt

flavicon
face
Nope.  You gain and lose power by injecting more or less fuel into a
cylinder for each ignition event.  You can go from 300hp to 0hp in 4
ignition events if no fuel goes into the cylinder.  Unfortunately,
mechanical inertia has nothing to do with it. :(

-David

{Original Message removed}

2005\07\17@195004 by David de Regt

flavicon
face
> No, this wasn't what I was saying at all.  Go look up Nyquist.

> An analog signal updated to a new level at 100Hz can't contain
meaninful
> information past 50Hz.  But that says nothing about what the ECU
requires,
> only what is in your signal should you chose to update it 100 times
per
> second.
Ohhh, you mean like if I was tossing in a sin wave or something, I can't
send anything useful at more than 50 Hz due to sampling errors, I'll get
weird beat patterns and utter nonsense output.  Yeah, okay, I know about
that.  I wasn't even thinking about that.  I'm not outputting sine waves
or anything, just voltage levels.  A given voltage corresponds to how
much air is going through.  So, usually, at 100Hz, it's not going to
change more than a few mV, if any, between updates.

> Sounds like 200Hz bandwidth is a good spec for this purpose.  From an
> earlier post you should be able to see that the PWM output of a
30F4012 can
> easily achieve this with sufficiently low ripple and sufficiently high
> resolution.
*nods*

> > Given that I don't have access to an oscilloscope in the car, the
best I
> > can do is, unfortunately, look at my handy-dandy radio shack 10$
> > multimeter while the output is happening, and it's usually moving
around
> > by 10mV or so.

> That tells you nothing about frequency content over a few Hz due to
the
> mechanical damping of the meter movement.  Even if you had 1 volt
ripple at
> 50Hz, you'd never see it on the meter.
Exactly, hence my problem with using that tool. =/

> So why is it called an air *counter*?  The word counter implies
discrete
> events.  If so, it would be better to catch these directly by using an
input
> capture module than to convert them to analog, then back to digital
again in
> the PIC, then back to analog again to the ECU.

> > I'm trying to get rid of my stock AFM and switch to a different
system
> > of monitoring air that's a combination of other sensors.

> Why?  These systems were carefully designed.  I wouldn't mess with
them
> unless you really really know what you're doing.

Believe it or not, I know exactly what I'm doing, and in my car is a
beta setup using an ARM chip to do this, that drives around fairly well.
I'm just trying to switch to an easier/simpler setup.  The ARM setup I'm
using has a bunch of odd quirks that's making it hard to do exactly what
I want, so I want to start over with something simpler and more
applicable to what I'm trying to do.

Also, air counter is just kinda a generic name for it.  Also, airbox,
air flow meter, etc.  In general, it's counting how much air is passing
through it.  There's a flap on a spring that opens and closes depending
on how much air is forcing it open, but there's always a continuous
stream of air holding it open to some position.  It's attached to a
potentiometer that then returns an analog signal from 0-5V saying how
open it is.  So, unfortunately, not discrete events at all.

In any event, last night I ordered a simple dev kit and a PIC16F88 for
30$, which looks to do what I want.  I just need to do some more
research on exactly how to hook up the filters on the PWM output to get
what I want.

Thanks for the help, sorry I was being so vague about it,
-David

2005\07\17@202058 by Dave Lag

picon face
Oh, a MAF
http://www.autoshop101.com/forms/h34.pdf


David de Regt wrote:

> Also, air counter is just kinda a generic name for it.  Also, airbox,
> air flow meter, etc.  In general, it's counting how much air is passing
> through it.  There's a flap on a spring that opens and closes depending
> on how much air is forcing it open, but there's always a continuous
> stream of air holding it open to some position.  It's attached to a
> potentiometer that then returns an analog signal from 0-5V saying how
> open it is.  So, unfortunately, not discrete events at all.

2005\07\17@204048 by David de Regt

flavicon
face
It's actually a VAM, but yes, same general idea.  I think h33 is the one
with the VAM description.

-David

{Original Message removed}

2005\07\18@055037 by Alan B. Pearce

face picon face
>Well, on the chip I was mentioning, it had 2k WORD program space.  Last
>I used a C library on an ARM, as soon as I touched a floating point op,
>the compiler immediately pulled in ~20k of library code.  While I
>realize it could be done much simpler in raw assembly, it still seems
>likely I'm going to have some issue with space.  If I switch to a bigger
>chip, it's obviously less of a problem, and it sounds like I'm going to
>have to switch to a bigger chip anyway.

I am still reading through the thread that came in over the weekend, so
haven't caught up on all the details yet.

However your description here sounds like you are using the wrong tools for
the job in hand. I suspect you should be looking at what you can do using
fixed point math rather than floating point. The signal that you get from
the ADC will be essentially fixed point, not floating point, and the same
goes for the DAC signal, so why is floating point being used between the
input and output?

2005\07\18@055323 by David de Regt

flavicon
face
Simple - typing:

WORD Output = pow(input,somepower);

is a lot easier than writing my own fixed point function, when the
compiler does it for me.  Rapid Application Development at its finest.

For the PIC, obviously I'm just going to have to write/find something
written in fixed point.

-David

{Original Message removed}

2005\07\18@061703 by Alan B. Pearce

face picon face
>Simple - typing:
>
>WORD Output = pow(input,somepower);
>
>is a lot easier than writing my own fixed point function, when the
>compiler does it for me.  Rapid Application Development at its finest.
>
>For the PIC, obviously I'm just going to have to write/find something
>written in fixed point.

Yes, but ----

As you have already discovered, the compiler is likely to pull in a heap of
floating point code to do the calculation (slow) and then convert it to
fixed point. Now this may be fine for a
get-you-up-and-running-to-test-the-idea type solution, but is not an
efficient way to do it, and also suggests that you may be missing or
introducing some underlying side effect which could have an effect on the
end performance.

Do think through the math and how to do it in fixed point (faster) and what
the calculation is actually doing.

2005\07\18@062026 by David de Regt

flavicon
face
Yep, I understood the compiler problems from the get-go.  However, the
fact that, in 15 seconds, I could type that line of code, and not have
to think about it, was very nice.  That's what initial testing was for.

The initial idea was just to see if the darn idea was going to work in
the first place.  And it most definitely did, so now it's time to find
the right tool for the job and get it actually working well. :)

I haven't had to do fixed point math in years.  This should be fun. :)

That and making this PWM stuff work.

-David

{Original Message removed}

2005\07\18@075358 by olin piclist

face picon face
David de Regt wrote:
> Ohhh, you mean like if I was tossing in a sin wave or something, I can't
> send anything useful at more than 50 Hz due to sampling errors, I'll get
> weird beat patterns and utter nonsense output.  Yeah, okay, I know about
> that.  I wasn't even thinking about that.  I'm not outputting sine waves
> or anything, just voltage levels.

Argh.  You really do need to learn something about signal theory before
trying to mess with filters.  Go look up Fourier.  You *are* sending sine
waves.  It's just that you are sending many of them superimposed so that
your signal doesn't look sinusoidal anymore, and mix of sine waves is
varying over time.  But you can still analyse the signal as a summation of
independent sine waves.  Again, go look up Fourier.

> Believe it or not, I know exactly what I'm doing,

Maybe with your car, but you've got a lot to learn about signal processing
and engineering in general.

> In any event, last night I ordered a simple dev kit and a PIC16F88 for
> 30$, which looks to do what I want.

Hmm, well it probably can.  Note that the 16F88 PWM is 6 times slower than
that of the 30F4012, but I think your requirements are low enough that the
'F88 can get the job done as far as analog input and output.  Don't come
complaining to me though when you can't get all the floating point math to
run at the speed you want.  This might be exactly the right chip for a
volume production design, but I don't understand why you don't want to give
yourself a little more headroom for $3-4 total on this one-off project.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\18@081634 by John J. McDonough

flavicon
face
----- Original Message -----
From: "David de Regt" <akillaspamKILLspamakilla.net>
Subject: RE: [PIC] Looking for a PIC with ADC, DAC, and UART...


> Simple - typing:
>
> WORD Output = pow(input,somepower);
>
> is a lot easier than writing my own fixed point function, when the
> compiler does it for me.  Rapid Application Development at its finest.

I've spent decades in control, and while this may be fine for scientific
calculation, for control it is a recipe for disaster.  When doing control,
it is very important to understand the range and precision, not only of all
the inputs an outputs, but also of all the intermediates.  If you don't get
into this habit, you WILL get yourself into trouble sooner or later.  Using
the floating point crutch will keep you from ever really understanding the
problem you are trying to solve.

The thread with Olin was a small example.  Here, of course, Olin was merely
pointing out that in the real world, you need a lot less complexity (cost)
than you might think.,  But lack of understanding of the problem can also
lead to more serious consequences.

OK, sure, if I'm flashing a LED what's the harm?   But you are proposing
controlling a car.  Your "Rapid Application Development at its finest" could
get someone killed.  Better to be sure you THOROUGHLY understand the
problem.

--McD

2005\07\18@093608 by Tim N9PUZ

picon face
> ----- Original Message ----- From: "David de Regt" <.....akillaKILLspamspam.....akilla.net>
> Subject: RE: [PIC] Looking for a PIC with ADC, DAC, and UART...
>
>
>> Simple - typing:
>>
>> WORD Output = pow(input,somepower);
>>
>> is a lot easier than writing my own fixed point function, when the
>> compiler does it for me.  Rapid Application Development at its finest.

As others have pointed out it's a good thing to really understand your
problem, especially when the consequences of an error are non-trivial.
Here's a starting point along with some code examples...

<http://www.embedded.com/showArticle.jhtml?articleID=15201575>

Tim

2005\07\18@100640 by Scott Dattalo

face
flavicon
face

On Mon, 2005-07-18 at 02:59 -0700, David de Regt wrote:
> Simple - typing:
>
> WORD Output = pow(input,somepower);
>
> is a lot easier than writing my own fixed point function, when the
> compiler does it for me.  Rapid Application Development at its finest.
>
> For the PIC, obviously I'm just going to have to write/find something
> written in fixed point.

David,

If you're going to write your own pow() function, then I'd suggest
Feynman's algorithm as described in Knuth's AOCP Vol 1. It's buried away
in the problems section of the first chapter. The algorithm is very
similar for the one to find a logarithm. Look at the 3rd implementation on
this page:

http://www.dattalo.com/technical/theory/logs.html

Scott

2005\07\18@170557 by David de Regt

flavicon
face
I come from a physics background, so I have lots of theory, but
basically nothing as it applies to reality.  So, yes, I know about
things like fourier analysis and all the theory behind it, but how it
applies to circuits is something I'm still learning from the ground up.
I make not claim to know what I'm doing with digital sampling.  I'm
learning completely from scratch here...

So I then take it that what you're saying is that if you're sampling at
100 Hz, the useful fourier coefficients are only the ones up through the
first 50 wavenumbers.  (Watch me be wrong again)

As for the 16F88, it was a cheap programmer kit, that came with a 16F88.
So, if it doesn't do what I want, I'll buy the 30F4012 and continue.  To
be honest, I'm really quite broke right now waiting for a check from a
lot of work I did earlier this year, so the fact that this kit was 30$
instead of a more advanced programmer that can program the 30 series was
the difference between being able to work on this now and working on it
in a few weeks.  So, while I'd love to get the right tool for the job
immediately, I don't have the money for it, yet.

In any event, this will let me get started and learn about how to filter
the PWM output.  Then, when and if I need to, I can upgrade to the
bigger chip.  I assume it will have very similar usage of PWM and ADC
registers, as well as very similar, if not equivalent, instruction set?

-David

{Original Message removed}

2005\07\18@174237 by Peter Onion

flavicon
face
On Mon, 2005-07-18 at 14:11 -0700, David de Regt wrote:

> So I then take it that what you're saying is that if you're sampling at
> 100 Hz, the useful fourier coefficients are only the ones up through the
> first 50 wavenumbers.  (Watch me be wrong again)
>

Yes, but the problem is that any component in the signal being sampled
that is higher than half the sampilng rate (Nyquist Rate) will appear as
a "mirror image" or "alias" in the sampled signal.  This is why ADCs
have and "anti-aliasing" filter on their input.  Ideal response would be
brick wall low pass at half the sampling rate of the ADC.

So, sampling at 100 samples a second,
Input 0Hz    Sampled 0Hz
Input 25Hz   Sampled 25Hz
Input 48Hz   Sampled 48Hz
Input 49Hz   Sampled 49Hz
Input 50Hz   Sampled 50Hz
Input 51Hz   Sampled 49Hz
Input 52Hz   Sampled 48Hz
Input 75Hz   Sampled 25Hz
Input 100Hz  Sampled 0Hz

Peter


2005\07\18@195206 by olin piclist

face picon face
David de Regt wrote:
> So I then take it that what you're saying is that if you're sampling at
> 100 Hz, the useful fourier coefficients are only the ones up through the
> first 50 wavenumbers.

I don't know what a "wavenumber" is.  If you're point sampling a continuous
signal at 100Hz, then only those input frequency up to 50Hz will be properly
represented in the sample stream.  The remaining frequencies "fold back" in
frequency space.  A 51Hz input will produce a 49Hz signal in the sample
stream.  A 99Hz input will produce a 1Hz output.  These signals that are not
at their original frequencies are called "aliases".

This is why the incoming signal is usually low pass filtered to attenuate
frequencies above 1/2 sample rate to levels that don't matter.  Digital
filters are more accurate and can implement techniques that would require
unrealizably accurate analog components.  For this reason, often there is
some analog filtering, then an A/D running several times faster than needed,
then a digital "decimation" filter that reduces the sample stream to the
minimum rate needed.  That allows the analog filter to be sloppy and
conservative, then the remaining more accurate filtering is done digitally,
which can cut closer and sharper at the desired frequency.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\18@195630 by Dave VanHorn

flavicon
face

>  That allows the analog filter to be sloppy and
>conservative, then the remaining more accurate filtering is done digitally,
>which can cut closer and sharper at the desired frequency.

And without those interesting phase shift problems!  :)

2005\07\18@204232 by Dwayne Reid

flavicon
face
At 03:13 PM 7/16/2005, David de Regt wrote:

>Well, the real question I suppose, is that if it's in the kHz range,
>what is going to be the magnitude of the ripple?  If it's oscillating
>back and forth in the microvolt range, that'll be fine.  However, I
>suspect anything greater than a few millivolts is going to cause an
>issue.  I'm being vague because I don't actually _know_ what will be an
>issue or not.  I haven't actually tried throwing filtered PWM output at
>the ECU yet, so I don't know.

OK - so find out.

Grab a DC power supply and put a 1K resistor in series with the output -
feed the free end of the resistor to the control input on the ECU.  Now
take a function generator and use a fairly large capacitor (100uF) to
couple the AC signal from the function generator to the ECU.

Note that you can now set the DC level into the ECU to what you need, then
adjust the function generator to various voltages and frequencies to see
the effects.  A triangle wave shape will most likely be the closest to what
comes out of the PWM filter.

dwayne

--
Dwayne Reid   <EraseMEdwaynerspam_OUTspamTakeThisOuTplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 21 years of Engineering Innovation (1984 - 2005)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

2005\07\18@224853 by David de Regt

flavicon
face
I don't own a function generator, so as much as I'd like to do this, I
can't do it until I get a PIC and start generating my own stuff. :(

-David

{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...