Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

IAR minimalna konfiguracja na przykładzie stm32H7

PiotrLenarczyk 09 Lis 2018 20:44 453 24
  • #1 09 Lis 2018 20:44
    PiotrLenarczyk
    Poziom 8  

    Program IAR jest jednym z podstawowych, dostępnych narzędzi do tworzenia oprogramowania na mikrokontrolery. Posiada kolorowe i wygodne środowisko graficzne, wraz ze zestawem zoptymalizowanych, standardowych bibliotek. Poniższy samouczek ma na celu pokazanie, jak skonfigurować te środowisko do wydajnej pracy. W autora praktyce sporym utrudnieniem są czasy inicjalizacji i programowania zewnętrznym programatorem. Aby efektywnie programować projekt, dobrze jest zaczynać ze świadomie przygotowanym kompilatorem, jego interfejsem graficznym, jak i odpowiednio napisanym programem. Przykład opiera się o jeden z najmocniejszych mikrokontrolerów dostępnych na rynku stm32H743VI, standardowy programator za kilkadziesiąt złotych STLinkv2 i darmową wersję IAR kickstart 32kiB. Podejście jest uniwersalne i może się opierać np. o optymalny stm32L011 i przykłady CMSIS korporacji ST ( https://www.st.com/en/embedded-software/stm32snippetsl0.html ), czy którąś ze standardowych płytek Nucleo, lub Discovery.
    1) pobieramy program IAR ze strony producenta oprogramowania, czytamy ze zrozumieniem licencję, instalujemy i rejestrujemy wersję ograniczoną rozmiarem generowanego kodu do 32kiB,
    2) otwieramy program IAR ( od wersji 8.32 jest spora poprawa wydajności programu, w porówaniu do poprzednich edycji ) i ściągamy samouczek firmy ST,
    IAR minimalna konfiguracja na przykładzie stm32H7
    3) usuwamy wszytko poza folderem output i plikiem main.c z pustą funkcją main. Klikamy prawym przyciskiem myszy na projekcie, wchodzimy w ustawienia i w okienku kompilatora zaznaczamy tworzenie pliku list, oraz wybieramy poziom optymalizacji na low,
    IAR minimalna konfiguracja na przykładzie stm32H7
    4) usuwamy wpisy bibliotek HAL w definicjach preprocesora
    IAR minimalna konfiguracja na przykładzie stm32H7




    5) tworzymy czytelny dla człowieka plik zawartości pamięci,
    IAR minimalna konfiguracja na przykładzie stm32H7
    6) wybieramy programator STLINK i wpisujemy na razie pustą nazwę funkcji end() do której program będzie kontynuował egzekucję. Zaznaczamy użycie firmware’u IAR do wgrywania zawartości flash, wraz z weryfikacją poprawności wgranego kontentu. W opcjach programatora zaznaczamy połączenie podczas resetu, aby uzyskać funkcjonalność programowania w trybach low power ( do debugowania należy dodatkowo ustawić rejestry ),
    IAR minimalna konfiguracja na przykładzie stm32H7
    IAR minimalna konfiguracja na przykładzie stm32H7
    7) tworzymy plik linkera wybierając odpowiedni typ ( zakres adresacji ) pamięci do przeprowadzanych operacji,
    IAR minimalna konfiguracja na przykładzie stm32H7
    8) tworzymy tablicę wektorów, korzystając z dokumentacji producenta procesora ( Reference Manual + Datasheet + Programming Manual + Errata ) i właściela praw autorskich rdzenia ( dokumentacja ARM ),
    IAR minimalna konfiguracja na przykładzie stm32H7
    9) podczas pisania programu sprawdzamy poprawność zlinkowanych sekcji, inicjalizację zmiennych, et cetera - przydatny jest plik list. Na przykład: otwieramy plik map załączonego projektu ( program 7zip ) i szukamy adresu funkcji Systick_Handler(). Kolejno otwieramy wygenerowany plik hex ( zawartość pamięci - danych wgranych do MCU, bez funkcji pomocniczych IAR ) i pod adresem 0x0800003C ( NVIC SystickHandler offset jest równy 0x3C ) można znaleźć podobny adres funkcji,
    IAR minimalna konfiguracja na przykładzie stm32H7
    IAR minimalna konfiguracja na przykładzie stm32H7
    10) wraz ze zwiększaniem się objętości pliku main.c przydaje się podzielenie widoku pojedynczego pliku funkcjonalnością split, która umożliwia edycję kilku części tego samego pliku na raz,
    IAR minimalna konfiguracja na przykładzie stm32H7
    IAR minimalna konfiguracja na przykładzie stm32H7
    11) konfigurujemy wygląd okienek, dodajemy:
    -ustawienie skrótów klawiaturowych,
    -Tools->Options->Project: Stop build operation on: Warnings
    -Tools->Options->Project: Enable parallel build [liczbaRdzeniPC] ( przydatne przy pracy z bibliotekami ),
    -Tools->Options->Editor: Show line numbers
    -koloryzację środowiska
    IAR minimalna konfiguracja na przykładzie stm32H7
    IAR minimalna konfiguracja na przykładzie stm32H7
    12) wchodzimy do folderu projektu kopiujemy podfoldery EWARM i Src, resztę usuwamy,
    IAR minimalna konfiguracja na przykładzie stm32H7
    13) w programie wielokrotnie używamy zmiennych globalnych, zamiast zmiennych lokalnych. Kopiując dążymy do operacji typu while( *destPtr++ = *srcPtr++ ); dla wskaźników o równych rozmiarach. Używamy struktur o zerowych ostatnich elementach, Wdrażane prototypowe algorytmy powinny być przetestowane przed implementacją na mikrokontrolerze,
    14) po podłączeniu zasilania mikrokontroler medianowo działa na wbudowanym generatorze ( rezonatorze ), posiada włączony rdzeń, pamięć RAM i Flash.
    Post Scriptum: argumentację, że “kompilatory są genialne” i “zrobią wszystko lepiej” uważam za bzdurne - należy kontrolować, co program wykonuje, w jaki sposób został wyprodukowany, oraz jak działają poszczególne instrukcje ( w tym działania na rejestrach, znajomość hazardów, et cetera ). Temat założyłem jako ewentualnie komuś przydatny:D

    0 24
  • #2 09 Lis 2018 21:41
    stmx
    Poziom 13  

    PiotrLenarczyk napisał:
    Program IAR jest jednym z podstawowych, dostępnych narzędzi
    Dalece dyskusyjne w środowisku hobbystycznym (I nie tylko)

    PiotrLenarczyk napisał:
    Przykład opiera się o jeden z najmocniejszych mikrokontrolerów dostępnych na rynku stm32H743VI, standardowy programator za kilkadziesiąt złotych STLinkv2 i darmową wersję IAR kickstart 32kiB.
    Zdecydowanie H7 i 32kB ograczenie jest perfekcyjnym połączeniem. Do migania diodą wystarczy, proponuję jednak spróbować dodać np. stos TCP/IP i wtedy pisać o jego jakiejkolwiek zastosowalności.

    PiotrLenarczyk napisał:
    Posiada kolorowe i wygodne środowisko graficzne
    A czy znasz jakieś monochromatyczne IDE?
    PiotrLenarczyk napisał:
    W autora praktyce sporym utrudnieniem są czasy inicjalizacji i programowania zewnętrznym programatorem.
    Rozumiem że piszesz o sobie w 3 osobie :). Czy Autor mógłby rozwinąć tę myśl? Czy po instalacji IAR z monitora wychodzą kabelki i łaczą się z płytką bez zewnętrznej debug probe? Jeżeli Szanownemu Autorowi nie pasuje ST-LINK to może go za darmo przerobić na o wiele szybszy ST-Link. Google pomoże w znalezieniu linka na stronie segger-a.

    PiotrLenarczyk napisał:
    dobrze jest zaczynać ze świadomie przygotowanym kompilatorem, jego interfejsem graficznym
    Czy gcc jest nieświadomie przygotowanym kompilatorem? Czy Autor wie o czym pisze? Co to jest interfejs graficzny kompilatora? Czy chodzi o teksty, które się wyświetlają w trakcie kompilacji? (hint IAR używa do kompilacji programu iararm i swojego linkera, którego nazwy nie pamiętam)


    Reasumując. IARa nie lubię miałem nieszczęscie używać w pracy do pracy z uC firmy co wszystko certyfikuje na samochody. Jedynym plusem są niektóre narzędzia debugowania i profilowania (i nie chodzi o podgląd rejestrów) - ale do tego Autor jeszcze nie dotarł.

    IMO wersja 32kb tego środowiska nadaje się tylko dla osób, które idą na rozmowę o pracę do firmy co tego używa i chcą zapoznać się ze środowiskiem aby zebrać trochę plusów.

    2
  • #3 09 Lis 2018 22:50
    PiotrLenarczyk
    Poziom 8  

    Też jestem zwolennikiem GCC - wrzucałem trywialną konfigurację kompilatora skrośnego na CM0+ i CM4F ( https://www.elektroda.pl/rtvforum/topic3509381.html ). Jednakże dla początkujących IAR jest zdecydowanie lepszym pomysłem, zwłaszcza biorąc pod uwagę popularność systemu LINUX.

    0
  • #4 09 Lis 2018 23:06
    stmx
    Poziom 13  

    PiotrLenarczyk napisał:
    Też jestem zwolennikiem GCC - wrzucałem trywialną konfigurację kompilatora skrośnego na CM0+ i CM4F ( https://www.elektroda.pl/rtvforum/topic3509381.html ). Jednakże dla początkujących IAR jest zdecydowanie lepszym pomysłem, zwłaszcza biorąc pod uwagę popularność systemu LINUX.
    Znam ten post ale jest niestety bardzo zły.

    Rozumiem że Autor uważa gcc nie ma na Linuxa, oraz że brak jest również dobrych bezpłatnych IDE.

    Wszelkie ograniczone w wersji demo środowiska nie nadają się dla nikogo kto nie zamierza za nie zapłacić. Jak już pisałem można sobie migać diodą.

    1
  • #5 10 Lis 2018 00:21
    _lazor_
    Moderator Projektowanie

    stmx napisał:
    PiotrLenarczyk napisał:
    Posiada kolorowe i wygodne środowisko graficzne
    A czy znasz jakieś monochromatyczne IDE?


    Terminal w linuksie :D

    Układ dobiera się do zapotrzebowania, polecanie cortex-m7 dla osób, które nawet nie potrafią skonfigurować IAR to trochę nie trafiony pomysł. Ten rdzeń ma bardzo dużo możliwości, które dla początkującego nie będą mieć znaczenia.

    Jeśli już chcesz zrobić jakiś poradnik, który przyda się początkującym to pokaż jak stworzyć projekt na ARM cortex-m "from scratch". Może wtedy wiele osób odkryje że do programowania nie trzeba IDE? No a może przynajmniej przestanie się mówić, że IDE to podstawowe narzędzie...

    0
  • #6 10 Lis 2018 09:49
    stmx
    Poziom 13  

    _lazor_ napisał:
    Terminal w linuksie :D
    Gwarancji nie ma. "Tyż" może być kolorowy :)

    IAR minimalna konfiguracja na przykładzie stm32H7

    _lazor_ napisał:
    Jeśli już chcesz zrobić jakiś poradnik, który przyda się początkującym to pokaż jak stworzyć projekt na ARM cortex-m "from scratch".


    Już próbował, ale problemem jest, że Autor ma raczej mgliste pojęcie o temacie (co pokazał w tamtym wątku) oraz w wątku poradnika kol. Szczywronka (tak na marginesie to w wątku poradnika - jako że czytają to początkujący - tak niskiej jakości posty powinny być usuwane, po co mącić w głowach tych, co dopiero się uczą)

    0
  • #7 10 Lis 2018 10:20
    PiotrLenarczyk
    Poziom 8  

    Nie piszę poradników, a ekspertem nigdy nie byłem, proszę Panów smutasów:D Konkretny procesor to przykład, równie dobrze można pisać w IAR na potężny, ( jeśli umiejętnie użyty ) stm8L001 w cenie oranżady. A co do bycia amatorem środowisk programistycznych, to temat piszę dość na gorąco, bo dopiero niedawno porzuciłem ograniczone Arduino IDE ( od którego znacznie lepszy jest również darmowe środowisko AVR Studio ). Nie wiem, skąd komentarze "to nieprofesjonalne", lub "nietakie, bo nietakie" - prosiłbym o konkrety;)

    0
  • #8 10 Lis 2018 12:05
    stmx
    Poziom 13  

    PiotrLenarczyk napisał:
    proszę Panów smutasów:D


    A ja proszę o odrobinę pokory. Jeżeli publikujesz makra - to najpierw naucz się je pisać. Jak opisujesz płatne IDE - to się z nim dokładnie zapoznaj, dowiedz się czym się wyróżnia na tle innych, a jakie ma wady. Niestety nie zrobisz tego instalując sobie na kompie i wklepując jakiś trywialny przykład. Aby to opisać musisz zrobić kilka dużych projektów , poznać plusy i minusy. Podobnie z innymi narzędziami. Dopiero wtedy możesz coś o nich pisać a nie :

    PiotrLenarczyk napisał:
    Aby efektywnie programować projekt, dobrze jest zaczynać ze świadomie przygotowanym kompilatorem


    Jak chcesz się przyłużyć początkującym to podam Ci temat:

    Mało który z hobbystów korzysta z jakiegoś systemu kontroli wersji. Zapoznaj się z git , poeksperymentuj na prawdziwych projektach i napisz poradnik dla początkujących jak tego używać, dlaczego jest to bardzo wygodne, jak używać z wiersza poleceń, a jak zintegrować z popularnymi IDE. Jeżeli zrobisz to jak należy (to znaczy sam się najpierw nauczysz) to zdobędziesz sławę na forum nie mniejszą niż kolega szczywronek.

    0
  • #9 10 Lis 2018 15:27
    PiotrLenarczyk
    Poziom 8  

    Nie rozumiem za bardzo celu wypowiedzi, ale ok. Co do dużych projektów, to jeszcze w żadnym nie brałem udziału i jakoś mi się nie widzi branie w takowym. Temat założyłem, bo swego czasu sam szukałem podobnych treści, ale była komercyjna - za przeproszeniem lipa. W poście makr również nadmieniałem, że publikuję celem pokazania, tudzież podpowiedzi. Profesjonalnie to się pisze książkę, spełnia koncert życzeń wydawcy i zdobywa sławę profesjonalisty:) Jak się nie podoba, to można nie używać, tudzież wnieść niezbędne merytoryczne uwagi.
    Post Scriptum: stm32H7 nie jest głupie - za kilkanaście zł ma się niezły MCU z GPIO max. freq. 200MHz, jednocyklowym SRAM z pamięcią podręczną danych, instrukcji i sześcio - stopniowym potokiem, a całość okraszona elastycznym poborem energii.

    0
  • #10 10 Lis 2018 17:30
    Freddie Chopin
    Specjalista - Mikrokontrolery

    PiotrLenarczyk napisał:
    Post Scriptum: stm32H7 nie jest głupie - za kilkanaście zł ma się niezły MCU...

    Nie ma to jak precyzja, biorąc pod uwagę, że w detalu najtańszy kosztuje 40 zł i to netto, więc brutto prawie pół setki. W zasadzie to ten za 40 zł jest jakiś dziwny chyba, ale nie chce mi się wnikać w to dlaczego - kolejny pod względem ceny jest już za ponad 60 zł (oczywiście netto).

    0
  • #11 10 Lis 2018 17:58
    stmx
    Poziom 13  

    PiotrLenarczyk napisał:
    Post Scriptum: stm32H7 nie jest głupie
    Nie rozumiesz - glupie jest proponowanie użycia narzędzia ograniczonego do 32kB do takiego procesora. To jest najpotężniejszy i najdroższy uK od STM-a, i nie jest przeznaczony do małych projektów. Do tego mało przyjazne dla amatorów obudowy.

    Tak przy okazji cechy, które wymieniłeś występują w tak samo w mniejszych rodzinach tych układów. Kosztują nie kilkanaście złotych tylko kilkanaście funtów + VAT. Taka drobnostka.

    Freddie Chopin napisał:
    że w detalu najtańszy kosztuje 40 zł i to netto, więc brutto prawie pół setki. W zasadzie to ten za 40 zł jest jakiś dziwny chyba, ale nie chce mi się wnikać w to dlaczego


    Pewnie dlatego że go nie ma :)
    Tak jak w arrow: https://www.arrow.com/en/products/stm32h750vbt6/stmicroelectronics
    Jak się pojawią na stanie to będą po kilkanaście funtów a nie 3. Jak ktoś naiwny weźmie do BOM to się zdziwi :) Bardzo fajna jest też ilość ostatniej rubryczce - normalnie jak rezystory

    0
  • #12 10 Lis 2018 18:42
    Freddie Chopin
    Specjalista - Mikrokontrolery
  • #14 10 Lis 2018 20:03
    Marek_Skalski
    Moderator Projektowanie

    @stmx @Freddie Chopin Rodzina H7x0 jest tania, ponieważ została mocno wykastrowana, dzięki czemu zmniejszono znacząco rozmiar struktury (die) i więcej wychodzi z jednego wafla, w mniejszej ilości cykli naświetlania. To pozwoliło na obniżenie kosztów.
    @PiotrLenarczyk Początkujący zaczynający od Arduino wyrabiają sobie mylne pojęcie, że "mikroprocesorem steruje się podając komendy", czy coś w tym stylu. W rzeczywistości jest tak, że środowisko Arduino wykonuje wiele operacji w tle, w sposób niewidoczny dla użytkownika, ale magii w tym nie ma.
    Kiedy Arduino nie wystarcza, to zaczyna się poszukiwanie alternatywy. Jedni wybierają Keil uVision - wszak pochodzi od ARM, a kto może wiedzieć lepiej jak pisać programy na ARMy, jeżeli nie ARM. Ale tutaj dość szybko zderzają się z barierą wielkości programu 32KiB. Później dochodzą różne niezbyt oczywiste rozszerzenia dla języka C, przez które program napisany pod ten kompilator, niekoniecznie będzie można skompilować innym kompilatorem, kiedy przekroczymy wspomniane 32KiB.
    Dla początkującego lub amatora, zdecydowanie lepszą opcją jest w pełni darmowe Eclipse (IDE) + gcc (kompilator). Nie kosztuje, nie ma ograniczeń wielkości programu, ma dobrą dokumentację, w pełni wspiera C, dobrze wspiera C++. Występuje w wielu smakach, np. DYI opisane na Forum i przez Kolegę Freddie Chopin, SW4STM od AC6, Atollic True Studio od STMicroelectronics i pewnie jeszcze kilka innych wersji.
    Polecanie IAR, to trochę nieuczciwe podejście. IAR jest zamknięty i dość specyficzny. Kosztuje dużo, a darmowa wersja z limitem 32KiB kończy przygodę tak jak wcześniej wspomniany uVision. Interfejs jest jakieś 10 lat do tyłu względem Eclipse, a kompilator IAR również jest specyficzny. Dlaczego jest używany? Ponieważ jest wiele dużych firm, które dawniej pracowały na C51 i dla nich jedynym dobrym kompilatorem był IAR. Czasy się zmieniają, sentymenty pozostały. Ogromna bazy danych z bibliotekami, driverami, firmware również i rezygnacja z IAR oznacza dla nich konieczność przepisania wszystkiego na nowo. Więcej, trzeba przeszkolić tych staruszków, którzy nie wyobrażają sobie pracy w czymś innym niż IAR, a to kosztuje bardzo dużo i rodzi wielki opór. Jedyna zaleta dla IAR, to kompilatory Green Hills, które tworzą bardzo wydajny kod. ST testuje ne tym swoje konstrukcje w ramach CoreMark.
    Osobiście polecam początkującym Eclipse, ponieważ jest to żywe i otwarte środowisko. Najszybciej uzyskają pomoc na Forum, a jak im się znudzi programowanie, to nie będą żałować wydanych tysięcy dolarów za pełną licencję.
    Tobie Kolego proponuję zrealizować chociaż 3 projekty, opublikować je w DYI, a dopiero później radzić początkującym co i jak należy robić. Pokaż swoim działaniem, że to ma sens, zamiast pisać mało precyzyjne opisy wyglądające trochę jak nieudolna próba reklamy.

    0
  • #15 10 Lis 2018 21:09
    stmx
    Poziom 13  

    @Marek_Skalski Przyjrzalem się specyfikacji i w sumie różnica jest we FLASH :). Czyżby to te, które miały zwalone pamięci FLASH?

    0
  • #16 11 Lis 2018 16:09
    PiotrLenarczyk
    Poziom 8  

    Robiłem jakiś prosty projekt mikrokontrolerowy na dział DIY, przy którym spędziłem trochę czasu ale wylądował w koszu - więcej nie zamierzam się tam zapuszczać:) Wcześniej poruszona była tematyka profilowania kodu MCU w środowisku IAR:
    nie znam się na profilowaniu, trochę używałem profilowania przy określaniu wydajności GPU w nieskomplikowanej koncepcji obliczeń rozproszonych. Jeśli już miałbym określać wydajność fragmentów kodu to na pewno nie byłby blink na pinie oscyloskopu ( opóźnienia ), ale coś w rodzaju pojedynczo wyzwalanego Systicka ( z, lub bez dzielnika /8 ), po restarcie. Na pewno w wersji finalnej oprogramowania - debugowanie wpływa na pracę MCU, a dodatkowe symbole debugowania zwiększają ilość instrukcji ( pracy do wykonania ), co również wpływa negatywnie na rzetelność pomiaru.

    0
  • #17 11 Lis 2018 16:20
    Freddie Chopin
    Specjalista - Mikrokontrolery

    PiotrLenarczyk napisał:
    dodatkowe symbole debugowania zwiększają ilość instrukcji ( pracy do wykonania )

    what? (;

    0
  • #18 11 Lis 2018 16:34
    PiotrLenarczyk
    Poziom 8  

    Może się mylę - wtedy poprosiłbym o wyjaśnienie jak inaczej to działa. Ale wystarczy przejrzeć plik wersji debug i release. Program skompilowany w wersji z symbolami debugowania ( która część źródeł odpowiada instrukcjom ) może być uruchomiony bez podłączonego debuggera, analogicznie sesją debugowania można się podłączyć do zwykłego programu na MCU - wystarczy wprowadzić dodatkowe instrukcje.

    0
  • #19 11 Lis 2018 16:44
    Freddie Chopin
    Specjalista - Mikrokontrolery

    PiotrLenarczyk napisał:
    Program skompilowany w wersji z symbolami debugowania ( która część źródeł odpowiada instrukcjom ) może być uruchomiony bez podłączonego debuggera, analogicznie sesją debugowania można się podłączyć do zwykłego programu na MCU - wystarczy wprowadzić dodatkowe instrukcje.

    what? (;

    Nie no, sorry - naprawdę nie wiem o czym Ty piszesz... Co chcesz porównywać z czym? Programy na różnym poziomie optymalizacji oczywiście różnią się wydajnością, ale obecność lub nieobecność w pliku .elf symboli debuggera (które nigdy nie trafiają do pamięci flash mikrokontrolera) nie ma z tym absolutnie nic wspólnego. To są dwie niezależne kwestie i nic nie stoi na przeszkodzie aby używać sobie debuggera z programem skompilowanym na wysokim poziomie optymalizacji - będzie to nieco utrudnione (taka natura optymalizacji), ale jest to możliwe. Tak samo można wyłączyć dodawanie symboli debuggera do programu skompilowanego bez optymalizacji i wtedy jedynie można sobie debuggować assemblera. Symbole te na pewno nie są żadnymi "dodatkowymi instrukcjami".

    Innymi słowy - błądzisz.

    0
  • #20 11 Lis 2018 16:53
    BlueDraco
    Specjalista - Mikrokontrolery

    PL: Najpierw się dokształć, a potem snuj teorie... Plik programu w wersji "debug" nie musi zawierać ani jednej instrukcji więcej, niż w wersji "niedebug", zawiera za to mnóstwo informacji używanych przez debugger, którch mikrokontroler nigdy nie zobaczy, bo nie są one kopiowane do pamięci uC. Debugowanir w ARM ani w żadnych innych współczesnych uC/uP nie spowalnia wykonania programu.

    0
  • #21 11 Lis 2018 17:18
    stmx
    Poziom 13  

    @PiotrLenarczyk Naprawdę najwpierw zdobądź wiedzę, później się nią dziel.

    Zdaj sobię sprawę, że praktycznie każde zdanie jakie napisałeś jest wręcz humorystycznie błędne,

    Nie uczysz się też z tego co Ci piszą inni (czyli się nie rozwijasz).

    Ten "projekt", który zamieściłeś jest w 100% błędny. Dlaczego? Bo jest niezgodny ze standardem języka C. C zakłada że nie zainicjalizowane obiekty ze storage typu static będą wyzerowane, a zaincjalizowane będą mieć takie wartości jakie przypisał im programista. Dlatego też przed skokiem do main wykonuje się inny kod, który to robi (oczywiście często robi też inne rzeczy). Twój "projekt" jest po prostu jednym wielkim UB.

    Uważam wątek za szkodliwy. Nie daj Bóg jakiś podobny do Ciebie początkujący postanowi skorzystać. I nic mu nie będzie działać. Żadne biblioteki, ani jego własny kod. Napisze sobie np program:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    I to już nie zadziała (bo startup jest niezgodny ze standardem C)

    To samo robiłeś w poprzednim swoim temacie, to samo robisz teraz.


    Nie wspominając o już wręcz humorystycznych (bo inaczej się tego nie da skomentować, a dużej części nawet zrozumieć):

    PiotrLenarczyk napisał:
    Jeśli już miałbym określać wydajność fragmentów kodu to na pewno nie byłby blink na pinie oscyloskopu ( opóźnienia ), ale coś w rodzaju pojedynczo wyzwalanego Systicka ( z, lub bez dzielnika /8 ), po restarcie

    PiotrLenarczyk napisał:
    debugowanie wpływa na pracę MCU, a dodatkowe symbole debugowania zwiększają ilość instrukcji ( pracy do wykonania ), co również wpływa negatywnie na rzetelność pomiaru.

    PiotrLenarczyk napisał:
    stm32H7 nie jest głupie - za kilkanaście zł ma się niezły MCU z GPIO max. freq. 200MHz, jednocyklowym SRAM z pamięcią podręczną danych, instrukcji i sześcio - stopniowym potokiem, a całość okraszona elastycznym poborem energii.
    PiotrLenarczyk napisał:
    w programie wielokrotnie używamy zmiennych globalnych, zamiast zmiennych lokalnych. Kopiując dążymy do operacji typu while( *destPtr++ = *srcPtr++ ); dla wskaźników o równych rozmiarach. Używamy struktur o zerowych ostatnich elementach, Wdrażane prototypowe algorytmy powinny być przetestowane przed implementacją na mikrokontrolerze
    PiotrLenarczyk napisał:
    po podłączeniu zasilania mikrokontroler medianowo działa na wbudowanym generatorze
    PiotrLenarczyk napisał:
    że “kompilatory są genialne” i “zrobią wszystko lepiej” uważam za bzdurne - należy kontrolować, co program wykonuje, w jaki sposób został wyprodukowany, oraz jak działają poszczególne instrukcje ( w tym działania na rejestrach, znajomość hazardów, et cetera )
    PiotrLenarczyk napisał:
    W autora praktyce sporym utrudnieniem są czasy inicjalizacji i programowania zewnętrznym programatorem.
    PiotrLenarczyk napisał:
    Aby efektywnie programować projekt, dobrze jest zaczynać ze świadomie przygotowanym kompilatorem, jego interfejsem graficznym, jak i odpowiednio napisanym programem.
    Programuje się komputery, projektów nie trzeba. Zresztą jak mam już "odpowiednio napisany program" to po co mam się zabierać za programowanie?

    0
  • #22 12 Lis 2018 18:36
    PiotrLenarczyk
    Poziom 8  

    Aha, prawie zostałem przekonany... Spoko, niektóre spostrzeżenie są trafne - zawsze to coś. Debugowanie spowalnia pracę mikrokontrolera i to bardzo - uprzejmie mówię, aby sobie to sprawdzić.
    Post Scriptum: oczywiście, że się dokształcę - zacznę od największych braków:)

    Dodano po 2 [minuty]:

    Tylko przypomnę, że dyskusja dotyczy optymalizacji środowiska IAR - mile widziane byłyby wpisy związane z tematem:)

    Moderowany przez Marek_Skalski:

    Proszę Kolegę o utrzymanie pewnego minimum poziomu merytorycznego. Nie widzę tutaj wiedzy, nie widzę pożytku, ani inspiracji. Widzę natomiast brak zrozumienia podstaw i próbę tworzenia ideologii. Do tej pory spodziewałem się dyskusji na poziomie, ale tracę nadzieję. Jeżeli Kolega nadal ma zamiar brnąć w obranym kierunku, to cały temat przeniosę do kosza. Proszę się zastanowić nad kolejnym wpisem i nie narażać na śmieszność podając informacje nieprawdziwe, nieprecyzyjne lub nieadekwatne do tematu. Bardzo zachęcam do opanowania podstaw programowania.
    Polecam lekturę regulaminu forum, szczególnie punkty: 3.1.11, 3.1.14.

    0
  • #23 12 Lis 2018 19:16
    BlueDraco
    Specjalista - Mikrokontrolery

    No fakt, debugowanie bardzo spowalnia pracę, bo przy pracy krokowej lub po wpadnięciu w pułapkę uC się zatrzymuje i czeka, aż programista naciśnie guzik "idź dalej", a bez debugowania po prostu wykonuje program bez zatrzymań.

    0
  • #24 12 Lis 2018 19:36
    stmx
    Poziom 13  

    PiotrLenarczyk napisał:
    Debugowanie spowalnia pracę mikrokontrolera i to bardzo - uprzejmie mówię, aby sobie to sprawdzić.
    Naprawde proszę nie pisz takich rzeczy.

    PiotrLenarczyk napisał:
    Tylko przypomnę, że dyskusja dotyczy optymalizacji środowiska IAR - mile widziane byłyby wpisy związane z tematem:)
    A gdzie Ty optymalizujesz środowisko IAR, bo jakoś nie widzę. Jedyne co zrobiłeś to:

    1. Wołasz main bez żadnego statupu - m.in. dlaczego to jest bardzo źle już Ci napisałem.
    2. Utrudniasz sobie życie poprzez nie używanie standardowych headerow oraz plików gdzie ktoś pracowicie wpisał tablicę wektorów. Teraz powodzenia z jej ręcznym wypełnieniem ...

    0
  • #25 12 Lis 2018 22:30
    tomzor
    Poziom 14  

    PiotrLenarczyk

    To wytłumacz wszystkim w jaki sposób osiągnąłeś to znaczące opóźnienia przy "debugowaniu".
    Albo jak to zrobić, to będzie ciekawsze.

    0
  Szukaj w 5mln produktów