Need 4 modes with just 3 switches - need all modes to be selectable QUICKLY!

[HankMcSpank]

Hi Guys,

here's my conundrum.

I'm knocking up a guitar widget that has four modes - becuase the unit needs to be physcially small, I can only shoehorn 3 momentary switches into it.

Ok, so at the moment, I've arranged 'user interface' as follows...

Switch 1 pressed quickly = mode 1
Switch 2 pressed quickly = mode 2,
Switch 3 pressed quickly = mode 3, pressed and held for 250ms = mode 4.

(all switches use interupts - thanks Darrel! :) )

ok, no problems....ie I've got four modes out of the three switches - *But*...I don't know if you've ever played a guitar, but in mid Steve Vai-esqe solo (I wish!), that Switch3 200ms press & hold to select mode 4 seems like a lifetime waiting. Also, I reckon that mode 4 won't be actually used that often, but presently when selecting either mode 3 or 4, the program pauses 250ms (to see if the switch has been held down), before deciding whether it's actually mode 3 or mode 4 that's required...this means that mode 3 is held back when selecting too - there has to be a slicker way of doing this!

So, I'm now thinking about rather a press & hold for mode 4, you press Switch3 twice in quick succession (& bringing a timer into play)

I was just wondering what the more experienced among you think about the viability of getting the speed of 4 mode selection with 3 switches down to lightning fast levels?

[Kamikaze47]

I assume the switches are right next to eachother? if so, why not make it so that mode 4 can be activated by pressing 2 and 3 at the same time. To do this i would suggest that for the interrupt handler for switch 3, have a quick loop that checks button 2 for a short time (something like 20ms). If it is pressed, activate mode 4, else activate mode 3.

The "double click" can be done too, but requires a bit more logic and probably a timer.

[HankMcSpank]

I assume the switches are right next to eachother? if so, why not make it so that mode 4 can be activated by pressing 2 and 3 at the same time. To do this i would suggest that for the interrupt handler for switch 3, have a quick loop that checks button 2 for a short time (something like 20ms). If it is pressed, activate mode 4, else activate mode 3.

The "double click" can be done too, but requires a bit more logic and probably a timer.

Thanks for your input...I'd pondered that option - and yes the switches are near each other - but I worry a little over the actual logistics. A guitarist will be selecting these switches with his right hand - this will already have a plectrum in it (between the thumb and forefinger), this leave him needing to press two switches concurrently but with two fingers partially out of action - then there's the accuracy at landing fingers on two small (3.5mm diameter) button tops 'on the fly' in mid solo etc on a dimly lit stage etc.

[Bruce]

How about using 1 switch as the mode switch? Use a toggle switch to select how the other 2 switches act.

Mode switch = 1, other two act as switches 1 & 2. Mode switch = 0, other two act as switches 3 & 4.

Or use a normally open mode switch. Press once, in mode 1. Press again, in mode 2.

Kind of like the Shift key on your keyboard that doesn't need to be held down to select other key functions.

[Kamikaze47]

In that case the double press is probably the best option. Something like this:

button3 interrupt handler:

IF timer is not running THEN
set timer so it will overflow after x time (max double click time), and start timer running
ELSE
set to mode 4
stop timer
ENDIF

timer interrupt handler:

set to mode 3
stop timer

[HankMcSpank]

Bruce,

Thanks for the idea - I'm unable to use a toggle switches (though I'd have loved to have), because this PIC/PCB/Switches are going in a small control box with just 5.5mm headroom inside (just under 1/4"" in old money)....also the control box will affixed to the guitar body with four small adhesive pads - a toggle switch would mean the player would be applying force 'sideways' on the switch (with respect to the control box surface), which could place some stress of the adhesive fixings whereas momentary switches, the force will be down (ie pressing the adhesive pads down).

Kamikaze47,

i'm not a programmer...& this stuff doesn't come naturally to me....but thanks for the example to get me started, I'll see how I can weave that concept into my code over the next day or two.

