Searching \ for '[PIC] C18 calculating the interrupt loading' 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/ints.htm?key=interrupt
Search entire site for: 'C18 calculating the interrupt loading'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] C18 calculating the interrupt loading'
2006\06\28@192534 by Phillip

picon face
Hi Jan-Erick
Thanks again for your patience and help.
I am truly grateful.

Let me throw out some more details here first.
I'm confident my PCB layout will support the full Monty (40MHz) (the up side
of my RF design experience) but I'm using 4MHz  crystals (4.096 to be
exact)from my old designs so I'd like to use those but if I can't there is
no great love lost.

There will be a a GPS receiver on the second serial port.
The good news is that there is not that much data it will send out standard
NEMA message strings by default I think I can turn them all off so it will
send a message like a GGA that is about one hundred or so characters long at
one second intervals.
I'll need to parse the message and adjust some digital attenuators based on
the message.
(There is no big hurry on parsing the message and adjusting the attenuator
it can happen in the foreground)

I will also need to read three A/D channels once every 3330msecs.
All that needs to happen in the ISR is to read the value and put it in the
appropriate place.
I can process the result in the fore ground as long as it gets done before
the next interrupt interval for that channel then that will be quick enough.
(for the record they are
current level detect (current converted to a voltage with an op amp).
antenna bias voltage detect
oscillation detect (RF level converted to a voltage with detector an op
amp)

In my button/switches ISR (
I only check the state of port bits and record them and move on or after so
many interrupts based on what I've stored away I decide that a de-bounced
switch closure has occurred and push a command into a circular buffer for
foreground processing.
(I'm leaving out a lot of the detail here I have a mode that looks for a
button down and then an up before it qualifies as a good press and another
mode that the user can hold it down (e.g. to adjust the brightness of the
lcd with out having to press the button a hundred times) so I don't need the
up for that particular switch if a global variables are set.


So I'm reading your message and I'm confused...obviously confusing me is not
a difficult task.
It seems to me that it is not the time between events that matters.
It is the time to process each event and still get back to the remaining
events because all the asynchronous events could happen at once.
A character could arrive at both serial ports right as the user was pressing
a button. (technically as the button ISR was executing is more correct)
So I need to be able to have an ISR button event interrupted for a higher
level event (serial character) and not lose the button event
information...because I was able to process the high level ISR event[s] and
get back to the low level ISR "in time"
Or said another way I think that I should be able to read a character on the
serial port[s] during the button ISR and not lose a button press because my
serial ISRs were fast enough to get it over with and get back to the button
press ISR before my user gets his finger on and off the button?

The A/D conversions are like the button press because but they can be made
to happen when the button ISR aint by setting the interval not to coincide
with the button ISR but the serial ports will be asynchronous.  (I'm still a
little fuzzy on this part)
A/D channels are different in the sense when the conversion is done they
will hang around so if that is interrupted they are not going away I just
want to take care of it before the next one so I "think" I'll always be able
to get to them and handle them in time provided I my fore ground is not too
larded up.

So this a very long way to say I think the problem is different than you
described because of asynchronous events.

Anyway thanks in advance Jan-Erick or anyone else that puts the effort into
reading this tome.
I have to go pick up my son.






Phillip
Things should be as simple as possible but no simpler



Phillip Coiner
CTO, GPS Source, Inc.


Your source for quality GNSS Networking Solutions and Design Services, Now!

{Original Message removed}

2006\06\29@071028 by Jan-Erik Soderholm

face picon face
Phillip wrote :

> I'm confident my PCB layout will support the full Monty
> (40MHz) (the up side of my RF design experience)...

One of the reasons there is a HSPLL mode (10 Mhz xtal,
40 Mhz internal) is to get lower RF interference.

> but I'm using 4MHz  crystals (4.096 to be
> exact)from my old designs so I'd like to use those but if I
> can't there is no great love lost.

Fine, as long as you have enough processing cycles... :-)

> There will be a a GPS receiver on the second serial port.

Running at 9600 baud or so ? 1200 maybe ?

> (There is no big hurry on parsing the message and adjusting
> the attenuator it can happen in the foreground)

And of course you have to translate "no big hurry" into
real micro/milli seconds... :-)

> I will also need to read three A/D channels once every 3330msecs.
> All that needs to happen in the ISR is to read the value and
> put it in the appropriate place.

OK, so a rather short ISR's once each 3 seconds. Shouldn't
be a problem.

