Go Down

Topic: how to save memory on this function call (Read 115 times) previous topic - next topic



I am developing a graphical menu to drive a few banks of relays and want to save on memory space, the program uses 71% for global vaariables. I can use some help on this.

The menu is stored as an array of MenuItems, where each menuItem is a struct.
Code: [Select]

struct MenuItem {
  char text[15];
  byte bank;
  byte position;
  static byte length ;

To initialize the menu I use a function addItem().
Code: [Select]

void addItem(const String text, boolean status,  byte bank,  byte position) {
  byte n = MenuItem::length;
  text.toCharArray(item[n].text, STRLEN);
  item[n].bank = bank ;
  item[n].position = position ;
  MenuItem::length ++;

I call this function 24 times during setup, for example
Code: [Select]

  addItem("Wifi", false, 2, 4);
  addItem("USB", false, 1, 5);

For each call to addItem a String object is created that is copied to a char array in the function body. I think the String objects remains in memory long after the function call. Is that true? If so, do they live during setup() or during program life? Is there another, more efficient, way to pass the menutext to the function?


Is there any reason this menu structure can't live in flash? How much is constant and how much varies?

Also, why use String? If your menu structure expects a char array, why not just use those and rid yourself of the dynamic allocation issues usually associated with String?


Mar 15, 2019, 12:48 am Last Edit: Mar 15, 2019, 12:50 am by AswinFoobar
All of the menu structure is constant. The Menuitems array is initialized in gobal variable space. Its items are added using the addItem function during setup and the members of the structure never get a new value after that.
I don't know if they can be stored in flash.
I also don't know how to pass the text as a char array without creating the array before the function call and introducing a new variable to store the array. I would like to avoid the extra lines of code this brings.

BTW. The program uses 71% of data space tells the compiler. So there is no urgent need for extra space. But I thinks this code is inefficient.

Go Up