[Kamikaze47]

Kamikaze47,

i'm not a programmer...& this stuff doesn't come naturally to me....but thanks for the example to get me started, I'll see how I can weave that concept into my code over the next day or two.

Give it a try, and if you get stuck, post the code you have written here and we can help.

[Jumper]

3 buttons right? 4 modes.....


press button 1 to enter mode 1
press button 2 to enter mode 2
press button 3 to enter mode 3

press both 1&2 to enter mode 4
press both 2&3 to enter mode 5

[Darrel Taylor]

I assume the switches are right next to eachother? if so, why not make it so that mode 4 can be activated by pressing 2 and 3 at the same time. ...


A guitarist will be selecting these switches with his right hand - this will already have a plectrum in it (between the thumb and forefinger), this leave him needing to press two switches concurrently but with two fingers partially out of action - then there's the accuracy at landing fingers on two small (3.5mm diameter) button tops 'on the fly' in mid solo etc on a dimly lit stage etc.

What if the accuracy wasn't as difficult?

Maybe any 2 buttons pressed at/near the same time could be mode 4.
You wouldn't have to find the correct 2 buttons. Any two (or 3) will do. So it should be easier for the player.

[Mike, K8LH]

Three pins will easily support up to six Charlieplexed switches (requires one diode per switch).

[HankMcSpank]

