led flasher problem

[rd1196]

Hello I wrote my first assembly program yesterday and all it does is go through the numbers 7 to 0 and using that output along with the 7442 decoder to flash through a line of 8 leds, I programmed the pic last night and it worked like I wanted it to except for some reason the outputs were on RB7-5 with the MSB being on RB7. I thought it was flashing a bit too fast so I tried to add a third delay loop and when I programmed it the output was a constant 7 and it was now in RB0-2 with RB2 being the msb (what I was expecting from the beginning) when i restored the code to the way it was the same thing happened and I tried programming the LED flasher tutorial code and RB0 was at a constant high. For some reason the outputs are stuck on a value and dont seem to be looping.

I have attached both my program and the version of the ledflasher im using with the pic (I dont believe ive made any changes)

any thoughts on what may cause this?

[tumbleweed]

Are you sure that the leds are stuck on, or is it just appear that way? The 'delay' routine only provides 1.5ms of delay at 4MHz so I doubt you'd be able to see much of anything.

I've cleaned up the code a bit and added a 'longdelay' routine. Change the 'call delay' to 'call longdelay' and see if that works any differently. If not, it could be the decr instruction operating on PORTB that's causing issues.

I'd also recommend changing the CONFIG settings to enable the PWRT and MCLR (but you'll have to have a pullup on the MCLR pin)

Code: Select all

  LIST p=16f648A
  #include "p16f648a.inc"

  ;the configurations and such are essentially copy/paste from brads tutorials
  ;the delay routine is also following Brads LED flasher idea
 
  ; sets the configuration settings
  ; internal oscillator, watchdog timer OFF
  ; Power Up Timer DISABLED, Master Clear DISABLED, Brown Out Detect DISABLED,
  ; Low Voltage Programming DISABLED, Data EE Read Protect Disabled,
  ; Code Protect OFF
  __config _FOSC_INTOSCIO & _WDT_OFF & _PWRTE_OFF & _MCLRE_OFF & _BOREN_OFF & _LVP_OFF & _CPD_OFF & _CP_OFF

  ; recommend turning MCLRE and PWRTE ON (need a 10K pullup to 5V on MCLR pin)
  ;__config _FOSC_INTOSCIO & _WDT_OFF & _PWRTE_ON & _MCLRE_ON & _BOREN_OFF & _LVP_OFF & _CPD_OFF & _CP_OFF

  ;errorlevel -302 ; Turn off banking message (for known tested/good code)

  cblock h'20'
  delay_1
  delay_2
  endc 
 
  org h'0000'
 
setup:
  movlw b'00000111'
  banksel CMCON
  movwf CMCON

  movlw h'00'
  banksel TRISB
  movwf TRISB

  movlw h'20'
  banksel TRISA
  movwf TRISA
  
  banksel PORTB ; sets bank 0
begin:
  movlw h'07'   ; basically what im doing is running from 7 downto 0 to go through
  movwf PORTB   ; 8 LEDs using the 7442 decoder
 
  call decrement
  goto begin
 
decrement:
  call delay       ;hold the current value for some time
  decfsz PORTB,f   ; decrement the value and skip to return once it reaches 0
  goto decrement
  return

; pretty much Brads delay in Tutorial 1
; note: at 4MHz this only provides about 1.5ms of delay
delay:
  movlw h'ff'
  movwf delay_1
  movwf delay_2
delayloop:
  decfsz delay_1,f
  goto delayloop
delayloop_2:
  decfsz delay_2,f
  goto delayloop_2
  return 

; at 4MHz this provides almost 200ms of delay (196.8)
longdelay:
  movlw 0
  movwf delay_1
  movwf delay_2
ldelayloop:
  decfsz delay_1,f
  goto ldelayloop_2
  return
ldelayloop_2:
  decfsz delay_2,f
  goto ldelayloop_2
  goto ldelayloop

  end

[bitfogav]

Are you sure that the leds are stuck on, or is it just appear that way? The 'delay' routine only provides 1.5ms of delay at 4MHz so I doubt you'd be able to see much of anything.

I've cleaned up the code a bit and added a 'longdelay' routine. Change the 'call delay' to 'call longdelay' and see if that works any differently. If not, it could be the decr instruction operating on PORTB that's causing issues.

