Blue pill with external EEPROM

[GonzoG]

I think that the problem is with pointers you use do get data from eeprom.

[Green77]

I’m a real noob on this. And just eeprom seems to be really hard for me to understand

Pointer? I dont follow…

Thanks for your help.

BR// Daniel

[ag123]

if your storage needs are modest, and your sketch (the compiled bin file) is *small*, you may want to try using a stm32 chip with lots of flash like 256k.
things like stm32f401ccu may be 'adequate'
https://www.st.com/en/microcontrollers- ... 401cc.html
of course, bigger chips like stm32f401re or f411re
https://www.st.com/en/microcontrollers- ... 401re.html
https://www.st.com/en/microcontrollers- ... 411re.html
would be even better, they have 512k flash and a very comfortable cache of sram (128k i'd think)

the RE chips are on the Nucleo NUCLEO-F401RE and NUCLEO-F411RE boards
https://www.st.com/en/evaluation-tools/ ... 401re.html
https://www.st.com/en/evaluation-tools/ ... 411re.html

Then that f401ccu is found on those 'F401CCU blackpill' boards. But it is better to check and get a reliable one, it seemed there are quite a few different f401c(?) 'pill' boards floating around in the wild. (e.g. on those AliX, ebay, amazon markets). This is less reliable if you can't get a 'trustable' vendor. WeAct seemed 'ok' but that check for the 'clones' they looked alike, and mostly works the same, but those "online flea" markets it is hard to tell it until you receive it.

A thing about using on chip flash is that often, it seemed the flash erase needs to erase nearly *half* of it. e.g. for 256k it erase 128k of the 'upper' half.
then for 512k it erase 256k ! (well, I'm not sure, check the specs and manuals).
this means if you have a "fat" bin binary to install, you risk erasing itself.
But if your sketch binary is after all *small* and with those chips with lots of flash, the "EEPROM" library may be useful for it :
https://github.com/stm32duino/Arduino_C ... ies/EEPROM
it is there bundled with the core.
imho, it would still be necessary to review the library codes and lookup the manuals to see that it is "right" section, given the large area bulk erase mentioned above.
btw, some thing about "flash" technology, when the flash is erased, every thing is '1', i.e. all the bytes are 0xff.
when you 'write' something there, you turn those bits that you want to '0', so in theory, you could keep writing until it is all used up then do a bulk erase and restart again. there are some 'flash file system' that does some of those tricks.

some would not recommend that as flash memory has limited re-write cycles. But the convenience is "attractive", it is that same chip and nothing else, no other 'extra' connections etc, everything on a single chip. And unlike external flash, that is *memory*, your sketch can directly reference and read from it, unlike external devices which normally needs to read into a buffer.

[GonzoG]

I’m a real noob on this. And just eeprom seems to be really hard for me to understand

Pointer? I dont follow…

All those variables with *, those are pointers.

[Green77]

Hmm, got it, But prog works perfect on Arduino Due. Can’t understand why it wont work here when in download ok on stm32…

BR//Daniel

[GonzoG]

Because STM32duino is not an Arduino. It's similar, mostly compatible, but it's not the same.
There are differences in data types and how they behave, in some math functions, etc. It's the difference between C++ and Arduino.

[Green77]

if your storage needs are modest, and your sketch (the compiled bin file) is *small*, you may want to try using a stm32 chip with lots of flash like 256k.
things like stm32f401ccu may be 'adequate'
https://www.st.com/en/microcontrollers- ... 401cc.html
of course, bigger chips like stm32f401re or f411re
https://www.st.com/en/microcontrollers- ... 401re.html
https://www.st.com/en/microcontrollers- ... 411re.html
would be even better, they have 512k flash and a very comfortable cache of sram (128k i'd think)

the RE chips are on the Nucleo NUCLEO-F401RE and NUCLEO-F411RE boards
https://www.st.com/en/evaluation-tools/ ... 401re.html
https://www.st.com/en/evaluation-tools/ ... 411re.html

Then that f401ccu is found on those 'F401CCU blackpill' boards. But it is better to check and get a reliable one, it seemed there are quite a few different f401c(?) 'pill' boards floating around in the wild. (e.g. on those AliX, ebay, amazon markets). This is less reliable if you can't get a 'trustable' vendor. WeAct seemed 'ok' but that check for the 'clones' they looked alike, and mostly works the same, but those "online flea" markets it is hard to tell it until you receive it.

A thing about using on chip flash is that often, it seemed the flash erase needs to erase nearly *half* of it. e.g. for 256k it erase 128k of the 'upper' half.
then for 512k it erase 256k ! (well, I'm not sure, check the specs and manuals).
this means if you have a "fat" bin binary to install, you risk erasing itself.
But if your sketch binary is after all *small* and with those chips with lots of flash, the "EEPROM" library may be useful for it :
https://github.com/stm32duino/Arduino_C ... ies/EEPROM
it is there bundled with the core.
imho, it would still be necessary to review the library codes and lookup the manuals to see that it is "right" section, given the large area bulk erase mentioned above.
btw, some thing about "flash" technology, when the flash is erased, every thing is '1', i.e. all the bytes are 0xff.
when you 'write' something there, you turn those bits that you want to '0', so in theory, you could keep writing until it is all used up then do a bulk erase and restart again. there are some 'flash file system' that does some of those tricks.

some would not recommend that as flash memory has limited re-write cycles. But the convenience is "attractive", it is that same chip and nothing else, no other 'extra' connections etc, everything on a single chip. And unlike external flash, that is *memory*, your sketch can directly reference and read from it, unlike external devices which normally needs to read into a buffer.

Thanks, program is almost at full memory so i don't want to use flash memory.

BR// Daniel

[Green77]

Because STM32duino is not an Arduino. It's similar, mostly compatible, but it's not the same.
There are differences in data types and how they behave, in some math functions, etc. It's the difference between C++ and Arduino.

Crap, i was hooping that i missed a line or two when i made the convert from Due to STM32...

So, the pointers...

When save the program will save a byte, is this the pointer?

Code: Select all

 
 // For Settings1
    eeAddress=eeAddressS;                // Address of Settings1
    Settings1.variable=1;         // Store default preamp mode setting to EEPROM
    Settings1.preamp_def_vol=100;  // Store default preamp volume setting to EEPROM
    Settings1.backlight=10;       // Store default TFT backlight setting to EEPROM
    myEEPROM.write(eeAddress, (byte *)&Settings1, sizeof(DAC_Settings));    // write to EEPROM
 
 [Code /] 
    
 Same byte get loaded during startup..?
 [Code] 
   // Load Settings1 from EEPROM
  eeAddress = eeAddressS;
  byte *pSettings = (byte*)&Settings1;
  myEEPROM.read(eeAddress, pSettings, sizeof(DAC_Settings));
 [Code /] 
 
 BR// Daniel

[GonzoG]

Every time when there * before a variable name or after data type name, it means that this is a pointer.
I think that problem might be with casting pointers to a byte.

Code: Select all

(byte *)

Casting is a way of telling program to treat data as different type then variable it's stored.


The whore EEPROM reading is wrong.
1. pSettings is a pointer to a byte type variable, but you read there a whole structure (DAC_Settings) which needs at least 5 bytes.
It should look like this:

Code: Select all

  eeAddress = eeAddressS;
  DAC_Settings *pSettings = &Settings1;
  myEEPROM.read(eeAddress, pSettings, sizeof(DAC_Settings));

Same thing here:

Code: Select all

eeAddress = eeAddress1;
byte *pData = (byte*)&Input[0];
ee.readBlock(eeAddress, pData, sizeof(DAC_Input));

Should be like:

Code: Select all

eeAddress = eeAddress1;
DAC_Input *pData = &Input[0];
ee.readBlock(eeAddress, pData, sizeof(DAC_Input));

And then again with input 2, 3 and 4.

[Green77]

Thanks.
I will update soon and i get back.

BR// Daniel