Just an update (since you've all been so kind to chime in with your ideas...many thanks!)

Last night got home & thought ok....ok, so let's learn about timers - so I went to Darrel's site & saw the timer based flashing LED example....absolutely perfect for one of my other needs -so I went off on a slight (but related) tangent!!

I have a tri-colour LED - ie a green & red LED (which obviously also gives amber if they're both switched on at the same time).....so three possible colours. But with four operational modes, I also need a visual representation to the player when in the the fouth mode - that'd be a flashing LED!

Previously, I was checking regularly within the main code to see if the player had selected the 4th mode - and if so, I'd flash an led. But as Darrel has mentioned to on his site, it's tricky using this method to have a flashing LED with stable, regular interval flashes.

So Darrel's solution was a breath of fresh air (thanks Darrel - again :) )

I then got waylaid trying to work out some wayof getting my program, to 'remember' whether switch3 was last selected in 'mode 3' or 'mode 4' (I have an involved switching arrangement, where any of the 3 switches will turn the device on...once on, you can freely press another switch to move to ther other modes - but for user practicality, if the unit was switched on in mode3, then say switch 2 was pressed, when going back to switch 3, I'd reckon the player would want whichever mode he was last in with switch3 to be recalled - eeeuggh ...this is getting wordy & hard to describe so I'll digress!).

Darrel...good idea about 'any two...no matter which two' ....I'll mull that one over (might be better than me having to learn about timers for my situation!!). The wierd thing is that even though some ideas seem fine, when you come you actually use them ....they're not so good. My earlier example about holding swith3 longer to enter mode 4 - it just doesn't fit in with the intended applicated - fast switching for a guitarist going hell for leather!


Mike....all my switches use diodes.

[Mike, K8LH]

Hi Hank',

Got a schematic we could look at? Maybe there's a way to recover an extra pin that you haven't thought of.

How are you sampling and managing your switches? Polling them in a loop or polling them via periodic interrupt?

Are you using two pins for that tri-color LED or are you using any pins for LED mode indicators? If so, you might consider reclaiming those pins and using one of them for the fourth switch, then mux' the mode LEDs with the switches.

Regards, Mike

[HankMcSpank]

Hi Hank',

Got a schematic we could look at? Maybe there's a way to recover an extra pin that you haven't thought of.

Are you using two pins for that tri-color LED? Or are you using any pins for LED mode indicators?

How are you sampling and managing your switches? Polling them in a loop or via periodic interrupt?


Here's the switching part....

http://i37.tinypic.com/2i8dsld.jpg

(I know some consider it bad form, but I use the PIC's internal weak pullups, for no other reason than it saves space - and believe me, I need all the space I can get!)

...there are a few spare pins Pin on the 16f690, Pin 4 is somewhat restricted in its use, so I stay clear of it, Pin 9 is 'forsaken' so I can use that bit of track/pcb real estate to 'conduit' the +4.1V onwards to the rest of the PCB, Pins 6, 15, 16 & 19 are essentially 'landlocked' from a PCB track routing perspective

Yes, I'm using two pins (pins 2 & 3) for driving the LED (must remember to order common anode LEDs next time, so I can sink current from the main 9V VCC rail vs the PIC's 4V.1 rail ...puts less demand on the 100mA LDO regulator I've used!)

Re how am I sampling the switches? - using DT's mighty fine interupt routine. :)

There is no room for a fourth switch - likewise no room for illuminated switches - I'm only using 6mm square momentary push switches because they're the only ones I can shoehorn in.

The problem of course is the more 'modes' I offer (and it would be lovely to offer 6 or 7), is providing the guitarist with meaningful (rememberable) visual indication of the modes with just one LED ...green, amber & red is fine. ....squeezing in a 'flashing LED' for the extra mode is pushing it - any more modes, that it's going to be hell to remember what the LED is telling you! (& there's no room for a lcd, 7 seg display etc)

To give you some idea of my challenge, the pcb 'real estate' is about 40mm x70mm x 5.5mm high (1.5" x 3" x 0.2" high) - in that space I have to fit 2 x 20SOIC, 1 x 8 SOIC, 1 POT, 4 switches (the fourth switch is not at all related to this circuit), one single coil guitar pickup (that I make myself), one chunky electrolytic....and this is all on single sided pcb (along with a whole heap of 1206 SMD components) - it's crammed!

[Mike, K8LH]

Oh my! Some pretty nasty self-imposed restrictions there Hank'.

There are smaller switches (see below, just left of the machined socket). And if you think about it, that tri-color LED actually has four states (off, red, green, and yellow).

Good luck on your project.

** added **

Someone just wrote to ask about the driver for that mux'd switch & LED drawing so I'll add it here if nobody minds. And sorry for the C code (I don't have PBP)...

The routine sets the four pins to inputs to read the switches. Standard 'parallel' switch state logic filters out all but a "new press" state while ignoring the other three states (for each switch). 1-of-N logic (only 1 mode on at any time) dictates that we save the "new press" pattern as the new "mode". Since a pressed switch could short out a pin that is set to output '1' we cannot turn off the inactive LEDs by outputting a '1' and so we leave those pins tri-stated (RC3..RC0 output latch bits are maintained at '0').


/* *
* isr debounce & switch state management (1-of-N switch logic) *
* using 8 to 32 msec interrupt intervals *
* *
* swnew ____---____-----___ new switch sample *
* swold _____---____-----__ switch state latch *
* delta ____-__-___-____-__ changes, press or release *
* newhi ____-______-_______ filter out new release bits *
* */
trisc |= 0x0F; // set RC3..RC0 to inputs
swnew = ~portc; // sample active lo switches
swnew &= 0x0F; // on RC3..RC0 pins
swnew ^= swold; // changes, press or release
swold ^= swnew; // update switch state latch
swnew &= swold; // filter out new release bits
if(swnew) // if "new press"
mode = swnew; // save 1000,0100,0010, or 0001
trisc ^= mode; // light the correct mode LED

[Kamikaze47]

Maybe I've got something wrong, but wont there be an awful lot of current flowing through those diodes when the buttons are pressed? Or at least, as much as the PIC I/O pin can deliver.

[HankMcSpank]

Oh my! Some pretty nasty self-imposed restrictions there Hank'.

There are smaller switches (see below, just left of the machined socket). And if you think about it, that tri-color LED actually has four states (off, red, green, and yellow).

Good luck on your project.

Hi Mike, yes, there maybe smaller switches out there, but I couldn't find them - in this scenraio the shaft of the switch needs to extend at least 7 mm vertically....to clear the case top & leave enough protuding for a finger to press on (& I'm not the one imposing the restrictions - it's the guitar that is ...the unit slides under the strings!)

Kamikaze47 - I'm using the PIC's own weak pullups internally (to save using pullup resistors externally) - so for all it looks to be, it's not a 'short' of 4.1V to ground through the diode when the switch is pressed, but a path as follows...

4.1V->PIC Internal Weak Pullup->Diode-> ground. (most of the voltage is dropped across the internal weak pullup)

(and not all the PIC's pins have weak pullups internally ...this was something else that imposed a restriction on me!)

[Kamikaze47]

Kamikaze47 - I'm using the PIC's own weak pullups internally (to save using pullup resistors externally) - so for all it looks to be, it's not a 'short' of 4.1V to ground through the diode when the switch is pressed, but a path as follows...

4.1V->PIC Internal Weak Pullup->Diode-> ground. (most of the voltage is dropped across the internal weak pullup)

(and not all the PIC's pins have weak pullups internally ...this was something else that imposed a restriction on me!)

Ahh, right. I was assuming you were setting that pin high. Makes sense now.

[Mike, K8LH]

What's the purpose of diodes D2-D4 and their connection to RA2, please?

[HankMcSpank]

What's the purpose of diodes D2-D4 and their connection to RA2, please?

RA2 (pin 17) on a 16F690 is the external interupt pin. So when a switch is pressed, RA2 is grounded & an interupt occurs - I then check in the interupt subroutine to see which of the three 'switch' connected pins was actually pressed (ie which one of the three switch pin also went low) - the diodes isolate the 'switched' ground from the other two pins not pressed.

It essentially allows you to implement three physical pins (or more) to be 'psuedo'-interupt pins (vs just the one ext interupt that the 16f690 has)

All credit to forum members on this thread for filling me in on how to do it....

http://www.picbasic.co.uk/forum/showthread.php?t=13272&p=89900#post89900


Ahh, right. I was assuming you were setting that pin high. Makes sense now.

RA2 (pin 17) is set high...but high via an internal weak pullup (at the risk of teaching grannie to suck eggs, note the lack of the word 'resistor' on the end of that phrase - apparently not a resistor, but some silicon junction internal to the PIC providing the resistance here)

Just for the record, any similar noobs like me, who may find this thread via a search, here are the 16F690 register settings needed to bring the weak pullups into play (obviously change the 1 & 0s of wht WPUA & WPUB registers to suit your own external connections)



OPTION_REG.7 = 0 'enable weak pullups.
WPUA = %00000110 'activate weak pullups on RA1 & RA2.
WPUB = %01100000 'activate weak pullups on RB5 & RB6.

[Bruce]

The schematic I drew in the thread you linked to above used a PIC without all the extra interrupt inputs, so it has switches ORed to 2 interrupt pins.

The 16F690 you're using has IOC for all 3 of your switch inputs. So you could get rid of the diodes if you want to save parts & realestate on your board.

[Mike, K8LH]

That's what I thought you might be doin' (OR'ing active lo switch signals to trigger INT). As Bruce mentioned, using IOC might be a better option.

Is there some compelling reason you're using interrupts for the switches instead of just polling them at regular intervals?

Also, I re-read your original post and see where you said you don't have physical space for four switches so I apologize for not paying attention...

[HankMcSpank]

Hi Bruce,

I'd not investigated IOC, cos I wasn't sure how to implement! (like I say - n00b alert!) I like the idea of saving 3 x diodes worth of pcb space!

So, would it go something like thus....



ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler IOC_INT, _Switch_Interupt, PBP, yes
endm
INT_CREATE ; Creates the interrupt processor
ENDASM

@ INT_ENABLE IOC_INT ; Enable 'Int On Change' interrupts
************************************************** ******************

(main body of code)

'************************************************* *******************
Switch_Interupt:

if portB.4 = 0 then mode = 1
if portB.5 = 0 then mode = 2

blah blah...

@ INT_RETURN



That's what I thought you might be doin' (OR'ing active lo switch signals to trigger INT).

Is there some compelling reason you're using interrupts for the switches instead of just polling them at regular intervals?

Nothing other than wanting my unit's 'mode' to change the instant a switch is pressed. (what originated this thread, was I'd noticed that even holding a button down for a mere 200ms - to determine say mode 3 or mode 4 from one switch - seemed like a lifetime when playing a guitar, so polling three switches is just not gonna cut it - my code uses a whole heap of pauses in the main body of the program, this would hinder such polling)

[Mike, K8LH]

Hank',

Thanks. I think I understand your concerns and constraints. Best of luck on your project Sir.

Cheerful regards, Mike

[Bruce]

I think what you want here is RABC_INT. So:


ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler RABC_INT, _Switch_Interupt, PBP, yes
endm
INT_CREATE ; Creates the interrupt processor
ENDASM

@ INT_ENABLE RABC_INT ; Enable 'Int On Change' interrupts

Note: Your schematic is wrong with pins 11 & 12 shown as RB2 & RB3. These should be RB6 & RB5 respectively. So;


Switch_Interupt:

if portB.4 = 0 then mode = 1
if portB.5 = 0 then mode = 2

Should be;


Switch_Interupt:

if portB.6 = 0 then mode = 1
if portB.5 = 0 then mode = 2
if porta.2 = 0 then ? whatever ' this is the interrupt pin on RA.2

Or, of course, you can use RA.1 as shown in your schematic for this interrupt pin. Either will work the same since they both have IOC (interrupt-on-change) functionality, and internal pull-ups.

Note I have not used DT_INTs on this PIC type with interrupt-on-change, but that should get you going. I'm sure Darell will jump in here, and correct me if I'm wrong, but I think that's what you're looking for.

But, I HAVE used his DT_INTs for our 4-digit & 6-digit serial LED displays, and I most certainly can vouch for them working spot-on, and making life a lot easier for us mere mortals...:D

I've also used DT_INTs in several commercial applications, and had ZERO problems - so a huge thanks to DT for all the hard work, and sharing his routines with us.

[HankMcSpank]

Bruce ....you're good, like *really* good! :cool:

You spotted my Eagle Part mistake - I failed to declare it, because it's been there for a while & I get used to it....my actual code does reference the right port names! (I need to go back into my Eagle part I created and change the text for those pins....not sure if you've ever had to make your own device/parts in Eagle - fit's not pretty!)

Quick question - if IOC stands for interupt on change(?), then the 'change' in this scenario will be the pin going from 1 to 0...this will generate an interupt - but what happens when the switch is released (since it's another 'change', then in theory another interupt?!) now I'm sure this is catered for with a rising/falling edge setting in some register but I thought I'd ask!

Even though the term gets a little over used nowadays ...guys like yourself, DT (& others who've helped me here - a list too long to mention), really do make a difference

Already, after your recent input - the 3 diodes have already been whipped out on my schematic & I've now just that little bit more pcb real estate to arrange the board layout more to my liking....so a a genuine thanks.

[Bruce]

Thanks Hank. But you're good too. You spotted this. Good catch. Interrupt-on-change is exactly what it means, but you have to know how it works to really take advantage of it.

So here's a quick tutorial.

Sample the port/ports first, then enable interrupt-on-change, but only after all port pins with this interrupt enabled are in the non pressed state.

This takes a snap-shot of pins, which is used later on to determin the change-of-state when a switch is pressed. I.E. a transition from logic 1 to 0, assuming a switch grounds the pin, and it has internal pull-ups enabled.

What you'll normally want to do is use a WHILE WEND statement to WAIT until all switches are in the un-pressed state. I.E. just wait until all port pins that have interrupt-on-change enabled return a value indicating the switch is NOT pressed. Then enable int-on-change.

The last read of the port is saved & used to determine the transition from un-pressed to pressed - or the transition from logic 1 to 0.

And - yes - I know Mike will yell at me for suggestiing this, but I normally wait for the pin to return to the un-pressed state in my interrupt handler, then exit & clear the interrupt flag bit. It's just so much easier than sampling pins for a switch-press in a timer-based interrupt. But - Mike does have some cool stuff to do this if you're interested.

Interrupt-on-change requires you to read the port first to end the miss-match condition before it will allow you to clear the interrupt flag bit, so it just makes sense to wait until the switch is released before clearing the flag bit & exiting the int handler.

If you don't (like you just mentioned), then you end up having an interrupt generated by switch press & switch release - because both events = a change after you have read the port, and cleared the int-on-change flag bit, and exit the int handler.

Assuming the user isn't going to press & hold a switch down for any length of time, this is for sure the way to go, and it can be incredibly fast if the user just taps & releases the switch.

If the user does hold a switch down, it will simply wait for them to release the switch before exiting the interrupt handler, which also works fine, but it does delay exit from your inerrupt handler until switch release.

This is really simple with just a few extra lines of code in your interrupt handler like this:



IF PORTB.6 = 0 THEN
WHILE PORTB.6 = 0
WEND
ENDIF

And you can do this for any port pin with int-on-change enabled.

Hope this helps!

[HankMcSpank]

And - yes - I know Mike will yell at me for suggestiing this, but I normally wait for the pin to return to the un-pressed state in my interrupt handler, then exit & clear the interrupt flag bit. It's just so much easier than sampling pins for a switch-press in a timer-based interrupt. But - Mike does have some cool stuff to do this if you're interested.
!

Great explanation, just one thing...

[noob alert]

Could you please give me an example of some code to implement the bolded bit above? (particularly the exiting sequence & clearing the interupt flag - can't say I've had to do that before)

[/noob alert]

Also, forgive me for asking - but have you a link to Mike's info that you referred to?

Edit: remainder of post deleted cos I spotted a mistake & sorted it!

[Bruce]

You already have the reset flag option enabled with DT_INTs, so you don't have to worry about the int flag being reset. It's just up-to-you to make sure it CAN reset the flag by first reading the port pins, and waiting, as in my example above, for whatever input pins you're using, to return to the non-pressed logic level.

Just duplicate my example above for each pin. I'm going to make you figger that out on-you-own..:o

Hint: Just replace PORTB.6 with whatever pin you need to test next. It's blazingly fast if a pin isn't at logic 0.

Mike will have to help you on his end. He posts here reqularly with some very cool stuff, but you may have to convert it from C to PBP, which really isn't too hard since the C structure is darn close to BASIC (for very simple code).

And, if you need it, I can do the translation for you, but I'll let Mike chime-in with here with his code example first. He's quite good. Right up there with Darell, and I learn a lot from his input...;)

Edit: Make sure you have the latest/greatest version of DT_INTs. Looks like you may have an older version that doesn't have the newer int handlers.

[HankMcSpank]

Wow...great stuf - thanks.

you'll be pleased to hear it's bedtime here in the UK, so radio silence falls upon this thread!

You've been a great help, in closing re the IOC interupt config ....we were both wrong - I think (...though you were only one character out - I was way out!), the correct IOC config might be like this...???



ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler RBC_INT, _ToggleLED1, PBP, yes
endm
INT_CREATE ; Creates the interrupt processor
ENDASM

@ INT_ENABLE RBC_INT ; enable IOC interrupts


Re having the latest DTS-14 files, they were downloaded from Darrel's site...

http://darreltaylor.com/DT_INTS-14/downloads.htm (dated Jan 29 2006)

[Bruce]

Also - just for the sake of other list members, you might want to just create a 2nd post, and leave whatever you had to change in the original.

Just so folks can see where you made a mistake (if any), and learn from it. Rather than editing your previous post. I myself learn a lot from things that need to be changed to work properly, and it's a tad confusing for folks to follow-along if you edit a previous code example that needed changing.


we were both wrong
I don't think so. The 16F690 has different interrupt enable & flag bits for PORTA/PORTB interrupt-on-change.

From DT_INTS-14;

#define RBC_INT INTCON,RBIF, INTCON,RBIE ;-- RB Port Change
These registers aren't available in the 16F690.

These are;

#define RABC_INT INTCON,RABIF, INTCON,RABIE ;-- RAB Port Change *

[Mike, K8LH]

Hey Bruce,

Despite the very warm welcome from everyone here I feel that posting non-PBP examples isn't cool and probably is not helping anyone so perhaps it's best if I just stay on the sidelines and stop preaching (lol).

Cheerful regards, Mike

[Bruce]

Hi Mike,

Sorry you feel that way, but i think everything you post has some benefit to some.

Large portions of Darells' code that everyone uses BIG time here is in assembler, and that doesn't detract from its usefulness.

[Bruce]

See if this works.

[HankMcSpank]

See if this works.

Bruce,

Many thanks for the example - you're a diamond.

Alas, it's not compiling on my PC - I'm certain that I've a parameter wrong somewhere or other on my machine, becuase after finishing posting last night such was my keeness, I spent another hour trying to get a very minimalist IOC test program to compile - & I was getting the same type of compilation errors.

The errors I'm seeing (both last night & now with your program) are as follows....

Error[128] [filepath]test_ioc.asm: Missing Arguments
Error[113] [filepath]test_ioc.asm: Symbol not previously defined (IntFlagReg)
Error[113] [filepath]test_ioc.asm: Symbol not previously defined (IntFlagBit)
Error[101] [filepath]test_ioc.asm: ERROR (Interupt Source (IntFlagReg, IntFlagBit) not found


If I remove the RABC_INT entry in in the interupt header & replace with INT_INT - it always compiles fine.

Any tips greatfully received, as I'm not getting off the ground with this IOC melarkey (& I'm chomping at the bit to breadboard the MKII 'no diodes' puppy!)

Many thanks once again.

Hank.

(PS I'm using V1.0 - the latest DTS-14.BAS)

[Acetronics2]

Bruce,

Alas, it's not compiling on my PC
(PS I'm using V1.0 - the latest DTS-14.BAS)

Hi hank ...

Did you select the right processor ???

Compiles fine, here ( 386 Words ).

PBP 2.60 " not patched yet" ...

Alain

[HankMcSpank]

Hi hank ...

Did you select the right processor ???

Compiles fine, here ( 336 Words ).

PBP 2.60 " not patched yet" ...

Alain


Hi Alain,

I'm selecting my intended PIC (a 16F690)

Likewise PBP V2.6 (unpatched) but just patched it about 20 mins ago - still didn't compile (same errors)

I'm thinking it's likely something to do with my DTS_INTS-14.bas (I used the one at the bottom of this page... http://darreltaylor.com/DT_INTS-14/intro2.html )

( A quick search for some of the errors I'm seeing brings up stuff relating to DT's interupt routines - so likely something I've not got right wrt that aspect :( )

[Bruce]

Drop a copy of DT_INTS-14.bas and ReEnterPBP.bas in the same directory as the file you're compiling, or save the file to the same directory they're already in.

[HankMcSpank]

Drop a copy of DT_INTS-14.bas and ReEnterPBP.bas in the same directory as the file you're compiling, or save the file to the same directory they're already in.

Thanks Bruce.....that seems to have got rid of the majority of my errors.

After dropping it into the right directory 9there was one in there...but it must have been ab older version?), I did get some relating to wsave, a judiscous amount of trial & error with commenting the DTS_INTS-14.bas....




wsave VAR BYTE $20 SYSTEM ' location for W if in bank0
'wsave VAR BYTE $70 SYSTEM ' alternate save location for W
' if using $70, comment out wsave1-3

' --- IF any of these three lines cause an error ?? ----------------------------
' Comment them out to fix the problem ----
' -- It depends on which Chip you are using, as to which variables are needed --
wsave1 VAR BYTE $A0 SYSTEM ' location for W if in bank1
wsave2 VAR BYTE $120 SYSTEM ' location for W if in bank2
'wsave3 VAR BYTE $1A0 SYSTEM ' location for W if in bank3
' ------------------------------------------------------------------------------


Now the only error I have left is this one....

Error [118] [filepath]test_ioc.asm Overwriting previous address content (2007)

....which I'm without a clue how to sort! (help!)

[Bruce]

The last error is because you have config settings in your code, and in your 16F690.INC file.

[HankMcSpank]

The last error is because you have config settings in your code, and in your 16F690.INC file.

Success!!! (both with the compilation and on the breadboard!) ie if I Press switch 1 the LED blinks once, press Sw2 blinks twice etc - you'd never have thought a couple of blinking LEDs could make a grown man so happy!)

Many *many* thanks Bruce for hanging in there with me - now off to have a dabble (& work out what you've done!)

[HankMcSpank]

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?

[Acetronics2]

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

[HankMcSpank]

??

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.

[Acetronics2]

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

[HankMcSpank]

so wouldn't SOMETHING as noobesque (as befits me) like this suffice...



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?

[Bruce]

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.

[HankMcSpank]

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!)

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!

[HankMcSpank]

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?

[HankMcSpank]

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)



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.

[Darrel Taylor]

Is that the whole program?

The errors seem to indicate there's another INT_CREATE somewhere.

[Acetronics2]

Is that the whole program?

The errors seem to indicate there's another INT_CREATE somewhere.

Hi, Darrel

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

[Darrel Taylor]

Do you remember those errors also appeared in MPLAB 8.30 ( ? ), when PBP 2.50 was released ???
Thought about that, but it only affected DT_INTS-18.
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+.

[Acetronics2]

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:

Alain

[HankMcSpank]

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)...



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)



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!!)

[Bruce]

Have you tried changing IF debug_out = 1 then DEBUG "Sw1 On_status= ", dec on_status, " Mode = ", DEC mode, 13, 10

to

IF debug_out = 1 then
DEBUG "Sw1 On_status= ", dec on_status, " Mode = ", DEC mode, 13, 10
ENDIF
It may be interpreting the DEBUG command as a label to jump to?

[HankMcSpank]

Have you tried changing IF debug_out = 1 then DEBUG "Sw1 On_status= ", dec on_status, " Mode = ", DEC mode, 13, 10

to

IF debug_out = 1 then
DEBUG "Sw1 On_status= ", dec on_status, " Mode = ", DEC mode, 13, 10
ENDIF
It may be interpreting the DEBUG command as a label to jump to?

Hi 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???)

[Bruce]

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

[HankMcSpank]

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....

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.

[Darrel Taylor]

Mainly, I'd be embarrased at posting my code.

Then send it to me ... darrel at pbpgroup.com.

No DT_INTS problem is allowed to go un-answered.
It's a rule. :)

[HankMcSpank]

Then send it to me ... darrel at pbpgroup.com.

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!!!!)

[mackrackit]

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!
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.

Keep working and be proud of your accomplishments!!!

[Darrel Taylor]

(& please ...if it's something stupidly simple....lie a bit for me!!!!)
I got the file. And you have nothing to worry about.
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.

[HankMcSpank]

Yes, you found a bug in DT_INTS-14 v1.00, and have won the daily prize. (TBD)

Thanks for the find Hank.

Wow ....& thank you for the quick feedback Darrel.

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. :)

[l_gaminde]

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.

[HankMcSpank]

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!

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!

[Darrel Taylor]

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.

[HankMcSpank]

Spanky,
Thanks again for bringing the problem to my attention HankMcSpank.

And thank you for such great support - it compiles like a dream now....

http://www.tweak3d.net/forums/imagehosting/12254a885fadccc3b.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)

[Darrel Taylor]

http://dt.cambs.net/files/happybirthdaywhite.gif

OK, enough celebration.
Get back to work on that guitar thingy. :D