Size of build too large to fit into 1MB about espeasy HOT 18 CLOSED

We could add a header file that defines a macro name for every plugin file, and have the plugin contents surrounded by an #ifdef. For instance for _P002_ADC.ino:

#include "enabled_plugins.h"
#ifdef _POO2_ADC
...
#endif

and in enabled_plugins.h:
// #define _P001_Switch
#define _POO2_ADC
...

Then we could use a program (a wizard) that takes the information from Plugin_sizes.txt and displays a menu choice to the user. When we additionally add the dependencies then this could work like a charm (or e.g., a bit like the linux kernel configuration)...

And fantastic work. I still have to understand the different types of RAM and their limits.

from espeasy.

just delete plugins you do not need (everything with _P*), you can even delete unneeded controllers (_C*)....

from espeasy.

Ok, works. Thank you...

Should we have a special build target that e.g., uses a configuration file to decide which plugins should be included?

from espeasy.

yes we should, we already have defines for dev/test and normal plugins.

we also should make a selection of 'minimal' plugins, that we want in the 8285 version.

from espeasy.

ideally we would have some sort of "wizard" which allows the user to select which plugins to include in the firmware... ...in a future far far away :)

from espeasy.

just wrote a memory analyser that shows us the memory usage per plugin (ram iram and rom).

from espeasy.

👍

from espeasy.

The results are here: https://github.com/letscontrolit/ESPEasy/blob/mega/dist/Plugin_sizes.txt

Especially the IRAM usage is a problem currently. Without any plugins we only have around 2k left. Some plugins with ISR's need to use some IRAM. I'll see what i can do to reduce that first.

from espeasy.

from espeasy.

the main problem i see with "customized" build like @jbaumann describes it, is how do we get a "deploy able" build environment to the user?

from espeasy.

Wouldn't it be three steps?

1. Implement a mechanism that allows to turn on and off the build of specific plugins.
2. Create a wizard for this mechanism that can be used when building on your own computer.
3. Create a web application (like https://nodemcu-build.com/) that allows to build a customized version for people who do not want to build themselves.

The complexity of using the mechanism drops with each step...

from espeasy.

@psy0rz how do i run this memory analyzer?? ...you are developing on a *nix like system? ...is it possible the path things are wrong on a windows system?

from espeasy.

currently it needs the git and platformio commandline programs.

i just hacked it together quickly without worrying about other operating systems too much.

in linux you have to start it with the path to the correct objdump tool that is part of the platformio toolkit:

$ ./memanalyzer.py /home/psy/.platformio/packages/toolchain-xtensa/bin/xtensa-lx106-elf-objdump 

to make things easier i can make it a part of travis, so that you can watch the travis output for the results. (you would have to do a pull request first)

from espeasy.

ill try to get a buildservice like nodemcu-build.com running.

from espeasy.

Hi,

I have written a small wizard in Java, but I would need the max values for 1M and 4M configurations (assuming the 8285 is the same as a 8266 with 1M). @psy0rz could you provide me with the values for the different categories listed in the output from your memanalyzer?

Cheers, Joachim

from espeasy.

Hi,
if you want to play with the program I can either send it to you or append here.

Later on, when I have time, I will put it on Github. @psy0rz, I still need the correct values for the memory limits...

Cheers, Joachim
PS: It now produces a correct header file, examines the plugin files in the changeable source directory, is configurable using a YAML file, highlights the changes etc.

from espeasy.

We're now also building firmware for the 8285 by default. (called normal_8285.bin )

So this bug is fixed, correct?

from espeasy.

Yes, I think so.

from espeasy.