Witam, Środowisko projektowe: Kinetis Design Studio 3.2.0. MCU: Arm Cortex-M4 (MK22FN512VLH12)
Po skompilowaniu i zaprogramowaniu FLASH'a program działa prawidłowo, ale mogło by być lepiej, gdyby był wykonywany nie z FLASH'a lecz z RAM'u. Maksymalna częstotliwość taktowania FLASH'a to 24MHz, natomiast RAM'u to 60MHz.
Jak to zrobić, żeby po włączeniu urządzenia program przekopiował się z FLAH do RAM i następnie rozpoczął życie w RAM?
Aby był uruchamialny z obu miejsc, wymaga to posiadania kodu który jest niezależny od lokalizacji (PIC). To nie jest domyslny tryb kompilacji, zerknij na flagę pic w gcc, modyfikuje ona kod do stanu, w którym skoki są wyłącznie względne.
Druga sprawa: zazwyczaj nie chcesz całego programu - zazwyczaj chcesz kilka funkcji.
Inny workaround to zmuszenie linkera do zlinkowania częsci programu w RAM i wydłubanie tej sekcji z pliku elf, a nastepnie potraktowanie jej jako zwykłej tablicy danych do skopiowania do RAM. Widziałem sztuczke, kiedy automatycznie kompilowało się do sekcji .data, wiec kopiowanie do RAM ogarniała inicjalizacja.
Jeszcze inny, to niejakie gotowce, typu __RAM_FUNC.
To jest ogólnie trudne zagadnienie z poziomu ogarniania linkera, kompilacji ręcznej, pisania makefiles, opcji w narzędziach itd. Trudno o ogólną odpowiedź, to są rzeczy specyficzne do kompilatora i narzędzi na około niego. Niewykluczone, że narzędzia, z których korzystasz, mają to ogarnięte w postaci prostych do użycia modyfikatorów funkcji, flaczy czy innych wynalazków.
Tu masz kilka podpowiedzi:
Nie ten procesor ale podobnie.
On 13.02.2023 11:49, heby wrote: [...]
Ja bym powiedział, że tak się robi standardowo. Nazywasz sekcję np. "dupa", w skrypcie linkera oznaczasz, że docelowo ma być RAM, a funkcje, które mają wyladować w tej sekcji oznaczasz za pomocą __attribute__((section("dupa"))). Mowa oczywiście o jedynym słusznym kompilatorze, czyli gcc.
A to nie są jakieś wrappery wokł attribute section?
IMO nie ma tu nic trudnego. Aczkolwiek jak widać na przykładzie OP, IDE ogłupiają ludzi. Tzn. IDE są OK, sam używam, ale dobrze jest wiedzieć co się dzieje pod spodem.
On 13.02.2023 11:29, Stachu Chebel wrote: [...]
Niekoniecznie mogłoby być lepiej. M3/M4 to architektura harwardzka, czyli oddzielne szyny dla danych i dla instrukcji. Więc jeśli będziesz przewalał dane i instrukcje tylko jedną szyną, to całkiem możliwe, że osiągniesz efekt odwrotny od zamierzonego. Do tego współczesne MCU mają pipelining.
Oczywiście kod startowy składający się 5-6 linijek assemblera czy 4 linijek w C na starcie przekopiowuje sekcję z Flasha w odpowiednie miejsce w RAM.
Jak na tym tutaj jest to nie wiem, autor sobie sprawdzi. Na produkcie nxp M3 którego numerka nie pamiętam to było szybciej. I normalnie się robiło na poziomie funkcji. MM
On 13.02.2023 20:33, m wrote: [...]
Po pierwsze trzeba przestudiować dokumentację, a po drugie trzeba zmierzyć. Producenci stosują różne przyspieszacze w postaci flasza o szerokości szyny danych np. 256 bitów i jakieś tam dodatkowej logiki. Zobacz np. M4 od STM (STM32F405xx): „Based on CoreMark benchmark, the performance achieved thanks to the ART accelerator is equivalent to 0 wait state program execution from Flash memory at a CPU frequency up to
168 MHz”. Na takim MCU wykonywanie programu z SRAMu w praktyce na pewno będzie wolniejsze od wykonywania z flasza.A co to znaczy? Zwłaszcza „na poziomie funkcji”.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required