>
> In my button/switches ISR (
> I only check the state of port bits and record them and move
> on or after so many interrupts based on what I've stored away
> I decide that a de-bounced switch closure has occurred and
> push a command into a circular buffer for foreground processing.

Fine, also seems to be a fairly short ISR.

> (I'm leaving out a lot of the detail here I have a mode that
> looks for a button down and then an up before it qualifies
> as a good press and another mode that the user can hold
> it down (e.g. to adjust the brightness of the lcd with ou
>  having to press the button a hundred times) so I don't
> need the up for that particular switch if a global variables
> are set.

OK, but there is nothing that will "trapp" the processor in the
button-ISR for some undefined lenght of time, right ?

> It seems to me that it is not the time between events that matters.
> It is the time to process each event and still get back to
> the remaining events because all the asynchronous events
> could happen at once.

Yes, my example was mor or less based on the scenario with
*two* interrupt sources. With more then two, one have to add
up the time to be sure.

> A character could arrive at both serial ports right as the
> user was pressing a button. (technically as the button
> ISR was executing is more correct) So I need to be able
> to have an ISR button event interrupted for a higher
> level event (serial character)

Only if the time spend in the button-ISR would make you
miss the *next* character !

Note that you do not have to read the serial character
"at once", it have to be read before the next character is
received. The USARTs are double buffered so they can have
one character waiting in the RXREG while another (the next)
character is currently received.

> Or said another way I think that I should be able to read a
> character on the serial port[s] during the button ISR and
> not lose a button press because my serial ISRs were fast
> enough to get it over with and get back to the button
> press ISR before my user gets his finger on and off the button?

Or in yet another way, the serial character can wait in the RXREG
until the button-ISR have finished, since it will always finish
before the next serial character is completely recevied.

Now, if that is *NOT* the case, you have a real trouble !
The solutions can be :
1 Using the two-level interrupt priority feature.
2 Redesign of the button-ISR (making it run faster).
3 Running the processor faster.


> The A/D conversions are like the button press because but
> they can be made to happen when the button ISR aint by
> setting the interval not to coincide with the button ISR but
> the serial ports will be asynchronous.  (I'm still a
> little fuzzy on this part)

Now the ADC conversons are run at 3 sec intervalls, right ?
Is it of a great importance that the ADC valus are processed
within some minimum delay ? Or do you have the full 3 sec
intervall to process them ? If so, I don't see any real problem
and the fact that the ADC interrupt and the button- (timer-)
interrupts "fires" at the same time doesn't matter much. The
interrupt logic will "serialize" the processing. That is, when
the processor runs the RETFIE at the end of you main ISR,
the processor will at once "see" the other xxxxF flags and a
new interrupt will fire at once. It will "only" introduce a slight
delay for the second interrupt source.

You can introduce your own priorities in the main ISR by
the order of the tests of the F-flags, in the case that multiple
F-flags should be set. Such as, if the two USARTS are running
at different speeds, I'd make sure to process the faster one
before the slower, in the case that both F-flags should happen
to be set at entry of the main-ISR.


> A/D channels are different...

Different from what ?

> in the sense when the conversion is done they will hang
> around so if that is interrupted they are not going
> away I just want to take care of it before the next one...

Just as the character in the RXREG in the USART !
It will no "go away" until the next character is fully received
(and you will also have to "overflow" bit set in that case).

> so I "think" I'll always be able to get to them and handle
> them in time provided I my fore ground is not too
> larded up.

Again, just as the serial character...

> So this a very long way to say I think the problem is
> different than you
> described because of asynchronous events.

No, that *was* what I described. The interrupts can be used
to process asynchronous events, it just a question on
having control over the processing times of each ISR
and the allowed delays before begining processing
of each ISR. Those two factors have to "match"...

Regards,
Jan-Erik.



2006\06\29@072835 by olin piclist

face picon face
Phillip wrote:
> so it will send a message like a GGA that is about one hundred or
> so characters long at one second intervals.
>
> ...
>
> I will also need to read three A/D channels once every 3330msecs.
> All that needs to happen in the ISR is to read the value and put it in
> the appropriate place.
>
> ...
>
> In my button/switches ISR (
> I only check the state of port bits and record them and move on or
> after so many interrupts based on what I've stored away I decide that a
> de-bounced switch closure has occurred and push a command into a
> circular buffer for foreground processing.

I think you should have 3 interrupts, the UART, A/D conversion complete, and
a timer.  Buttons, especially ones that require debouncing, are usually
easier to handle by sampling than by interrupting on closure or state
changes.  You need timing anyway for the debouncing, so you might as well
base everything off a timer.

I asked right in the beginning (and you seemed to have ignored) why not use
a standard UART interrupt that stuffs the received byte into a FIFO, then
let the foreground code drain the FIFO as it gets to it?  This seems even
more appropriate now after you described more about your system.

The timer interrupt can have 1mS period.  Every timer interrupt you check
the switches, perform any debouncing logic, and update the global state of
the official debounced switches state for the foreground code to look at.
50mS, which will be 50 ticks, is a good debounce time.  Just about all
switches will finish bouncing well before that, but it will still feel
instantaneous to a human.  You also start a A/D conversion every timer tick.

In the basic version the A/D interrupt grabs the A/D value, updates the
global value for that channel, and switches the A/D to acquiring the next
channel.  Note that 1mS is much much longer than the required acquisition
time plus conversion time plus A/D interrupt handling time.

The foreground code handles events like UART input byte available and
debounced switches changed state.  This can probably be a main event loop
architecture for most things, although the UART input stream handler may
benefit from being implemented as a pseudo thread due to the highly
history-sensitive nature of parsing the data stream.

That's the basic setup.  However I would apply some low pass filtering to
the A/D readings.  You need a new reading only every 3.3 seconds, during
which time you can take 1100 readings per channel and still only use a small
fraction of the CPU.  Two poles of LPF each with 8 shift bits per pole
settles to about 93% in 1100 iterations.  That sounds like a good match,
especially since shifting by 8 bits is particularly trivial, and 2 x 8 bits
is a lot of random noise attenuation.

> It seems to me that it is not the time between events that matters.
> It is the time to process each event and still get back to the remaining
> events because all the asynchronous events could happen at once.

The latency to handle an interrupt after the condition has occurred is what
matters.  None of your interrupts require particularly low latency, so there
is no need for a priority scheme.  Even if only running at 16MHz (using your
4MHz crystal), you get 4 instructions/uS and 4000 instructions/mS.  The most
latency critical interrupt is the UART.  Even at 115.2Kbaud baud you have
11,520 bytes/second, or 87uS/byte, or 347 instructions/byte.  Can you
imagine any one of the other interrupts taking 347 instructions?  I can't.
The A/D with filtering will be the most, but should still be much less than
347 instructions (unless maybe you do something silly like use a compiler
for interrupt code).  And that was for 115.2Kbaud.  The GPS can probably be
set for 9600 baud, in which case you get over 4000 instructs/byte.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\06\29@131925 by Phillip

picon face
Hi Jan-Erick

Crystal:
I did not realize the HSPLL PLL mode could be made to work like that but it
is great to know.
So I'm sure you know what my next question is....Can I run the HSPLL with my
trusty crusty 4.096MHz crystal for 16MHz internal eh?


GPs receiver:
There are resistors to program the GPS receiver to default to 9600.
I see no reason not to run both ports at 9600.
(It is a module from Sony.
It really has good sensitivity and the price is right ublock has a good
module too (their sensitivity specs are marketing hype but it is still very
good performer that I might add a foot print for later so I have a second
source.
They are both available as a chip sets too.
Later on I plan to switch to the chip set mode to save a few bucks but you
have to do micro vias/BGAs so it is not for PCB layout feint of heart or
those with out reflow soldering capability.
The modules can be made to work using fairly standard PCB layout techniques
& proper grounding.
)


ISR Traps:
There are no traps (at least not intentionally) in any of my ISRs it either
is or aint and we move one.
So it is fairly short/terse.

AD interrupts.
All three to channels to sample at 330msecs intervals (this works out to 3
times per second not once every 3 seconds but the concept is the
same...sorry if I was not clear)
If the result for all three is processed/acted on before the next 3330msec
interval then all is fine.
They can be in synch i.e. all be told to sample at the same time or in
series as long as they each happen every 330mses.



I have read the last part of your message but I need to do some research and
let it sink in but on the first pass it makes perfect sense.
I'll write back later when I have a plan

Thanks again for your help and and very grateful for your time and expertise

Phillip
Things should be as simple as possible but no simpler



Phillip Coiner
CTO, GPS Source, Inc.


Your source for quality GNSS Networking Solutions and Design Services, Now!

{Original Message removed}

2006\06\29@135018 by Phillip

picon face
Hi Olin

Thanks again for your help

I'm think I addressed some of your questions in the messages to Bill and
Jan-Erik


The last part of your message answers my crystal question to Jan-Erik


I asked right in the beginning (and you seemed to have ignored) why not use
a standard UART interrupt that stuffs the received byte into a FIFO, then
let the foreground code drain the FIFO as it gets to it?  This seems even
more appropriate now after you described more about your system.

I did not ignore this or any advice from this group.
As a whole the help I get here is first rate especially yours.

I "think" I am doing what you are saying with a slight twist.
If I get one of a set of chars I push a CMD in a circular buffer if I get a
special char I push the following chars in a buffer to form strings it takes
a few more instructions but I think it is worth it so that my main loop is
just processing commands or a command and its associated string.
Because of this
"None of your interrupts require particularly low latency"

I think I can get away with the extra instructions inside my serial ISR even
using the silly compiler generated ones...I can always rewrite them in
assembler if I need fewer instructions but right now I don't think I'm any
where near the limit of instructions if I operate the serial ports at 9600
or switched up to 11,520 bytes/second.

I also agree that there is no real need to have a priority scheme now but I
don't see what it hurts.
I want to build a PLL later in another similar design and it might require
low latency ISR and I want to leverage this code there so I'm trying to
structure it/ learn the ropes for a priority scheme now.

I have another damn meeting.
I would like to ask you some more questions about the filtering.
I have just been averaging my AD interrupts (in another product) and would
prefer to use filtering.


Phillip
Things should be as simple as possible but no simpler



Phillip Coiner
CTO, GPS Source, Inc.


Your source for quality GNSS Networking Solutions and Design Services, Now!

{Original Message removed}

2006\06\29@135049 by Mark Rages

face picon face
On 6/29/06, Phillip <spam_OUTpcoinerTakeThisOuTspamgpssource.com> wrote:
> Hi Jan-Erick
>
> Crystal:
> I did not realize the HSPLL PLL mode could be made to work like that but it
> is great to know.
> So I'm sure you know what my next question is....Can I run the HSPLL with my
> trusty crusty 4.096MHz crystal for 16MHz internal eh?
>

Yes.   Read the datasheet.

But you sure don't need 16MHz for what you are trying to do!

You have listed:
1) 9600 baud serial communication
2) Nine A/D readings/second
3) Debouncing keypresses

You do not need two levels of interrupt for this.

By way of example, my last application had:
1) 115200 baud serial communication
2) One hundred A/D readings per second
3) Two floating-point PID loops
4) Edge triggered PLL
5) I2C communications to a DAC

