What memory location should the beginning (lowest address) of flash EEPROM be ORG'ed for the PIC16F877A? Maybe this info is located in a F87x data sheet or the mid-range ref. manual but I haven't found it. There are copious references to EEADR, EEDATA, etc., but no example of ORG-ing in an ASM file. Microchip seems to have hidden this vital info. very well.
IIRC, I discovered this info. for a 16F628A (ORG 2100H, by the way) only by looking at another experimenter's code!
I seem to remember seeing the code your'e talking about(using ORG
2100H for getting EEPROM data into a 16F877A)-I tried it and it worked. I used MPLAB with the "de" directive. Here's a snippet from the MPLAB help file:
==================================================================== "Syntax [label] de expr [, expr, ..., expr] Description de - Data EEPROM.
This directive can be used at any location for any processor.
For PIC18 devices, reserve memory word bytes are packed. If an odd number of bytes is specified, a 0 will be added unless in a code_pack section. See the description for code_pack for more infomation.
For all other PICmicro devices, reserve memory words with 8-bit data. Each expr must evaluate to an 8-bit value. The upper bits of the program word are zeroes. Each character in a string is stored in a separate word.
Usage This directive is used in the following types of code: absolute or relocatable. For information on types of code, see Assembler Operation.
This directive is designed mainly for initializing data in the EE data memory region of PICmicro devices with EE data FLASH.
For PIC18 devices, make sure to specify the start of data memory at
0xF00000. For other PICmicro devices, make sure to specify the start of data memory at 0x2100. Always check your device programming specification for the correct address.
See Also data db dt dw code_pack Simple Example Initialize EEPROM data on a PIC16 device:
org 0x2100 de "My Program, v1.0", 0
PIC16 Application Example - de #include p16f877a.inc ;Include standard header file ;for the selected device. org 0x2100 ;The absolue address 2100h is ;mapped to the 0000 location of ;EE data memory. ;You can create a data or character table starting from any ;address in EE data memory. ch_tbl2 de "PICmicro" ;6 EE data memory locations ;(starting from 0) will be filled ;with 6 ASCII characters. end PIC18 Application Example - de #include p18f452.inc ;Include standard header file ;for the selected device. org 0xF00000 ;The absolue address F00000h is ;mapped to the 0000 location of ;EE data memory for PIC18 devices. ;You can create a data or character table starting from any ;address in EE data memory. ch_tbl2 de "PICmicro" ;6 EE data memory locations ;(starting from 0) will be filled ;with 6 ASCII characters. end" ================================================================ Unfortunately, the PIC in the example is an '877A. I suppose you could just try 2100H and see if it gets burned. or If you are using MPLAB to control the burner you could:
1) make sure the EEPROM selection in the programmer setup is checked
2) prior to burning, goto "View-EEPROM Memory"
3) poke in the hex values you want programmed
4) burn the PIC MPLAB will take care of the EEPROM starting address for you
Of course if you want to change the contents of EEPROM during program execution, you'll have to use the EEADR,EEDATA,etc. procedure shown in the data sheets.
HTH Let us know how it works out.
_______ >What memory location should the beginning (lowest address) of flash EEPROM be
Quidquid latine dictum sit, altum viditur. (Whatever is said in Latin sounds profound.)
And so it is! I'd marked that part of the page with yellow hi-liter, though I wasn't certain that "logically mapped ... 2100H" means it should be ORG'd there. And so many types of memory mentioned in Microchip docs - "configuration"; "user"; "test" - that I get confused.
Yes, I realize it's a coincidence that both 16F628 and 16F877 have their EEPROM at 2100H, that others have theirs elsewhere. Having programmed EEPROM in the F628 quite a bit, I was kinda surprised to learn that 2100H would have worked for the F877 too. As for "consult the documentation for your programmer", I built the programmer. :-) Have used it with both 16F84/F84A and 16F628/F628A for years, and right now I'm wrestling with writing PC software for it that supports 16F877A.
I grabbed AN910 "PICmicro Dev. Prog.: What You Always Wanted To Know ...", while I was still looking for that ORG info I needed, and oh-my-gosh what an eye-full that is. "It's usually this way but there are exceptions. For example ..." is sprinkled all over. Reminded me of college texts in a lot of ways. I am an EE, worked as a tech. writer for several years in the 80's, and yet Microchip's docs. sometimes leave me scratching my head.
I've been there. I'm actually trying to get out of the programming software game. My game plan at the moment is to use Alain Gibaud's pikdev software, specifically his pkp CLI module. You can find it here:
It's Linux based software, but if I get some time I hope to do a Windows port of at least the CLI module.
I like it because it uses an object model for both programming algorithms and progamming hardware. So it isn't too painful to add a new object for a new algorithm or a new piece of hardware. Also he has tons and tons of PIC devices (including all of the parts you listed) already done. So no more having to rewrite algorithms.
Now if you have a parallel port based programmer, I do have an experimental version of a heavily modified version of Brian Lane's picprg program. It was originally Linux software targeted for the 16F84. My updated version will do PICs that require multiword writes (such as the 16F877A above), auto part detection (so no worries as to whether or not the PIC is detected, the programmer is properly configured, and the correct algorithm is selected), and I have a Windows port for it that works. Drop me a line if you're interested in using it. It'll save you the trouble of having to write more code for the programmer.
Thanks for the offer, Byron. I've copied your post and will keep it in mind.
As a matter of fact I D/L a bunch of PicProg stuff some time ago because the descriptions I read online picqued my interest. Couldn't use it because I don't run Linux nor Windows, but just wanted to take a look.
I've checked and triple-quadruple-checked the programming s/w I wrote for the F877A but it refuses to work. Looks like the PIC chokes while trying to burn the first (program) word of the first "8-pack". Burns garbage in that loc., rest of program mem. stays 0x3FFF (erased). Possibly the 5v p.s. (78L05) sags; just a thought. I'm going to rebuild the programmer anyway, to accommodate both an 18-pin and the needed 40-pin sockets, so I'll beef up the p.s. while I'm at it.