increase usable memory (macro)

[dynatron832]

hi
iam currently trying around with qmk/vial.
some of the features i want to use seems to working fine in testing. others not so much.
but what i realy cant get to work is a larger memory size for macro usable by vial.

iam using a ST32F103 a bluepill. and this one should have 128kb of flash memory.
the persitant memory is realized with an "fake" eeprom driver into the flash intself. so far so good.

and vial show´s me a aviable macro count of around 3000. but no matter what i try is working.

add an i2c eeprom end´s in boot error. no matter what chip i chose or what settings i use. it end´s in a compile error or the chip wont boot at all.
next i had a look on was spi. but as i try this it wont even compile with spi driver enabled. no matter how.

the only thing leaves is the 128kb flash memory. if the firmware leaves space in the flash then i can use this to expand the emulated eeprom size ? so qmk/vial can use more space of the flash for the eeprom emulating.

but also this dont work for me. no matter what i try changes anything.

so my question. what settings are needed to change the emu eeprom size so that vial can use more of the free flash space ?

thx for help.

[xyzz]

To set up a larger emulated EEPROM size, add this to your config.h:

#define WEAR_LEVELING_BACKING_SIZE 16384
#define WEAR_LEVELING_LOGICAL_SIZE 8192

You can modify WEAR_LEVELING_BACKING_SIZE and WEAR_LEVELING_LOGICAL_SIZE as you see fit. The value of WEAR_LEVELING_BACKING_SIZE is how much space it will take on the flash, and WEAR_LEVELING_LOGICAL_SIZE is the amount of space that will be available to emulated EEPROM. A ratio of 2x or more is generally recommended for good flash wear life time.

Note that in addition to the space used on the flash, it will also utilize additional WEAR_LEVELING_LOGICAL_SIZE bytes of RAM. So you should set it up depending on how much SRAM memory the MCU has.

Generally an external SPI/I2C eeprom is not recommended for use with Vial because the QMK driver will perform a read transaction on every key press (and often multiple).

[dynatron832]

thx that works very well.

[AngelontheRoad]

I seems to have a similar problem.

I tried to disable some features and the add macro mentioned above in config.h. The firmware size decreased but the memory used by macros shows at the bottom of Vial macros page unchanged (It was always 143).

what should I do to increase the memory used by macros?

Best regards.

[dynatron832]

you have both parameters
#define WEAR_LEVELING_BACKING_SIZE
and
#define WEAR_LEVELING_LOGICAL_SIZE
in the main config.h ? not the /keymaps/vial/ config.h

and you have to chose the right values. BACKING_SIZE is the size of storage should be used. and LOGICAL_SIZE should be half of the BACKING_SIZE so the controller isnt writing over the same flash adresses over and over again.

[AngelontheRoad]

Yes, they were added in the main config.h, but the size is not right...

#pragma once
#define RGBLIGHT_DEFAULT_VAL 125
#define RGBLIGHT_LAYERS 6
#define DYNAMIC_KEYMAP_LAYER_COUNT 6
#define WEAR_LEVELING_BACKING_SIZE 16384
#define WEAR_LEVELING_LOGICAL_SIZE 8192

I apologize that I'm ignorant of chip. I asked the manufacturer for the chip information. And the storage is:

32 KB self-programming Flash program memory, 2.5 KB SRAM, 1 KB EEPROM

So which value should be chosen for BACKING_SIZE?

Thanks for your help:)

[dynatron832]

this sounds like a ATmega32U4. i had my first QMK try´s with this one. the basic features worked but soon some hardware issues appered and i switched to a bluepill with a STM32. the ATmega has a real EEPROM which is used by QMK. the bluepill has no real EEPROM but there it is possible to write into the flash storage with the running programm. QMK is "emulating" the EEPROM on a STM32.
so the Atmega32U4 is bound to it´s tiny 1KB EEPROM. technically it would be possible to connect a external i2c/spi storage chip and QMK has support for those. but even with an STM32 i never got it running with this.

i would suggest you are switching to a STM32 if you need more space for flexible macros with vial. or even a blackpill with up to 512KB. take a look.

[PeterMortensen]

even with an STM32, I never got it running with this

Despite the move to data-driven configuration (fields "backing_size" and "logical_size" in file info.json), Vial still seems to be using DYNAMIC_KEYMAP_MACRO_EEPROM_SIZE.

After compiling the latest source and flashing on a Keychron V6, the Vial client shows "Memory used by macros: 16 / 512" in tab "Macros".

Changing DYNAMIC_KEYMAP_MACRO_EEPROM_SIZE had an effect on the size of macros (512 bytes) on a Keychron V6. I could change the value to 2048 (2 KB), and the Vial client now shows "Memory used by macros: 16 / 2048" in tab "Macros"

I didn't test WEAR_LEVELING_BACKING_SIZE and WEAR_LEVELING_LOGICAL_SIZE.

[PeterMortensen]

the ATmega32U4 is bound to its tiny 1 KB EEPROM. Technically it would be possible to connect an external I²C/SPI storage chip and QMK has support for those.

The documentation says (my emphasis):

All wear-leveling drivers require an amount of RAM equivalent to the selected logical EEPROM size. Increasing the size to 32 kB of EEPROM requires 32 kB of RAM, which a significant number of microcontrollers simply do not have

So even with excess flash memory (that is also a stretch), it will not help much for the AVR microcontrollers. They do not have enough RAM for this purpose. The ATmega32U4 has a total of 2.5 kB RAM. I am not sure how much of that QMK (typically) uses.

Presumably, the same applies for serial flash memory on external chips.