Request check code of 60Hz signal 12F510

Status
Not open for further replies.

mvs sarma

Well-Known Member
i am attaching a small code for 60Hz output with external4MHz clock on GP0 and GP1 and an inverted signal on GP2. This is working on MPLAB sim, but not comfortable on real world with All the outputs are LOW.

Help me know where I blundered.
Code: 
;clockgen with 12f510	
		list p=12F510
		#include <P12F510.inc>
		__CONFIG 0FD9h
		errorlevel	-302
clk0		equ		10h
clk1		equ		11h
clk2		equ		12h	
CounterA    equ     15h      
CounterB	equ		16h 
CounterC	equ		17h
CounterD	equ		18h 
	
	org 0x00
	goto begin
	
begin	CLRF	ADCON0
		movlw	0x28
		TRIS	06H
rpt clrf	GPIO  
	movlw	d'4'
	movwf	GPIO	
		movlw	D'1'	;1
		movwf	CounterD
		movlw	D'1'	;1
		movwf	CounterC
		movlw	D'11'	;11
		movwf	CounterB
		movlw	D'206' 	;206
		movwf	CounterA
loop1	decfsz	CounterA,1
		goto	loop1	
		decfsz	CounterB,1
		goto	loop1
		decfsz	CounterC,1
		goto	loop1
		decfsz	CounterD,1
		goto	loop1
		movlw	d'3'
		movwf	GPIO
 	  	movlw	D'1'	;1
		movwf	CounterD
		movlw	D'1'	;1
		movwf	CounterC
		movlw	D'11'	;11
		movwf	CounterB
		movlw	D'206' 	;206
		movwf	CounterA
loop2	decfsz	CounterA,1
		goto	loop2
		decfsz	CounterB,1
		goto	loop2
		decfsz	CounterC,1
		goto	loop2
		decfsz	CounterD,1
		goto	loop2
	  	goto 	rpt
       
		END
 

Attachments

  • 510clock60.asm
    1,008 bytes · Views: 179
As you have simulated it OK in mplab I think it could be your config word bit 4 is set, requiring GP3/MCLR pin (pin4) to be tied high or you could instead clear config bit 4 so that it does not need the MCLR pin at all.
(change config to 0FC9h)
 
picasm said:
As you have simulated it OK in mplab I think it could be your config word bit 4 is set, requiring GP3/MCLR pin (pin4) to be tied high or you could instead clear config bit 4 so that it does not need the MCLR pin at all.
(change config to 0FC9h)
Click to expand...
In fact I tied it high. it would help me not to run after VPP before Vdd issues while further programming.

PS:
Tried it and removed the pull up for MCLR after the mod.
status quo. no change.
 
Last edited:
hi Sarma,
Just run your code in the Oshonsoft sim, it runs OK.

How are you measuring the waveforms on the GP0 , 1 pins..?
 
ericgibbs said:
hi Sarma,
Just run your code in the Oshonsoft sim, it runs OK.

How are you measuring the waveforms on the GP0 , 1 pins..?
Click to expand...

Approximately similar code is showing results in 16F628A. I can measure the 60Hz by my frequency counter, also the LEDs wired on the pins using buffer transistors glow half bright LEDs and so on.

But by the time the code is ported, here on 12F510 with necessary mods, it wouldn't respond on real world. At the same time MPLABsim itself is working fine. For avoiding delay on simulator,I reduce the "11" and "206" values of delay loops to 1 & 2, and while programming restore them back.
 
With your configuration settings, you're supposed to use a crystal. Is that ok for you? or are you willing to use the internal oscillator?
 
eng1 said:
With your configuration settings, you're supposed to use a crystal. Is that ok for you? or are you willing to use the internal oscillator?
Click to expand...

YES, I am using 4MHz crystal with two 33pF caps.and either i can have external or internal MCLR
I just need 3 outputs of 60Hz, 60Hz and 60Hz*
 
I would try writing zero to CM1CON0 and 0xc0 to the option register.

<edit>beaten to it on both suggestions.</edit>

Mike.
 
Last edited:
Now with mods indicated below I am getting signals on GP0 and and GP1. I had written 5 and 6 alternately with interfacing delay. Still I am unable to get the output on GP2 and request for comment on what mistake i am doing.
Code: 
;60Hz clockgen with 12f510	
		list p=12F510
		#include <P12F510.inc>
		__CONFIG 0FC9
		errorlevel	-302
