Searching \ for '[PIC] Hysteresis routine?' 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/devices.htm?key=pic
Search entire site for: 'Hysteresis routine?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Hysteresis routine?'
2005\06\14@015726 by PicDude

flavicon
face
Hey folks,

Got a problem here with a PIC application where the lowest (rightmost) digit
of a numerical value is "toggling" back and forth between 2 (consecutive)
values rapidly -- example it will jump back and forth between 283 and 284
rapidly (like 3-4 times a second, which is the update rate on the display).

The app repeatedly samples values from an A/D port, performs calcs and
displays the result on the numerical LED's.  It also has some averaging and a
software IIR filter, which after some experimentation, has significantly
reduced the occassions when it toggles, but has not eliminated it.  An error
of +/-1 is not a problem, so a hysteresis routine should work well.  Is there
such a thing?

I've come up with a routine that is somewhat crude -- it keeps track of the
last 3 calculated values (sort of a FIFO), and if a new value varies by
exactly +/-1 from the last displayed value, then it does not immediately
update the display -- it waits until that new value is the result for 3
consecutive cycles.  If it goes back to the last displayed value within the
next 2 cycles, then no change will be seen.  If the change is more than 1 at
any time, it updates the display immediately.  But I'm guessing there's a
better way -- is there?

Cheers,
-Neil.


2005\06\14@064035 by Spehro Pefhany

picon face
At 01:03 AM 6/14/2005 -0500, you wrote:


>I've come up with a routine that is somewhat crude -- it keeps track of the
>last 3 calculated values (sort of a FIFO), and if a new value varies by
>exactly +/-1 from the last displayed value, then it does not immediately
>update the display -- it waits until that new value is the result for 3
>consecutive cycles.  If it goes back to the last displayed value within the
>next 2 cycles, then no change will be seen.  If the change is more than 1 at
>any time, it updates the display immediately.  But I'm guessing there's a
>better way -- is there?
>
>Cheers,
>-Neil.

How about not updating the display unless the difference from the displayed
value is > x,  (and set x = 1) ?

>Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2005\06\14@065728 by Alan B. Pearce

face picon face
>How about not updating the display unless the difference
>from the displayed value is > x,  (and set x = 1) ?

Trouble is you do want it to show a drift in value, and I think he has it
set about right, but possibly needs to expand the count out to about 5 or 6
from 3, for the number of counts where it needs to be 1 different from the
current display value.

2005\06\14@074609 by Spehro Pefhany

picon face
At 11:57 AM 6/14/2005 +0100, you wrote:
> >How about not updating the display unless the difference
> >from the displayed value is > x,  (and set x = 1) ?
>
>Trouble is you do want it to show a drift in value, and I think he has it
>set about right, but possibly needs to expand the count out to about 5 or 6
>from 3, for the number of counts where it needs to be 1 different from the
>current display value.

I guess it depends on the application whether a trend is important. If it's
something like a weigh scale, it might not be important. Once the number
settles, that's it.

I am wary of the "number of counts the same" because it changes the
behavior based on the noise in the signal, which could be different in
the field.

He could also implement a slow low-pass filter and preload it to improve the
response to large step changes (nonlinear filter). Obviously the internal
calculations would be done to a higher resolution than the display.

I usually work very hard to make the system much better than the display,
usually throwing away a decimal digit or more of resolution to get a good
solid display, but then I'm a persnickety instrument engineer type. I don't
want the user to lose confidence in the instrument.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam@spam@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2005\06\14@081328 by olin piclist

face picon face
PicDude wrote:
> Got a problem here with a PIC application where the lowest (rightmost)
> digit of a numerical value is "toggling" back and forth between 2
> (consecutive) values rapidly -- example it will jump back and forth
> between 283 and 284 rapidly (like 3-4 times a second, which is the
> update rate on the display).

That is expected when taking real world measurements.  No amount of linear
filtering can prevent the resulting signal from going back and forth accross
a specific threshold.

> I've come up with a routine that is somewhat crude -- it keeps track of
> the last 3 calculated values (sort of a FIFO), and if a new value
> varies by exactly +/-1 from the last displayed value, then it does not
> immediately update the display -- it waits until that new value is the
> result for 3 consecutive cycles.  If it goes back to the last displayed
> value within the next 2 cycles, then no change will be seen.  If the
> change is more than 1 at any time, it updates the display immediately.
> But I'm guessing there's a better way -- is there?

The first thing to ask is why the display update needs to be so fast.  If
numbers changing every update is annoying or diffucult to read, then it
sounds like the display is being updated to quickly.  Try every 250-500mS.


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

2005\06\14@083309 by Mike Hord

picon face
> I've come up with a routine that is somewhat crude -- it keeps track of the
> last 3 calculated values (sort of a FIFO), and if a new value varies by
> exactly +/-1 from the last displayed value, then it does not immediately
> update the display -- it waits until that new value is the result for 3
> consecutive cycles.  If it goes back to the last displayed value within the
> next 2 cycles, then no change will be seen.  If the change is more than 1 at
> any time, it updates the display immediately.  But I'm guessing there's a
> better way -- is there?

Median filter?  Take, say, 5 samples, put them in increasing order from least
to greatest, then take sample 3.

Mike H.

2005\06\14@090644 by olin piclist

face picon face
Mike Hord wrote:
> Median filter?  Take, say, 5 samples, put them in increasing order from
> least to greatest, then take sample 3.

That still can't gurantee no bounces from sample to sample.

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

2005\06\14@100308 by Dave Tweed

face
flavicon
face
olin_piclist@embedinc.com (Olin Lathrop) wrote:
> Mike Hord wrote:
> > Median filter?  Take, say, 5 samples, put them in increasing order
> > from least to greatest, then take sample 3.
>
> That still can't gurantee no bounces from sample to sample.

You can always come up with a series of samples to defeat any filter.

A median-value filter is a fairly standard approach to this problem.
It tends to preserve the underlying signal "waveform" fairly well while
filtering out glitches that are less than half the filter length. Its
primary drawback is the delay it introduces -- half the filter length,
just like any other symmetric FIR filter.

Since the implementation involves a sorting operation instead of a dot
product (multiply-add), it is well suited to smaller processors with no
hardware multiplier.

-- Dave Tweed

2005\06\14@110351 by Gerhard Fiedler

picon face
Spehro Pefhany wrote:

> How about not updating the display unless the difference from the displayed
> value is > x,  (and set x = 1) ?

This may get you calls from the customer why for slowly changing signals
the display always updates in increments of 2  :)

I actually think Neil's schema makes sense.

Gerhard

2005\06\14@111522 by Spehro Pefhany

picon face
At 12:03 PM 6/14/2005 -0300, you wrote:
>Spehro Pefhany wrote:
>
> > How about not updating the display unless the difference from the displayed
> > value is > x,  (and set x = 1) ?
>
>This may get you calls from the customer why for slowly changing signals
>the display always updates in increments of 2  :)

If the difference is less than, say, 3, you could have it change a maximum
of one per update. ;-)


>I actually think Neil's schema makes sense.
>
>Gerhard

Maybe, it's pretty situational, IMHO.

I'm trying to simulate a "sticky (meter) needle".

>Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffspamKILLspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2005\06\14@112206 by Bill & Pookie

picon face
Very interesting.  I have denounced a lot of  switches and led detectors,
but never "data".  The difference being that switches have two states and
data has many states depending on the number of bits.

There for, your data can be bouncing the LSB (Least significant Bit) and
then get go to a value that changes some of the other bits.  And you will
ignore the new value as long as the LSB keeps bouncing in the new value.
That would be bad.

To keep this from happening, would use a counter that was reset every time
the display was refreshed with new data and count down the timer every time
the data was not refreshed due to it bouncing.

The data may go from one unstable value to another unstable and not be
considered good data.  To keep this from happing, be sure to  use the
current data (stable or not) every so often..

A simplest way of denouncing would be to shift into a byte the LSB of the
data and if the resulting 3 or four bits are all 1's or 0"s then it is
stable.  Or more demanding and less simple is to compare the 4 LSB's of the
current reading to previous readings.

While thinking of buffers to hold a history of data, the normal way seems to
be to use a FIFO  (First In First Out) buffer.  And the data has to be
bumped up each time, which takes time.  What if a rotating buffer was used
where the new data was place in the next spot and a counter (modulo the
buffer size) was incremented.  But instead of incrementing the counter,
increment a state flag and have the program test this flag each time and run
code customized for that state (where things are in the buffer).  That would
require more code but less code would run each time.  Hummm

Bill


{Original Message removed}

2005\06\14@113644 by PicDude

flavicon
face
On Tuesday 14 June 2005 05:46 am, Spehro Pefhany scribbled:
> How about not updating the display unless the difference from the displayed
> value is > x,  (and set x = 1) ?

Prob here will be that if a value legitimately changes by 1 and stays there,
the display will never show it.  Now that 1 is not critical, but the routine
I have now will eventually put it there.  Perhaps I should stretch that out
to wait a longer number of cycles before deciding that it's okay....hmmm?

Cheers,
-Neil.


2005\06\14@114241 by PicDude

flavicon
face
On Tuesday 14 June 2005 05:57 am, Alan B. Pearce scribbled:
> Trouble is you do want it to show a drift in value, and I think he has it
> set about right, but possibly needs to expand the count out to about 5 or 6
> from 3, for the number of counts where it needs to be 1 different from the
> current display value.

Hey!  I just said this in another email 2 seconds ago.  Great minds.... :-)

I'm probably going to have to experiment with this, but I can't right now --
the code is about 4 bytes short of the first page boundary (and I've gone
thru it quite a bit to try and clean up/optimize), so any other new code will
require some mods to move some routines to the next code-page.  First time I
have ever needed to go past the 2k boundary, so it will require some careful
planning on my part.

Cheers,
-Neil.


2005\06\14@115216 by Spehro Pefhany

picon face

>Prob here will be that if a value legitimately changes by 1 and stays there,
>the display will never show it.  Now that 1 is not critical, but the routine
>I have now will eventually put it there.  Perhaps I should stretch that out
>to wait a longer number of cycles before deciding that it's okay....hmmm?
>
>Cheers,
>-Neil.

Suppose you low-pass filter the value (calculating to a resolution of, say,
1/8 or 1/16 count count)? Will that respond too slowly?

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam.....interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2005\06\14@115446 by olin piclist

