Newbie - 16F628A and switch latching

[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

[Pic_User]

I am new to the forum and hope not out of line...

Clues:

1) - The latching is not clean, in that sometimes the LED brightens and remains on when it should be off, or when off it is turned on by the reed switch, but fails to latch

"The LED brightens" (unintentionally) does not sound very digital.

Thanks, and yes it compiles OK and in tests works as required approx 70% (ie 7 out of 10) of the time. On three attepts LED2 remained lit, but its a lot better than my 0% success rate

I hooked up a test track and placed a magnet on a loco to see how it worked, as I had been using magnets passing over the switches by hand to test the code.
I don't know if it's due to the speed of the train (slower than my hand tests) but I got a 1 in 10 success rate of both LEDs being turned off when the train exited the siding

I wonder if there might be an interaction between the magnetics of the locomotive "engine" and the reed switch. Possible even modulating the switch as the loaded motor slowly passes over the switch. Monster size "contact bounce". Or perhaps the magnetics of the motor offsets the permanent magnet, causing it to not always trigger the reed switch.

If this is part of the problem then Melanie's suggestion would certainly apply:

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

Don't forget the sequence of permanent magnet and motor chatter would depend upon the direction of travel (just to make it interesting).

This may not be any part of Malcolm's problem but something we should keep in mind when using reed switches or hall effect devices. Don't ask why I thought of it.

This forum is the most useful resource, for beginners, on the entire web. Thanks to all you PIC gurus, most of the "gotchas" with PICs, can be found with a forum search. Thanks for all your hard work.

-Adam-

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

[mister_e]

At least, your config fuses are not declare the right way. See the following thread
http://www.picbasic.co.uk/forum/showthread.php?t=543


NOW, are you saying that if you change them manually in your device programmer software it doesn't work?

You declare to use an external RC oscillator... are the value of R and C meet the datasheet suggestion? Personnally, i would prefer to use the internal one

'  PIC config fuse using MPASM to compile
	@ __CONFIG  _INTRC_OSC_NOCLKOUT & _MCLRE_ON  &  _LVP_OFF & _WDT_OFF & _PWRTE_ON  & _BODEN_ON

[malc-c]

Steve,

I've tried most of the suggestions to include the config settings within the code. The only enties that doesn't halt the compiling process are

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

However these must me ignored by the compiler as the resulting LST file after the code has compiled shows a config setting of

__config _XT_OSC & _WDT_ON & _MCLRE_ON & _LVP_OFF & _CP_OFF

So when I come squirt the HEX file to the PIC via WinPIC pro I manually change the device config settings to RC no clockout, and have tried enabling / disabling WDT and MCLR input as well but it has no affect, the PIC seems to freeze after 60-90 seconds of running the code posted above.

Just to prove it isn't the PIC that's faulty, I programmed a simple "Flash LEDs" using JAL and that's been running for the past hour - so the issue must be somthing with either the PBP code, the communications between PBP and MPSAM or the way MPSAM compiles the files from PBP or the manual settings in WinPIC are being overlooked when the HEX is loaded.. but then why would the code run at all if that was the case ??

On the hardware front, as I'm using the internal OSC (or trying to) I have no Resistors or capacitors, or external crystal. The four reed switches are connected between ground and the first four pins of PORTB, with 10K pull-ups to +5v. The only other components are 8 LEDs and their 8 resistors.

Cheers

Malcolm

[malc-c]

Further Update...

If I keep triggering the LEDs on PORT A (via RB0 and RB1) the PIC runs fine for ages.. I can sit there triggering the reed switches until my hearts content. However if I then trigger RB2 or RB3 and thus the LEDs on RB5,6,7,&8 then it freezes...

I'll try making the last 4 pins of PORTA the inputs and PORTB all output and see what happens

Update:

Well making PORTB all outputs and A0,A1, A6 and A7 inputs (rest port A out) is worse. Now on power up all leds light up in random sequence and the extinguish and it freezes.... I'm going to try a trusty old 12F675 with just 2 inputs and see if that works - I have stack of those PICs so using 1 per pair of sidings is no real hard ship !

[malc-c]

Last update

Well, thinking that it might be the hardware, I stripped the breadboard and started from scratch making sure there was nothing left floating, or tied down to the wrong supply. Loaded the code and tested. The first two inputs (RB0 and RB1) and thier coresponding LEDs (RA1, RA0 and RA7, RA6) can be triggered until the cows come home. However triggering the any of input three or four (RB2, or RB3) causes the thing to freeze.

I'm off to try it with the 12F675's and see if that works.

[malc-c]

It turns out the problem is human error... I used the wrong varable in one of the couter checks... that will teach me to cut and paste and not pay attention ! (I blame it on the wife, kids, cat for interrupting me and thus causing me to overlook the error !)

Thanks for everyones input...

Malcolm