This used a 16F688, a much lower-spec chip than the one you are using.
It has one level of interrupts.  It was running at 8 MHz.  And this
was *not* some feat of engineering to shoehorn everything in.  My
point: You have *lots* of resources available.  No need to complicate
things.

Read the datasheet.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\06\29@135839 by Phillip

picon face
Hi Mark
I did (read the data sheet) it looks like it will work fine to run the HSPLL
to me.
I agree I don't need to go that fast so that is why I thought from the
beginning that my trusty 4.096 MHz part will do just fine.
Down the road is another story for another day.
Thanks for the post/help.

Phillip
Things should be as simple as possible but no simpler



Phillip Coiner
CTO, GPS Source, Inc.


Your source for quality GNSS Networking Solutions and Design Services, Now!

{Original Message removed}

2006\06\29@165847 by Jan-Erik Soderholm

face picon face
Phillip wrote :

> ...if I get a special char I push the following chars in
> a buffer to form strings...

And that is done in the *following* interrupts, right ?

Or are you staying *in* the ISR waiting for those
"following chars" ? That is rather bad design, if so.

Generaly speaking, no ISR should ever *wait* for anything.

> I also agree that there is no real need to have a priority
> scheme now but I don't see what it hurts.

It adds complexity to the design, with is OK if you need it...