face picon face
PicDude wrote:
> I'm probably going to have to experiment with this, but I can't right
> now -- the code is about 4 bytes short of the first page boundary (and
> I've gone thru it quite a bit to try and clean up/optimize), so any
> other new code will require some mods to move some routines to the next
> code-page.  First time I have ever needed to go past the 2k boundary,
> so it will require some careful planning on my part.

So how fast are you updating the display?

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

2005\06\14@115635 by PicDude

flavicon
face
On Tuesday 14 June 2005 06:51 am, Spehro Pefhany scribbled:
> He could also implement a slow low-pass filter and preload it to improve
> the response to large step changes (nonlinear filter). Obviously the
> internal calculations would be done to a higher resolution than the
> display.

Sounds interesting, but I'm not sure that I'm totally clear on what you mean
here.  Are you referring to the IIR software filter?  I have implemented this
in the code, which does make things a lot nicer than the previous
circular-buffer averaging routine, but after much tweaking I've come up with
the value of K that lets the display be responsive enough.  That left me with
a bit of toggling on the last digit still.  I would think that a smaller K
would reduce/eliminate the toggling, but would also make changes in general
less responsive.

If by "nonlinear", you mean that K would vary depending on the amount of the
change, then that sounds awesome here on paper.  Is there a recommendation on
how to do this and derive decent initial values of K?  Or am I way off track
here?

Another thought that this brings up is that I might try changing the *rate* of
display updates based on the amount of the change.  The lower the change, the
longer the display holds before changing.  This might be easy-ish to
implement by adding successive change amounts and allowing the display to
change only after the total reaches a certain value.  I'll have to think
about this more.

Cheers,
-Neil.



2005\06\14@115809 by PicDude

flavicon
face
On Tuesday 14 June 2005 07:13 am, Olin Lathrop scribbled:
> The first thing to ask is why the display update needs to be so fast.  If
> numbers changing every update is annoying or diffucult to read, then it
> sounds like the display is being updated to quickly.  Try every 250-500mS.

The update rate has been set based on real-world use -- how fast the display
moves once the signal changes.  I'd prefer not to make that any slower now,
and if possible, I'd like to get it a bit fast eventually.

Cheers,
-Neil.


2005\06\14@120136 by PicDude

flavicon
face
On Tuesday 14 June 2005 07:33 am, Mike Hord scribbled:
> Median filter?  Take, say, 5 samples, put them in increasing order from
> least to greatest, then take sample 3.


Hmmm... I just googled on this and it looks interesting/useful.  I'll put some
sample values on paper to see how it could/would work, compared to averaging,
etc.

Thanks,
-Neil.


2005\06\14@120300 by Peter Onion

flavicon
face
On Tue, 2005-06-14 at 01:03 -0500, PicDude wrote:
> Hey folks,
> It also has some averaging and a
> software IIR filter, which after some experimentation, has significantly
> reduced the occassions when it toggles, but has not eliminated it.

If you already have the code in place for IIR filter, and it has
improved things, then I would try increasing the number of taps in your
filter so that more samples are taken into account.  Personally IIR
filters give me nightmares so I stick to FIR ones where I can make a
reasonable prediction of their behaviour with nothing more that a pencil
and a sheet of squared paper ;-)

Peter


2005\06\14@122929 by Scott Dattalo

face
flavicon
face
PicDude wrote:

> Got a problem here with a PIC application where the lowest (rightmost) digit
> of a numerical value is "toggling" back and forth between 2 (consecutive)
> values rapidly -- example it will jump back and forth between 283 and 284
> rapidly (like 3-4 times a second, which is the update rate on the display).

Neil,

Here's a 2-sample hysteresis filter:

  current_sample = filtered_data();

  if ( (current_sample == last_sample) ||
       (abs(current_sample - displayed_sample) > THRESHOLD))
    displayed_sample = current_sample;

  last_sample = current_sample;

This cuts the flicker rate in half. To reduce it more, you can increase
the number of required consecutive samples from 2 to N and save the last
N-1 samples in an array.


Scott

2005\06\14@123742 by Bill Cornutt

picon face
Mr. Dattalo,

How would your fantastic switch debounce work if used to debounce a byte or
all bytes of the data?

Bill

{Original Message removed}

2005\06\14@132830 by olin piclist

face picon face
Peter Onion wrote:
> If you already have the code in place for IIR filter, and it has
> improved things, then I would try increasing the number of taps in your
> filter so that more samples are taken into account.  Personally IIR
> filters give me nightmares so I stick to FIR ones where I can make a
> reasonable prediction of their behaviour with nothing more that a pencil
> and a sheet of squared paper ;-)

Not all IIR filters are hard to analize or finnicky.  Consider

 FILT <-- FILT + FF*(NEW - FILT)

This is a simple single pole low pass filter, and the equivalent of an
analog R/C filter.  That's about as easy as it gets.


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

2005\06\14@135031 by PicDude

flavicon
face
On Tuesday 14 June 2005 09:03 am, Dave Tweed scribbled:
> A median-value filter is a fairly standard approach to this problem.
> It tends to preserve the underlying signal "waveform" fairly well while
> filtering out glitches that are less than half the filter length. Its
> primary drawback is the delay it introduces -- half the filter length,
> just like any other symmetric FIR filter.

Therein lies a problem -- significant/noticeable delays would be unacceptable.  
This is one reason I scaled back significantly on the amount of averaging,
and added the IIR filter code.  I'm still going to experiment with this a bit
to see if/how it helps.

Cheers,
-Neil.


2005\06\14@142041 by PicDude

flavicon
face
On Tuesday 14 June 2005 10:22 am, Bill & Pookie scribbled:
> Very interesting.  I have denounced a lot of  switches and led detectors,
> but never "data".  The difference being that switches have two states and
> data has many states depending on the number of bits.

Interesting perspective -- I would not have thought to analogize it with
debouncing a switch.  But now it has me thinking about the similarities.  [
For switch debouncing, I have a timer set a flag indicating it's time to read
switches.  When the main code loop sees the flag, it reads all inputs and
shifts each into a byte that is setup as a shift register for a particular
switch.  At that point, the switch processing routine compares the latest 2
bits for "00" (no change), "11" (switch still held down), "01" (switch just
pressed), and "10"  (switch just released), and acts accordingly depending on
what's needed.  Controlling debouncing is just a matter of setting the
correct timer 1 frequency.  Works beautifully! ]  One of the big diffs I see
here is that with a switch, when the input changes to a value (say from 0/OFF
to 1/ON), I know for a fact that the switch was pressed, no matter how short
the duration.  In the case of data, a change can mean noise based on the
duration.  So I don't think these are really analogous.


> There for, your data can be bouncing the LSB (Least significant Bit) and
> then get go to a value that changes some of the other bits.  And you will
> ignore the new value as long as the LSB keeps bouncing in the new value.
> That would be bad.

Not sure what you exactly mean here -- are you referring to the data bouncing
between say 99 and 100?  Where a change in the LSB will affect all the other
bits to the left?  If so, this is not a problem in my existing routine, since
I'm comparing the last vs. current *values* and looking for a change of +/-1
-- not just a change in the LSB.


{Quote hidden}

How does this differ then the routine I'm experimenting with now (where it
waits to see if a value (with a change of just +/-1) holds for 3 cycles
currently before sending it to the display)?

