PDA

View Full Version : EEROM problems in 16F877A



BrianT
- 30th April 2007, 06:53
I have a system with a 12 way rotary switch. The switch position is read by the ADC and the result converted to a number 0 to 11. That switch position then generates an index to an array of 12 entries, each of 18 bytes, stored in the EEROM. The array first byte is "Valu" and the second byte is "Scale". The next 16 characters are a message to be displayed to the user for that switch position. The user can increment or decrement "Valu" and when he presses ENTER the new number for "Valu" is written to the EEROM.

I should be able to write a total of 18 characters including the 16 character message to every one of the twelve array locations but I get EEROM collision error messages for all the values where index/2 is an odd number. In these locations, I can only write a total of 17 characters to these locations.

When I run the program and display the 18 characters stored at each array location, every instance of Valu and of Scale are correct. The message strings however are only correct if index/2 is even. For all where index/2 is odd, the message starts with a different (stray) character.

Has anyone seen this before? Is there a problem in PBP 2.47? I seem to recall an upgrade/patch to PBP a few revisions ago to allow EEROM writing to odd locations. I have checked the Melabs site but can't find anything related to PBP 2.47.

The code is attached.

Cheers
Brian

Darrel Taylor
- 30th April 2007, 07:34
Hi Brian,

I think it's the dollar signs in your data statements.
They shoud be @ signs, like the rest of them.
<br>

mister_e
- 30th April 2007, 14:34
Or simply remove all of them + @ signs. Still possible to use Labels to point to the start address of the Message string you want. 'Embedded string in codespace' is another approach.

BrianT
- 1st May 2007, 02:52
Thanks for the replies. Amazing and annoying that I missed the very obvious $ instead of @ in some of the data statements. It compiles without any error message.

I can't put the text in code space until I change assemblers from PM to MPASM but that is probably not far off.

Cheers
Brian