tumbleweed is spot on here!. the delay time is too fast and the code "longdelay" should fix the one issue but yes tumbleweed is also right with the "decfsz" on the PORT. you will need to change the code something like the code below. I have added another variable to cblock "count1" here we will store a count value. I have also change the code to write the data from the counter to the port.
It is also worth noting that the 7442 chip will turn on the leds all bar one, that is the normal function of the decoder. And you will probably need all data lines A,B,C,D connected to pic to control all 8 leds.

Code: Select all

  LIST p=16f648A
  #include "p16f648a.inc"
 
  ; sets the configuration settings
  ; internal oscillator, watchdog timer OFF
  ; Power Up Timer DISABLED, Master Clear DISABLED, Brown Out Detect DISABLED,
  ; Low Voltage Programming DISABLED, Data EE Read Protect Disabled,
  ; Code Protect OFF
  __config _FOSC_INTOSCIO & _WDT_OFF & _PWRTE_OFF & _MCLRE_OFF & _BOREN_OFF & _LVP_OFF & _CPD_OFF & _CP_OFF

  ; recommend turning MCLRE and PWRTE ON (need a 10K pullup to 5V on MCLR pin)
  ;__config _FOSC_INTOSCIO & _WDT_OFF & _PWRTE_ON & _MCLRE_ON & _BOREN_OFF & _LVP_OFF & _CPD_OFF & _CP_OFF

  ;errorlevel -302 ; Turn off banking message (for known tested/good code)

  cblock h'20'
  delay_1
  delay_2
  count1
  endc 
 
  org h'0000'
 
setup:
  movlw b'00000111'
  banksel CMCON
  movwf CMCON

  movlw h'00'
  banksel TRISB
  movwf TRISB

  movlw h'20'
  banksel TRISA
  movwf TRISA
  
  banksel PORTB 		; sets bank 0

begin:
  movlw h'08'    		; 
  movwf count1   		; add value to counter
  call decrement
  goto begin
 
decrement:

  movf count1,w			; move value to wreg
  movwf PORTB			; move wreg value to port
  call longdelay        ; hold the current value for some time
  decfsz count1, f   	; decrement the value and skip to return once it reaches 0
  goto decrement		; if not zero
  return				; if zero return

; at 4MHz this provides almost 200ms of delay (196.8)
longdelay:
  movlw 0
  movwf delay_1
  movwf delay_2
ldelayloop:
  decfsz delay_1,f
  goto ldelayloop_2
  return
ldelayloop_2:
  decfsz delay_2,f
  goto ldelayloop_2
  goto ldelayloop

  end

If you need any help on the changes of code then feel free to ask..

[rd1196]

Alright so first of all I apologize for any bad style in my code it was something I quickly put together as soon as I dug up an old pickit2 to test, I also appreciate the patience to explain any rookie questions I might ask im still struggling to separate what lines of code are specific instructions from the chip and what lines are standard assembly syntax.

I made the changes to see if it solved the problems and it did, both for the flasher code and my own. now I have a few questions about the longdelay routine:

-Why do you load a zero to delay_1 and delay_2, or is that not what that line is doing? I wonder since you didnt specify b'00000000' or d'0' or h'00' and also that would mean you return on the first decfsz try no? or what you decrement the already zero do you get an overflow of sorts and go back to the max value and start decrementing again?

Code: Select all

longdelay:
  movlw 0
  movwf delay_1
  movwf delay_2
ldelayloop:
  decfsz delay_1,f
  goto ldelayloop_2
  return
ldelayloop_2:
  decfsz delay_2,f
  goto ldelayloop_2
  goto ldelayloop

Now going back to my code, the way I had the circuit set up was 8 leds from the 0 output of the 7442 to the 7 output, and the ABC inputs going to the PIC with the D input to GND. With the current code it will never send a 0 code to PORTB but it still goes through 8 combinations total since now it starts from 8 but that means shifting all the LEDs one spot and also using the D input as well. Now this is obviously not much trouble but Im curious if there is a way around that in the code while still using the decfsz instruction.


Thank you both for the help