> While thinking of buffers to hold a history of data, the normal way seems
> to be to use a FIFO  (First In First Out) buffer.  And the data has to be
> bumped up each time, which takes time.  What if a rotating buffer was used
> where the new data was place in the next spot and a counter (modulo the
> buffer size) was incremented.  But instead of incrementing the counter,
> increment a state flag and have the program test this flag each time and
> run code customized for that state (where things are in the buffer).  That
> would require more code but less code would run each time.  Hummm

You are referring to a circular buffer, right?  Since I was checking only 3
cycles for now, I did this manually for now.  A circular buffer would've
taken more code space, which I was trying to squeeze to stay within the first
2k code page.  But if I stretch this out to more cycles, I will probably have
to convert to this.

Cheers,
-Neil.



2005\06\14@142415 by PicDude

flavicon
face
On Tuesday 14 June 2005 10:57 am, Spehro Pefhany scribbled:
> Suppose you low-pass filter the value (calculating to a resolution of, say,
> 1/8 or 1/16 count count)? Will that respond too slowly?

Pretty sure it will.  I'm using 1/4 now IIRC, which is just right for display
update rate, as determined by experimentation.  Input stimulus can change a
large amount in relatively short time, and anything less than 1/4 makes the
change slow on the display.  I like the non-linear filter idea, so need to
put some thought into that.  I think it will let me have the best of both
worlds.

Cheers,
-Neil.


2005\06\14@142446 by PicDude

flavicon
face
On Tuesday 14 June 2005 10:55 am, Olin Lathrop scribbled:
> So how fast are you updating the display?

IIRC about 4-5 times a second.
-Neil.

2005\06\14@142520 by Peter Onion

flavicon
face
On Tue, 2005-06-14 at 13:28 -0400, Olin Lathrop wrote:

> Not all IIR filters are hard to analize or finnicky.  Consider
>
>   FILT <-- FILT + FF*(NEW - FILT)
>
> This is a simple single pole low pass filter, and the equivalent of an
> analog R/C filter.  That's about as easy as it gets.

The exception that proves the rule Olin !  ;-)

But I take your point,

Peter



2005\06\14@142542 by Peter

picon face

On Tue, 14 Jun 2005, PicDude wrote:

> Got a problem here with a PIC application where the lowest (rightmost) digit
> of a numerical value is "toggling" back and forth between 2 (consecutive)
> values rapidly -- example it will jump back and forth between 283 and 284
> rapidly (like 3-4 times a second, which is the update rate on the display).

> better way -- is there?

Not really. This problem is inherent with noise on A/D converters. You
did a low pass filter with an override rule. It will solve the problem
only for high frequency noise, as you seem to have. What you can do is
take each two consecutive values and average them. This yields one extra
bit of precision (at half the ad rate). The extra bit will 'toggle' as
above but at half the speed. This is a basic low pass filter. You can
extend this as you did to three or more samples. It depends on the type
of noise you have.

Overriding the low pass filter is not necessarily a good idea. For
example if the signal is then used in a pid loop the 'extra' rule of
changing the output immediately if it changes by more than 1 count is
equivalent with extra (nonlinear) D gain in the pid loop. Then if you
adjust the loop for correct coefficients for fast change it will have
too low D for small changes and precision will not be good near the
setpoint. taintstafl. The fix consists in allowing the noise into the
pid and setting a deadband at the *output* of the pid in this case.

Peter

2005\06\14@142858 by PicDude

flavicon
face
On Tuesday 14 June 2005 11:29 am, Scott Dattalo scribbled:
> Neil,
>
> Here's a 2-sample hysteresis filter:
>
>    current_sample = filtered_data();
>
>    if ( (current_sample == last_sample) ||
>         (abs(current_sample - displayed_sample) > THRESHOLD))
>      displayed_sample = current_sample;
>
>    last_sample = current_sample;
>
> This cuts the flicker rate in half. To reduce it more, you can increase
> the number of required consecutive samples from 2 to N and save the last
> N-1 samples in an array.


That's pretty much what I'm doing now (except in assembly), except that it
seems in this case, a change of <= THRESHOLD which never get updated on the
display no matter how long that value holds.

Cheers,
-Neil.


2005\06\14@143027 by Peter

picon face

On Tue, 14 Jun 2005, Spehro Pefhany wrote:

> How about not updating the display unless the difference from the displayed
> value is > x,  (and set x = 1) ?

In that case, how do you adjust the value precisely (assume it has to be
adjusted to the nearest LSB with a screwdriver and a trimmer, the
display shows 125 and you need to adjust 126). Exercise in frustration ?

Low pass filtering is the only viable solution. A display should not
change more than 4 times per second if someone is to make sense of it
anyway, slower for most physical values. Usually you can low pass enough
to achieve this since ad frame rate is often hundreds of times faster
than this. Low pass with 8 or more steps is usually drastic enough.

Peter

2005\06\14@144509 by Spehro Pefhany

picon face
At 09:30 PM 6/14/2005 +0300, you wrote:

>On Tue, 14 Jun 2005, Spehro Pefhany wrote:
>
>>How about not updating the display unless the difference from the displayed
>>value is > x,  (and set x = 1) ?
>
>In that case, how do you adjust the value precisely (assume it has to be
>adjusted to the nearest LSB with a screwdriver and a trimmer, the display
>shows 125 and you need to adjust 126). Exercise in frustration ?

Yes, indeed, unless you have a bypass for calibration.

>Low pass filtering is the only viable solution. A display should not
>change more than 4 times per second if someone is to make sense of it
>anyway, slower for most physical values. Usually you can low pass enough
>to achieve this since ad frame rate is often hundreds of times faster than
>this. Low pass with 8 or more steps is usually drastic enough.
>
>Peter

Depends. I've has some applications where a simple LPF would never do the
trick.

Large process variable variation (due to constraints on the actuator) and
excessively fine display resolution (customer imposed constraint) and
an integrating process.

>Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
EraseMEspeffspam_OUTspamTakeThisOuTinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2005\06\14@145906 by Scott Dattalo

face
flavicon
face
PicDude wrote:
{Quote hidden}

