⚙ [TO DO] Co chcielibyście jeszcze dodać do GUI-Generic? ☕

[krycha88]

Trafiłeś w sedno

po wycofaniu tych dwóch zmian:
https://github.com/krycha88/GUI-Generic ... 16e1456db3
oraz
https://github.com/krycha88/GUI-Generic ... e32de3bb99

rozmiar na teście 503KB

EDIT: A jednak się pomyliłem i nie na ten plik się popatrzyłem

[klew]

Trafiłeś w sedno
rozmiar na teście 503KB

EDIT: A jednak się pomyliłem i nie na ten plik się popatrzyłem

Już się dziwiłem co tam takiego mogło się zminić, że kod zmalał

[klew]

Mógłbyś podać wersje/rewizje supla-device, które porównujesz między tymi kompilacjami?

[krycha88]

A czy problemem nie są takie miejsca:
https://github.com/SUPLA/supla-device/b ... rs.cpp#L42
??

na produkcji używam biblioteki z przed 4 miesięcy:
https://github.com/krycha88/GUI-Generic ... uplaDevice

na teście wgrałem dzisiaj najnowszą supla-device

[Goral64]

A czy problemem nie są takie miejsca:
https://github.com/SUPLA/supla-device/b ... rs.cpp#L42
??

Oj zapewne. Najlepiej strosować F(string) w Arduino IDE aby zminimalizować miejsce przeznaczone na stringi w kodzie programu.

The F() macro does two things:

uses PSTR to ensure that the literal string is stored in flash memory (the code space rather than the data space). However, PSTR("some string") cannot be printed because it would receive a simple char * which represents a base address of the string stored in flash. Dereferencing that pointer would access some random characters from the same address in data. Which is why F() also...

casts the result of PSTR() to __FlashStringHelper*. Functions such as print and println are overloaded so that, on receiving a __FlashStringHelper* argument, they correctly dereference the characters in the flash memory.

[klew]

Wziąłem jakiś przykładowy program.

Binarka zbudowana na bibliotece z aktualnego GG:
414453

Na nowej bibliotece bez logów, bez certyfikatów, bez serwera i konfigu
456137

Na nowej z logami:
462397

Dodanie certyfikatów
464781

Dodanie little fs config
474217

Dodanie webserver
508101

Najbardziej zastanawia mnie czemu w tym pierwszym kroku jest taki duży wzrost, bo pozostałe są raczej uzasadnione - dodawane są nowe klasy z dużą ilością danych (certyfikaty, html, css) oraz dodatkowe komponenty/biblioteki są dokładane (little fs, esp server)

[klew]

A czy problemem nie są takie miejsca:
https://github.com/SUPLA/supla-device/b ... rs.cpp#L42
??

Oj zapewne. Najlepiej strosować F(string) w Arduino IDE aby zminimalizować miejsce przeznaczone na stringi w kodzie programu.

F(string) oszczędza wyłącznie pamięć RAM i nie ma większego wpływu na wielkość binarki.
Nowe kompilatory dla ESP automatycznie robią to co robi makro F() dla wszystkiego co jest "const char". Stąd nie bawiłem się w dodawanie tych F() do kodu HTML, bo nie miało to wypływu na ilość RAM-u.

Poza tym, ten kod html jak nie jest używany w programie, to kompilator to wycina. Możecie sobie spróbować skompilować jakiś program, a następnie wyrzucić ten plik protocol_parameters.cpp - kompilacja przejdzie, rozmiar binarki będzie identyczny.

[krycha88]

Ja w GG nie korzystam z LittleFS a ze starego spiffs. Więc może dodanie już samej biblioteki do kompilacji tyle zajmuje?

[klew]

Ja w GG nie korzystam z LittleFS a ze starego spiffs. Więc może dodanie już samej biblioteki do kompilacji tyle zajmuje?

Coś tu jest

Bez pliku little fs config cpp
472621

Z plikiem little fs config cpp, ale bez użycia w kodzie
498665

[krycha88]

Kiedyś jak próbowałem zmniejszyć rozmiar binarki to o dziwo ale konstrukcje typu
const char test[] PROGMEM = "test"
czy
#define test "test"
pomimo, że nie było nigdzie wykorzystane powiększało rozmiar.