[tumbleweed]

I mostly cleaned it up because MPASM can be picky about what goes where... you should make sure column 1 is only used for labels and I like to delineate them using ':' to make it clear.

still struggling to separate what lines of code are specific instructions from the chip and what lines are standard assembly syntax

About the only things I added were the BANKSEL instructions, which do the same as setting the bank bits in the STATUS register but it's a lot less error-prone (IMHO). Also, the __config long-form is a lot better than setting it using the hex word. It's too easy to make a mistake.

Why do you load a zero to delay_1 and delay_2, or is that not what that line is doing? I wonder since you didnt specify b'00000000' or d'0' or h'00' and also that would mean you return on the first decfsz try no?

I loaded it with 0 so the loops take 256 iterations. They take advantage of the fact that 'decsz' decrements it first (so on entry 0->255).
They won't reach 0 again until they count all the way back down. 0 is pretty much the same in any number base, so take your pick.

This should "fix" using 7-0 for your decoder. I'm not an asm expert, so there might be easier ways to do this.

Code: Select all

  LIST p=16f648A
  #include "p16f648a.inc"

  ;the configurations and such are essentially copy/paste from brads tutorials
  ;the delay routine is also following Brads LED flasher idea
 
  ; sets the configuration settings
  ; internal oscillator, watchdog timer OFF
  ; Power Up Timer DISABLED, Master Clear DISABLED, Brown Out Detect DISABLED,
  ; Low Voltage Programming DISABLED, Data EE Read Protect Disabled,
  ; Code Protect OFF
  __config _FOSC_INTOSCIO & _WDT_OFF & _PWRTE_OFF & _MCLRE_OFF & _BOREN_OFF & _LVP_OFF & _CPD_OFF & _CP_OFF

  ; recommend turning MCLRE and PWRTE ON (need a 10K pullup to 5V on MCLR pin)
  ;__config _FOSC_INTOSCIO & _WDT_OFF & _PWRTE_ON & _MCLRE_ON & _BOREN_OFF & _LVP_OFF & _CPD_OFF & _CP_OFF

  ;errorlevel -302 ; Turn off banking message (for known tested/good code)

  cblock h'20'
  delay_1
  delay_2
  count1
  endc 
 
  org h'0000'
 
setup:
  movlw b'00000111'
  banksel CMCON
  movwf CMCON

  movlw h'00'
  banksel TRISB
  movwf TRISB

  movlw h'20'
  banksel TRISA
  movwf TRISA
  
  banksel PORTB ; sets bank 0
begin:
  movlw h'07'   ; basically what im doing is running from 7 downto 0 to go through
  movwf count1         ; add value to counter
 
  call decrement
  goto begin
 
decrement:
  movf count1,w         ; move value to wreg
  movwf PORTB         ; move wreg value to port
  call longdelay        ; hold the current value for some time
  movlw 1              ; decrement the value until it overflows (so we get 0 included)
  subwf count1, f
  btfsc STATUS, C      ; for subtract, carry is a borrow
  goto decrement
  return

; pretty much Brads delay in Tutorial 1
; note: at 4MHz this only provides about 1.5ms of delay
delay:
  movlw h'ff'
  movwf delay_1
  movwf delay_2
delayloop:
  decfsz delay_1,f
  goto delayloop
delayloop_2:
  decfsz delay_2,f
  goto delayloop_2
  return 

; at 4MHz this provides almost 200ms of delay (196.8)
longdelay:
  movlw 0
  movwf delay_1
  movwf delay_2
ldelayloop:
  decfsz delay_1,f
  goto ldelayloop_2
  return
ldelayloop_2:
  decfsz delay_2,f
  goto ldelayloop_2
  goto ldelayloop

  end

[rd1196]

Thank you very much for all the help!

[rd1196]

Hello again guys, I recently got a smaller PIC that has both PWM and A/D converter modules for a current project. I decided to test the LED flasher routine first to see how the PIC behaves and what configurations have to be done differently. I had a read through the datasheet and made some changes accordingly and the LED flashes, but for some reason GPIO 5 is set whereas all the others are cleared as they should be (except for GPIO 1 which we are using for the flasher). Im not sure why this is happening but if there is something obvious in my code that im missing please let me know.


