 |
 |
| View previous topic :: View next topic |
| Author |
Message |
MCUprogrammer
Joined: 08 Sep 2020
Posts: 221
|
| use of internal eeprom |
 Posted: Sun Jan 15, 2023 5:28 am |
 |
|
Hello
Again I am facing a problem. I am trying to save EepromVal value to internal eeprom. But I am having a problem.
In the program I added, if I compile the program and load it into the processor without assigning a value to the float EepromVal variable, the button and the + and - buttons do not increase or decrease the EepromVal value. However, if the float assigns EepromVal = 0.0, the value increases and decreases very smoothly with the +/- buttons. But this time it does not record to eeprom. What is the reason of this.
Also, even if I don't write 0 to the variable value you assigned in the global namespace, doesn't that mean 0? In standard C, static and global variables are initialized to 0. Auto-lived variables are initialized with a garbage value. Even using a variable with a garbage value causes undefined behavior. | Code: |
#include <18F45K22.h>
#device ADC=10
#FUSES NOWDT
#use delay(internal=64MHz)
#use fast_io(c)
#include <internal_eeprom.c>
#define OLED_FAST_DRAW
#include <math.h>
#include <SSD1306_UPDATED.c>
#define incBUTTON PIN_C0
#define minBUTTON PIN_C1
#define resBUTTON PIN_C2
char textBUF[9];
float EepromVal = 0.0;
void Print_Eeprom_To_Screen(void)
{
read_float_eeprom(0x00);
sprintf(textBUF, "%2.1f ",EepromVal);
textBUF[4] = '\0';
oled_text57(80,45, textBUF, 2, 1);
}
void main()
{
char Eeprom[]="Eeprom:";
set_tris_c(0x1F);
oled_init();
oled_clearScreen();
oled_rect(1, 1,127,63, 0, 1);
oled_line(0,22,127,22,1);
oled_line(0,42,127,42,1);
oled_text57(5,45,Eeprom,2, 1);
//write_float_eeprom(0x00,EepromVal) ;
Print_Eeprom_To_Screen();
while(TRUE)
{
if(input(incBUTTON)) {
EepromVal+=.1;
write_float_eeprom(0x00,EepromVal) ;
Print_Eeprom_To_Screen();
}
if(input(minBUTTON)) {
EepromVal-=.1;
write_float_eeprom(0x00,EepromVal) ;
Print_Eeprom_To_Screen();
}
if(input(resBUTTON)){
delay_ms(20);
while(input(resBUTTON));
reset_cpu();
}
oled_flush();
}
}
|
_________________
Best Regards...
MCUprogrammer
_______________________________
Work Hard |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Sun Jan 15, 2023 5:54 am |
|
|
An empty (erased) EEPROM cell contains 0xFF. The value 0xFFFFFFFF
is defines as 'NAN' (not a number). So when you first program the chip
the EEPROM read will not return an accepted number.
You can include a default number into your code, by assigning a value to
the EEPROM using #ROM. Look at the internal define for the
EEPROM_ADDRESS. This will be written back when the chip is reprogrammed.
Alternatively turn off erasing the EEPROM in your programmer, then the
values here will be retained when you reprogram. |
|
|
MCUprogrammer
Joined: 08 Sep 2020
Posts: 221
|
|
| Posted: Sun Jan 15, 2023 6:46 am |
|
|
Ok, don't return a known number. But when I press the + button, I thinks that the value should increase. There is no action. Also using #ROM I can start the eeprom from yes 0 or any value I want. I've tried. When I start it as 0, the problem is solved. But why do we need such a thing? Why doesn't the increment operation succeed without initializing it with a value. or registration to eeprom does not occur
Normally how should the sequence be to use the internal eeprom.
For example.
1-) Define the variable to be registered in the eeprom.
2-) Use the eeprom writing function suitable for that type.
3-) use the read function wherever you want to read.
Is it true?
How do I turn this off?
"Alternatively turn off erasing the EEPROM in your programmer, then the values here will be retained when you reprogram."
The programmer I use is the ICD-U80 device.
_________________
Best Regards...
MCUprogrammer
_______________________________
Work Hard |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Sun Jan 15, 2023 7:12 am |
|
|
Because the existing number is so large that adding 0.1 makes no difference
to it. A FP number only has 6.5 decimal places. Now visualise you have:
1
Add 0.1 to this and it goes to 1.1
However have
10000000
Now add 0.1 to it. What happens?. It would technically become 10000000.1
but the floating point representation is only storing 6.5 decimals. So it
remains 10000000. |
|
|
MCUprogrammer
Joined: 08 Sep 2020
Posts: 221
|
|
| Posted: Sun Jan 15, 2023 7:44 am |
|
|
 okay. I understand. Thank you very much. Then if my variable was of type int I wouldn't need to use #ROM. But do you think using #ROM is a better option?
I also asked something based on our previous mail. How do I turn this off?
| Quote: |
Alternatively turn off erasing the EEPROM in your programmer, then the
values here will be retained when you reprogram. |
_________________
Best Regards...
MCUprogrammer
_______________________________
Work Hard |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Sun Jan 15, 2023 8:23 am |
|
|
Depends on the program used to control your programmer.
If you look in CCSLoad (the CCS control program), it has:
Top right corner of window, 'options'. Hit the expand button for this and
you get a window with options to tick 'Program memory', 'Data EE',
'Config bits'. Turn Data EE off, and select Erase mode (right of this), to
'erase only blocks in hex file'. Then so long as you do not include a #ROM
pointing to the EEPROM, it's contents will be left unchanged. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Sun Jan 15, 2023 9:15 am |
|
|
just a comment....
PICs are well known to NOT do 'floating point math' very well. FPM consumes a lot of code space and time to execute, giving less precise results compared to 'scaled integers'.
It may be worth exploring the use of 'scaled integers', depending on program requirements. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Mon Jan 16, 2023 4:16 am |
|
|
Also, if you have an int32 for example, the default value from the erased
EEPROM for this will be 4294967295. If you are using a button to count
this down in 1's, you'd need several weeks to count this down to a sensible
value.
Having the code detect there is no legitimate value there and set a
starting point, or using #ROM to fill in a starting point, is essential in
both cases.
My normal method is to have the value stored as a structure, with a
'legit_value' flag, which is something like AA55. Then if when the value
is read, if this flag is not found, have the code fill in default values for
all the numbers stored in the EEPROM. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
