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?

do góry

On 13/02/2023 11:29, Stachu Chebel wrote:
> 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:

https://stackoverflow.com/questions/15137214/how-to-
run-code-from-ram-on-arm-architecture

do góry

Nie ten procesor ale podobnie.

https://community.nxp.com/t5/LPCXpresso-IDE-FAQs/Rel
ocating-code-from-FLASH-to-RAM/m-p/473993

Adam Górski

> 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?

do góry

On 13.02.2023 11:49, heby wrote:
[...]
> 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.
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.

> Jeszcze inny, to niejakie gotowce, typu __RAM_FUNC.
A to nie są jakieś wrappery wokł attribute section?

> To jest ogólnie trudne zagadnienie z poziomu ogarniania linkera,
> kompilacji ręcznej, pisania makefiles, opcji w narzędziach itd. Trudno o
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.

do góry

On 13.02.2023 11:29, Stachu Chebel wrote:
[...]
> 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.
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.

do góry

On 13.02.2023 13:27, JDX wrote:
> On 13.02.2023 11:49, heby wrote:
> [...]
>> 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.
> 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.
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.

do góry

W dniu 13.02.2023 o 13:29, JDX pisze:
> On 13.02.2023 11:29, Stachu Chebel wrote:
> [...]
>> 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.
> 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.
>
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

do góry

On 13.02.2023 20:33, m wrote:
[...]
> 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.

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.

> I normalnie się robiło na poziomie funkcji.
A co to znaczy? Zwłaszcza ,,na poziomie funkcji".

do góry