Come on ski.
You're not being a "Teacher".
You are purposely tormenting him. And enjoying it.
It's a single line of code.
Just tell him.
<br>
|
Come on ski.
You're not being a "Teacher".
You are purposely tormenting him. And enjoying it.
It's a single line of code.
Just tell him.
<br>
DT
|
But I'm not a teacher, heck, as you all probably know, I'm not even a programmer!Originally Posted by Darrel Taylor
I am, however, a leader. Ask any of the guys that I trained to replace me, and they have...they'll tell you...(show me your war face! Arrrrrggghhhh!)
And I'm not enjoying it. It's like having a noob (at my job anyways) and trying to explain the inner workings of a synchro system and how it fully applies to an autopilot system...and he just doesn't get it (ran into this exact situation last week). Felt like slapping the kid across the flightline. Took him 3 days, then he came in monday morning with the answers and it had all clicked over the weekend (of course I had assigned him weekend duty just to try and comprehend the whole thing)...
|
Remind me not to fly on one of your planes.
When people get thrown extra duty because they didn't know something and the boss refused to help.
It's likely they won't bother asking questions the next time they have problems.
Who know's what goes un-fixed.
Fine, I'll do it.
xnihilo,
Remove the other INTCON statement.Code:i VAR BYTE i = PORTA ' Clear mismatch condition INTCON = %00001000 ' enable porta interrupts on change and clear flag ON INTERRUPT GOTO in_sig ' int routine
DT
|
WHOA! Don't get me wrong...I'm not that much of a jerk. They had it coming to them anyways...regardless if they would've had the answer or not.
And I had given them ALL of the tools they needed to solve the issue at hand.
And...don't forget...I'm a pilot myself. I know the responsibility that comes with having others living directly in your hands.
Sounds like a 'Hair Club for Men' commercial...
Not only am I a pilot, but I work on them too...
At any rate...I hope that fixes the issue with the program. I was going to fix it in a more roundabout way, but your solution works better.
Last edited by skimask; - 21st March 2008 at 23:03.
|
solving interrupt mysteries
Thank you very much, I'll report if it worked for me.
Have a nice WE.
|
Progressing
It looks like I could finaly prevent interrupts occuring without no reason.
I still have to thoroughly test the program.
I would like to know what's the need for GIE.
In your code above, you don't enable GIE at all, I followed your instructions and it worked.
I thought that in order for Interrupts for PORTA change (or any interrupts) to be enabled, GIE bit had to be set. I could not find clear information neither in pbp manual nor in the pic datasheet.
I have more strange things happening though, in my program just after the int routine label if I add an LCD output with the value of variable "a" bits (with a loop of 6 iterations and LCDOUT #a.0(i)) after an "a=porta" to get port pins values and clear mismatch), the value displayed doesn't change no matter what pin triggered the int (even if the right pin is detected), and ever more strange, after the interrupt routine is finished and before going back to the infinite loop, the value of portA bits is displayed once again, with no reason...
Subtleties...
Anyway, thanks a lot for your help, hope it solved the problem. It is still not crystal clear for me how to use stuff related to interrupts, I'm using the instructions more or less empiricaly and I'm not sure about the order in which I write the program sections.
If you have some time to waste, maybe you could have a look at my program and let me know if you see very horrible things
http://users.edpnet.be/charlesetchri...g/se230308.pbp
Best regards
|
When using ON INTERRUPT, the GIE bit is controlled by PBP.
Any attempts to change it manually will cause problems.
And the IOC port change interrupt, doesn't save the state of the PINs for you. If you're just getting a quick pulse, it's possible that the pulse is gone by the time you try to display the pins, or determine who shot you with what.
The very first statement in the interrupt handler should read PORTA and save the value in a variable. Then use that variable throughout your handler, instead of the pins themselves.
The IOC interrupt also triggers on any pins transition from low to high, or high to low.
But your program is only looking for HIGH states. If it makes it all the way through the handler before the pulse goes away, then you will get another interrupt at the end of the input pulse. This time it'll look like all the pins are at their default state, as if nothing changed. You'll need to account for the second interrupt, somehow.
You're also clearing the interrupt flag in 2 places in the handler, one at the beginning, and another at the end of the handler. The first one attempts to clear the flag, before PORTA has been read. But it won't clear the flag, because the mismatch condition still exists.
Read PORTA first, then clear the flag.
At the end of the handler, it clears the flag, but doesn't read PORTA.
With things like LCDOUT's in the handler, it can take quite a while to complete the handler, and the PINs may have changed in the mean time, so it would be necessary to read PORTA again before clearing the flag.
hth,
DT
|
Thank you
I didn't understand that when I read PBP manual section dedicated to INTERRUPTS.
I understand but then I need to poll the pin that triggered the int because I'm reading a PWM signal on a Infrared Sensor (that pulls the pin LOW) that looks like:And the IOC port change interrupt, doesn't save the state of the PINs for you. If you're just getting a quick pulse, it's possible that the pulse is gone by the time you try to display the pins, or determine who shot you with what.
The very first statement in the interrupt handler should read PORTA and save the value in a variable. Then use that variable throughout your handler, instead of the pins themselves.
a header (1200us ON, 600us OFF, 1200us ON, 600us OFF), then 8 times (8bits) either 600us ON or OFF followed by 600us OFF spacers, then a 600us OFF (trailer).
By the way, is the following indexed byte variable bit accessing "variable.0(indexvariable)" correct? Everyone on the forum does not seem to agree.
a VAR BYTE
...
a = porta
for i = 0 to 5
LCDOUT #a.0(i)
next i
In fact, pins are HIGH because of the WPU, I'm looking for HIGH->LOW transitions.The IOC interrupt also triggers on any pins transition from low to high, or high to low.
But your program is only looking for HIGH states.
Am I wrong about the use of WPU?
By the way, something strange in PIC16f684 datasheet: to enable individual WPU, OPTION_REG bit 7 has to be "0"... Strange, isn't it? Shouldn't the bit be set instead of cleared?
If it makes it all the way through the handler before the pulse goes away, then you will get another interrupt at the end of the input pulse. This time it'll look like all the pins are at their default state, as if nothing changed. You'll need to account for the second interrupt, somehow.
In my routine, there is a block that will scan the input on the triggering pin for the duration of the expected signal (about 14.4ms) so the interrupts will not be re-enabled until the 14.4ms duration has elapsed. Efter that, yes, another interrupt may occur if some signal arrives on a pin and the int handler will check if the signal has the right structure, duration and if the data carried is valid. I hope my algorythm was fine.
Right.You're also clearing the interrupt flag in 2 places in the handler, one at the beginning, and another at the end of the handler. The first one attempts to clear the flag, before PORTA has been read. But it won't clear the flag, because the mismatch condition still exists.
Read PORTA first, then clear the flag.
You are geat, thank you so much for your explanations.At the end of the handler, it clears the flag, but doesn't read PORTA.
With things like LCDOUT's in the handler, it can take quite a while to complete the handler, and the PINs may have changed in the mean time, so it would be necessary to read PORTA again before clearing the flag.
hth,
|
Oh, is that what it's supposed to do.In my routine, there is a block that will scan the input on the triggering pin for the duration of the expected signal (about 14.4ms) so the interrupts will not be re-enabled until the 14.4ms duration has elapsed.
Might be a problem there. The comment also says 14400 uS, but those loops are going to take about 14.4 seconds instead.
Actually, it looks like all your comments show PAUSEs in uS. But the PAUSE statement delays in milliseconds.Code:FOR i = 0 TO 960 'total loop time: 14400 uS which is the total length of the bullet PAUSE 15 'remember that the minimum delay at 8MHz is 12 uS IF PORTA.0(area) == 1 THEN breakloop2 'when signal goes high, exit loop and check duration before the change, you need about 600us NEXT i
You probably wanted PAUSEUS.
DT
|
Do you know the movies "SAW", I wonder why I think about it when I read your posts...But I'm not a teacher, heck, as you all probably know, I'm not even a programmer!
I am, however, a leader. Ask any of the guys that I trained to replace me, and they have...they'll tell you...(show me your war face! Arrrrrggghhhh!)
And I'm not enjoying it. It's like having a noob (at my job anyways) and trying to explain the inner workings of a synchro system and how it fully applies to an autopilot system...and he just doesn't get it (ran into this exact situation last week). Felt like slapping the kid across the flightline. Took him 3 days, then he came in monday morning with the answers and it had all clicked over the weekend (of course I had assigned him weekend duty just to try and comprehend the whole thing)...
|
'cause you like things like heating pads and shooting things I guess.
And no, I haven't seen SAW. Should have seen SAW? I'll ask the wife if she saw SAW...while she's on the see-saw. Maybe she saw SAW. Maybe I should go see SAW. If I saw SAW, maybe I'd see what you saw when you saw SAW. I'll report back after I see SAW to tell you what I saw when I saw SAW.
Members who have read this thread : 0You do not have permission to view the list of names.
Posting Permissions
Bookmarks