Regards,
Jan-Erik.



2006\06\29@171859 by Phillip

picon face
Hi Jan-Erik

That is correct.
A special char sets a flag so when the next char arrives I know it is part
of the string one interrupt per char no waiting around!
If it is the terminating character I push a command in the buffer and start
over.
If string grows too long then I know some thing went wrong and it is ditched
and we start over either pushing CMDs in the buffer or building a new string
(pushing chars into a buffer).

Of course I do more sophisticated checking on the string later in the
foreground when I have the time and money.


priority scheme
I don't really need it now but I suspect I will need it later when I add a
low latency PLL circuit.


Phillip
Things should be as simple as possible but no simpler



Phillip Coiner
CTO, GPS Source, Inc.


Your source for quality GNSS Networking Solutions and Design Services, Now!

{Original Message removed}

2006\06\29@183734 by Kevin

picon face
> Olin Lathrop <.....olin_piclistKILLspamspam@spam@embedinc.com> said:
> > That's the basic setup.  However I would apply some low
> pass filtering to
> > the A/D readings.  You need a new reading only every
> 3.3 seconds, during
> > which time you can take 1100 readings per channel and
> still only use a small
> > fraction of the CPU.  Two poles of LPF each with 8
> shift bits per pole
> > settles to about 93% in 1100 iterations.  That sounds
> like a good match,
> > especially since shifting by 8 bits is particularly
> trivial, and 2 x 8 bits
> > is a lot of random noise attenuation.

Anybody care to expand on this or throw in some code
snippets ?

TIA,
Kevin


2006\06\29@222645 by John Chung

picon face


--- Jan-Erik Soderholm <jan-erik.soderholmspamKILLspamtelia.com>
wrote:

{Quote hidden}

 Fortunately this requirement is a rare occurance. If
it locks itself in the ISR you can't get anywhere when
the BOR occurs. Therefore it should be eliminated.

John

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

2006\06\30@000941 by Phillip

picon face
Hi John
I agree
There is no waiting in my ISR.

The only difference between my ISR and a standard one that just pushes every
received char to a buffer is a test to see which buffer I push to.
If it is a CMD char I push a byte to the command buffer if I have received a
special character and I have set a flag I push the single char to a string
buffer.
If I receive a terminating char I push a CMD.
If the string grows too long I know something has gone wrong and I clear the
special char received flag and start over.
So there are some tests but they are very short and only operate on a single
character at a time and then move on.
Either way I'm only pushing a byte and leaving there is no waiting for
anything.




