Post by thread:[PICLIST] CCS C - Reading and Writing Program EEPR

I'm using a 16F877 part, which allows reading and writing to the program memory area for data storage. I notice the functions WRITE_PROGRAM_EEPROM(address, data) and i=READ_PROGRAM_EEPROM(address) should theoretically be able to handle up to 14 bit numbers, since the program area is 14 bits deep. Does this mean that the functions both use longs (two byte numbers), AKA WRITE(data) should be passed a long, and READ should return a long? How do you insure that your reading and writing is not trashing real program memory area? Is it wise to protect the lower end of the PIC's program memory to prevent this, and use addresses in the upper end of the memory, or is this neccesary? I'd hate to write over my program with a string of temperature data. -- Lawrence Lile Sr. Project Engineer Salton inc. Toastmaster Div. 573-446-5661 Voice 573-446-5676 Fax -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

> I'm using a 16F877 part, which allows reading and writing to the program > memory area for data storage. > > I notice the functions > > WRITE_PROGRAM_EEPROM(address, data) and > i=READ_PROGRAM_EEPROM(address) > > should theoretically be able to handle up to 14 bit numbers, since the > program area is 14 bits deep. Does this mean that the functions both use > longs (two byte numbers), AKA WRITE(data) should be passed a long, and READ > should return a long? That would depend on how the functions were implemented, but they certainly could use 14 bit numbers. > How do you insure that your reading and writing is not trashing real program > memory area? By being very careful what values you pass to the WRITE_PROGRAM_EEPROM instruction. > Is it wise to protect the lower end of the PIC's program > memory to prevent this, and use addresses in the upper end of the memory, or > is this neccesary? I'd hate to write over my program with a string of > temperature data. I wouldn't use memory protection for this. If your program is buggy enough to write over itself that is probably a good thing :-) Two other points: 1: remember that program eeprom has a much lower endurance than data eeprom 2: while writing program eeprom your program can be doing nothing else (everything is frozen) Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics