Newbie - 16F628A and switch latching

[mister_e]

... if you're real nice I just might change it for a while to something more sophisticated -

I have a feeling of what it could be Maybe i'm in the 3rd category ... LOL easy to start some rumor here

BTW Melanie, if you change your Avatar to 'something more sophisticated', i feel that some end-of-class student here could be shocked OR spam your PM! May i bet on the second one

[Melanie]

My PM is already spammed...

Dear Miss Whiplash... Thank you for last nights session... I won't be able to sit down for a week, but it was worth every minute... PS My PIC still doesn't work.

Now, now Steve... people might get the wrong idea on how you ended up in hospital...

[malc-c]

I'm hoping that you guys and Miss whippy, sorry Mel can tell me why the following code won't work correctly.

Having managed to sort out the delay for the debounce I had each LED bing turned on, latched and turned off by activation of the corresponding reed switch - Great !

However I now want to evolve the code so that the following happens. The siding has the buffer at the left, and trains enter from the right. A reed switch (sw1) is placed at the start of the siding (on the right), a train enters the siding and activated sw1 and LED1 is lit. The train continues to the end of the siding where it activates the second reed switch (sw2) and thus LED2 is lit, and the operator shuts off the power. So far so good.

Now the operator can re-arrange the train and place the loco at the other end ready to go back on the main layout. When it does sw1 is then activated again, but this time I need it to clear both LED1 and LED2. Ok I thought, lets simply have a new varible (swset5) that is toggled only when swset1 and swset2 are high.. but it won't work. activating sw1, then sw2, then sw1 again just turns off LED1, LED2 remains lit

