Post by thread:Tight Loop for Input Detection

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

On Thu, Dec 18, 2008 at 4:59 PM, Larry Bradley <spam_OUTlarry.bradleyTakeThisOuTncf.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

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.bradleyKILLspam@spam@ncf.ca> wrote: {Quote hidden}> 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

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/

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.

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.bradleyKILLspamncf.ca>wrote: {Quote hidden}> 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 >

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.bradleyKILLspam.....ncf.ca>wrote: {Quote hidden}> 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 >

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/