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

Exact match. Not showing close matches.
PICList Thread
'[PIC] Tight Loop for Input Detection'
2008\12\18@192027 by Marcel Birthelmer

picon face
Why don't you just check the interrupt bit itself from the routine and don't
use interrupts at all? For PORTB interrupt-on-change, this would be
INTCON<0> = RBIF (at least based on this 18F452 datasheet I have laying
around).
- Marcel

2008\12\18@201116 by Jinx

face picon face
I haven't received the original post. Probably many others haven't either

Can you re-send it please

2008\12\18@201758 by Marcel Birthelmer

picon face
(from Larry, with no subject):

I have a program that is sampling an input port in a tight loop. I want that
loop to have as few instructions as possible.

I detect a switch press by using port change interrupt. I want the switch
press to get me out of the loop and go "elsewhere"

I have made it work by setting a bit in the ISR, and having code in the loop
to test this bit and then exit the loop. This works just fine, except that
it adds code (and thus time) to the loop.

I'd like to have the ISR return to "elsewhere". I've looked in the 18F
series reference manual, at the push and pop instructions. There is
discussion about this in section 7.7.2, but it is a bit confusing.

I think what I have to do is initialize the stack with the address of
"elsewhere" (the location to which I want the ISR to return). Then, in the
ISR, just before I issue the RETFIE, I need to POP the stack to throw away
the top address (where the interrupt occurred) and allow the RETFIE to use
"elsewhere" as the return address.

The reference manual suggests that I put the desired return address
("elsewhere") into the three TOS registers, then do a PUSH. What confuses me
is that the PUSH documentation says that is puts the current PC on the
stack. Thus after this, the top of stack would be the current PC, and the
entry below would be the address of "elsewhere".

Has anyone done this kind of thing, and can point me to an example?

Many thanks.

Larry Bradley
Ottawa, Canada

2008\12\19@081511 by olin piclist

face picon face
> (from Larry, with no subject):

Duh.

> I have a program that is sampling an input port in a tight loop. I
> want that loop to have as few instructions as possible.
>
> I detect a switch press by using port change interrupt. I want the
> switch press to get me out of the loop and go "elsewhere"

Why does it need to be so tight for detecting a mechanical switch?  If the
switch is pressed by a human, then you've got 10s of mS slop before anyone
can notice the difference.  Even if not, mechanical switches will have a few
100 uS uncertainty at least.  What's the rush?

Then there is bouncing.  Are you really only looking at the leading edge of
the switch press, or will it mess things up if the switch appears to be
released and pressed again 10s of times in the first few mS?  If the latter,
you need to put some debouncing logic in there anyway.

> I have made it work by setting a bit in the ISR, and having code in
> the loop to test this bit and then exit the loop. This works just
> fine, except that it adds code (and thus time) to the loop.

So?  How much time?  Why is that a problem?  How much lag can you tolerate
from first switch press to PIC responding?  And no, don't tell me "as fast
as possible".

> I'd like to have the ISR return to "elsewhere".

That is likely a bad approach.  Spec the problem better and step back two
levels and explain the higher level problem you are trying to solve.  You're
not ready yet for implementation details, especially something like making
the interrupt routine not return normally.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\12\19@120940 by Larry Bradley

flavicon
face
I didn't explain the actual problem very well. The "sampling in a tight loop" is trying to measure the width of a pulse on an input pin. The button press isn't what is being sampled. The button press invokes a menu system that controls the action of the program. The problem I'm trying to solve is that if there is NO signal on the input pin, the program stays in the loop, and ignores (naturally) the button.

What I want to do is exit the loop when the button is pressed. One way, which works fine, is to test the button pin in the sampling loop as well as the signal pin. It just means that the minimum pulse width that I can measure increases as the size of the loop increases. I thought that having an interrupt routine for the button that returns to code that process the button push would be a solution.

I thought perhaps that someone here might have done this kind of thing.

I have been directed to a Microchip app note (AN818) that discusses this very thing, so I'll give it a try.

This is as much a learning exercise as anything practical. The concept of having an interrupt return to some place other than the point of interrupt is used in other programming environments, so I though that using it in the PIC would be an interesting exercise.

Thanks

Larry


Original Message:
>
> (from Larry, with no subject):

Duh.

> I have a program that is sampling an input port in a tight loop. I
> want that loop to have as few instructions as possible.
>
> I detect a switch press by using port change interrupt. I want the
> switch press to get me out of the loop and go "elsewhere"

Why does it need to be so tight for detecting a mechanical switch? If the
switch is pressed by a human, then you've got 10s of mS slop before anyone
can notice the difference. Even if not, mechanical switches will have a few
100 uS uncertainty at least. What's the rush?

Then there is bouncing. Are you really only looking at the leading edge of
the switch press, or will it mess things up if the switch appears to be
released and pressed again 10s of times in the first few mS? If the latter,
you need to put some debouncing logic in there anyway.

