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

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?

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.

Quote:

---

Originally Posted by 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.

---

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.

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.

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

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.

Quote:

---

Originally Posted by HankMcSpank

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.

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

Quote:

---

Originally Posted by 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. ...

---

Quote:

---

Originally Posted by HankMcSpank

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.

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

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.

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

Quote:

---

Originally Posted by 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.

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!

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

Code:

---

/*                                                                *
  *  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

---

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.

Quote:

---

Originally Posted by 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.

---

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

Quote:

---

Originally Posted by HankMcSpank

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.

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

Quote:

---

Originally Posted by Mike, K8LH

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/show...9900#post89900

Quote:

---

Originally Posted by Kamikaze47

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)

Code:

---

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

---

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.

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

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

Code:

---

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

---

Quote:

---

Originally Posted by Mike, K8LH

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)

Hank',

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

Cheerful regards, Mike

I think what you want here is RABC_INT. So:

Code:

---

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;

Code:

---

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

---

Should be;

Code:

---

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.

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.

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:

Code:

---

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!

Quote:

---

Originally Posted by Bruce

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!

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.

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

Code:

---

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)

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.

Quote:

---

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;

Code:

---

#define RBC_INT      INTCON,RBIF,  INTCON,RBIE  ;-- RB Port Change

---

These registers aren't available in the 16F690.

These are;

Code:

---

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

---

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

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.

See if this works.

Quote:

---

Originally Posted by Bruce

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)

Quote:

---

Originally Posted by HankMcSpank

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

Quote:

---

Originally Posted by Acetronics

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

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.

Quote:

---

Originally Posted by 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.

---

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

Code:

---


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

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

Quote:

---

Originally Posted by Bruce

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