Newbie - 16F628A and switch latching

[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

[Melanie]

You have of course set the Config Fuses to have MCLR as an Input Pin?

I use MCLR as an I/O in dozens of 16F628 designs without problems, so I suspect you haven't.

[Acetronics2]

Our friend MUST discover some little things by experience ...

Copy and paste is really the worst solution !!!

He surely forgot that !!!

Alain

[malc-c]

You have of course set the Config Fuses to have MCLR as an Input Pin?

I use MCLR as an I/O in dozens of 16F628 designs without problems, so I suspect you haven't.

When programing (using WinPIC pro) I've tried setting MCLR input enabled (and disabled) and it didn't have any effect. It seems that the problem is with the config as you suggest, however as I'm a newbee it would be nice if you could tell me how to set MCLR as I/O (well I guess input only).

Anyway, I've had a think and came up with the idea of connecting the two reed switches for each track to the same pin and simply counting the times the pin is grounded, and then using the IF/THEN statement to set the condition of the two LEDs. This works for a while and then the PIC seems to stop running

Here's the revised code:

PORTA = 0 ' declare port level BEFORE port direction = safe power-on
PORTB = 0
CMCON = 7 ' PortA Digital inputs
CCP1CON = 0 ' PWM off
VRCON = 0        ' Voltage reference disabled
OPTION_REG.7 =    0

TRISA=%00000000        'set PORTA as all output
TRISB=%00001111        'set RB4,5,6 &7 as output and the rest input

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

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

' set up outputs to drive LEDs
LED1 var  PORTA.1       
LED2 var  PORTA.0       
LED3 var  PORTA.7       
LED4 var  PORTA.6       
LED5 var  PORTB.7       
LED6 var  PORTB.6       
LED7 var  PORTB.5       
LED8 var  PORTB.4       

; set up reed switch inputs
SW0 var PORTB.0          
SW1 var PORTB.1          
SW2 var PORTB.2          
SW3 var PORTB.3          

; set up switch counters
SWFLAG1 var Byte
SWFLAG2 var Byte
SWFLAG3 var Byte
SWFLAG4 var Byte

'set all LEDs to off
low led1
low led2 
low led3 
low led4
low led5
low led6 
low led7 
low led8  
                
'zero the switch counters             
SWFLAG1=0
SWFLAG2=0
SWFLAG3=0
SWFLAG4=0

Main:
' check counters and reset if >2
if SWFLAG1 >2 then
    low led1
    low led2
    SWFLAG1=0
endif
if SWFLAG2 >2 then
    low led3
    low led4
    SWFLAG2=0
endif
if SWFLAG3 >2 then
    low led5
    low led6
    SWFLAG1=0
endif
if SWFLAG4 >2 then
    low led7
    low led8
    SWFLAG2=0
endif

'siding one operation
If SW0=0 Then
swflag1 = swflag1 +1 
pause 500
endif
if swflag1=1 then
high led1                
endif
If SWFLAG1=2 then         
high led2                
endif

'siding two operation
If SW1=0 Then
swflag2 = swflag2 +1 
pause 500
endif
if swflag2=1 then
high led3              
endif
If Swflag2=2 then         
high led4                
else
endif

'siding three opertaion 
If SW2=0 Then
swflag3 = swflag3 +1 
pause 500
endif
if SWFLAG3=1 then
high led5        
endif
If SWFLAG3=2 then    
high led6                
endif

'siding four operation
If SW3=0 Then
swflag4 = swflag4 +1 
pause 500
endif
if SWFLAG4=1 then
high led7        
endif
If SWFLAG4=2 then      
high led8             
endif

Goto Main             

End

When first powered up I can get it working fine, led1 lights the first time sw0 is triggered, then led2 the second time, and then both go out on the third pass of the magnets. This works for all four reed switches, for about 60 seconds and then seems to lock up in what ever state the LEDs are set at. I have 10K pull ups on all input pins, and a 10K pull up on MCLR

Any further comments ?

[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