clk0		equ		10h
clk1		equ		11h
clk2		equ		12h	
CounterA    equ     15h      
CounterB	equ		16h 
CounterC	equ		17h
CounterD	equ		18h 
	
	org 0x00 
	goto begin
	
begin	
;		OPTION	0x00 
		movlw	0xC0
		movwf	CM1CON0
		CLRF	ADCON0
		movlw	0x28
		tris	06h
rpt  
		movlw	d'5'
		movwf	GPIO	
		movlw	D'1'	;1
		movwf	CounterD
		movlw	D'1'	;1
		movwf	CounterC
		movlw	D'11'	;11
		movwf	CounterB
		movlw	D'206' 	;206
		movwf	CounterA
loop1	decfsz	CounterA,1
		goto	loop1	
		decfsz	CounterB,1
		goto	loop1
		decfsz	CounterC,1
		goto	loop1
		decfsz	CounterD,1
		goto	loop1
		movlw	d'6'
		movwf	GPIO
 	  	movlw	D'1'	;1
		movwf	CounterD
		movlw	D'1'	;1
		movwf	CounterC
		movlw	D'11'	;11
		movwf	CounterB
		movlw	D'206' 	;206
		movwf	CounterA
loop2	decfsz	CounterA,1
		goto	loop2
		decfsz	CounterB,1
		goto	loop2
		decfsz	CounterC,1
		goto	loop2
		decfsz	CounterD,1
		goto	loop2
	  	goto 	rpt
       
		END

OPTION could not have effect. i was expected to clear OPTION,TOCS bit
still i must be doing a mistake!!
 
Pommie said:
Try doing,
Code: 
		movlw	0xC0
		option

Mike.
Click to expand...
Nope. it didn't respond. the other pins continue to output.
at this time GP2 is taken HIGH
changed code attached.
 

Attachments

  • 510clock60.asm
    1 KB · Views: 196
Last edited:
Pommie said:
You need to write zero to CM1CON0.

Mike.
Click to expand...

Thanks Pommie, and one and all.
I am a big fool, writing 5 and 6 to the port I should not expect the GP2 to change.
after modding "0" to CM1CON0, I observed this and changed the values to 4 and 3 to represent 0100 and 0011.

Now it works !! Grateful for the help in debugging.The final code is attached.
I need to fine tune for exact 60Hz as I wanted to use it for driving a radio alarm clock employing SC(LM)8560, to overcome the local mains inconsistent frequency.
 

Attachments

  • 510clock60.asm
    1 KB · Views: 182
Last edited:
If you use the simulator and the stop watch you should be able to get the time exact. You're delay is currently 80 cycles per second too long.

Mike.
 
Last edited:
Pommie said:
If you use the simulator and the stop watch you should be able to get the time exact. You're delay is currently 80 cycles per second too long.

Mike.
Click to expand...
I had measured the output on my frequency counter and it reads 60 or 61Hz (0.000060 MHz to be precise.)

For 60 Hz, each cycle period works to 1/60 =0.016666 Sec or 16666uS. I took 50% of this for each half cycle. thus 8333 or 8334uS.
i used this value of delay into the Picloops: Delay Loop Calculator v2.2 by William J. Boucher, Web site: Biltronix Home and sought 4 loop delay and it has output as indicated below. but he claimed 8334uS, without call or return.
Code: 
;PIC Time Delay = 0.00833400 s with Osc = 4000000 Hz
		movlw	D'1'
		movwf	CounterD
		movlw	D'1'
		movwf	CounterC
		movlw	D'11'
		movwf	CounterB
		movlw	D'207'
		movwf	CounterA
loop		decfsz	CounterA,1
		goto	loop
		decfsz	CounterB,1
		goto	loop
		decfsz	CounterC,1
		goto	loop
		decfsz	CounterD,1
		goto	loop


Now i had adopted the same.

I could not understand how you have computed 80 cycles/sec, Pommie! Whether the simulator can have realistic timing? let me wire it up into the clock, and I shall give further feed back. i do agree , that some fine tuning of cycles by NOP and/or 4MHz trimming needs to be done.
 
Last edited:
mvs sarma said:
I could not understand how you have computed 80 sec timing, Pommie. let me wire it up into the clock, and I shall give further feed back. i do agree , that some fine tuning of cycles by NOP and/or 4MHz trimming needs to be done.
Click to expand...

If you run your code in the simulator and set a break point on the rpt line then you can use the stop watch to time how long it takes. If you zero the stop watch first time it hits the break point and then hit F9 60 times you will see the time if 1,000,080 cycles.

Mike.
 

I would check and revert back please.
 
Status
Not open for further replies.
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…