@dasej Proponuję abyś poczytał wpierw co to jest tzw storage duration.
W C masz 3 rodzaje: static auto i allocated.
Static to zmienne globalne oraz zmienne w funkcjach z atrybutem `static`
Auto to zmienne (a raczej generalnie obiekty) zadeklarowane w funkcjach
Allocated - utworzone przez funkcje dynamicznej alokacji pamęci (w standardzie C jest któraś z funkcji z roziny malloc)
przykład
tmf wrote: Bycie inżynierem zakłada myślenie. Jeśli mam szybką pamięć w MCU i wolniejszą dodatkową, a tak jest zazwyczaj w AVR, to nie ma sensu wszystkiego przekładać do tej wolniejszej
Jak również czytanie tego co poprzednicy napisali.
osctest1 wrote: Proponuję zostawić .data, .bss i stos w wewn RAMie a heap (o ile używasz) + to co chcesz przenieść do tego segmentu.
Tak że z punktu widzenia używania C i tej pamięci IMO rozwiązanie, które zaproponowałem jest chyba optymalne (i z tego co widzę w programach pisanych przez innych najczęściej stosowane), bo pozwala wykorzystać własności języka C i mieć pełną kontrolę nad tym gdzie są obiekty umieszczone bez półśrodków i protez typu dostęp przez wskaźniki inicjalizowane adresami (jak w fotce z książki). Taki dostęp zostawmy dla rejestrów sprzętowych mapowanych w przestrzeni adresowej. Takie wskaźniki to proszenie się o trudne do wykrycia błedy i upierdliwość w pisaniu że już nie wspomnę o static w funkcjach i wieloplikowych projektach - gdzie nie da się tym już zarządzać).
zamiast po prostu (co to EXTRAM to odsyłam do jednego z moich poprzednich postów)
Kompilator i linker zadbają o wszystko, sprawdzą czy się dane zmieszczą itd itd
tmf wrote: Pozostaje więc tylko jedna możliwość - alokacja dynamiczna pamięci. Która może być właściwie quasi-statyczna, bo przecież nikt nie każe zwalniać tej pamięci i alokować ponownie.
To w takim razie po kiego ta alokacja dynamiczna. Nie prościej jak to K&R przykazali? To taka kolejna proteza, żeby tylko tego diabelnego skryptu linkera nie ruszyć.
tmf wrote: A filozoficznie, to nie widzę specjalnie problemu w alokacji dynamicznej. W czym ona niby jest taka dużo gorsza, niż alokacja, w sumie dynamiczna, tyle, że z użyciem stosu dla zmiennych automatycznych?
No tym pytaniem to mnie Kolega rozbroił. Zasada działania stosu i sterty jest całkowicie inna - a podstawowa róznicą jest to, że stosu nie można sfragmentować (bo nie można z niego wyjąć niczego ze środka tylko ze szczytu). Stosu nie dotyczy także tzw storage leakage i parę innych - które to znajdzie Kolega bez problemu w internecie. Do tego C jakie takie nie zna pojęcia stos i to że obiekty auto są na nim umieszczane. To jest akurat kwestia implementacji.
tmf wrote: Poza tym, jeśli by ortodoksyjnie podchodzić do alokacji dynamicznej, to trzebaby z mikrokontrolerów wyrzucić C++, co jest jeszcze bardziej kontrowersyjne.
Nie jest kontrowersyjne - bo C++ niekoniecznie musi używać sterty. Pseudo dynamiczna alokacja - choćby przez memory pools, która jako deterministyczna jest dopuszczalna przez wiele standardów (ale nie typu malloc/free). Jak to zrobić - to odsyłam do internetu - dyskusji i pomysłów co niemiara, a do tego myślę że przekracza to ramy tego wątku.
Dodam jeszcze, ze ten sam problem dotyczy RTOS-ów - tu też się stosuje w aplikacjach, które tego wymagają (np. z powodów certyfikacyjnych) statyczną alokację pamięci dla wszelkich obiektów - tasków, kolejek etc, etc. Tak że w świecie embedded to nie jest żadna nowość.
W ramach ciekawostki powiem że STM w HAL też parę razy walnął babola q postaci malloc-ów w przerwaniach, albo wiele i o różnych rozmiarack - co powodowało że programy działy ale tylko przez jakiś czas. Jak się sterta sfragmenowała to przestawały
