PIC 16F877: ORG-ing EEPROM

Michael-

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.)

or

references

Many thanks, Charles, for the fast response. I've been hovering online, hoping someone would speak up *very* soon, because my F877A project is halted for want of that info.

So all that good stuff is in MPLAB Help, huh? I couldn't have looked because there's something wrong with my MPLAB installation: it always tells me there's no Help file available. (DOH!)

--
Michael

0x2100. The information is the "Programming Specifications" document.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Note that this address is a convention and isn't set in stone. You really need to consult the documentation for your programmer. I've seen several programmers where this address can be parameterized.

Again it's simply a convention. For example in 18F PICs the conventional address is something like 0xf000000 or somesuch.

The purpose is to put the EEPROM data somewhere not in the program address space.

BAJ

or

references

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.

--
Michael

or

references

address

space.

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.

--
Michael

I meant programming software. Sorry.

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.

BAJ

game.

specifically

algorithm

algorithms.

version

originally Linux

multiword

whether

correct

line

write more

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.

--
Michael