Phillip
Things should be as simple as possible but no simpler



Phillip Coiner
CTO, GPS Source, Inc.


Your source for quality GNSS Networking Solutions and Design Services, Now!
{Original Message removed}

2006\06\30@054340 by Alan B. Pearce

face picon face
>Can I run the HSPLL with my trusty
>crusty 4.096MHz crystal for 16MHz internal

Well, that one is a definite read the datasheet question.

2006\06\30@064936 by olin piclist

face picon face
Kevin wrote:
>> That's the basic setup.  However I would apply some low pass
>> filtering to the A/D readings.  You need a new reading only every 3.3
>> seconds, during which time you can take 1100 readings per channel and
>> still only use a small fraction of the CPU.  Two poles of LPF each
>> with 8 shift bits per pole settles to about 93% in 1100 iterations.
>> That sounds like a good match, especially since shifting by 8 bits is
>> particularly trivial, and 2 x 8 bits is a lot of random noise
>> attenuation.
>
> Anybody care to expand on this or throw in some code
> snippets ?

There are whole digital signal processing books discussing this sort of
thing.  Expanding on it is impossible to do efficiently without knowing what
part specifically you want to know more about.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\06\30@073053 by olin piclist

face picon face
Phillip wrote:
> The only difference between my ISR and a standard one that just pushes
> every received char to a buffer is a test to see which buffer I push to.
> If it is a CMD char I push a byte to the command buffer if I have
> received a special character and I have set a flag I push the single
> char to a string buffer.

And why does this processing need to be done in the interrupt routine?  Why
can't you get the same effect with less complexity by pusing onto a single
FIFO in the interrupt routine, then letting the foreground code parse the
whole data stream?  This seems like an arbitrary and unoptimal division of
labor between the ISR and the foreground routine.  What are you getting in
return for the extra cycles and complexity in the interrupt routine and the
second FIFO?  I get the impression you latched onto an architecture for no
other reason than that is what popped into your head, and haven't gone back
and really thought about it since then.

Given that your problems seem to be related to the interrupt handler and
some related misconceptions about how the hardware works, you should be
aiming for the simplest minimal ISR that gets the job done.

> Things should be as simple as possible but no simpler

Right.  But this is also a content-free useless statement because the issue
is about the judgement when something is as simple as possible, not the
desire to make it so.  Do you really think anyone goes around saying "this
way would be the simplest, but I'm going to do it this other way because I
prefer a little more complicated"?  You might as well have a signature line
that says "Don't make mistakes".

> Phillip Coiner
> CTO, GPS Source, Inc.

I happen to be investigating different offerings for a GPS solution, so I
was curious and looked up the name of your company on the web.  I guess I
had just tuned out your signature before that because none of it triggered
any subliminal keyword recognition.  Frankly what I've seen here is a bit
troubling in regards to GPS Source.  Why is the CTO doing low level PIC
work?  A CTO is supposed to be the company technical guru, visionary,
evangelist, and possibly chief architect.  If it's a small company and he
also has to do product development, that's understandable.  But if he's the
best guru they got and he has serious misconceptions about interrupts in
general and specifically about PICs despite clear documentation, and his
software architecting is questionable, what does that say about the other
engineers?

My advice is to loose the tag line when asking basic questions.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\06\30@082440 by Kevin

picon face
> Kevin wrote:
> >> That's the basic setup.  However I would apply some low pass
> >> filtering to the A/D readings.  You need a new reading only every 3.3
> >> seconds, during which time you can take 1100 readings per channel and
> >> still only use a small fraction of the CPU.  Two poles of LPF each
> >> with 8 shift bits per pole settles to about 93% in 1100 iterations.
> >> That sounds like a good match, especially since shifting by 8 bits is
> >> particularly trivial, and 2 x 8 bits is a lot of random noise
> >> attenuation.
> >
> > Anybody care to expand on this or throw in some code
> > snippets ?
>
> There are whole digital signal processing books discussing this sort of
> thing.  Expanding on it is impossible to do efficiently without knowing what
> part specifically you want to know more about.
>
This part.
Two poles of LPF each with 8 shift bits per pole settles to about 93% in 1100
iterations.
especially since shifting by 8 bits is particularly trivial,
and 2 x 8 bits is a lot of random noise attenuation.

Maybe a code snippet on how to implement this in code to
improve my AD readings.

TIA,
Kevin

2006\06\30@085821 by Dave Lag

picon face
Kevin wrote:
>>Olin Lathrop <.....olin_piclistKILLspamspam.....embedinc.com> said:
>>
>>>That's the basic setup.  However I would apply some low
>>
>>pass filtering to.....
>
> Anybody care to expand on this or throw in some code
> snippets ?
>
> TIA,
> Kevin
>
>
recent related thread:

