Aktualizacje oprogramowania [bramka ZigBee]

[vajera]

Po cichu liczyłem na "podaję hasło - OKOŃ"

Ad rem

Prawie od samego początku w pliku z2s_devices_database.h zdefiniowane są 2 duże tabele:

• Z2S_DEVICES_DESC (4080 B) przechowuje tzw. opisy urządzeń, czyli liczbę i rodzaj klastrów:

Code: Select all

static z2s_device_desc_t Z2S_DEVICES_DESC[] PROGMEM [[maybe_unused]] = {
  
  { .z2s_device_desc_id = Z2S_DEVICE_DESC_TEMPHUMIDITY_SENSOR, .z2s_device_clusters_count = 3, .z2s_device_clusters =
    { ESP_ZB_ZCL_CLUSTER_ID_POWER_CONFIG, 
      ESP_ZB_ZCL_CLUSTER_ID_TEMP_MEASUREMENT,
      ESP_ZB_ZCL_CLUSTER_ID_REL_HUMIDITY_MEASUREMENT }},

  { .z2s_device_desc_id = Z2S_DEVICE_DESC_TEMPHUMIDITY_SENSOR_1, .z2s_device_clusters_count = 3, .z2s_device_clusters =
    { ESP_ZB_ZCL_CLUSTER_ID_POWER_CONFIG,
      ESP_ZB_ZCL_CLUSTER_ID_TEMP_MEASUREMENT,
      ESP_ZB_ZCL_CLUSTER_ID_REL_HUMIDITY_MEASUREMENT }}, ......

• Z2S_DEVICES_LIST (34 440 B) zawiera definicje samych urządzeń:

Code: Select all

static z2s_device_entity_t Z2S_DEVICES_LIST[] PROGMEM = { 
  
  { .manufacturer_name = "_TZ3000_akqdg6g7", .model_name = "TS0201", 
    .z2s_device_desc_id = Z2S_DEVICE_DESC_TEMPHUMIDITY_SENSOR, .z2s_device_endpoints_count = 1},

  { .manufacturer_name = "_TZ3000_dowj6gyi", .model_name = "TS0201", 
    .z2s_device_desc_id = Z2S_DEVICE_DESC_TEMPHUMIDITY_SENSOR, .z2s_device_endpoints_count = 1},

  { .manufacturer_name = "Xiaomi", .model_name = "LYWSD03MMC-z", 
    .z2s_device_desc_id = Z2S_DEVICE_DESC_TEMPHUMIDITY_SENSOR_1, .z2s_device_endpoints_count = 1},

Na oko wszystko wygląda OK a przynajmniej tak mi się wydawało - dyrektywa PROGMEM nakazuje na odczyt danych bezpośrednio z pamięci FLASH, więc tabele nie zużywają cennej pamięci RAM.

Niestety wychodzi na to, że:

"You know nothing, Jon Snow"

Niewinna zmiana z:

Code: Select all

static z2s_device_entity_t Z2S_DEVICES_LIST[] PROGMEM

na:

Code: Select all

static const z2s_device_entity_t Z2S_DEVICES_LIST[] PROGMEM

i 35K RAMu odzyskane - a przecież ta tabela rośnie z każdym nowym urządzeniem...

[Zibi_007]

Po cichu liczyłem na "podaję hasło - OKOŃ"

Nie ma okonia, Miecugowa zresztą też już nie

[...]

i 35K RAMu odzyskane - a przecież ta tabela rośnie z każdym nowym urządzeniem...

To zmień jeszcze wszędzie gdzie się da int32 na int16 i może też parę kilo się zyska...

[vajera]

Nie ma okonia, Miecugowa zresztą też już nie
[...]

A teraz Joanna K...;(

To zmień jeszcze wszędzie gdzie się da int32 na int16 i może też parę kilo się zyska...

Z int32 raczej nie szalałem, tutaj wielkich oszczędności nie będzie - niektóre dane koduję nawet na poszczególnych bitach, jak za dawnych czasów .
Mam jeszcze poważnego kandydata w postaci tabeli kanałów - aktualnie ma ona 16 KB, bo jest zdefiniowana na sztywno - 128 rekordów (MAX_CHANNELS). W praktyce mało kto ma więcej niż 50-60 kanałów (tak zakładam), więc gdyby zrobić ją dynamiczną to można urwać 8-10 KB, ale to wymaga już sporych zmian w kodzie, więc chyba poczekam na kolejny kryzys RAMu

[Zibi_007]

A teraz Joanna K...;(

Byłem na Hrabi pod koniec maja zeszłego roku w Krakowie (symfonicznie). Niesamowite przeżycie, warto było. W tym roku liczyłem na jakąś powtórkę, a tu takie wieści Choć o chorobie mówiło się już od jakiegoś czasu, to nie myślałem, że to takie poważne...

@vajera - Przepraszam!!! Daj mi przeprosić! Czemu nie dajesz mi przeprosić?

Mam jeszcze poważnego kandydata w postaci tabeli kanałów - aktualnie ma ona 16 KB, bo jest zdefiniowana na sztywno - 128 rekordów (MAX_CHANNELS). W praktyce mało kto ma więcej niż 50-60 kanałów (tak zakładam), więc gdyby zrobić ją dynamiczną to można urwać 8-10 KB, ale to wymaga już sporych zmian w kodzie, więc chyba poczekam na kolejny kryzys RAMu

Nawet, jak robiłem testy i sprowałem z bramką ponad 20 urządzeń, to z kanałami nigdy nie doszedłem do 40. Więcej i tak będzie ciężko tej bramce pociągnąć. Jakby to było samo Zigbee, to może, ale tu jest jeszcze SD.

Proponuję obciąć na stałe do 64, ale wcześniej możemy zrobić ankietę ile maksymalnie ktoś miał kanałów. Ja nie dobiłem do 40, a blisko takiej ilości bramka wyraźnie dostawała czkawki...

[klew]

W esp-idf (a w Arduino to też leci na esp-idf), PROGMEM nie jest używany.
Ogólnie static consty są przechowywane we flashu i nie są kopiowane do RAMu (co już zauważyłeś).

Natomiast ta struktura nadal traci dużo pamięci. Tak na szybko:
Ustawienie uint8_t i za nim uint32_t powoduje że tracisz 3 B na paddingu.
Zamiast char[33] możes zdać const char * i incicjalizować literałami "_nazwa_producenta".
Wtedy zamiast 33 B (a właściwie zamiast 36 B - po dochodzi padding), zużywasz 4 B na wskaźnik na napis + długść samego napisu (które z reguły mają chyba połowę tej długości). Do tego jeśli coś się powtórzy, to kompilator powinien tylko raz ten napis dodać do flasha.

Dalej, te Z2S_DEVICE_DESC_ aktualnie używają uint16_t (liczby w stylu 0x2004). Nigdzie nie używasz liczb wykraczających poza uint16, a w tablicy masz uint32_t - to masz w tablicy oraz w tablicy endpointów.

Wszystkie te z2s_device_endpoints są numerowane 1, 2, 3, ... - po co trzymać te numery, skoro zawsze numeracja idzie po kolei?

MAX_BOUND_ENDPOINTS masz ustawione na 8, a używasz max 4. Jak będziesz gdzieś potrzebował 5, to wtedy to można zmienić . Ewentualnie można na te endpointy wymyślić bardziej optymalne przechowywanie, bo obecnie tam z ~10 urządzeń z całej tabeli tego używa.

No i ogólnie można zmienić padding/upakowanie, aby wstawiać co 1 B dane. Ale z tym ostrożnie, bo to potrafi generować bardzo dziwne crashe. Bezpieczniej ułożyć dane z głową, czyli to co zajmuje po 1B dać koło siebie, itd.

[vajera]

Byłem na Hrabi pod koniec maja zeszłego roku w Krakowie (symfonicznie). Niesamowite przeżycie, warto było. W tym roku liczyłem na jakąś powtórkę, a tu takie wieści Choć o chorobie mówiło się już od jakiegoś czasu, to nie myślałem, że to takie poważne...

@vajera - Przepraszam!!! Daj mi przeprosić! Czemu nie dajesz mi przeprosić?

Teraz będę wybaczał! Wybaczam! RIP JK

Nawet, jak robiłem testy i sprowałem z bramką ponad 20 urządzeń, to z kanałami nigdy nie doszedłem do 40. Więcej i tak będzie ciężko tej bramce pociągnąć. Jakby to było samo Zigbee, to może, ale tu jest jeszcze SD.

Proponuję obciąć na stałe do 64, ale wcześniej możemy zrobić ankietę ile maksymalnie ktoś miał kanałów. Ja nie dobiłem do 40, a blisko takiej ilości bramka wyraźnie dostawała czkawki...

4 przyciski 4x3 i mamy 48 Niemniej 64 rzeczywiście wydaje się rozsądną granicą, niezależnie od rodzaju kanału. W przypadku tych bardziej rozbudowanych (HVAC, RELAY+EM) już 8 - 10 może mocno obciążać bramkę. Z drugiej strony natywne urządzenia Supla mają zwykle 1-3 kanały/ESP32, więc nie ma co narzekać

[vajera]

W esp-idf (a w Arduino to też leci na esp-idf), PROGMEM nie jest używany.
Ogólnie static consty są przechowywane we flashu i nie są kopiowane do RAMu (co już zauważyłeś).

Natomiast ta struktura nadal traci dużo pamięci. Tak na szybko:
Ustawienie uint8_t i za nim uint32_t powoduje że tracisz 3 B na paddingu.
Zamiast char[33] możes zdać const char * i incicjalizować literałami "_nazwa_producenta".
Wtedy zamiast 33 B (a właściwie zamiast 36 B - po dochodzi padding), zużywasz 4 B na wskaźnik na napis + długść samego napisu (które z reguły mają chyba połowę tej długości). Do tego jeśli coś się powtórzy, to kompilator powinien tylko raz ten napis dodać do flasha.

Dalej, te Z2S_DEVICE_DESC_ aktualnie używają uint16_t (liczby w stylu 0x2004). Nigdzie nie używasz liczb wykraczających poza uint16, a w tablicy masz uint32_t - to masz w tablicy oraz w tablicy endpointów.

Wszystkie te z2s_device_endpoints są numerowane 1, 2, 3, ... - po co trzymać te numery, skoro zawsze numeracja idzie po kolei?

MAX_BOUND_ENDPOINTS masz ustawione na 8, a używasz max 4. Jak będziesz gdzieś potrzebował 5, to wtedy to można zmienić . Ewentualnie można na te endpointy wymyślić bardziej optymalne przechowywanie, bo obecnie tam z ~10 urządzeń z całej tabeli tego używa.

No i ogólnie można zmienić padding/upakowanie, aby wstawiać co 1 B dane. Ale z tym ostrożnie, bo to potrafi generować bardzo dziwne crashe. Bezpieczniej ułożyć dane z głową, czyli to co zajmuje po 1B dać koło siebie, itd.

Dziękuję za wszystkie uwagi, będę wracał do tego postu i pewnie jeszcze jakieś pytania się pojawią. Na razie próbuję optymalizować zużycie RAMu, ale na FLASH też przyjdzie czas.

Na marginesie mam bardzo ciekawe spostrzeżenie - bramka testowa (10 urządzeń, 35 kanałów Supla) - podłączona do USB komputera, logi przez Serial vs ta sama bramka podłączona do zasilacza - w tej pierwszej opcji FreeHeap i MinimalFreeHeap znacząco mniejsze niż w tej drugiej?

[[email protected]]

Bo pewnie jak nie ma seriala podpiętego to nie buforuje i leci w dev null

[lukasz06]

Próbuje skompilować samemu soft z Arduino i jest taki błąd:

Code: Select all

Compilation error: variable or field 'updateLabel_P' declared void

[vajera]

Próbuje skompilować samemu soft z Arduino i jest taki błąd:

Code: Select all

Compilation error: variable or field 'updateLabel_P' declared void

W pliku z2s_device_web_gui.h linie 468-472 wyglądają, jak poniżej?

Code: Select all

void updateLabel_P(Control::ControlId_t id, const char* value) {

	working_str = value;
	ESPUI.updateLabel(id, working_str);
}