Ok, having just dabbled with this on breadboard for a short while, my immediate thought is that the wait for the finger being lifted from the switch, ever so slightly delays the led from lighting up instantly... which makes the actual switch depress feel a tad unresponsive.
Without the wait, then there's obviously going to be another interupt when the finger is removed - but is this such a concern? - can't this second interupt be ignored with dedicated code?
Poor Bruce ...
It's not a book upon PBP he'll have to write , but a 32 parts encyclopaedia ...
sure this explains ...
No, no, Bruce, please , ... do not strike the head :D
Regards
Alain
??
I'm not locked into your groove there ....just feeding back what I'm experiencing. The led obviously lights up after removing the finger from the switch, which sounds fine on paper but in practise it feels a little weird to the senses (ie I guess a lifetime of pushing buttons that immediately light up, is messing with my own grey matter - "Does not compute"!!)
By the way, I'm not asking for anyone to write further code (Bruce has gone beyond the cause here!) ....just bouncing ideas of you all! IOC is all new to me - using the three diodes and the INT pin was ultra responsive....just wondering what ideas can be tabled to make IOC feel similar.
Hi, Hank ( Humour ON : I do love how this sounds ...)
seriously,
I think twisting the Switch: and Process: labels could do it... at first sight. :confused:
Alain
so wouldn't SOMETHING as noobesque (as befits me) like this suffice...
Code:Switch_Interrupt:
If sw1 = 0 then
mode = 1
HIGH LED1 'green LED
LOW LED2 ' red LED
endif
If sw2 = 0 then
mode = 2
HIGH LED1 'green LED
HIGH LED2 ' red LED
endif
If sw3 = 0 then
mode = 3
LOW LED1 'green LED
HIGH LED2 ' red LED
endif
@ INT_RETURN
(Yielding either a green LED, amber-esque led, red led)
ok, it needs padding out....just wanted to get the main cut & thrust across.... the LED would change colour pretty darned quick, thereby giving the user the feeling of 'rapido'.
Yes, sure there'll be an interupt generated when the finger is removed from the switch, but since none of the conditions in the Switch_interrupt subroutine would be met (since the pins would be high when the second interrupt happens) nothing will happen? - a few clock cycles wasted - but hey, there's heaps more where they came from?
or would the quick succession interrupt from the finger being removed from the switch cause probs?
Ok. This one blinks immediately, it's 133 words smaller, and a lot faster than the last...:)
Edit: I don't see why your own version wouldn't work too, but you'll need to sort out the interrupt-on-release.
:o -wow Bruce, what can I say ....that nailed the puppy - my leds are positively zippy now (they light before I've even pressed the switch - and they know which switch I'm going to press...like I say you're good!)Quote:
Originally Posted by Bruce
Can't thank you enough - to paraphrase the woman in Poltergeist "This thread is cleeeeaaan"
....no more questions your honour.
Now, back to PCB layouts....wow, look at all the new space I now have!
Ok....experiencing a few diffs here.
Basically I need IOC interupts (which I'm basing on a simpler cut down noobesque version of excellent Bruce's provided code)...but I also need timer interupts.
My problem is that I get a boat load of errors when my program compiles when IOC & timer interupts are enabled together - what are the errors I hear you say? Well, I'm at work right now so can't cut/paste in what I'm seeing, but what I can say is that when I remove the timer interupt it compiles fine. Or when I remove the IOC interupt it compiles fine - only when both are enabled does it spew out heaps of errors during compilation.
I also know that my overall code is fine - previously I was using the INT pin for interupts ...I was able to get both INT & Timer interupts enabled & working in that setup. So I'm figuring here that maybe this latest way of handling the switches - IOC interupts - are using up a whole lot more PIC resource than the previous way I was doing this? Maybe the combinbation of IOC interupts, timer interupts, plus my coat are pushing things too far?
How to progress this?
Ok, I'm home now.....here are the compile errors...
Error[116] : Address label duplicated or different in second pass (_305AfterUserRoutine)
Error[116] : Address label duplicated or different in second pass (_305NoInt)
Error[116] : Address label duplicated or different in second pass (INT_EXIT)
Error[116] : Address label duplicated or different in second pass (_290OverCREATE)
Error[116] : Address label duplicated or different in second pass (L00001)
Error[116] : Address label duplicated or different in second pass (L00002)
Error[116] : Address label duplicated or different in second pass (L00003)
.....and so on.
Like I say I think it's to do with both interupt handlers being enabled?
Which prompts me, how should two interupt handlers be coded wrt 'returns'. Should it look like this (wrt IOC Interupts, I've stripped it back to basics & removed the disabling/enabling in the interupt handler here.... just for easiness on the eye)
Code:LED1 VAR PORTB.1
INCLUDE "DT_INTS-14.bas" ' Base Interrupt System
INCLUDE "ReEnterPBP.bas" ' Include if using PBP interrupts
ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler RABC_INT, _Switch_Interupt, PBP, no
INT_Handler TMR1_INT, _ToggleLED1, PBP, yes
endm
INT_CREATE ; Creates the interrupt processor
ENDASM
T1CON = $31 ; Prescaler = 8, TMR1ON
@ INT_ENABLE TMR1_INT ; enable Timer 1 interrupts
@ INT_ENABLE RABC_INT
Main:
PAUSE 1
GOTO Main
'---[TMR1 - interrupt handler]--------------------------------------------------
ToggleLED1:
TOGGLE LED1
@ INT_RETURN
'---[ioc Interupt Handler]------------------------------------------------------
Switch_Interupt:
TOGGLE LED2
@ INT_RETURN
Many thanks.
Is that the whole program?
The errors seem to indicate there's another INT_CREATE somewhere.
Hi, DarrelQuote:
Originally Posted by Darrel Taylor
May be not it here, but ...
Do you remember those errors also appeared in MPLAB 8.30 ( ? ), when PBP 2.50 was released ???
( was necessary to twist the Project/Build options/project/settings :" -ampasmwin -k#" )
Alain
Thought about that, but it only affected DT_INTS-18.Quote:
Do you remember those errors also appeared in MPLAB 8.30 ( ? ), when PBP 2.50 was released ???
He's using -14 here.
And as shown, it compiles without error here on a 16F690.
PBP2.60A
MPASM 5.36 from MPLAB 8.53, using MCS+.
Compiles fine here with MPLAB 8.53 ... IF Led2 is declared :rolleyes:Quote:
Originally Posted by Darrel Taylor
Alain
Ok, the plot thickens.
Rightly or wrongly, I have somewhat bloated interupt handlers (BTW are there any guidelines/rules about how many lines, if statements etc you can lob in there?)
For example, this is what I'm doing when an IOC occurs (this is my interupt handling routine)...
Code:Switch_Interrupt:
@ INT_DISABLE RABC_INT ; Disable further IOC interrupts
'DEBUG "Interrupt On_status= ", dec on_status, " Mode = ", DEC mode, " AGC Status= ", dec Agc_on_status, 13, 10
IF sw1 = 0 THEN
if on_status = 1 and mode = 1 then goto Switch_off
Mode2_control = 1
Mode3_control = 0
Mode4_control = 1
on_status = 1
MODE = 1
high GREEN_LED
low RED_LED
'IF debug_out = 1 then DEBUG "Sw1 On_status= ", dec on_status, " Mode = ", DEC mode, 13, 10
goto interrupt_end
endif
IF sw2 = 0 THEN
pause 150
if sw3 = 0 then
Mode2_control = 1
Mode3_control = 1
Mode4_control = 0
on_status = 1
HIGH GREEN_LED
low RED_LED
MODE = 4
'IF debug_out = 1 then DEBUG "Sw3&4 On_status= ", dec on_status, " Mode = ", DEC mode, 13, 10
goto interrupt_end
endif
endif
IF sw2 = 0 THEN
if on_status = 1 and mode = 2 then goto Switch_off
Mode2_control = 0 '
Mode3_control = 0
Mode4_control = 1
on_status = 1
MODE = 2
high GREEN_LED
high RED_LED
'IF debug_out = 1 then DEBUG "Sw2 On_status= ", dec on_status, " Mode = ", DEC mode, 13, 10
goto interrupt_end
endif
IF sw3 = 0 THEN
if on_status = 1 and mode = 3 then goto Switch_off
Mode2_control = 1
Mode3_control = 1
Mode4_control = 1
on_status = 1
MODE = 3
low GREEN_LED
high RED_LED
'IF debug_out = 1 then DEBUG "Sw3 On_status= ", dec on_status, " Mode = ", DEC mode, 13, 10
goto interrupt_end
endif
goto interrupt_end
Switch_off:
on_status = 0
mode = 0
low Green_LED
low Red_led
Mode2_control = 1 '
Mode3_control = 1
pwm_width = 0
'IF debug_out = 1 then DEBUG "Switch_Off On_status= ", dec on_status, " Mode = ", DEC mode, 13, 10
interrupt_End:
IOC_FLAG = 0
@ INT_ENABLE RABC_INT
'IF debug_out = 1 then DEBUG "Int_End On_status= ", dec on_status, " Mode = ", DEC mode, 13, 10
@ INT_RETURN
'---[TMR1 - interrupt handler]--------------------------------------------------
ToggleLED1:
IF MODE = 4 THEN
TOGGLE Green_LED
TOGGLE RED_LED
ENDIF
@ INT_RETURN
END
If I comment out all the lines above starting "if debug_out = 1", my program then compiles fine! If I uncomment them I get 53 compilation erros (along the lines of what I posted earlier). But get this, while they're uncommented - which would normally give the errors - if in the main body of my program (not the interupt handlers), I then reduce the number of 'if' statements, like thus...
(ignore the actual if/then statements - they're changed here to be easier on the eye & to get my point across)
Code:
IF Signal_In > target + 3 THEN goto a
IF Signal_In > target + 2 THEN goto b
IF Signal_In > target + 1 THEN goto c
IF Signal_In < target - 3 THEN goto d
IF Signal_In < target - 2 THEN goto e
'IF Signal_In < target - 1 THEN goto f ' program compiles even with my bloaty interupt if I comment out any one of these lines
pause 20
GOTO START
a:
b:
c:
d:
e:
' f: ' program compiles even with my bloaty interupt if I comment out any one of these lines
So it seems to be a either combination of the amount of code I've lobbed into the interupt handler &/or the number of if statements I have in my main progam body.
(before pouring scorn on the way I've approached this :D ...remember, I'm just a n00b - I work within the confines of my limited programming knowledge until a particular problem/situation forces me to learn something new!!)
Have you tried changing IF debug_out = 1 then DEBUG "Sw1 On_status= ", dec on_status, " Mode = ", DEC mode, 13, 10
toIt may be interpreting the DEBUG command as a label to jump to?Code:IF debug_out = 1 then
DEBUG "Sw1 On_status= ", dec on_status, " Mode = ", DEC mode, 13, 10
ENDIF
Hi Bruce,Quote:
Originally Posted by Bruce
Just tried your recommendation....still the same - compliation 53 errors (fwiw I have those same lines scattered throughout my main body of code & they all work fine...I don't think the errors relate to those particlar lines per se...if I only comment out a couple of those particular "IF debug_out = 1 " lines in the imnterupt handler - it compiles ok! Likewise if I uncomment the "IF debug_out = 1 " lines, but instead comment out a couple of of ther "if" lines in the interupt handler - it compiles - it seems to be related to the amount of code I've put into the interupt handler???)
Bummer. I guess the only way to get solid help then is for you to post all of your code, and let us help figger it out..:)
I've used DT_INTs in a TON of apps, and never had a single problem, but it's a tough call to help without seeing every-single-line-of-code you have.
If it's humongous, just post it as a text file in .zip format so we can compile it all, and see what the problem is
I'll push on for a night or two more, because....Quote:
Originally Posted by Bruce
1. Mainly, I'd be embarrased at posting my code (like I say I code what works within the confines of my very basic programming abilities...and it's not elegant!!)...I'm not quite ready to expose my unfeasibly small gonads to the programming world!
2. Even though it's rough (& probably laughable to you guys!)...I've actually spent (on & off) ages constructing the overall flow within the program & wouldn't want it posted on a public forum where some on other (non pic) forums could see what I've done! ;)
With this latest plea, just wanted to make sure it wasn't an error that had been seen before or a gotcha of some kind.
Many thanks for the continued offer of help though to a persistent n00b :o ....you guys really are great.
Then send it to me ... darrel at pbpgroup.com.Quote:
Mainly, I'd be embarrased at posting my code.
No DT_INTS problem is allowed to go un-answered.
It's a rule. :)
lol :o ....program just sent - many thanks (& please ...if it's something stupidly simple....lie a bit for me!!!!)Quote:
Originally Posted by Darrel Taylor
What do you have to be embarrassed about? You are working hard on a project, that is something to be proud of. If some one thinks your code is not "elegant" who cares what they think! If someone laughs? Again, who cares what those people think. "Those" people are not even worth the time of day.Quote:
1. Mainly, I'd be embarrased at posting my code (like I say I code what works within the confines of my very basic programming abilities...and it's not elegant!!)...I'm not quite ready to expose my unfeasibly small gonads to the programming world!
2. Even though it's rough (& probably laughable to you guys!)...I've actually spent (on & off) ages constructing the overall flow within the program & wouldn't want it posted on a public forum where some on other (non pic) forums could see what I've done!
Keep working and be proud of your accomplishments!!!
I got the file. And you have nothing to worry about.Quote:
Originally Posted by HankMcSpank
It's a perfect program with logical structures throughout it's well constructed code.
OK ... it's something stupidly simple ... so I lied. :)
Even though the stupid mistake was mine. :eek:
Yes, you found a bug in DT_INTS-14 v1.00, and have won the daily prize. (TBD)
But seriously.
I see what the problem is, I can get your program to compile, but need to make sure the fix is really a fix.
I should have it by tomorrow.
Thanks for the find Hank.
Wow ....& thank you for the quick feedback Darrel.Quote:
Originally Posted by Darrel Taylor
I feel honoured, chuffed & more than anything *relieved* (a few nights have been spent 'chin stroking' with a furrowed brow on this one!) to have unknowingly & unwittingly stumbled upon a bug in the world renowned, universally embraced & snappily entitled DTS-INTS-14.bas. :)
I have a question about this setup you can get 4 modes from two switches or do you really need 5 modes or no_mode also. could you always start in mode 1 which would be no button pressed? mode 2 left button, mode 3 right button, mode 4 both buttons, it would be smaller.
sorry I may not have followed this thread correctly.
Thanks for your contribution, since you've asked, then here's bit more meat on the bone wrt the switching!Quote:
Originally Posted by l_gaminde
The is for a guitar widget...as such the control box that the final pcb will be going into will be rather very small - I can actually only shoehorn four momentary (6mm square) switches in there - one of these switches acts as an analogue signal 'kill switch' (it simply shorts the guitar signal to ground giving a gated type effect - guitarist love kill switches!) The fourth switch is not integrated into the PIC circuitry at all - that leaves three switches.
Ok, wrt the switching itself....when external power is unit is applied to the circuit, it just sits there waiting in standby for one of the switches to be pressed
Now I could have used just one switch & have the player toggle through the differnt modes - but the modes are used in such a way, they need to be instantly accessible., hence...
Pressing Switch1 takes the unit out of standby & instantly into Mode 1
Pressing Switch2 takes the unit out of standby & instantly into Mode 2
Pressing Switch3 takes the unit out of standby & instantly into Mode 3
once the unit is active (ie in Mode 1, 2 or 3), you can switch between modes freely by just pressing any of the other switches (in other words, you don't have to deacrivate a mode by pressing the dedicated switch again, prior to selecting another switch/mode).
the unit is deactivated by pressing on the switch for whichever mode is active, so if Mode 2 is active, press mode 2 switch & the unit goes into standy again ( an LED gives visual representation of whichever mode is active)
That's pretty much the background - what flushed out this thread was me seeking ideas how to squeeze a 4th, 5th mode etc out of the three switches - obviously such requirements starts invoking double presses, holding switches down for longer or pressing two switches at once (I've still not decided on the final version ...but for now I've settled on pressing two switches together to get a 4th mode)
Then Bruce came along - took a look at the way I'd implemented my interrupts on my schematic ...and chimed in that by changing the interrupt type from the shared 'INT' pin....to Interrupt on Change - I could save on some components/space. That was a fantastic bit of input, but then I hit some issues (I didn't know how to implement IOC - Bruce sorted this....then I got some compilation errors when I tried to combine IOC Interrupts & TMR1 Interrupts ....Darrel has hopefully sorted the latter)
And you're pretty much bang up to date - the thread has took a few bends & curves...but I now know how to implement IOC interrupts, I've therefore saved some space on my (crammed PCB), this has allowed better track layout (but has also meant I've had to redesign my PCB....but worse, redesign/rebuild my test tig (I have a hinged pogo pin endowed test/debug setup - this allows me to program my PIC in situ, as well as facilitating a debug pin (I use the PICKIT2 UART2 to view stuff on my PC) as well as test points for monitoring the analogue aspect of the circuit etc)...
http://i35.tinypic.com/2h863gh.jpg
(you can see the four switches I'm referring to on the PCB above - that space to the left will be filled up with other stuff so it's not free space)
The closer I get to finishing this project - the further the goalposts seems to get away!
I'm now using the downtime wrt my interrupt probs being sorted by Darrel, to hack an old eprom eraser my work was throwing away to reutilize as a UV lightbox (with a nice new PIC countdown timer) - I'v just removed the old clunky analogue switch....
http://i37.tinypic.com/nbw19g.jpg
I started work on the UV Timer program (& PCB) earlier this afternoon - hope to have it finished over the weekend!
Spanky,
I've finished the changes to DT_INTS-14.
You can download the new files from http://www.darreltaylor.com/DT_INTS-14/downloads.htm
Anyone else using ver 1.00 should get them too.
In trying to add some optimization to ver 1.00, I introduced a problem that caused the error when the Handlers crossed a Page boundary.
I'm pretty sure that's fixed now.
In your program it was right at the edge, and only 1 of the handlers crossed the boundary, which is why commenting one of them allowed it to compile.
It also gave me a chance to fix a problem caused by MPLAB 8.53 when using 16F1 chips.
Thanks again for bringing the problem to my attention HankMcSpank.
And thank you for such great support - it compiles like a dream now....Quote:
Originally Posted by Darrel Taylor
http://www.tweak3d.net/forums/imageh...85fadccc3b.gif
(btw: if you'd waited another 90 mins, the new DTS_INTS-14.bas have been released on my birthday (UK time) ....& in that vein, I promise not to use it until then! :D)
http://dt.cambs.net/files/happybirthdaywhite.gif
OK, enough celebration.
Get back to work on that guitar thingy. :D