www.piclist.org/techref/postbot.asp?by=thread&id=fractional+powers+in+integer+math%2E&tgt=&key=fractional+powers+in+integer+math&from=

2006\06\30@101627 by olin piclist

face picon face
Kevin wrote:
> This part.
> Two poles of LPF each with 8 shift bits per pole settles to about 93%
> in 1100 iterations.
> especially since shifting by 8 bits is particularly trivial,
> and 2 x 8 bits is a lot of random noise attenuation.

There are a lot of statements in there, so again it's not clear what
specifically you are asking about.

I guess the only choice is to start at the beginning.  The "two poles of
LPF" means two low pass filters concatenated.  This would be like two RC
filters with a buffer in between them.

Better answers require better questions.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\06\30@120203 by Kevin

picon face
>Kevin wrote:
> > This part.
> > Two poles of LPF each with 8 shift bits per pole settles to about 93%
> > in 1100 iterations.
> > especially since shifting by 8 bits is particularly trivial,
> > and 2 x 8 bits is a lot of random noise attenuation.
>
> There are a lot of statements in there, so again it's not clear what
> specifically you are asking about.
>
> I guess the only choice is to start at the beginning.  The "two poles of
> LPF" means two low pass filters concatenated.  This would be like two RC
> filters with a buffer in between them.
>
> Better answers require better questions.

I guess it falls into the I don't know what I don't know
category. I'll check out a book and post a more direct
question in the future.

TIA,
Kevin

2006\06\30@130738 by olin piclist

face picon face
Kevin wrote:
>> Kevin wrote:
>>> This part.
>>> Two poles of LPF each with 8 shift bits per pole settles to about 93%
>>> in 1100 iterations.
>>> especially since shifting by 8 bits is particularly trivial,
>>> and 2 x 8 bits is a lot of random noise attenuation.
>>
>> There are a lot of statements in there, so again it's not clear what
>> specifically you are asking about.
>>
>> I guess the only choice is to start at the beginning.  The "two poles
>> of LPF" means two low pass filters concatenated.  This would be like
>> two RC filters with a buffer in between them.
>>
>> Better answers require better questions.
>
> I guess it falls into the I don't know what I don't know
> category. I'll check out a book and post a more direct
> question in the future.

Or you could say what specifically you want clarification on.  Do you not
understand what is meant by two poles?  By shifting 8 bits?  What settling
time is?  How 93% was arrived at?  What an iteration is?  Why 1100
iterations?  Why shifting by 8 bits is particularly trivial?  Why 2 x 8 bits
is a lot of random noise attenuations?  What is meant by random noise?

Do you see how it would be unreasonable to try to answer all these questions
in a single message, especially since you probably only want the answer to a
few of them?


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\06\30@141726 by Kevin

picon face
{Quote hidden}

Yes, what is meant by two poles ?

>By shifting 8 bits?
I understand how to shift 8 bits, but why ?
Normally, I would take 50 10bit adc readings, add them and
then divied by 50 to get an average result.

What is settling time ?
I believe it is the time needed in between AD readings.
You said previously 1ms. is more that adequate between
successive ADC readings.

Yes How is 93% arrived at and what is it's significance?

What an iteration is?
A computational procedure in which a cycle of operations is
repeated, often to approximate the desired result more
closely. >>> from dictionary.com

Why 1100 iterations?
I assume based on the original discussion, he had time to
perform this many reads of the ADC while performing other
tasks.

Why shifting by 8 bits is particularly trivial?
I assume it has something to do with a bit mask,
Or is achieved by a single instruction ?

Why is 2 x 8 bits a lot of random noise attenuations?

> What is meant by random noise?
I understand random noise.


TIA,
Kevin

2006\06\30@151931 by olin piclist

face picon face
part 1 3866 bytes content-type:text/plain; format=flowed; charset="iso-8859-1"; (decoded 7bit)

Kevin wrote:
> Yes, what is meant by two poles ?

In this context, a pole means a single simple filter.  In analog, one RC
creates a single pole.  A simple iterative equation for a single pole low
pass filter is

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

where FILT is the filter output value, NEW is the filter input value this
iteration, and FF is an adjustment factor intended to range between 0
(infinitely heavy filter, output never changes) to 1 (no filtering at all,
output follows input).  The nice thing about this equation is that it's easy
to compute, especially when FF is 1 / 2**N where N is an integer.  In other
words, FF could be 1/4, 1/8, 1/16, etc.  In those cases, the multiply by FF
can be performed by a right shift of N bits.

This type of filter is the same as a RC low pass filter in the analog
domain.  Just like you can use several RC filters in series, you can use
several of these digital filters in series.  Each one of the operations
described by this equation is a pole.  This is like connecting the output of
one RC low pass filter to the input of another with a buffer amp in between.
For example, a two pole digital low pass filter based on the above equation
is:

 FILT1 <-- FILT1 + FF1(NEW - FILT1)
 FILT2 <-- FILT2 + FF2(FILT1 - FILT2)