Thanks a lot guys I have been reading through the datasheets and Im slowly getting the hang of what sorts of things change with PICs and what things are language standard but for now Im guiding myself with various samples

Code: Select all

;First test of the 12f615
;April 20,2015 by Ricardo Dupouy
    
    
    LIST p=12f615
    include "P12f615.inc"
    
    __config _FOSC_INTOSCIO & _WDT_OFF & _PWRTE_OFF & _MCLRE_OFF & _BOREN_OFF & _CP_OFF ;& _IOSCFS_4MHZ
     ; is 4MHZ the default?
    
    PC equ h'02'
 
 
    cblock h'40'
    delay_1
    delay_2
    endc
    
    
    org h'0000'
    
    
    movlw h'07'	;	This will turn the comparators OFF.	
    movwf CMCON0
    
    bsf STATUS, RP0  ;GP3 is an input only (- - GP5 GP4 GP3 GP2 GP1 GP0)
    movlw h'08'
    movwf TRISIO
    bcf STATUS, RP0
    
   
    
    
begin:					;	essentially same routine as the previous Flasher					
	bsf GPIO, 0		        ;	set GPIO pin 0 to a logic 1 (turns the LED on)
	call longdelay		        ;	call the delay so that the LED stays on for a while
	bcf GPIO, 0			;	clear GPIO pin 0 to a logic 0 (turns the LED off)
	call longdelay			;	call the delay so that the LED stays off for a while
	goto begin			;	and now go and do it all again (it will run in a continuos loop)
	

			

	
; the improved delay routine provided by tumbleweed
longdelay:
  movlw 0
  movwf delay_1
  movwf delay_2
ldelayloop:
  decfsz delay_1,f
  goto ldelayloop_2
  return
ldelayloop_2:
  decfsz delay_2,f
  goto ldelayloop_2
  goto ldelayloop
	


  end	

[bitfogav]

for some reason GPIO 5 is set whereas all the others are cleared as they should be (except for GPIO 1 which we are using for the flasher).

In you're code you have setup TRISIO which will set the port pin functions, but you don't seem to have any code which tells the port pins what to actual output.
This will lead to random high/low on the outputs. try using the following code within you're code:

Code: Select all

CLRF GPIO

[rd1196]

Alright that makes sense Thank you very much.

A quick question though, is it possible to program multiple microcontrollers at once using the same pickit2? lets say I want to have 5 circuits built each with a micro running the same code can I hook them all up to the pickit2 using a breadboard or a PCB and program them all at once?

Thank you

[tumbleweed]

is it possible to program multiple microcontrollers at once using the same pickit2?

No, you'll have to connect up to each one individually and program it.

If you have multiple pics you might want to ask yourself if it'd be easier to use a single chip with more IO pins. Usually that's the better way.

[rd1196]

If you have multiple pics you might want to ask yourself if it'd be easier to use a single chip with more IO pins. Usually that's the better way.

well one pic is more than enough for the circuit but I wondered if you wanted to build several prototypes for testing if there was a way to program them all at once to save time but i figured there wasnt I just wanted to confirm

thanks

[Garth]

They can't just be connected in parallel, because of the read-back for checking to see if the programming "took," and that one of them may prove to need more (or longer) programming pulses than others, depending on the programming algorithm for the particular part.

[rd1196]

Yea it seemed so clear in my head a couple of months ago when I was still dreaming about programming PICs but once I started actually programming the code I realized it probably isnt that simple

Thanks for the response

[bitfogav]

As we are on that topic, can I just mention that it is possible to have multiple Pickit2's running with multiple GUI's on one PC.
This is possible by giving each PicKit2 an ID, and this is done via the PicKit2 GUI.
You can then select the GUI with the corresponding PicKit2 and programme the selected PIC.
I'm not sure what the maximum number of PicKit2's are though that you can have connected at one time...

[rd1196]

That is a very interesting alternative, unfortunately I only have the one pickit2 and Im just using the programming button on MPLABX without any IPE for now since its actually a borrowed pickit2 and I couldnt find the CD with the GUI install anywhere

Thanks a lot