Thanks, Papabravo. I had already considered your second explanation and something told me that I was wrong on that instance as soon as I posted it. As for the 14 bit address length in the Harvard Architecture that's a very valuable thing to me know, because pretty soon I'm going to have to write a routine that is capable of writing data into the Flash Memory section of the device.

Thanks again for your help.

 

Thanks, Papabravo. I had already considered your second explanation and something told me that I was wrong on that instance as soon as I posted it. As for the 14 bit address length in the Harvard Architecture that's a very valuable thing to me know, because pretty soon I'm going to have to write a routine that is capable of writing data into the Flash Memory section of the device.

Thanks again for your help.

Eres mas que bienvenido
Did I get thar right?

 

Eres mas que bienvenido
Did I get thar right?

You got that perfectly, my friend...

Edit: the word "más" is written with an accent above the "a", but I doubt your keyboard is configured with that capability.

 

Here's an interesting bit. I've discovered that both goto $-1 and goto $-2 instructions in the previous example work perfectly during program execution. Although I suspect that the "more correct" way of coding is using goto $-2, and then goto$-4, goto $-6, and so on..

 

Here's an interesting bit. I've discovered that both goto $-1 and goto $-2 instructions in the previous example work perfectly during program execution. Although I suspect that the "more correct" way of coding is using goto $-2, and then goto$-4, goto $-6, and so on..

How does the actual instruction decode and what comes before the btfss instruction.
Is this in an executing part or in the simulator?

 

Here's an interesting bit. I've discovered that both goto $-1 and goto $-2 instructions in the previous example work perfectly during program execution. Although I suspect that the "more correct" way of coding is using goto $-2, and then goto$-4, goto $-6, and so on..

Avoid using "$-1", etc. You'll be screwed when you edit the program and forget to change those relative jumps. Use labels instead.

 

How does the actual instruction decode and what comes before the btfss instruction.
Is this in an executing part or in the simulator?

It's during physical execution. I don't like simulating code.

Avoid using "$-1", etc. You'll be screwed when you edit the program and forget to change those relative jumps. Use labels instead.

I normally use labels. But when it comes to a single instruction waiting for an even to happen, I find that the $-x format makes for less clutter and is easier to read. I always use labels for any jump larger than a single instruction.

 

I use $-1. Example:

banksel   OSCSTAT             ;                                       |B1
     movlw     b'11100000'         ;8 MHz int oscillator x4 (PLLEN=1)      |B1
     movwf     OSCCON            ;int oscillator & PLL set by config     |B1                       
     btfss    OSCSTAT,HFIOFR       ;config oscillator ready?             |B1                                  
     bra       $-1                 ;keep checking                          |B1 DEBUG

Note, it will also work with any backstep within reason, as it is just a delay. While such assembler shortcuts can be a problem for larger jumps when revising code, the risk in situations such as this is nil.

A greater concern is whether one is checking the correct bit in OSCSTAT. Be sure to check the ERRATA. Some bits cannot be used depending on the chip and other settings. That does not appear to be a problem with that bit in the 16F1823.

 

How does the actual instruction decode

I think I get your question now. Are you asking about the assembled hex code? I think I'm gonna go check, and be back with a report.

 

I think I get your question now. Are you asking about the assembled hex code? I think I'm gonna go check, and be back with a report.

I would be interested to know if there is a difference that between the two and/or if the PC goes back two instructions what is the instruction before the btfss instruction? Does it have any meaningful effects?

 

Question,

- How do I include EEPROM values that I wish to store in the chip when it is being programmed?
- I.E. the PIC16LF1823 EEPROM entire 256 bytes have a default value of 255D when read. How can I set those values to zeroes instead, but specifying them in my source code?

 

Question,

- How do I include EEPROM values that I wish to store in the chip when it is being programmed?
- I.E. the PIC16LF1823 EEPROM entire 256 bytes have a default value of 255D when read. How can I set those values to zeroes instead, but specifying them in my source code?

Going out on a limb here, but for both C and assembler there should be a mechanism for declaring a constant data section. The linkage editor will allocate this constant data area and the code downloading tools will copy that image to the part. This is not the end of the story. You also need the option to skip this step so you can download updated code without disturbing the parameters in the EEPROM that have been modified during development under program control. The option is also useful when you mess up the EEPROM and want to reset to "factory" values.

 

Going out on a limb here, but for both C and assembler there should be a mechanism for declaring a constant data section. The linkage editor will allocate this constant data area and the code downloading tools will copy that image to the part. This is not the end of the story. You also need the option to skip this step so you can download updated code without disturbing the parameters in the EEPROM that have been modified during development under program control. The option is also useful when you mess up the EEPROM and want to reset to "factory" values.

Thanks... I kind of understood the same sort of thing. But the user's guide says that "Most PIC1X MCUs" EEPROM address starts at 0x2100." But I get an error when I try to compile my program with the following code at the end of it:

