PIC Code Uncertainty: Why Does Placement Matter?

In summary, the conversation discusses a problem with two different codes used for programming a PIC. The first code does not work, while the second code works successfully. The conversation explores the reasons for this and concludes that it is due to the reset vector and uninitialized values causing problems in the first code. The second code works because the uninitialized value happens to point to a valid location in the program code. To fix the issue, the reset vector and code placement need to be adjusted.
  • #1
El Moriana
33
0
Hi, I have just managed to make a PIC light blink. My question has to do with the syntax. In my code, I use a Delay subroutine that is called in between turning the LED on and turning it off.

I tried two codes. The first had my Delay subroutine being placed before my main code. The second had the subroutine placed after my main code (but before END). Only the second code worked. Why? What is the problem with the first method?

Below are the two codes I used:

************************************
1st METHOD
************************************

list p=16F690 ; defines chip that will be used
#include <p16F690.inc> ; imports instructions specific to PIC used

;================
;configuration

__CONFIG _CP_OFF & _CPD_OFF & _BOR_OFF & _MCLRE_ON & _WDT_OFF & _PWRTE_ON & _INTRC_OSC_NOCLKOUT & _FCMEN_OFF & _IESO_OFF

;================
;declarations

org 1FFh ; reset
goto start ;
org 0 ;



count1 equ 20h ; general purpose registers used in the delay
counta equ 21h ;
countb equ 22h ;

;================
;subroutines

Init ; initialisation subroutine
clrf PORTA ; clears the port file registers
clrf PORTB ;
clrf PORTC ;

bsf STATUS,RP0 ; selects bank 1
bcf STATUS,RP1 ;

clrf TRISC ; sets all of portC to output

bcf STATUS,RP0 ; selects bank 0
bcf STATUS,RP1 ;

retlw 0

Delay movlw d'250' ;delay 250 ms (4 MHz clock)
movwf count1
d1 movlw 0xC7
movwf counta
movlw 0x01
movwf countb
Delay_0
decfsz counta, f
goto $+2
decfsz countb, f
goto Delay_0

decfsz count1, f
goto d1
retlw 0

;================
;main code

start call Init ; calls the intitialization subroutine

main bsf PORTC,0 ; LED on
call Delay
bcf PORTC,0 ; LED off
call Delay
goto main ; infinite loop
END ; end of program

;================



************************************
2nd METHOD
************************************

list p=16F690 ; defines chip that will be used
#include <p16F690.inc> ; imports instructions specific to PIC used

;================
;configuration

__CONFIG _CP_OFF & _CPD_OFF & _BOR_OFF & _MCLRE_ON & _WDT_OFF & _PWRTE_ON & _INTRC_OSC_NOCLKOUT & _FCMEN_OFF & _IESO_OFF

;================
;declarations

org 1FFh ; reset
goto start ;
org 0 ;



count1 equ 20h ; general purpose registers used in the delay
counta equ 21h ;
countb equ 22h ;

;================
;subroutines

Init ; initialisation subroutine
clrf PORTA ; clears the port file registers
clrf PORTB ;
clrf PORTC ;

bsf STATUS,RP0 ; selects bank 1
bcf STATUS,RP1 ;

clrf TRISC ; sets all of portC to output

bcf STATUS,RP0 ; selects bank 0
bcf STATUS,RP1 ;

retlw 0

;================
;main code

start call Init ; calls the intitialization subroutine

main bsf PORTC,0 ; LED on
call Delay
bcf PORTC,0 ; LED off
call Delay
goto main ; infinite loop

Delay movlw d'250' ;delay 250 ms (4 MHz clock)
movwf count1
d1 movlw 0xC7
movwf counta
movlw 0x01
movwf countb
Delay_0
decfsz counta, f
goto $+2
decfsz countb, f
goto Delay_0

decfsz count1, f
goto d1
retlw 0

END ; end of program

;================
 
Engineering news on Phys.org
  • #2
I can't see how either of your two codes would work
since the reset vector for all PIC's is 0x0000, not 0x01FF.

The PIC will execute the init method without being called, and when it reaches the
'retlw' instruction that will cause a stack overflow reset.
 
  • #3
That may be. I am only beginning to code PICs and know very little on the subject.

However I have written both those exact codes to a PIC16F690 and the second code worked, with the LED physically turning on and off.

I will keep in mind for future that the reset vector is 0x0000, but is there anything else that could cause the difference?
 
  • #4
JimmyAlz said:
I can't see how either of your two codes would work
since the reset vector for all PIC's is 0x0000, not 0x01FF.

The PIC will execute the init method without being called, and when it reaches the
'retlw' instruction that will cause a stack overflow reset.

Possibly what I have done is (quite uselessly) placed the instruction "goto start" at 0x01FF and mislabeled it "reset", which has little overall bearing on the working of the code... does this sound correct?
 
  • #5