> I have made it work by setting a bit in the ISR, and having code in
> the loop to test this bit and then exit the loop. This works just
> fine, except that it adds code (and thus time) to the loop.

So? How much time? Why is that a problem? How much lag can you tolerate
from first switch press to PIC responding? And no, don't tell me "as fast
as possible".

> I'd like to have the ISR return to "elsewhere".

That is likely a bad approach. Spec the problem better and step back two
levels and explain the higher level problem you are trying to solve. You're
not ready yet for implementation details, especially something like making
the interrupt routine not return normally.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014. Gold level PIC consultants since 2000.

2008\12\19@123658 by olin piclist

face picon face
Larry Bradley wrote:
> I didn't explain the actual problem very well. The "sampling in a
> tight loop" is trying to measure the width of a pulse on an input
> pin. The button press isn't what is being sampled. The button press
> invokes a menu system that controls the action of the pr

Don't send paragraphs as single long lines.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\12\19@124537 by Isaac Marino Bavaresco

flavicon
face
Larry Bradley escreveu:
> I didn't explain the actual problem very well. The "sampling in a tight loop" is trying to measure the width of a pulse on an input pin. The button press isn't what is being sampled. The button press invokes a menu system that controls the action of the program. The problem I'm trying to solve is that if there is NO signal on the input pin, the program stays in the loop, and ignores (naturally) the button.
>
> What I want to do is exit the loop when the button is pressed. One way, which works fine, is to test the button pin in the sampling loop as well as the signal pin. It just means that the minimum pulse width that I can measure increases as the size of the loop increases. I thought that having an interrupt routine for the button that returns to code that process the button push would be a solution.
>
> I thought perhaps that someone here might have done this kind of thing.
>
> I have been directed to a Microchip app note (AN818) that discusses this very thing, so I'll give it a try.
>
> This is as much a learning exercise as anything practical. The concept of having an interrupt return to some place other than the point of interrupt is used in other programming environments, so I though that using it in the PIC would be an interesting exercise.
>
> Thanks
>
> Larry
>  

With a PIC18, it *is* possible for an ISR to "return" to a different
address, but this is a tricky approach.

One possible alternative which will work with any MCU is your ISR to set
an abort flag and then generate artificially the signal that you are
waiting for.

If the signal is open drain, the ISR just needs to make the pin output a
zero (PORTxx = 0, TRISxx = 0). When the ISR returns, the loop will stop
and you must test to see if the TRISxx is a zero (aborted) or a one (the
signal really changed).

Best regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2008\12\19@131341 by Isaac Marino Bavaresco

flavicon
face
Isaac Marino Bavaresco escreveu:
> With a PIC18, it *is* possible for an ISR to "return" to a different
> address, but this is a tricky approach.
>  

Perhaps not too tricky. If you are using C, the setjmp/longjmp should
work (must test).

It should be easy to implement setjmp/longjmp in assembly as well.

> One possible alternative which will work with any MCU is your ISR to set
> an abort flag and then generate artificially the signal that you are
> waiting for.
>
> If the signal is open drain, the ISR just needs to make the pin output a
> zero (PORTxx = 0, TRISxx = 0). When the ISR returns, the loop will stop
> and you must test to see if the TRISxx is a zero (aborted) or a one (the
> signal really changed).
>  

Even if your signal is not open drain, you can add a resistor in series
with the pin to isolate it from the external signal. If the PIC must not
interfere with the signal, you may add a buffer between the signal and
the resistor.

This way is even better, you may abort if you are waiting for a rising
edge also.

Are you trying to make a mini logic-analyzer?

Best regards,

Isaac.
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2008\12\19@133545 by M Wedin

picon face
2008/12/19 Olin Lathrop <spam_OUTolin_piclistTakeThisOuTspamembedinc.com>:

>
> Don't send paragraphs as single long lines.

Yes, please do. Do allow each recipients mail client to present the
text in a decent way such that single words don't get cut off and make
the text incredibly annoying to read.

Example: this is a sentence that
should
be free of carriage returns!

Wed

2008\12\19@134249 by Larry Bradley

flavicon
face
Actually, I'm making a frequency/period/pulse width meter. The tighter the loop, the smaller the pulse width that can be measured. It really isn't a big deal - 2 usec min width vs 1 usec - but as I said to Olin, this is as much a learning exercise as a practical project.

I have the modify-return-address stuff working - that is, I can get out of the loop and back into my main processing loop where I then handle button presses. In the ISR for the button, I increment the stack pointer, put the desired address into the TOS registers, and then return. Works fine.

There are some other issues, but the concept works. The devil is in the details.

Larry



Original Message:
>
Isaac Marino Bavaresco escreveu:
> With a PIC18, it *is* possible for an ISR to "return" to a different
> address, but this is a tricky approach.
>

Perhaps not too tricky. If you are using C, the setjmp/longjmp should
work (must test).

It should be easy to implement setjmp/longjmp in assembly as well.

