rozmiar typu a przetwarzanie

[squeez]

Mam takie pytanie czy dla ESP ma jakieś znaczenie rozmiar typu? jak wiadomo dla 8 Bitowców (AVR) lepiej jest korzystać z typu 8bit (jeśli jest wystarczający ze względu na mneijsze zasoby przetwarzania, mniej taktów zajmuje niż obsługa 16bit).
Gdzieś kiedyś wyczytałem że w przypadku ARM lepiej jest stosować 16bitowe zamiast 8 bitowe nawet jeśli zakres wystarcza nam 8 bitów bo jest to lepiej optymalizowane przez kompilator. Choć nie wiem czy to prawda.

Czy w przypadku ESP też są tego typu zalecenia? w datasheet nie spotkałem choć może nie byłem zbyt uważny jak go czytałem

[xbary]

W sumie to nie zastanawiałem się nad tym, ale można by sprawdzić w assemblerze jaki nakład jest na zajętość kodu. Czyli porównać przy zerowej optymalizacji w C operacje na 8 16 32 bitach, wygenerować podczas kompilacji sobie plik assemblera. To tak na szybko.
Chyba -S czy jakoś tak było trzeba podać w argumencie.

[squeez]

no tak tylko by trochę było zabawy z szukaniem tego. bo kompilując nawet prosty kod dodawane są biblioteki do samego ESP jak choćby stos tcp obsługa wifi i wiele innych bibliotek

W przypadku normalnych mikrokontrolerów nie ma takiego kłopotu bo zrobisz czystą funkcję main z tym co chcesz sprawdzić i tylko to będzie generowanym kodzie asm.

[mpo]

Można pisać kod bez tego całego balastu SDK.
Co ciekawe, można wtedy użyć wyższych częstotliwości taktowania rdzeni, bo 80/160MHz wymuszane są tylko przez taktowanie części odpowiedzialnej za wifi.
https://github.com/cnlohr/nosdk8266

Nie próbowałem tego osobiście, ale jak widać można "podsypać węgla pod kocioł".

[squeez]

no dobra ale jak ma się to do mojego pytania? czy kod będzie kompilowany przez arduino, nonossdk czy nosdk to bez znaczenia bo kompilator raczej jest ten sam, a operacja maszynowe jaki jest generowany dla prostych operacji będzie pewnie identyczny np dla działania val++; będzie to rozbite na proste działania na rejestrach uc.

A jak zrezygnuję z SDK to co samemu pisać stos tcp albo wlasnorecznie portować lwip ... mija się z celem.
A pozbawianie ESP lacznośći ze światemi używanie go jako zwykłego uc to też mało interesujący pomysł, może w jakichś skrajnych przypadkach

[mpo]

no dobra ale jak ma się to do mojego pytania?

Nijak się ma
Ale zadałem sobie trud skompilowania kodu:
volatile uint64_t i;
for (i = 0; i < 255; i++);

Zmieniałem typ zmiennej i kolejno na uint8_t, uint16_t, uint32t, uint64t
Wyniki odpowiednio:
Program Sketch1 size: 222 047 bytes (used 21% of a 1 044 464 byte maximum) (1.66 secs)
Program Sketch1 size: 222 047 bytes (used 21% of a 1 044 464 byte maximum) (1.85 secs)
Program Sketch1 size: 222 047 bytes (used 21% of a 1 044 464 byte maximum) (1.70 secs)
Program Sketch1 size: 222 079 bytes (used 21% of a 1 044 464 byte maximum) (1.67 secs)

[squeez]

Program Sketch1 size: 222 047 bytes (used 21% of a 1 044 464 byte maximum) (1.66 secs)
Program Sketch1 size: 222 047 bytes (used 21% of a 1 044 464 byte maximum) (1.85 secs)
Program Sketch1 size: 222 047 bytes (used 21% of a 1 044 464 byte maximum) (1.70 secs)
Program Sketch1 size: 222 079 bytes (used 21% of a 1 044 464 byte maximum) (1.67 secs)

czyli można by to zinterpretować tak że zmienna jest traktowana jako 32bit no chyba że przekroczy zakres wówczas widać nieznaczny narzut.

[SunRiver]

Otóż to panowie każda zmienna 8bit i 16bit jest traktowana jako 32bit i rezerwowana jest dla niej odpowiednia ilość pamięci
jest to poniekąd wygodne i dobre rozwiązanie. Zresztą sam KOLBAN gdzieś opisuje to zjawisko

[mpo]

Otóż to panowie każda zmienna 8bit i 16bit jest traktowana jako 32bit i rezerwowana jest dla niej odpowiednia ilość pamięci
jest to poniekąd wygodne i dobre rozwiązanie. Zresztą sam KOLBAN gdzieś opisuje to zjawisko

To jak wytłumaczyć poniższe?

typedef struct /*__attribute__((__packed__))*/
{
uint8_t a;
uint8_t b;
uint16_t c;
} spakowana_t;

volatile spakowana_t liczniki;
void setup()
{
Serial.begin(115200);
Serial.printf("Rozmiar: %d\n", sizeof(spakowana_t));
for (liczniki.a = 0; liczniki.a < 10; liczniki.a++, liczniki.b++, liczniki.c++, Serial.printf(" %d", liczniki.a)); //cokolwiek...
}


Rozmiar struktury wynosi 4, niezależnie od tego czy struktura jest zadeklarowana normalnie czy jako packed.
Przy zmianie typów pól struktury na uint32_t, rozmiar to 12.

[SunRiver]

I to jest właśnie ciekawostka na którą odpowiedziec potrafią Tfu-rcy SDK dla Tensilica z esspresife ... osobiście czasem sam nie
łapię co autor miał na myśli i dlaczego tak .... ale działa

dodatkowo wiele dziwactw jest na nieoficjalnym sdk i pod toolchainem dla arduino ,
tu mi się wydaje ze jest nieco za mocno poprzesadzane od strony powiazania Tolchaina z SDK na pomoście core dla arduino

najprościej ... zrób to samo na SDK NonOS i SDK z RTOS dopiero się zdziwisz