I'm sorry it sounded like I didn't believe you. (English is not my first language)

I'm still leaning towards the reset vector. It is a clear problem.
What happens if you rewrite using 0x0000 as reset vector?
 
  • #6
Possibly what I have done is (quite uselessly) placed the instruction "goto start" at 0x01FF and mislabeled it "reset", which has little overall bearing on the working of the code... does this sound correct?

Yes this sound correct. And would not affect the code. Executing "retlw" without first executing "call" is I think what causes the problems.
 
  • #7
Firstly,coding:

org 0x0000
goto start
org 0

Does indeed give me an error:

Error[118] G:\...\MYFILE.ASM 61 : Overwriting previous address contents (0000)

Secondly:
JimmyAlz said:
Executing "retlw" without first executing "call" is I think what causes the problems.

In this case, why is it that I am able to call the 'Init' subroutine (which is placed before the call) successfully, as I do in the 2nd method?
 
  • #8
Checked the data sheet ... 16F690 doesn't *have* stack overflow reset ... :/

So what happens is that the "retlw" instruction fetches an uninitialized value from the stack and jumps to it.
So your code #2 works because you are "lucky".
The uninitialized value just happens to point inside your program code in #2.
 
  • #9
JimmyAlz said:
The uninitialized value just happens to point inside your program code in #2.

Ok, this makes sense. =) So what do I need to change to code this properly?
 
  • #10
In this case, why is it that I am able to call the 'Init' subroutine (which is placed before the call) successfully, as I do in the 2nd method?
I'm confused, what do you mean by "(which is placed before the call)"?
The placement of the code does not matter.

this will work:

org 0 ; or 0x0000 or 000h (all mean the same thing)
goto start

init
<some code>
retlw

start
call init
main
call something_else
goto main


this will not work:

org 0

init
<some code>
retlw

start
call init
main
call something_else
goto main


I hope I have helped somewhat, going to bed now ... it's 3am here in Sweden.
 
  • #11
Ah, I see! It all makes sense now =), thank you *very* much for your help. Go well.
 

1. Why is placement important in PIC code uncertainty?

Placement plays a crucial role in PIC code uncertainty because it affects the accuracy and reliability of the simulation results. The placement of particles, boundary conditions, and other parameters can significantly impact the behavior of the system being simulated.

2. How does PIC code uncertainty affect my research?

PIC code uncertainty can introduce errors and inaccuracies in your simulations, which can ultimately affect the validity and reliability of your research results. It is essential to understand and account for PIC code uncertainty to ensure the accuracy of your findings.

3. What factors contribute to PIC code uncertainty?

There are several factors that can contribute to PIC code uncertainty, including numerical errors, statistical noise, and the choice of numerical methods and algorithms. Additionally, the placement of particles and boundary conditions can also significantly impact the uncertainty in PIC simulations.

4. How can we reduce PIC code uncertainty?

There are several ways to reduce PIC code uncertainty, including increasing the number of particles, using more accurate numerical methods and algorithms, and carefully selecting the placement of particles and boundary conditions. Conducting sensitivity analyses and comparing results with analytical solutions can also help identify and reduce uncertainty.

5. Are there any limitations to PIC code uncertainty reduction?

While there are ways to reduce PIC code uncertainty, it is impossible to eliminate it entirely. PIC simulations involve simplifications and assumptions, and there will always be some level of uncertainty in the results. However, by carefully considering and accounting for uncertainty, we can improve the accuracy and reliability of simulations and research results.

Similar threads

PIC16F877A I2C communication problem
    • Electrical Engineering
Replies
2
Views
2K
Creating a Blinking LED with PIC 16F84A and 32K Crystal: A Step-by-Step Guide
    • Electrical Engineering
Replies
9
Views
2K
PIC Microcontrollers: problem with LCD module (see below)
    • Electrical Engineering
Replies
5
Views
2K
Generating a square wave with a PIC12F
    • Electrical Engineering
Replies
2
Views
2K
Finding errors in a section of microprocessor assembly code
    • Engineering and Comp Sci Homework Help
Replies
4
Views
1K
Creating a TMR0 delay using PIC16F84?
    • Programming and Computer Science
Replies
3
Views
1K
Why Is My PIC18F45J10 Not Lighting Up an LED Despite Correct Code and Circuit?
    • Electrical Engineering
Replies
6
Views
3K
Need micro controller 18f4580
    • Engineering and Comp Sci Homework Help
Replies
1
Views
2K
Having trouble reading input values in PIC assembly programming?
    • Programming and Computer Science
Replies
2
Views
3K
Set PIC IO Pin High - Assembly Help
    • Programming and Computer Science
Replies
4
Views
2K

Hot Threads

Recent Insights

Back
Top