The overall input is NEW and the output FILT2.

>> By shifting 8 bits?
> I understand how to shift 8 bits, but why ?

I was referring to the right shift to realize the multiply by FF.  Using a
shift value of 8 bits means FF = 1/256.

> Normally, I would take 50 10bit adc readings, add them and
> then divied by 50 to get an average result.

That takes a lot of memory and cycles.  At the very least it would be better
to average 32 or 64 readings.  The expensive divide by the number of
readings then becomes just an inexpensive right shift.

This type of filter is called a box filter.  It's not that great in terms of
frequency response, random noise attenuation compared to the filter I
described above.

> What is settling time ?

I was referring to the settling time, or step response time of the filter.
If everything starts out at zero, then you change the input instantaneously
to 1, how fast will the output follow?  Since it is an exponential
approaching 1, it is not meaningful to ask how long it takes to get to 1.
However, you can talk about how long it takes to get various fractions of
the way there.  I use my FILTBITS or PLOTFILT programs to show me the step
response of filters given the FF values for each pole.  Actually the command
line values are in bits of shift rather than FF directly.  I have attached a
step response plot of two poles each with 8 shift bits (FF = 1/256 for each
pole).  From this you can see that this filter settles to about 90% in 1000
iterations.

> Yes How is 93% arrived at and what is it's significance?

>From the plot you can see that the filter reaches about 93% of its final
value at 1100 iterations.

> Why shifting by 8 bits is particularly trivial?
> I assume it has something to do with a bit mask,
> Or is achieved by a single instruction ?

No, it's because the machine addresses memory in 8 bit chunks called bytes.
Therefore there is no need to "shift" a value right 8 bits, you just read it
starting 1 byte into it.

> Why is 2 x 8 bits a lot of random noise attenuations?

Look at what happens when NEW in the top equation has a glitch one
iteration.  FF of that glitch will make it to the output.  For two poles,
FF1*FF2 of the glitch will make it to the output.  If you express the FF
values in terms of the bits shifted, then the glitch is attenuated by 2**N
where N is the sum of all the shift bits for all the poles.  Two poles of 8
shift bits each (FF1 = FF2 = 1/256) attenuates a glitch, or any random
noise, by 16 bits or 1/65536.


part 2 6086 bytes content-type:image/gif; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2006\06\30@181812 by Kben

picon face
Olin Lathrop <EraseMEolin_piclistspam_OUTspamTakeThisOuTembedinc.com> said:

> Kevin wrote:
> > Yes, what is meant by two poles ?
>
> In this context, a pole means a single simple filter.  
In analog, one RC
> creates a single pole.  A simple iterative equation for
a single pole low
> pass filter is
>
<< Snipped for space >>>

Well, I am heading on vacation, so I will have a few days
to digest your detailed response.

I appreciate you taking the time to educate me !

Thanks Again,
Kevin



'[PIC] C18 calculating the interrupt loading'
2006\07\02@112918 by Phillip
picon face
Olin
What I'm getting from adding a simple test in my ISR is that the extraneous
characters are simply dropped when they arrive so the foreground task is
only processing exact commands from the UART device.
The price is only a few cycles because it is a very simple test.
I have thought about it and I'm happy to pay that very low price because it
makes things simpler and more elegant elsewhere.
When I wrote DOS device drivers (many years ago) my philosophy was that a
device driver should hide complexity from the application and make the
device simple for the application programmer to use.
Of course this can never come at the cost of performance.
For the record I view ISRs in a PIC as device drivers.
By adding a simple test my ISR removes complexity from the application and
I'm happy with that decision.
I'm not sure how much more clearly I can make this for you or why this is so
blasphemous but I think it is more about your being right than my design
being hopelessly flawed...BTW it works just fine.
This does not mean I don't understand why you do things the way you do.
Most PIC projects have high latency requirements and if servicing ISRs take
too long you will miss events so they can't be larded up with extra stuff
that could be done later on when there is plenty of time.
I have another project where I use the standard technique exactly.

My tag line is just that a tag line.
"It is not a philosophy to live or to write code by it is the equivalent of
a smiley face to show I don't take my self too seriously nor should anyone
else."
Of the thousands of E-mails I have sent in the last few years as far as I
know you are the only person to take it seriously.
WI suspect you are not and that are only looking for a put down because that
is what drives your giant ego and your need to feel superior by putting
others down with your dazzling PIC programming skills..
(For the record the tag line was used by a friend of mine for years.
The above quote was his.
Unlike me he was actually a real software engineer and a wise and decent
person that taught me much about programming and even more about life.  
I never thought much of tag lines or used them. When I learned of his death
I began to use it as a tribute to my friend.  I believe the quote is
originally attributed to Albert Einstein.)

