Arduino for STM32

Green77 wrote: Sat Aug 20, 2022 2:58 pm I’m a real noob on this. And just eeprom seems to be really hard for me to understand

Pointer? I dont follow…

ag123 wrote: Sat Aug 20, 2022 3:27 pm 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 wrote: Sat Aug 20, 2022 9:22 pm 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.

 
 // 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