If the least significant digit is fluttering around, then this
hysteresis will reduce the flicker rate. If the sample is bouncing
around by more than 1-count but less than the threshold, then this
routine will not necessarily track the change. That's because it *is* a
hysteresis filter. You may wish to examine the routine again. Here's the
behavior for sample data for a THRESHOLD = 2:

curr displayed
 283    ???
 283    283
 285    285
 284    285
 285    285
 286    285
 287    287
 286    287
 286    286

In this contrived example, the value 285 remains steady even though the
data bounces around it. Only when the data exceeds the threshold do we
see the displayed value change.

Scott

2005\06\14@152156 by Spehro Pefhany

picon face
At 11:02 AM 6/14/2005 -0500, you wrote:
>If by "nonlinear", you mean that K would vary depending on the amount of the
>change, then that sounds awesome here on paper.  Is there a recommendation on
>how to do this and derive decent initial values of K?  Or am I way off track
>here?

No, you're not off track. You could take the reading (with minimal LPF) and
compare it to the displayed variable. If the difference exceeds a threshold
you preload the variable (essentially set K = 0). That way you can tolerate
a very long filter time constant because it only affects the last few counts.
You could try more levels than just two but it might not be necessary.

As Olin points out, it's possible with any of the "non-sticky" schemes that
the variable sits on the edge of a threshold long term and flickers back
and forth. You can make that less likely, but it's still probably possible.

If you added a smidge of stickiness you could eliminate even that, but that
adds some complexity. For example, suppose for the moment you have the number
y = x * 10 available and are going to display d, to approximate x /10;
(d is the previous display variable).

y += ((y-10*d)> 5) ? -2:+2;
d = y/10;

Will give you just a whisper of stickyness. Probably enough to be irritating
if you're using pots to calibrate the old-fashioned and time-tested way. ;-)
If you're doing calibration in EEPROM, of course, you just use the original
value of y.

Of course you'd probably prefer to do this in powers of two and maybe in
assembly,
the C code and base-10 is just for pedagogic piclist purposes.

>Another thought that this brings up is that I might try changing the
>*rate* of
>display updates based on the amount of the change.  The lower the change, the
>longer the display holds before changing.  This might be easy-ish to
>implement by adding successive change amounts and allowing the display to
>change only after the total reaches a certain value.  I'll have to think
>about this more.

Might be the equivalent of some other schemes that have been discussed.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffspamspam_OUTinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2005\06\14@172110 by olin piclist

face picon face
PicDude wrote:
>> So how fast are you updating the display?
>
> IIRC about 4-5 times a second.

Why so fast?  It takes a certain amount of time to see a bunch of blinky
lights, recognize them as a number, comprehend that number, then do
something with the information.  If you go too fast, you annoy people that
the number changed before they had fully internalized the previous one.  I
think 5Hz is probably over that limit or at least near it.  Take a look at a
normal digital voltmeter.  I think you'll find the update rate is more like
2-3Hz.  I'm sure Fluke and other put some thought into this.  Why not just
do what they did?  If your display bounced between adjacent numbers every
500mS, I doubt it would be all that annoying.


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

2005\06\14@201949 by PicDude

flavicon
face
On Tuesday 14 June 2005 01:25 pm, Peter scribbled:
> ...
> Overriding the low pass filter is not necessarily a good idea. For
> example if the signal is then used in a pid loop the 'extra' rule of
> ...

In this case though, this is not part of a PID loop.  This is the final
output.

Cheers,
-Neil.

2005\06\14@202847 by PicDude

flavicon
face
On Tuesday 14 June 2005 01:58 pm, Scott Dattalo scribbled:
{Quote hidden}

Okay, now I got ya.  I was interpreting your "last_sample" variable to mean
"last displayed" sample.  What I now see here it that this is exactly what I
was doing initially, but got noticeable digit toggling still.  This is when I
extended it to 3 cycles.  I'm guessing at this point, that extending the
testing out to more than 3 cycles will help a lot.  When I posted the
question originally, I was really hoping there was some algorithm that I had
not heard of before that would take care of this (expectedly common) problem.
:-(

On the side, since you mention abs(), is there a neat trick/way in PIC
assembly to calculate abs(x-y)?  I'm currently doing the subtraction, and
then explicitly comparing for -1 or +1.  (Actually, I'm adding 1 after the
subtraction, then comparing for 0 or 2).

Cheers,
-Neil.



2005\06\14@203241 by PicDude

flavicon
face
On Tuesday 14 June 2005 02:27 pm, Spehro Pefhany scribbled:
> No, you're not off track. You could take the reading (with minimal LPF) and
> compare it to the displayed variable. If the difference exceeds a threshold
> you preload the variable (essentially set K = 0). That way you can tolerate
> a very long filter time constant because it only affects the last few
> counts. You could try more levels than just two but it might not be
> necessary.
>
> As Olin points out, it's possible with any of the "non-sticky" schemes that
> the variable sits on the edge of a threshold long term and flickers back
> and forth. You can make that less likely, but it's still probably possible.

Exactamundo.  And I am still noticing this.


> If you added a smidge of stickiness you could eliminate even that, but that
> adds some complexity. For example, suppose for the moment you have the
> number y = x * 10 available and are going to display d, to approximate x
> /10; (d is the previous display variable).
>
> y += ((y-10*d)> 5) ? -2:+2;
> d = y/10;
>

Maybe it's late, I'm hungry, or both, but I can't get a clear picture of the
result of this in my head.  I need to plot some values on paper and track
this.... after dinner though.


> Will give you just a whisper of stickyness. Probably enough to be
> irritating if you're using pots to calibrate the old-fashioned and
> time-tested way. ;-) If you're doing calibration in EEPROM, of course, you
> just use the original value of y.

No pots here.


> Of course you'd probably prefer to do this in powers of two and maybe in
> assembly,
> the C code and base-10 is just for pedagogic piclist purposes.

Gotcha.

Cheers,
-Neil.



2005\06\14@203739 by PicDude

flavicon
face
On Tuesday 14 June 2005 04:21 pm, Olin Lathrop scribbled:
> PicDude wrote:
> >> So how fast are you updating the display?
> >
> > IIRC about 4-5 times a second.
>

