EEPROM failure vs TABLE use ?
- Thread starter manie
- Start date
Manie,
I think Technical is correct:-
Assuming the code is as per post #36 above, and as explained earlier, table or eeprom are interchanged in the setup part of your program then there is a coding issue.
Table reserves 256 bytes within the program space but eeprom is the same dedicated memory space that is used by the write command.
In the setup locations beginning at 0 thru to 255 are used.
in the case statement ( IdKey: ) writes are made to eeprom at location b0.
At a quick glance, I don't know what the value of b0 is but whatever it is at the the time the write takes place, that eeprom location will be written to which will overwrite the previously stored LCD data in the corresponding eeprom location.
Maybe table is the only option you have.
I think Technical is correct:-
Assuming the code is as per post #36 above, and as explained earlier, table or eeprom are interchanged in the setup part of your program then there is a coding issue.
Table reserves 256 bytes within the program space but eeprom is the same dedicated memory space that is used by the write command.
In the setup locations beginning at 0 thru to 255 are used.
in the case statement ( IdKey: ) writes are made to eeprom at location b0.
At a quick glance, I don't know what the value of b0 is but whatever it is at the the time the write takes place, that eeprom location will be written to which will overwrite the previously stored LCD data in the corresponding eeprom location.
Maybe table is the only option you have.
SilentScreamer
Senior Member
By corrupt he(or she?) means it loses the data that was originally stored in the location that is the same as the value as b20.
An example:
write 15,50
let b20 = 15
write b20,36
You "corrupt" the original value in location 15 with the value 36.
An example:
write 15,50
let b20 = 15
write b20,36
You "corrupt" the original value in location 15 with the value 36.
hippy
Ex-Staff (retired)
By "corrupt" Technical meant the WRITE may inadvertently change the value of an Eeprom location you are using elsewhere for some other reason so it will not be the value you expected to be there ( as in SilentScreamer's example ). Corrupt as in data damaged under program control, not faulty chip operation.
Agreed ! In Sub "IdKey" this could very well be a case of overwriting. The writes were a remnant and superfluous, removed the writes there, but have not tested again with data in EEPROM. I will test next week-end as I am busy installing the controller in the chicken-house. The above may be true for the 28x1 (LCD driver side). I will have to check with a fine toothed comb in the 40x1 controller side to see if this is also possible.
Believe me ! If that is the case I will be happy (case resolved then) and will beg the pardon of all concerned.
If variable b20 DID overwrite the locations, it just seems a bit funny still that the patterns displayed were almost always identical (triangles in various stances). B20 would have overwritten with 0 through 9 and maybe "#" and "*" which are the values allocated, but certainly what you are saying looks very possible. Wish I had more time to test (installation is 200Km away now, must wait for the weekend...) Thanks for all your inputs......
Believe me ! If that is the case I will be happy (case resolved then) and will beg the pardon of all concerned.
If variable b20 DID overwrite the locations, it just seems a bit funny still that the patterns displayed were almost always identical (triangles in various stances). B20 would have overwritten with 0 through 9 and maybe "#" and "*" which are the values allocated, but certainly what you are saying looks very possible. Wish I had more time to test (installation is 200Km away now, must wait for the weekend...) Thanks for all your inputs......
Values 0-9 may well all appear as the same triangle as they are not correct character values for ascii characters as used by the LCD.
Looks like BB in post #2 may have been correct after all!
Looks like BB in post #2 may have been correct after all!
No, not guilty. 
The bottom line is that this error happens with your PICAXE+code but with no-one else's. And it happen when you programme another PICAXE with your code.
And it happens on another of your PICAXEs with your code.
3 faulty PICAXEs? I think not.
Your code has some 'writes' in it which we can't see how they affect things.
Ergo.... according to Mr Spock, there is a 99.999% chance it is something you have overlooked. Put on your Deerstalker and get testing all those Write variables
When I saw those 'writes' I wondered why you would want to risk overwriting by having a variable as a <location> parameter?
The bottom line is that this error happens with your PICAXE+code but with no-one else's. And it happen when you programme another PICAXE with your code.
And it happens on another of your PICAXEs with your code.
3 faulty PICAXEs? I think not.
Your code has some 'writes' in it which we can't see how they affect things.
Ergo.... according to Mr Spock, there is a 99.999% chance it is something you have overlooked. Put on your Deerstalker and get testing all those Write variables
When I saw those 'writes' I wondered why you would want to risk overwriting by having a variable as a <location> parameter?
hippy
Ex-Staff (retired)
If you run the program under simulation, crank-up the generic value read by READADC for your key detector, you can clearly see the program overwriting the Eeprom. That may not be a real world test but shows the program is flawed and has the potential for corruption.
Your code is extremely hard to understand or follow. It's not clear what variables are being used for, what they hold or what their values mean. There are also too many cases of 'magic numbers' which are meaningless to anyone other than yourself; "if b18=88 then" etc.
One place where you can massively improve things is with respect to the 'readkey' and 'idkey' routines and the carrying around of some arbitrary word value. Make the two routines into one, use a 'gotKey' or similar byte variable for the result, return zero if no key pressed, an ASCII character of what that key means when pressed. Your ...
temw1=0
do until temw1>0 and temw1<510 'check for "#" pressed
gosub readkey
gosub idkey
pause 20
loop
can then become a much simpler and more understandable ...
Do
Gosub GetKey
Loop Until gotKey = "#"
Programming is a science in getting the right algorithms, interaction and timings but also an art. Aesthetics play an important part and you should aim to make code accessible to others. The pinnacle is writing code which others can follow and understand easily even when its intricacies may be well beyond their understanding. Do it right, and even someone unfamiliar with what the program is doing can find inconsistencies and flaws in reasoning behind the code which is a great aid to debugging and getting help.
Your code is extremely hard to understand or follow. It's not clear what variables are being used for, what they hold or what their values mean. There are also too many cases of 'magic numbers' which are meaningless to anyone other than yourself; "if b18=88 then" etc.
One place where you can massively improve things is with respect to the 'readkey' and 'idkey' routines and the carrying around of some arbitrary word value. Make the two routines into one, use a 'gotKey' or similar byte variable for the result, return zero if no key pressed, an ASCII character of what that key means when pressed. Your ...
temw1=0
do until temw1>0 and temw1<510 'check for "#" pressed
gosub readkey
gosub idkey
pause 20
loop
can then become a much simpler and more understandable ...
Do
Gosub GetKey
Loop Until gotKey = "#"
Programming is a science in getting the right algorithms, interaction and timings but also an art. Aesthetics play an important part and you should aim to make code accessible to others. The pinnacle is writing code which others can follow and understand easily even when its intricacies may be well beyond their understanding. Do it right, and even someone unfamiliar with what the program is doing can find inconsistencies and flaws in reasoning behind the code which is a great aid to debugging and getting help.
Last edited:
hippy
Ex-Staff (retired)
Don't feel bad about any code because it can always be better and it's rare anyone would do it exactly as anyone else would. I didn't men to be harsh if it came over that way. It takes years of practice to reach 'perfection' and someone will always still complain
Life's one long prototype. There's always improvement which can be made. Ripping it up and starting again based on previous experience is the way of the world.
Life's one long prototype. There's always improvement which can be made. Ripping it up and starting again based on previous experience is the way of the world.
Dippy: As said before, the writes were a remnant remaining and should NOT have been there at all, so the writes have been removed, I have to download the "corrected" program with the text loaded back into EEPROM and test. I can do that this weekend as the system is already "wall mounted" on site. Then I can let you know.... I'm sure the "write b0, xx" was the cause, but lets check and I'll report back. Hopefully everyone can rest assured then.
BeanieBots
Moderator
Can't wait to see if post #2 posted 28 minutes after your first question would have solved your problem!
Well, stranger things have happened at sea....
Then maybe we can rest assured that there is nothing wrong with the PIC.
Not that anyone else was really worried as only poor old Manie was having problems
Microchip can wipe the bead of sweat on their corporate foreheads.
(Just teasing).
Morals:
1. Never post anything more than 10 lines long as people tend not to read it.
2. If 10 people answer before poster gets back then he/she will only read the last one.
3. If there are a bunch of replies and it takes over the page then the poster will often only read the last page.
4. You can even see 'Old Lag' replies echoing things on the previous page...
5. I've got to over 10 lines....
Then maybe we can rest assured that there is nothing wrong with the PIC.
Not that anyone else was really worried as only poor old Manie was having problems
Microchip can wipe the bead of sweat on their corporate foreheads.
(Just teasing).
Morals:
1. Never post anything more than 10 lines long as people tend not to read it.
2. If 10 people answer before poster gets back then he/she will only read the last one.
3. If there are a bunch of replies and it takes over the page then the poster will often only read the last page.
4. You can even see 'Old Lag' replies echoing things on the previous page...
5. I've got to over 10 lines....
SilentScreamer
Senior Member
I read it at least, wasn't a complete waste
hippy
Ex-Staff (retired)
We do take ( looking for a not too strong word ) 'suggestions' that the PICAXE is not behaving as it should seriously and investigate the issues. Not least to confirm our, and PICAXE user's, confidence in the product; it can be highly damaging if an unwarranted reputation for unreliability or incorrect operation arises or, worse still, propogates.Not that anyone else was really worried as only poor old Manie was having problems
Microchip can wipe the bead of sweat on their corporate foreheads.
(Just teasing).
"We do take ( looking for a not too strong word ) 'suggestions' that the PICAXE is not behaving as it should seriously and investigate the issues.."
- of course. I would expect you to. Very tactful.
But a condition is "when programmed and used correctly"
Post #8
"BB, there are NO Write's in this program..."
- ah, mate, I'm only teasing. Just like the Lookout said to the Captain of the Titanic
Anyway manie, you'll have it tickety-boo soon. Great news. All the best.
- of course. I would expect you to. Very tactful.
But a condition is "when programmed and used correctly"
Post #8
"BB, there are NO Write's in this program..."
- ah, mate, I'm only teasing. Just like the Lookout said to the Captain of the Titanic
Anyway manie, you'll have it tickety-boo soon. Great news. All the best.
SilentScreamer
Senior Member
Personally I see it as an ideal example of how incredibly good your customer service is but others may see it differently.