EEPROM:       ORG    0x2100    ;EEPROM memory location
       de 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D ;16-bit row
       de 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D ;16-bit row
       de 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D ;16-bit row
       de 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D ;16-bit row
       de 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D ;16-bit row
       de 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D ;16-bit row
       de 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D ;16-bit row
       de 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D ;16-bit row
       de 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D ;16-bit row
       de 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D ;16-bit row
       de 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D ;16-bit row
       de 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D ;16-bit row
       de 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D ;16-bit row
       de 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D ;16-bit row
       de 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D ;16-bit row
       de 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D, 0D ;16-bit row

The specific error reported by the compiler being: "Error - section '.org_2' can not fit the absolute section. Section '.org_2' start=0x00002100, length=0x00000200"

I also know there's an option in the configuration section of MPLAB X to either program or not the EEPROM. But that won't make a difference until I find out how to set a definite state to the EEPROM section.

 

By the way, the above table does compile if I remove the ORG 0x2100 directive, but the specified values are not programmed into the EEPROM. This even though the PICkit 3 device reports that the EEData memory will be programmed.

 

By the way, the above table does compile if I remove the ORG 0x2100 directive, but the specified values are not programmed into the EEPROM. This even though the PICkit 3 device reports that the EEData memory will be programmed.

Remember (maybe you don't), that original PICs, had an absolute assembler. The absolute assembler required the ORG statement with an absolute address to do it's job correctly. The more advanced parts use a linkage editor to stitch the various object modules together. What you should be looking for is a keyword or a section name that is understood to go in the correct location for the processor type that you have selected. In the final output look for a linkage editor MAP file that tells you where the modules are located. It should be instructive.

 

Hi Cesar,

Here's what I did for writing and reading EEPROM for a similar device (16F1827). The delay (bra $-2) can probably be $-1:

;*******************************************************************************
; EEPROM ROUTINES
;*******************************************************************************
PutEEPROM
     movwf     EEDATL         ;
     bcf       EECON1,CFGS    ;deselect config space                            |B3
     bcf       EECON1,EEPGD   ;point to data memory
     bsf       EECON1,WREN    ;enable write
     movlw     0x55           ;required sequence
     movwf     EECON2         ;         "
     movlw     0xAA           ;         "                        
     movwf     EECON2         ;         "
     bsf       EECON1,WR      ;         "     
     bcf       EECON1,WREN    ;disable writes
     btfsc     EECON1,WR      ;
     bra       $-2            ;wait for writes to complete
     return

GetEEPROM
     movlb     3              ;                                                 |B3
     movwf     EEADRL
     bcf       EECON1,CFGS    ;deselect config space
     bcf       EECON1,EEPGD   ;point to data memory
     bsf       EECON1,RD      ;enable read
     movf      EEDATL,w       ;put read in w
     return

;*******************************************************************************

 

Hi Cesar,

Here's what I did for writing and reading EEPROM for a similar device (16F1827). The delay (bra $-2) can probably be $-1:

;*******************************************************************************
; EEPROM ROUTINES
;*******************************************************************************
PutEEPROM
     movwf     EEDATL         ;
     bcf       EECON1,CFGS    ;deselect config space                            |B3
     bcf       EECON1,EEPGD   ;point to data memory
     bsf       EECON1,WREN    ;enable write
     movlw     0x55           ;required sequence
     movwf     EECON2         ;         "
     movlw     0xAA           ;         "                       
     movwf     EECON2         ;         "
     bsf       EECON1,WR      ;         "    
     bcf       EECON1,WREN    ;disable writes
     btfsc     EECON1,WR      ;
     bra       $-2            ;wait for writes to complete
     return

GetEEPROM
     movlb     3              ;                                                 |B3
     movwf     EEADRL
     bcf       EECON1,CFGS    ;deselect config space
     bcf       EECON1,EEPGD   ;point to data memory
     bsf       EECON1,RD      ;enable read
     movf      EEDATL,w       ;put read in w
     return

;*******************************************************************************

Thank you, John. But my question is about how to include EEPROM values within the code that will be burnt into the chip along with the firmware at the moment it is programmed by the PICkit 3 device.

 

Use "ORG 0xF000" for your EEPROM data.

 

From same work as posted just above:

;*******************************************************************************
; INITIALIZE EEPROM (Check "Preserve EEPROM" when reprogramming to avoid going
;back to this default value)
;*******************************************************************************
DATAEE ORG 0xF000
de 3 ;index: 1, 3, 5, or 7
de low(416),high(416) ;9600 baud, 0.16% bit error
de low(207),high(207) ;19200 baud, 0.16% bit error
de low(103),high(103) ;38400 baud, 0.16% bit error
de low( 51),high( 51) ;76800 baud, 0.16% bit error
;*******************************************************************************

Beaten to it. Note the org directive.

 

From same work as posted just above:

Beaten to it. Note the org directive.

What? He posted "org 2100" in post 393. And nobody posted anything after that telling him the correct address is F000. You just posted to say "I thought of it first!" Seriously?