First a correction.  Since posting that, I measured it and it seems to be
about 3.5-4 times per second.


> Why so fast?  It takes a certain amount of time to see a bunch of blinky
> lights, recognize them as a number, comprehend that number, then do
> something with the information.  If you go too fast, you annoy people that
> the number changed before they had fully internalized the previous one.  I
> think 5Hz is probably over that limit or at least near it.  Take a look at
> a normal digital voltmeter.  I think you'll find the update rate is more
> like 2-3Hz.  I'm sure Fluke and other put some thought into this.  Why not
> just do what they did?  If your display bounced between adjacent numbers
> every 500mS, I doubt it would be all that annoying.

Yes and no.  The display output goes to both a numerical output and a bargraph
(24 leds).  The bargraph output looks really sluggish if slowed down more,
but you're correct that the numerical output gets jumpy.  So far though, with
the filtering, the numerical output is not that bad/annoying for quick
changes when it is following a trend and going towards one direction.  But
the digit toggling is a royal pain.

I can probably guess what you are thinking now, and I have been fearing doing
that -- ie: using independent IIR filters for the bargraph and numerical
outputs.  :-(

Cheers,
-Neil.





2005\06\14@213044 by Spehro Pefhany

picon face
At 07:43 PM 6/14/2005 -0500, you wrote:

>I can probably guess what you are thinking now, and I have been fearing doing
>that -- ie: using independent IIR filters for the bargraph and numerical
>outputs.  :-(

Do it. ;-)

Typical DMMs with bar-graph displays do maybe 3 measurements/second on the
digital display and 20 per second on the bar-graph.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
@spam@speffKILLspamspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2005\06\14@235030 by PicDude

flavicon
face
On Tuesday 14 June 2005 04:21 pm, Olin Lathrop scribbled:
> ...  I
> think 5Hz is probably over that limit or at least near it.  Take a look at
> a normal digital voltmeter.  I think you'll find the update rate is more
> like 2-3Hz.  I'm sure Fluke and other put some thought into this.  Why not
> just do what they did? ...

Different application.  BTW, I have always hated how 2 of my multimeters did
the same thing -- toggles back and forth.

Cheers,
-Neil.


2005\06\14@235424 by PicDude

flavicon
face
On Tuesday 14 June 2005 08:36 pm, Spehro Pefhany scribbled:
> At 07:43 PM 6/14/2005 -0500, you wrote:
> >I can probably guess what you are thinking now, and I have been fearing
> > doing that -- ie: using independent IIR filters for the bargraph and
> > numerical outputs.  :-(
>
> Do it. ;-)

Isn't that the words of the great philisopher Nike?... Just do it.  I'm
looking at that code again, and it's a can of worms to do that, mostly
because of a lot of required mods to move into another 2k code page.  But I
guess I'll have to do this sometime.

> Typical DMMs with bar-graph displays do maybe 3 measurements/second on the
> digital display and 20 per second on the bar-graph.

I have a raw version of a similar app with no filtering whatsoever -- none in
hardware, none in software.  But it is bargraph only.  The display updates so
fast that it's not at all annoying -- it's a smooth transition from one stage
to the next with the effect of the topmost LED fading on/off during the
transition.

Cheers,
-Neil.,




2005\06\15@075612 by olin piclist

face picon face
PicDude wrote:
> Yes and no.  The display output goes to both a numerical output and a
> bargraph (24 leds).  The bargraph output looks really sluggish if
> slowed down more, but you're correct that the numerical output gets
> jumpy.  So far though, with the filtering, the numerical output is not
> that bad/annoying for quick changes when it is following a trend and
> going towards one direction.  But the digit toggling is a royal pain.
>
> I can probably guess what you are thinking now, and I have been fearing
> doing that -- ie: using independent IIR filters for the bargraph and
> numerical outputs.  :-(

That's exactly what I was thinking when reading your first paragraph.
What's the big deal though unless you are using an overly complex IIR
filter?  Use maybe a two pole filter with maybe 10Hz rolloff on each pole
for the bar graph, then add another pole or two at 1-2Hz for the numeric
display and update that twice per second or maybe a little faster.  There is
nothing complicated here.


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

2005\06\15@081651 by olin piclist

face picon face
PicDude wrote:
> I'm
> looking at that code again, and it's a can of worms to do that, mostly
> because of a lot of required mods to move into another 2k code page.

You probably won't like hearing this, but shame on you.  If you had written
the code properly in the first place, this wouldn't even be noticeable.
Maybe now you're ready to see the light and write code so that none of this
matters in the future.  It may sound like a lot of work now, but frankly
anything that fits in 2K code space isn't that big a deal.  After all, we're
only talking about 2000 instructions.

Take a look at my PIC development environment at
http://www.embedinc.com/pic.  The GCALL, GJUMP, GLBSUB, and related macros
make it easy to write code so that modules can be arbitrarily assigned
different pages.  There's also a lot of other good stuff in there that may
look like a silly hassle at first, but will save you a lot of trouble in the
long run.  Take the time now to do things right, and in a month from now you
won't understand how you ever tolerated writing code the old way before.


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

2005\06\15@081732 by Bill & Pookie

picon face
I was referring to when treating data as switches and bits change other than
the ones you are watching.  But you not doing that, so "never mind".

So that problem does not exist, but the solution still has value.  With the
>1 test, you will not see any wiggle in the data nor will you see a single
step of 1.  A routine that insures that the data display is refreshed with
new data at least every so often would overcome theses concerns..  Also if
the display device is external then this would insure that if it lost it
little bitty mind, it would get back on the right track again.

As you increase the complexity of your test, there may be introduced a bug
where the new data does not pass the test even though you expected it to
pass and update the data display.  You could also add code to check for such
a software error and log it.  This would help in ensuring such a bug did not
exist.

Now the fun part.  If you have a spare LED, you could pulse it each time the
data wiggled.  Or two LED's with one pulsed for positive wiggles and the
other for negative wiggles.  Or even a two tone LED with red for a wiggle,
green for a swigged and yellow for "shimmy like my sister Kate".

Bill
   .

{Original Message removed}

2005\06\15@094933 by alan smith

picon face
Or move to the 18F.....no paging issues......

Olin Lathrop <KILLspamolin_piclistKILLspamspamembedinc.com> wrote:PicDude wrote:
> I'm
> looking at that code again, and it's a can of worms to do that, mostly
> because of a lot of required mods to move into another 2k code page.

You probably won't like hearing this, but shame on you. If you had written
the code properly in the first place, this wouldn't even be noticeable.
Maybe now you're ready to see the light and write code so that none of this
matters in the future. It may sound like a lot of work now, but frankly
anything that fits in 2K code space isn't that big a deal. After all, we're
only talking about 2000 instructions.

Take a look at my PIC development environment at
http://www.embedinc.com/pic. The GCALL, GJUMP, GLBSUB, and related macros
make it easy to write code so that modules can be arbitrarily assigned
different pages. There's also a lot of other good stuff in there that may
look like a silly hassle at first, but will save you a lot of trouble in the
long run. Take the time now to do things right, and in a month from now you
won't understand how you ever tolerated writing code the old way before.


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

2005\06\15@102218 by Scott Dattalo

face
flavicon
face
On Tue, 2005-06-14 at 19:34 -0500, PicDude wrote:

<snipped trivial example illustrating the hysteresis algorithm>


> Okay, now I got ya.  I was interpreting your "last_sample" variable to mean
> "last displayed" sample.  What I now see here it that this is exactly
what I
> was doing initially, but got noticeable digit toggling still.  This is
when I
> extended it to 3 cycles.  I'm guessing at this point, that extending the
> testing out to more than 3 cycles will help a lot.  When I posted the
> question originally, I was really hoping there was some algorithm that I
had
> not heard of before that would take care of this (expectedly common)
problem.


Part of the issue here is that you have conflicting goals: on the one hand
you want to update your display if the data changes but on the other you
don't want to update the display if the data changes. Filters are good at
discriminating between the two goals as long as the two can be
differentiated. And I think you're finding that for each filter you've
tried, there are either side effects or ways to spoof it!

I tried to answer your specific question about hysteresis filters. Other
have suggested different ways to approach the problem. Here are a couple
of more approaches you may wish to consider:

- Median + Low pass

Collect the last N raw samples into a sorted array. Low-pass filter the
array by ignoring the extremes. E.g. If you have 5 sorted samples, throw
away the high and low and average the remaining 3.

- Increased dynamic range

The internal representation of the displayed data can have a higher
dynamic range then the displayed data. In general, you'll want at least
LOG2(FIR taps) more bits. E.g. if your FIR filter is 4 taps then
maintaining an extra 2 bits on the filtered output is useful. (Note that
LOG2 is only an estimate, a more precise relationship for an averaging
filter is sqrt(number of samples).) The benefits of increased dynamic
range is that it can give you more precise control of your thresholding
and can minimize quantization errors.

> On the side, since you mention abs(), is there a neat trick/way in PIC
> assembly to calculate abs(x-y)?  I'm currently doing the subtraction, and
> then explicitly comparing for -1 or +1.  (Actually, I'm adding 1 after the
> subtraction, then comparing for 0 or 2).

This is off the top of my head, for the midrange family:

absoluteDifference_14bitcore:
       movf    var1,W
       subwf   var2,W    ; W = var2 - var1
       skpnc             ; If result is non-negative C=1
        goto   ad14_done
       xorlw   0xff      ; 2's complement of W. Note you'll pass
       addlw   0x01      ; through here if var1==var2, but the 2's
                         ; complement of 0 is 0.
ad14_done:


And for the 18F family:

absoluteDifference_16bitcore:
       movf    var1,W    ;
       subwf   var2,W    ; WREG = var2-var1
       bnn     ad16_done
       negf    WREG,F

I'm not sure if these can be classified as neat or not...

Scott

2005\06\15@102230 by Scott Dattalo

face
flavicon
face
On Tue, 2005-06-14 at 19:34 -0500, PicDude wrote:

<snipped trivial example illustrating the hysteresis algorithm>


> Okay, now I got ya.  I was interpreting your "last_sample" variable to mean
> "last displayed" sample.  What I now see here it that this is exactly
what I
> was doing initially, but got noticeable digit toggling still.  This is
when I
> extended it to 3 cycles.  I'm guessing at this point, that extending the
> testing out to more than 3 cycles will help a lot.  When I posted the
> question originally, I was really hoping there was some algorithm that I
had
> not heard of before that would take care of this (expectedly common)
problem.


Part of the issue here is that you have conflicting goals: on the one hand
you want to update your display if the data changes but on the other you
don't want to update the display if the data changes. Filters are good at
discriminating between the two goals as long as the two can be
differentiated. And I think you're finding that for each filter you've
tried, there are either side effects or ways to spoof it!

I tried to answer your specific question about hysteresis filters. Other
have suggested different ways to approach the problem. Here are a couple
of more approaches you may wish to consider:

- Median + Low pass

Collect the last N raw samples into a sorted array. Low-pass filter the
array by ignoring the extremes. E.g. If you have 5 sorted samples, throw
away the high and low and average the remaining 3.

- Increased dynamic range

The internal representation of the displayed data can have a higher
dynamic range then the displayed data. In general, you'll want at least
LOG2(FIR taps) more bits. E.g. if your FIR filter is 4 taps then
maintaining an extra 2 bits on the filtered output is useful. (Note that
LOG2 is only an estimate, a more precise relationship for an averaging
filter is sqrt(number of samples).) The benefits of increased dynamic
range is that it can give you more precise control of your thresholding
and can minimize quantization errors.

> On the side, since you mention abs(), is there a neat trick/way in PIC
> assembly to calculate abs(x-y)?  I'm currently doing the subtraction, and
> then explicitly comparing for -1 or +1.  (Actually, I'm adding 1 after the
> subtraction, then comparing for 0 or 2).

This is off the top of my head, for the midrange family:

absoluteDifference_14bitcore:
       movf    var1,W
       subwf   var2,W    ; W = var2 - var1
       skpnc             ; If result is non-negative C=1
        goto   ad14_done
       xorlw   0xff      ; 2's complement of W. Note you'll pass
       addlw   0x01      ; through here if var1==var2, but the 2's
                         ; complement of 0 is 0.
ad14_done:


And for the 18F family:

absoluteDifference_16bitcore:
       movf    var1,W    ;
       subwf   var2,W    ; WREG = var2-var1
       bnn     ad16_done
       negf    WREG,F

I'm not sure if these can be classified as neat or not...

Scott

2005\06\15@120139 by Marcel Duchamp

picon face
> And for the 18F family:
>
> absoluteDifference_16bitcore:
>         movf    var1,W    ;
>         subwf   var2,W    ; WREG = var2-var1
>         bnn     ad16_done
>         negf    WREG,F
>
> I'm not sure if these can be classified as neat or not...
>
> Scott

Maybe the subwf and bnn instructions can be done with one of the 18F
compare instructions?

        movf    var1,W    ;
       CPFSGT  var2,W          ; Compare f with W, Skip if f > W        
        negf    WREG,F    ;

Does that work?
MD

2005\06\15@133307 by Scott Dattalo

face
flavicon
face
Marcel Duchamp wrote:
>> And for the 18F family:
>>
>> absoluteDifference_16bitcore:
>>         movf    var1,W    ;
>>         subwf   var2,W    ; WREG = var2-var1
>>         bnn     ad16_done
>>         negf    WREG,F

> Maybe the subwf and bnn instructions can be done with one of the 18F
> compare instructions?
>
>         movf    var1,W    ;
>     CPFSGT  var2,W          ; Compare f with W, Skip if f > W  
>         negf    WREG,F    ;
>
> Does that work?

No. We want to compute abs(var1-var2), you're computing:

   if (var1 > var2)
     W = -var1
   else
     W = var1

Scott

2005\06\19@234018 by PicDude

flavicon
face
I should've also indicated that I was doing a 16-bit abs(var1-var2).  It is
fairly manual currently (see which is larger, then subtract var1-var2 or
var2-var1 accordingly, but 2 bytes with borrow, etc).  Was hoping for some
neat trick, but no real prob -- my routine does the job.

Cheers,
-Neil.


On Wednesday 15 June 2005 12:32 pm, Scott Dattalo scribbled:
> No. We want to compute abs(var1-var2), you're computing:
>
>     if (var1 > var2)
>       W = -var1
>     else
>       W = var1
>
> Scott


2005\06\19@234557 by PicDude

flavicon
face
Sure, but it wasn't even relevant in the first place -- the project was based
on a working PIC16F872 app and used about 1.1k of it's 2k code space.  There
was no chance of that ever needing more.  There was also another piece of
code running on a 16F627, and I integrated both into 1 PIC16F874 last week.  
The port was a very simple matter of changing constants that pointed to
specific pins and ports.  Perhaps you'll say that it should've been made
multi-page compliant when I ported it, but that's where I'm at now.

Cheers,
-Neil.



On Wednesday 15 June 2005 07:17 am, Olin Lathrop scribbled:
{Quote hidden}

2005\06\20@000207 by PicDude

flavicon
face
On Wednesday 15 June 2005 06:56 am, Olin Lathrop scribbled:
> > I can probably guess what you are thinking now, and I have been fearing
> > doing that -- ie: using independent IIR filters for the bargraph and
> > numerical outputs.  :-(
>
> That's exactly what I was thinking when reading your first paragraph.
> What's the big deal though unless you are using an overly complex IIR
> filter?  Use maybe a two pole filter with maybe 10Hz rolloff on each pole
> for the bar graph, then add another pole or two at 1-2Hz for the numeric
> display and update that twice per second or maybe a little faster.  There
> is nothing complicated here.


And I have now done this over the past couple days -- the bargraph has a
different display update rate than the numerical digits (bargraph is 4 times
faster), and each has it's own IIR filter factor.  I set up the filter
factors to be independently adjustable from 0 to 7/8 in 1/8 increments, when
the app is in operation (ie: without re-programming).  I also extended the
LSD toggling routine (as I previously described) to check back to the last 4
samples.  I need to get it in operation and experiment with the IIR factors.

I've looked a bit into non-linear IIR filters, but could not find much.  But
some thinking on a whiteboard has me believing that I might get much improved
results with as simple a scheme as having one threshold for the absolute
amount of the change and above/below that would each have a separate
IIR-filter factor.  Pretty much...
       if (abs(new_sample - last_result) > threshold)
               then k = larger_value
               else k = smaller_value
       call IIR_routine

I need to experiment with this to see if it really will work as I think it
should, without having to go to a more proper non-linear system where IIR
factor varys thru multiple values over multiple change levels.

Cheers,
-Neil.


2005\06\20@075442 by olin piclist

face picon face
PicDude wrote:
>>> it's a can of worms to do that, mostly
>>> because of a lot of required mods to move into another 2k code page.
>>
>> You probably won't like hearing this, but shame on you.  If you had
>> written the code properly in the first place, this wouldn't even be
>> noticeable.
>
> Sure, but it wasn't even relevant in the first place -- the project was
> based on a working PIC16F872 app and used about 1.1k of it's 2k code
> space.  There was no chance of that ever needing more.

But that's the point.  Clearly not, else we wouldn't be having this
discussion.  Part of good software engineering is realizing that many pieces
of code can and probably will have a life well beyond the immediate intended
use.  Writing 16F PIC code so that it can run accross the family is very
easy.

As I said before, fortunately you've only got code for at most 2000
instructions to clean up.  This shouldn't take long.  Then you can move
forward and write code that can be move from one 16F PIC to another with few
or no changes.  The good news is that you bumped into this issue while you
only had a trivial amount of legacy code.


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

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