Searching \ for '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/ios.htm?key=input
Search entire site for: 'Tight Loop for Input Detection'.

Truncated match.
PICList Thread
'Tight Loop for Input Detection'
2008\12\18@195955 by Larry Bradley

flavicon
face
Doesn't solve the problem - it adds code to the loop. I did the ISR with the flag to test the portb on change stuff and to test the rest of my code. But I want to avoid testing anything in the loop other than the port bit I'm examining.

The return-from-interrrupt-to-a-different-place is doable - I just can't figure out how from the 18F manuals

Larry



Original Message:
>
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@201331 by Marcel Birthelmer

picon face
On Thu, Dec 18, 2008 at 4:59 PM, Larry Bradley <spam_OUTlarry.bradleyTakeThisOuTspamncf.ca> wrote:

> Doesn't solve the problem - it adds code to the loop. I did the ISR with
> the flag to test the portb on change stuff and to test the rest of my code.
> But I want to avoid testing anything in the loop other than the port bit I'm
> examining.
>
> The return-from-interrrupt-to-a-different-place is doable - I just can't
> figure out how from the 18F manuals
>
> Larry


Maybe I'm not understanding what you're trying to achieve... With the scheme
I proposed (testing RBIF), you could completely avoid the ISR altogether:

test_rbif: BTFSS INTCON, RBIF
  goto test_rbif

; check which pin was toggled
; jump to appropriate routine.

I don't see how that's any slower than some nightmare-to-debug
jump-out-of-an-ISR mechanism.

- Marcel

2008\12\18@212047 by Larry Bradley

flavicon
face
I wonder why Marcel swa the post an others didn't?

Marcel, I'm measuring the width of a pulse on a port pin. I do exactly what you say, to test THAT pin.

But I also have a push button that is used to get into a menu system, and it has to be able to get the program out of the loop testing the input pin.

I can add code to the loop to test for the button, but that adds more code to the loop, which means that the minimum pulse width I can detect increases.

So I thought that the ISR could detect the pushbutton press, and rather than return back to the loop as it normally would, could return to another location in the program where I would handle the button press.

And this is a generally useful thing to be able to do - have an interrupt break out of a loop.

Larry



Original Message:
>
On Thu, Dec 18, 2008 at 4:59 PM, Larry Bradley <.....larry.bradleyKILLspamspam@spam@ncf.ca> wrote:

{Quote hidden}

Maybe I'm not understanding what you're trying to achieve... With the scheme
I proposed (testing RBIF), you could completely avoid the ISR altogether:

test_rbif: BTFSS INTCON, RBIF
goto test_rbif

; check which pin was toggled
; jump to appropriate routine.

I don't see how that's any slower than some nightmare-to-debug
jump-out-of-an-ISR mechanism.

- Marcel

2008\12\19@125758 by Larry Bradley

flavicon
face
Nice idea, Isaac. I'll look into that as well. Thanks

Larry



Original Message:

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=E7a liga=E7=F5es para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2008\12\19@130219 by Larry Bradley

flavicon
face
Olin:

Interesting. I didn't think I was. My email client sends out both HTML and plain text. The HTML has the proper format, - perhaps the plain text does not. Since I wrote the client, I can check it out and fix it if necessary.

Thanks .


Larry



Original Message:
>
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@131739 by Marcel Birthelmer

picon face
Larry,
1) most people on this list will prefer plain-text only, and indeed some
mail clients to not handle the multi-part messages very gracefully.
2) your client (or maybe server) keeps garbling the subject line with some
business about spam filtering. That's really obnoxious.

About your problem, how about just using a hardware timer to measure the
pulse width? In your main loop, just do your menu management stuff, if you
detect an interrupt on the line that you're measuring the pulse on, just
start a counter, then wait for another interrupt to stop it. Of course
that's subject to some limitations in terms of measurement length, but you
can work around those fairly easily I'd say.
- Marcel

On Fri, Dec 19, 2008 at 10:01 AM, Larry Bradley <larry.bradleyspamKILLspamncf.ca>wrote:

{Quote hidden}

2008\12\19@135612 by Larry Bradley

flavicon
face
Marcel:

The subject line is messed up by my server - if a sender is not recognized, it does this. I should clean it up whenever I reply, but I forget at times. I think I'll modify my email client to do this.

The way that multipart messages are supposed to work, is that a client that does not know about mutipart will get the plain text version. I don't have a mail client that doesn't handle multipart, so it's hard to check this out.

My mail program always sends multi-part, even if there is no HTML in the body of the message - it's a lot easier that way. But I do put a plain-text version in as well.

I'll have to check it out a bit more.

As to the pulse width, I've tried that, and also using the CCP module in capture mode. The "test the bit in a loop" gives the best results.

Larry



Original Message:
>

Larry,
1) most people on this list will prefer plain-text only, and indeed some
mail clients to not handle the multi-part messages very gracefully.
2) your client (or maybe server) keeps garbling the subject line with some
business about spam filtering. That's really obnoxious.

About your problem, how about just using a hardware timer to measure the
pulse width? In your main loop, just do your menu management stuff, if you
detect an interrupt on the line that you're measuring the pulse on, just
start a counter, then wait for another interrupt to stop it. Of course
that's subject to some limitations in terms of measurement length, but you
can work around those fairly easily I'd say.
- Marcel

On Fri, Dec 19, 2008 at 10:01 AM, Larry Bradley <.....larry.bradleyKILLspamspam.....ncf.ca>wrote:

{Quote hidden}

2008\12\19@142855 by Isaac Marino Bavaresco

flavicon
face
Larry Bradley escreveu:

....
> As to the pulse width, I've tried that, and also using the CCP module in capture mode. The "test the bit in a loop" gives the best results.
>
> Larry
....

Some PICs have a TMR1 with GATE input, which is the best way to measure
pulses (not total period, just the low or high part).

For instance if you want to measure the "high" width:

1) Stop TMR1;
2) Clear TMR1;
3) Set TMR1 to run when GATE is "high";
3) Wait for the signal (tied to the GATE pin) go "low";
4) Start TMR1;
5) Wait for the signal go "high" (may be a very sloppy loop);
6) Wait for the signal go "low" (may be a very sloppy loop);
7) Stop TMR1 and read the result.

This way you will get a resolution of one Tcy, but each semi-cycle must
be longer than the time you take to detect a transition.


Regards,

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

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