It seems to me the real problem here is my title of CTO not my obvious lack
of/poor PIC programming skills.
For the record I am more than the CTO at GPS Source I'm also the founder and
owner with my partner.
We have been in business for six years and I have fifteen full time
employees.
I also employee four consultants (two CAD engineers (full time) and a PCB
layout guy part time and a brochure/web graphics guy.
We might be small but I am very proud of all we have accomplished and that
we did it with our own money and sweat.
I am more proud of our low hardware failure rate in the field.
I would put my paycheck up against anyone's on this list not to mention my
equity in GPS Source.
I hired a guy that worked for me at another company to be my CEO last June
because I'm unqualified and I'm not good at it.
He insisted that I have a title other than engineer.
His reasoning was that when we did presentations and negotiated contracts
was that it would inspire confidence in our customers.
He also stopped making me say my title was "hey you butt face" in front of
customers... and he wouldn't let have a pool table in my new office some
nonsense about buying a new network analyzer instead.
I have never been a big believer in fancy titles they are highly over rated
and used to avoid paying people what they are really worth.
And I didn't want to do it because reactions like yours but I pay the guy to
run my company if I don't take his advice then I need to fire him.
Originally I had two signatures with one that said engineer but I
continually forgot to switch so finally I just left it the way he wanted and
moved on.
In the beginning of my company I did every job except for the soldering.
I can do it but don't have the patience.
My partner is an MBA but he was a technician in the military years ago and
is NASA certified for soldering.
So while my partner did the books sales and soldering I did everything else
from cleaning the toilets to shoveling snow to the RF design and wiring the
network.
For the record besides programming a PIC I scraped a big ward of gum off the
side walk two days ago and I washed all the containers and utensils from the
company picnic the day before.

As CTO my first rule is to always hire people that are smarter than myself.
I have a long successful track record of searching users groups to find
consultants and to hire talent.
It lets me see examples of their work and I can see their true nature that
is not present in a typical interview process.
Recently when I wanted to move to a new mechanical design tool from 2D
AutoCad I chose a tool and I taught myself how to use it.
I was no expert and I'm still not but my mechanical designs work fine and
the mill and injection molding tools are now driven from a solid modeling
program "Alibre design".
When the work load became too great I joined a user's group for Alibre
design and I found guys there that were able to answer my questions and
explain things to guy with only 2D experience.
>From my users group contacts I choose the two guys that work for me full
time.
I did the same thing for the PCB layout guy that we use when we need the
extra help.
Now I would be considered a PCB layout guru.
I have used Orcad schematic capture and PCB layout for years so I went to a
users group and started asking stupid questions.
There was a consultant there that happily took up the slack.
I plan on doing the same for the PIC though I might switch to the Atmel AVR
product for future designs. I'm impressed with the development tools and
device architecture.
I do all the IT work at my company currently but like the other things it
has now neared the point that I can no longer keep up with the work load and
I am considering a guy that is employed by a IT/MIS users group/advice web
site (it is fee based).
Yep I'm no IT guru either but the web site is up and my E-mail works and the
backups run every Saturday morning.

For the record I was considering sending some work your way but I would
never hire someone so arrogant and condescending.
Life is too short to deal with people that are so insecure that they can
only feel good about themselves by putting others down........no matter how
smart they are.

So I have a six year record of success as a CTO and a very profitable
company that has stellar growth and I managed to do it all with out being a
"lowly PIC guru".
For the record here is the link to the last product I designed using a
16F676 PIC http://www.gpssource.com/testproductdetail.php?id=118  
Is it up to great an mighty Olin's standards?
I'm sure it's not.
Did it pass environmental and electrical testing (I was worried about the
50kV surges on the RF ports) well as a matter of fact it did.
Is the customer satisfied?
Well yes they have placed a nice six figure order over the next three years
with more follow on likely.
So while I might not be a genius like you I'm doing ok as a PIC programmer.
This certainly does not mean I could not or would not like to learn more.
I will be following and likely heading your advice for coding a 2 pole low
pass filter.


If you want to learn about GPS there is much I could teach you but I doubt
I'll have time.
I just filed a patent for (I am the co-author of three now) what I call a
GPS spot locator and I have private equity investors that want to fund the
development as a separate company all without your approval of me as a PIC
guru.
So while you feign worry about my PIC ignorance I am not exactly losing
sleep over my poor PIC programming technique.
The guy I hire to take over that function will be just fine.
Plus having the right skill set he will not be condescending and arrogant.
I've know many smart engineers like you.
They would grouse when the sales guy got a $250K commission that they were
smarter than they deserved they money instead of the stupid sales guy.
They never missed a chance to put people in their place so it was clear
everyone knew how smart they were.
They were also passed over for upper management at each juncture and in the
end they ending being managed by kids out of school or working as a
consultant because no one could stand to work with them.

Phillip
Things should be as simple as possible but no simpler



Phillip Coiner
CTO, GPS Source, Inc.


Your source for quality GNSS Networking Solutions and Design Services, Now!

{Original Message removed}

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