Here is my code (I've yet to try the BUTTON command, but maybe that will happen when I come to tidy up the code ??)

@INTRC_OSC_NOCLKOUT
@WDT_ON
@PWRT_ON
@MCLR_OFF
@BOD_ON
@LVP_OFF
@CPD_OFF
@PROTECT_OFF

CMCON=7
TRISB=%00000011         'set RB0 & 1 as input and the rest output

SW1 var PORTB.0          'switch input pin 6 (RB0)
SW2 var PORTB.1          'switch input pin 7 (RB1)


LED1 var  PORTB.4       'LED1 on pin 10 (RB4)
LED2 var  PORTB.5       'LED1 on pin 11 (RB5)

Swset1 var bit
Swset2 var bit

Swset5 var bit

low led1
low led2 
                
Swset1=0 
Swset2=0

swset5=0                'Var swset is set low

Main:
if SW1=0 then            'If switch is LOW (Grounded) then
Toggle Swset1            'change swset1 from 0 to 1
pause 500                'debounce delay
endif

if SW2=0 then            'If switch is LOW (Grounded) then
Toggle Swset2            'change swset2 from 0 to 1
pause 500                'debounce delay
endif

If Swset1=1 then         'if swset1 is 1
high led1                'then turn on RB4 (and hence the LED)
else
low led1                 'else, LED is off
endif

If Swset2=1 then         'if swset2 is 1
high led2                'then turn on RB5 (and hence the LED)
else
low led2                 'else, LED is off
endif

If swset1=1 and swset2=1 then
toggle swset5
endif
if swset5=1 and sw1=0 then
low led1
low led2
else 
high led1
high led2
endif

End

I have even tried removing the "else" part at the end of the code so it reads

If swset1=1 and swset2=1 then
toggle swset5
endif
if swset5=1 and sw1=0 then
low led1
low led2
endif

But that still fails to work correctly.

Any advice guys and gals ??

[Acetronics2]

Hi, Malc

as SWset5 is tested AFTER the swset1 ... your condition never can happend, or during so little time, it can't work properly.

Alain

[malc-c]

So are you saying its the logic of PBP or my program logic that's not right

I modified the code to add in a new var for LED3 to test for the condition "swset1=1 and swset2=1 then swset5=1 and it didn't work either

If swset1=1 and swset2=1 then
swset5=1
else 
swset5=0
endif
if swset5=1 then
high led3

endif

When swset1=1 and LED1 is lit, and swset2=1 and LED2 is lit, LED3 fails to light, ergo swset5 can't =1

So any ideas on how to do what I want it to do ??

[Acetronics2]

YOUR Logic is wrong ...

Alain

[malc-c]

You ain't going to make this easy for me are you !

A hint in the right direction would help !!

[mister_e]

... I won't be able to sit down for a week, but it was worth every minute...

Now, now Steve... people might get the wrong idea on how you ended up in hospital...

How dare you post our private stuff in public

LOL! yeah maybe you're right... but damn you should be really strong to break my arms, legs and spinal cord. Guys, be aware of that!

LOL Melanie, at least i wish it could be true

Ok let's stop it here.. there's somebody who need help here, but Alain give some great tips.

[Acetronics2]

Ok let's stop it here ...

Thanks to Luciano, ve've a good idea of uptown girls at night ...

cool, Malc ... cool !!!

Alain

[Melanie]

There is another way of thinking here Alain...

Once a switch has closed (as detected by the first IF/THEN) then the assumption is that whatever event caused it to close (or open) is not a False Alarm and the event intended to happen (eg a User pressing a button). You therefore need no futher IF/THEN's to see if the contacts are still closed after the debounce time period expries.

All you have to do is delay looking at that switch again for a period of time greater than any possible contact bounce to ensure you don't register that event a second time (as would happen if you used interrupts for example).

Now the delay time is really down to the application. I tend to use 100mS for Keyboard Buttons, because that gives an 'auto-repeat' of 10cps which is quite nice when viewed on a display. Naturally, if you're timing something that happens a lot quicker, then you need to reduce the bounce delay time, but if you get it too short, you'll run into the multiple contact closure problem.

It's difficult to guage and is done mainly by look/see and a bit of experience because different switches (be they contacts on a Switch, Relay or a Reed) all exhibit different closure properties and have different bounce periods. Best method I've found is to overkill the delay as much as possible.

The best method for registering an event, but discarding any False Alarms, is to see how long a switch remains closed over a period of time. That then will require multiple IF/THEN's both at the beginning and at the end of the debounce period.

[malc-c]

Melanie, you are spot on.. The issue I have here is that each time the reed is triggered it will never be the same time period as the last, as some trains will pull in to the siding slower than others. I've found that, although not probably the ideal way, having lots of IF/THEN sections for checking the switches and activation the LEDs works, and more to the point I understand what happening and how I debugged the code to get it working.

The only issue I've run into with the 628 is replicating the action on PORTA. As taking MCLR low seems to reset the PIC even when including Alain's suggestions

PORTA = 0 ' declare port level BEFORE port direction = safe power-on

PORTB = 0

'Pour 16F628

CMCON = 7 ' PortA Digital inputs
CCP1CON = 0 ' PWM off

' DATA @1,word 625,0,word 545,word 750 ' pre-setting EEPROM

Its not much of a problem as I have another 628 PIC so I could use 2 PICs to cover the four sidings, but it would seem such a waste just using half of two chips. Looking at the datasheet all inputs on PORTA are ST where as PORTB has ST and TTL, could this be part of the problem in getting PORTA to work in the same way. Is there any command to turn off the VRCON or Vref function, so that PORTA is strictly in/out and all multiplexed pin options are turned off?

[malc-c]

OK I give up,

Does anyone know of a PIC with 28 pins, internal OSC (or runs off a 4Mhz xtal if no 28pin pics have internal OSC option) that has standard TTL ports...

Having MCLR on an input which is grounded has resulted in so much distress in the household I'm almost considering using descrete logic chips to do the same function.

[Acetronics2]

Hi,Malc

The 16F876A or 877A ( 40 pins ) are the ones ( huge memory, no internal bugs ...etc ...)

BUT, as they can do lots more they do need lots more understanding of their different options ...

Why don't you try to have a good working simple circuit before building the Babel tower ... you're on the soapy side ... still time to become humble.

Alain

[Acetronics2]

There is another way of thinking here Alain...

Once a switch has closed (as detected by the first IF/THEN) then the assumption is that whatever event caused it to close (or open) is not a False Alarm and the event intended to happen (eg a User pressing a button). You therefore need no futher IF/THEN's to see if the contacts are still closed after the debounce time period expries.

All you have to do is delay looking at that switch again for a period of time greater than any possible contact bounce to ensure you don't register that event a second time (as would happen if you used interrupts for example).

Now the delay time is really down to the application. I tend to use 100mS for Keyboard Buttons, because that gives an 'auto-repeat' of 10cps which is quite nice when viewed on a display. Naturally, if you're timing something that happens a lot quicker, then you need to reduce the bounce delay time, but if you get it too short, you'll run into the multiple contact closure problem.

It's difficult to guage and is done mainly by look/see and a bit of experience because different switches (be they contacts on a Switch, Relay or a Reed) all exhibit different closure properties and have different bounce periods. Best method I've found is to overkill the delay as much as possible.

The best method for registering an event, but discarding any False Alarms, is to see how long a switch remains closed over a period of time. That then will require multiple IF/THEN's both at the beginning and at the end of the debounce period.

Hi, Mel,

Here, the problem is we do not know for how long the magnet will be close to the reed switch ...
so, how to fix a reliable debouncing time ... ???

But we know one thing : if the reed switch is triggered, say 20 or 50ms long ( real debouncing ) ... the magnet is really here !!!
So, let's consider the triggering is then real.

We do not want new triggerings before some times ( That's THE problem ), even the magnet is still here ... right ???.

Let's say we allow few seconds for the magnet to go further ... before testing it once more.

If tested close ... the train is still here, stopped or so : What to do ????

If tested Open ... let's go on our program.

.............................

Back to PicBasic programming, we see here that it's the original scenario which is wrong, cause it doesn't allow a correct work of the Hardware connected.

In primary schools, our teachers always repeated us a clearly written problem has already found half its solution ...


Alain