> One possible alternative which will work with any MCU is your ISR to set
> an abort flag and then generate artificially the signal that you are
> waiting for.
>
> If the signal is open drain, the ISR just needs to make the pin output a
> zero (PORTxx = 0, TRISxx = 0). When the ISR returns, the loop will stop
> and you must test to see if the TRISxx is a zero (aborted) or a one (the
> signal really changed).
>

Even if your signal is not open drain, you can add a resistor in series
with the pin to isolate it from the external signal. If the PIC must not
interfere with the signal, you may add a buffer between the signal and
the resistor.

This way is even better, you may abort if you are waiting for a rising
edge also.

Are you trying to make a mini logic-analyzer?

Best regards,

Isaac.
__________________________________________________
Fa=E7a liga=E7=F5es para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2008\12\19@163311 by Jinx

face picon face
> Actually, I'm making a frequency/period/pulse width meter

Silicon Chip made a 50MHz meter with a 16F84 @ 4MHz

http://www.siliconchip.com.au/cms/A_30706/article.html

s/w download

http://www.siliconchip.com.au/cms/attachments/show.html?year=2003&month=October

Schematic

http://home.clear.net.nz/pages/joecolquitt/50MHz_meter_SC102003.gif

Perhaps you'll get some help from their project

2008\12\19@164642 by apptech

face
flavicon
face
>> I have a program that is sampling an input port in a tight loop. I
>> want that loop to have as few instructions as possible.
>>
>> I detect a switch press by using port change interrupt. I want the
>> switch press to get me out of the loop and go "elsewhere"

Consider trying hardware OR'ing of the signal and button press.
As long as an extra delay is tolerable once a pulse's width is measured you
can set the button press period to be longer than the maximum pulse width
and then make a loop exit decision based on this.

This allows the actual measurement loop to be as short as possible and to
have zero overhead for loop exit management.


            Russell

2008\12\19@165648 by olin piclist

face picon face
> This allows the actual measurement loop to be as short as possible
> and to have zero overhead for loop exit management.

If he's trying to measure pulse period, it sounds like a CCP module in
capture mode is the way to go.  That would be more accurate than even a
tight loop, and lets the code do other things, like look for a button press.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\12\19@181243 by Bob Blick

face
flavicon
face

On Sat, 20 Dec 2008 10:31:53 +1300, "Jinx" <.....joecolquittKILLspamspam@spam@clear.net.nz>
said:

>
> http://home.clear.net.nz/pages/joecolquitt/50MHz_meter_SC102003.gif

Wow, it uses an MC10116 in the front end. It's been a while since I saw
one of those - are they still available? They must have been sort of
obsolete even when that article was written.

Cheerful regards,

Bob

--
http://www.fastmail.fm - A no graphics, no pop-ups email service

2008\12\19@181639 by M.L.

flavicon
face
On Fri, Dec 19, 2008 at 4:31 PM, Jinx <joecolquittspamKILLspamclear.net.nz> wrote:
>> Actually, I'm making a frequency/period/pulse width meter
>
> Silicon Chip made a 50MHz meter with a 16F84 @ 4MHz
>
> http://www.siliconchip.com.au/cms/A_30706/article.html
>
> s/w download
>
> http://www.siliconchip.com.au/cms/attachments/show.html?year=2003&month=October
>
> Schematic
>
> http://home.clear.net.nz/pages/joecolquitt/50MHz_meter_SC102003.gif
>
> Perhaps you'll get some help from their project

I think this project is particularly clever:
hem.passagen.se/communication/freq_c.html
-
ML

2008\12\19@192633 by Jinx

face picon face
> > home.clear.net.nz/pages/joecolquitt/50MHz_meter_SC102003.gif
>
> Wow, it uses an MC10116 in the front end. It's been a while since I
> saw one of those - are they still available? They must have been sort
> of obsolete even when that article was written

Now that you've brought it up, I notice that the photo of the actual
board shows the IC date code as 8443. So his particular chip was
19 years old at the time of printing !!!!! I'm very surprised the editor
let such an old IC to be used - Silicon Chip generally don't make life
difficult for constructors - but the whole thing was available as a kit
at the time so somebody must've had them. Perhaps the author had
a boxful to unload ;-) The technique would still be useful with a more
modern topology. Spec is <20mV @ 100kHz and 85mV @ 50MHz

2008\12\19@193805 by Jinx

face picon face
> I think this project is particularly clever:
> http://hem.passagen.se/communication/freq_c.html

Often a trade-off is made between resolution and measurement time or the
time to accumulate a particular number of pulses, but different methods can
be used at different frequencies

IOW, simply put, a very slow frequency can be measured by capturing it
as an event with good resoltion (as a % compared with its period), whereas
a frequency too fast to measure directly can clock a counter within a set time
or to a particular value (eg rollover) which is timed. That method can lose
part-periods of pulses, although extending measurement periods will give
more accurate results, if your'e prepared to wait

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