Jak profesjonaliści używają bibliotek CMSIS w projektach STM32?

Witam. Chciałbym zapytać o to jak wygląda rzeczywistość w związku z używaniem tych bibliotek. Chodzi mi o ludzi, którzy programują mikrokontrolery zawodowo. Sam pracowałem w firmie, w której były produkowane urządzenia oparte o stm32 i ludzie którzy programowali używali tych bibliotek (nie wiem w jak dużym stopniu, ale na pewno były wykorzystywane). Jeśli ktoś ma wiedzę na ten temat jak wygląda sytuacja to będzie miło jak się nią podzieli.

CMSIS wykorzystują każdy programista bo to podstawa, inna sprawą jest SPL, i tu każdy poważny programista będzie tępił jej wykorzystywanie.

Jedni używają, inni nie.

Jako ciekawostkę polecam jednak przeczytać co pisze w nagłówku każdego pliku SPLa:

Cytat:

* THE PRESENT FIRMWARE WHICH IS FOR GUIDANCE ONLY AIMS AT PROVIDING CUSTOMERS
* WITH CODING INFORMATION REGARDING THEIR PRODUCTS IN ORDER FOR THEM TO SAVE
* TIME. AS A RESULT, STMICROELECTRONICS SHALL NOT BE HELD LIABLE FOR ANY
* DIRECT, INDIRECT OR CONSEQUENTIAL DAMAGES WITH RESPECT TO ANY CLAIMS ARISING
* FROM THE CONTENT OF SUCH FIRMWARE AND/OR THE USE MADE BY CUSTOMERS OF THE
* CODING INFORMATION CONTAINED HEREIN IN CONNECTION WITH THEIR PRODUCTS.

Jak dla mnie tutaj jest wprost napisane, że to jest takie "tech-demo", które służy demonstracji "jak to działa" czy "jak to zrobić", a że niektórzy nie potrafią nic zrobić bez takich bibliotek to już trudno...

4\/3!!

Może wypada zacząć od tego, co to jest CMSIS. W zależności od fantazji może to być albo tylko minimalna obsługa procesora, albo również biblioteka obsługi peryferiów.

Ta minimalna obsługa procesora zawiera pliki nagłówkowe, definiujące wszystkie zasoby mikrokontrolera oraz pliki definiujące zasoby rdzenia i podstawowe operacje na nich. Ponadto mamy jeszcze plik startowy oraz plik zawierający procedurę SystemInit.

Pliki nagłówkowe przydają się zawsze. Plik startowy też jest potrzebny, ale nie zawsze bierzemy go z CMSIS. SystemInit na ogół jest potrzebny, ale nie zawsze. W prostych projektach można go pominąć, a w większych niektórzy wolą go napisać samemu (chodzi o procedurę inicjującą generator zegara i parametry dostępu do Flash.

Same pliki nagłówkowe nie są translowane w kod wynikowy, więc hasło "bibliotek" jest tu nieco na wyrost. Po prostu używamy plików nagłówkowych z CMSIS w naszych modułach.

Oczywiście chodziło mi o SPL

SPL może służyć jako przykład źródło wiedzy dla początkujących.

tadzik85 napisał:

SPL może służyć jako przykład źródło wiedzy dla początkujących.

...jak nie pisać programów

Swoją drogą, to chyba tylko my tutaj na Elektrodzie tak nisko oceniamy SPL...jak się popatrzy po zagranicznych forach, to tam bezkrytycznie je stosują.
Stąd prawie całkowity brak przykładów bez użycia SPL w internecie i literaturze.
I pomyśleć że opiera się to na demie

Jak się popatrzy na zagranicznych witrynach, to znaczny odsetek problemów jest typu "użyłem funkcji biblioteki i mi timer/SPI/cokolwiek nie działa".

Wykorzystywanie bibliotek obsługi peryferiów daje zasadniczo dwie rzeczy:
-szybkie projektowanie i ewaluację otrzymanych wyników
-dużą objętość kodu

Sporo funkcji jest tak napisanych, że w praktyce wystarczyło by makro ale używane są funkcje, które obudowują całość.

Można ich także używać jako źródło przykładów. W tym przypadku jest to naprawdę kopalnia.

Dopóki nie pojawią się w sieci przykłady inicjalizacji peryferiów STM'ów bez użycia bibliotek, to ciężko będzie przełamać monopol SPL.
Pytanie tylko czy komuś zechce się takie przykłady w sieci umieszczać?
Ale może warto, bo taka stronka mogła by się cieszyć sporym powodzeniem (jako jedyna)

Dzięki za odpowiedź. Jednak nie o dyskusję jakie one są mi chodziło, tylko czy w praktyce są one stosowane, oczywiście w polskich przedsiębiorstwach. Kiedyś trafiłem na post, w którym jeden człowiek mówił, że u niego w firmie wszystkie projekty są pisane z użyciem SPL i nikt nie narzekał. Jestem ciekaw jak sprawa wygląda biorąc ogląd na inne firmy. Jeśli ktoś ma wiedzę na ten temat, to będzie miło jak coś napisze.

kaczor90 napisał:

Jeśli ktoś ma wiedzę na ten temat, to będzie miło jak coś napisze.

No przecież napisałem... Nie wiem jakiej odpowiedzi oczekujesz - konkretnych liczb ("w ostatnich 12-tu miesiącach SPL zostało użyte w 14235 projektach prowadzonych przez 52463 programistów w 8234 firmach") czy procentów ("SPL jest używany obecnie w 64,4436% firm, przy czym najwięcej używa się go na Warmii i Mazurach - 76,31% - a najmniej w okolicach Poznania - zaledwie 30,97%")?

Moim zdaniem to że projekty napisane z SPLem "działają" jest efektem tylko i wyłącznie tego, że STM32 ma wystarczający zapas mocy i układów peryferyjnych żeby podołać temu marnotrawstwu (;

Jado_one napisał:

Dopóki nie pojawią się w sieci przykłady inicjalizacji peryferiów STM'ów bez użycia bibliotek, to ciężko będzie przełamać monopol SPL.
Pytanie tylko czy komuś zechce się takie przykłady w sieci umieszczać?

Zupełnie nic by to nie zmieniło - tutaj mamy do czynienia z ludźmi którzy dadzą się pokroić żeby tylko napisać 10 linijek wypełniani dziwnej struktury zamiast 2 wpisów do rejestrów. Np ten wątek należy traktować w kategorii "ja też będę używał SPLa, bo jakaś firma go używa i jeszcze nie zbankrutowała" - czyli takie szukanie potwierdzenia swojego wyboru - już kiedyś był taki temat, niby "czy używać SPL?" a skończyło się na ostrej ewangelizacji że koniecznie trzeba go używać (;

Po prostu niektórzy chyba nie są w stanie ogarnąć, że zamiast tego:

UKLAD_InitStruct.Pole1 = Opcja1;
UKLAD_InitStruct.Pole2 = Opcja2;
UKLAD_InitStruct.Pole3 = Opcja3;
UKLAD_InitStruct.Pole4 = Opcja4;
UKLAD_InitStruct.Pole5 = Opcja5;
UKLAD_Init(&UKLAD_InitStruct);

Można zrobić po prostu to:

UKLAD->REG1 = UKLAD_REG1_Opcja1 | UKLAD_REG1_Opcja2 | UKLAD_REG1_Opcja3;
UKLAD->REG2 = UKLAD_REG2_Opcja4 | UKLAD_REG2_Opcja5;

Bo to naprawdę tak właśnie wygląda w rzeczywistości, włącznie z ładnymi nazwami itd.

Pewnie też część uprzedzenia do rejestrów wynika z tego, że dla niektórych "używanie rejestrów" jest tożsame z czymś takim:

SPI->CR1 = 0x8243FFAC;
SPI->CR3 &= 0xFFFC8845;
SPI->CR2 |= 0x40002000;

No to faktycznie - to powyżej to jest horror...

Kilka rzeczywistych przykładów:







Teraz porównaj sobie to z wywołaniami SPLa czy z jego wnętrznościami i jeśli powyższe przykłady są "niezrozumiałe", "nieczytelne" i "jakieś beznadziejne" to po prostu znaczy że może szydełkowanie albo ogrodnictwo byłyby lepszym wyborem niż STM32...

4\/3!!

Dziękuję Freddie. Jeśli masz liczby - może być Jeśli procenty - też. A jeśli nic, trudno.
Moje pytanie spowodowane jest opinią pewnego człowieka, który twierdzi że konieczne jest programowanie z użyciem SPL np. z powodu takiego, że bez tego praca zespołowa przy tworzeniu oprogramowania jest utrudniona i coś jeszcze wspomniał, ale nie pamiętam. Wydaje mi się również, że jeśli w jakiejś firmie piszą ciągle programy z SPL, to nie przyjdzie nowy pracownik i nie powie "nie, ja nie będę ich używał, bo są fe".
Nie rozumiem tych ataków na moją osobę, ale wybaczam Freddie. Zauważ, że nie napisałem o jakichkolwiek wątpliwościach czy ja mam ich używać czy nie. Dotychczas ich nie używałem i gdyby nie pewien doktorant, który mi dziś trochę naopowiadał, tego wątku by nie było. Prosiłbym o życzliwe odpowiedzi, jeśli ktoś chciałby dodać coś do dyskusji. Jestem autorem tego wątku, ja tu ustalam zasady

Freddie Chopin napisał:

Zupełnie nic by to nie zmieniło - tutaj mamy do czynienia z ludźmi którzy dadzą się pokroić żeby tylko napisać 10 linijek wypełniani dziwnej struktury zamiast 2 wpisów do rejestrów. Np ten wątek należy traktować w kategorii "ja też będę używał SPLa, bo jakaś firma go używa i jeszcze nie zbankrutowała" - czyli takie szukanie potwierdzenia swojego wyboru - już kiedyś był taki temat, niby "czy używać SPL?" a skończyło się na ostrej ewangelizacji że koniecznie trzeba go używać (;

W sumie racja. Każdy sam dokonuje wyboru - jeśli mu SPL działa i na jego potrzeby starcza, to OK. Jak w którymś momencie dojdzie do wniosku, że potrzebuje czegoś innego, to poszuka innych rozwiązań. Jak nie znajdzie ich w sieci, to ew. sobie sam napisze. Przy okazji się czegoś nauczy

Tak więc - nie robimy krucjaty przeciw (ani za) SPL
Zresztą to już było wałkowane.

Ten wątek nie powstał po to, żeby znów to wałkować. (patrz 1. post)

Jado_one napisał:

Swoją drogą, to chyba tylko my tutaj na Elektrodzie tak nisko oceniamy SPL...jak się popatrzy po zagranicznych forach, to tam bezkrytycznie je stosują.
Stąd prawie całkowity brak przykładów bez użycia SPL w internecie i literaturze.
I pomyśleć że opiera się to na demie

Kiedyś założyłem wątek na forum ST o to link:
https://my.st.com/public/STe2ecommunities/mcu...0D8867EAD444A5987D47BE638E0F¤tviews=385
Odpowiedzi były w stylu, że pisanie na rejestrach to jest programowanie z lat 80 mikrokontrolerów ala '51.
Ja jednak również nie używam SPL, są mało czytelne, dochodzi dodatkowa dokumentacja do czytania, nie wiadomo co w jakiej kolejności inicjalizować miały też na początku trochę błędów.

kaczor90 napisał:

Dziękuję Freddie. Jeśli masz liczby - może być Jeśli procenty - też. A jeśli nic, trudno.

Raczej nikt nie ma takich liczb... Jedni używają, inni nie - lepszej odpowiedzi raczej nie będzie (; W mojej poprzedniej pracy tylko ja nie używałem, mam swoje interpretacje tego faktu, ale muszą pozostać moją prywatną opinią (;

kaczor90 napisał:

Moje pytanie spowodowane jest opinią pewnego człowieka, który twierdzi że konieczne jest programowanie z użyciem SPL np. z powodu takiego, że bez tego praca zespołowa przy tworzeniu oprogramowania jest utrudniona i coś jeszcze wspomniał, ale nie pamiętam.

Praca zespołowa jest zależna od jakości oprogramowania które się tworzy - modułowości, abstrakcji, interfejsów itd. Osoba ta na 99% należy więc do kategorii która w "używaniu rejestrów" widzi tylko 0xF4AC8912 (pisałem o tym wyżej) - sorry.

kaczor90 napisał:

Wydaje mi się również, że jeśli w jakiejś firmie piszą ciągle programy z SPL, to nie przyjdzie nowy pracownik i nie powie "nie, ja nie będę ich używał, bo są fe".

To jest temat poboczny dla tej dyskusji <;

kaczor90 napisał:

Nie rozumiem tych ataków na moją osobę, ale wybaczam Freddie.

To było tak ogólnie, nie konkretnie - bez żadnych podtekstów. Szczególnie ta ostatnia cześć.

felekfala napisał:

Kiedyś założyłem wątek na forum ST o to link:
https://my.st.com/public/STe2ecommunitie...7EAD444A5987D47BE638E0F¤tviews=385
Odpowiedzi były w stylu, że pisanie na rejestrach to jest programowanie z lat 80 mikrokontrolerów ala '51.

Kolejny przykład niezrozumienia o którym piszę cały czas - takie osoby widzą albo SPL albo hexy, ewentualnie assemblera... A przecież można napisać DOBRĄ bibliotekę do DOWOLNEGO układu i byłoby OK. Problem jest tylko taki, że SPL nie jest dobry - on jest tragiczny (;

Wg tego "zrozumienia" to ja nie "używam rejestrów", bo przecież piszę swoje funkcje wyższego poziomu, a "używanie rejestrów" to by był program w jednej funkcji, 5000 linijek kodu, zero komentarzy, same hexy (ewentualnie liczby dziesiętne, bo hexy łatwiej skumać).

4\/3!!

Dzięki za cenne uwagi. Temat do zamknięcia, ale jeśli ktoś chciałby się jeszcze podzielić swoim doświadczeniem (zawodowym), z korzystaniem z STLiba, lub niekorzystaniem, będzie miło.

Pozwólcie na dorzucenie jeszcze krótkiego rysu historycznego. Jeszcze nie tak dawno silna była grupa wyznawców pisania w ASM, którzy mówili bardzo brzydkie rzeczy o C - przecież nic tak nie cieszy rasowego programisty jak "ręczne" mnożenie dwóch liczb 16bit zapisanych w U2 - tylko TAK pisze się OPTYMALNIE . Z biegiem czasu ich argumenty bardzo straciły na mocy. Można powiedzieć, że w większości współczesnych aplikacji praktycznie nie istnieją. Rączki do góry kto teraz takie rzeczy jak mnożenie czy obsługa LCD robi na piechotę! Kto się nie skalał użyciem gotowej biblioteki? Teraz uczestniczymy w kolejnym etapie rozwoju. Jest silna grupa nakazująca ręczne dłubanie w rejestrach - przecież tylko TAK jest OPTYMALNIE - nic tak nie cieszy rasowego programisty jak miotnięcie zaklęcia z pięknymi nazwami bitów dającym pełną kontrolę nad rejestrem Postęp jednak jest nieubłagany - powstaje SPL. W profesjonalnych projektach najważniejszym staje się skrócenie czasu do uzyskania w pełni funkcjonalnego produktu.
P.S. Pozdrowienia dla wszystkich mędrców, którzy twierdzą, że nie ma to jak dobrze wychłostać jakiegoś nieboraka, który próbuje na kolanach zapytać o coś obraźliwie banalnego.

Rox79 napisał:

W profesjonalnych projektach najważniejszym staje się skrócenie czasu do uzyskania w pełni funkcjonalnego produktu.

Nie byłbym taki pewny czy rozwiązaniem tego problemu jest akurat ta durna "biblioteka"... w ogóle całe porównanie kiepskie, bo tym sposobem ja mogę udowodnić, że skoro mamy postęp to wszystko należałoby robić stawiając Linuxa na ARM Cortex-A8...

4\/3!!

Rox:

Jest postęp i jest "postęp". Na 8051 czy PIC kod asemblerowy był znacznie szybszy niż kod C. O powodach można by długo pisać - jest kilka istotnych, i nie chodzi to bynajmniej o jakość kompilatorów. W przypadku ARM, czy nawet AVR dobry kompilator wygeneruje kod lepszy niż niezły programista (w AVR niekoniecznie). na ogół nie ma więc istotnych powodów, by na taki sprzęt pisać coś w asemblerze (chyba, że chodzi o jednostkę wektorową ARM, której kompilator chwilowo jeszcze nie ugryzie).

Tymczasem kod powstający wskutek użycia bibliotek jest koszmarnie długi, wolny i zasobożerny, a same biblioteki przykrywają kolejną warstwą sprzęt, literalnie NIC nie usprawniając. Jak już parę razy tu pokazywano, kod źródłowy (a nie tylko wynikowy) pisany z użyciem bibliotek jest znacznie dłuższy niż kod bez bibliotek. Gdzie więc ten "postęp"? Postęp nie polega na tym, że programista ma się uczyć nazw i znaczenia pól struktur zamiast nazw i znaczenia bitów w rejestrach.

Tak się składa, że od każdego, kto używał bibliotek (i to nie tylko od ST) i kto próbował pisać przy ich użyciu złożone, niezabawkowe programy, słyszałem, że biblioteki - to głównie źródło kłopotów. Użytkownicy bibliotek - to ci, co na różnych forach internetowych co chwila piszą, że im coś nie działa. Ciekawe, że zgłaszane przez nich problemy na ogół rozwiązują tacy, co bibliotek nie używają - elektroda nie jest tu wyjątkiem.

Bo trzeba powiedzieć sobie otwarcie - wszystko dla ludzi, byle rozsądnie, tak samo z biblioteką taką czy inną. Bez zrozumienia wszystkiego łykać nie należy. Zresztą w samej bibliotece niczego złego (pod względem idei) nie ma. W usprawnianiu pracy również.

Vendor lock-in to wada, ale jeśli sama biblioteka jest sensownie napisana nadal używać jej można, godząc się na ograniczenia. Taka Altera udostępnia do NIOS2 biblioteki, które pozwalają np. czytać/pisać na UART czy inne LCD1602 przy użyciu printfów, coutów itd. Tu jestem skłonny się zgodzić, że toto ma jakieś zadanie.

Jak mnie sesja przestanie gnieść to się wezmę za NutTX'a albo innego ChibiOSa bo gotowa warstwa HAL to świetna rzecz.

Ale poważnie, zastanawiam się co za różnica napisać
GPIO_SetBits(cośtam cośtam) czy jakoś tak, skoro mogę GPIOx->ODR | = wartość; albo jeszcze lepiej zrobić to z wykorzystaniem bit bandingu. Bo naprawdę abstrakcji wyższej tu nie ma.

pzdr.

edit: przeredagowałem trochę początek bo mi kawałek posta gdzieś wcięło. Zmian znaczących nie ma

Ja też dorzucę kilka słów. Pisałem przez 10 lat w asemblerze programy na 8051 i PIC'a (również na AVR'a tylko tu już asembler jest "ciężki") i wszystko działało jak trzeba. Asemblery były skierowane na użytkownika i powstawały całkiem zaawansowane programy matematyczne. Fakt - trzeba było trochę pomyśleć.
Teraz asembler jest budowany nie pod użytkownika tylko pod kompilator.
W "C" nawet małpa potrafi napisać program. Jak ten C-program wygląda to widać na forum - w skrócie "ojejejej nie działa" i "na pewno winni są inni (np. twórcy SPL)".
A co do biblioteki SPL to ktoś już napisał - można podejrzeć jak producentproponuje użycie urządzenia i zastanowić się czy wszystko z tej implementacji jest nam zawsze potrzebne. Faktem jest, że niektóre "patenty" stosowane w SPL są abstrakcyjne (np. wyliczanie wartości rejestrów pod określony "baudrate" do portu szeregowego ), ale nikt nie zmusza do ich stosowania.
Natomiast do tej pory wszystko z czego korzystałem w zakresie SPL działa i ma się dobrze (nie nadziałem się na mechanizm, który nie działał, ale dużo z tego nie korzystałem). Pewnie warto by było zebrać w jakimś osobnym wątku to co się sypie w SPL'u i na co należy uważać.

Natomiast wracając do CMSIS to np. w Keilu pojawił się mały ZONK. Oto można było sobie uruchomić kooprocesor (odznaczając w opcjach), ale zastosowanie standardowych nagłówków prowadziło do skutecznego ominięcia tego mechanizmu (przez kompilator) i wymuszenie obliczeń programowo. Dopiero użycie nagłówków z biblioteki prowadziło do wzrostu wydajności i uruchomienie FPU. Nie wiem czy coś się zmieniło w kolejnej wersji (nie sprawdzałem), ale widać, że nie wszystkie biblioteki są "be"

kemot55 napisał:

Faktem jest, że niektóre "patenty" stosowane w SPL są abstrakcyjne (np. wyliczanie wartości rejestrów pod określony "baudrate" do portu szeregowego ), ale nikt nie zmusza do ich stosowania.

To jest bardzo fajna sprawa przecież [; (w sensie takie podejście) Sam stosuje w swoich bibliotekach - wpisujesz częstotliwość i nic Cię nie obchodzi jak sobie to funkcje wyliczą. Całkiem przydatne np. w przypadku SPI, PLL, UARTa itd. [;

4\/3!!

W tym rzecz, że ja też miałem i mam makro do policzenia wartości rejestrów dla UART (i nie tylko). Dawniej wyliczało sobie precyzyjnie "mantysę" i "frakcję" - całe trzy skomplikowane linie (bazowałem trochę na SPL . A teraz to już jest jedna, krótka linia.
Biblioteka używa na to 2k kodu i działa (w wyniku) tak samo .
Tyle, że ja "w locie" nie zmienię prędkości na dowolną inną (a używając SPL mam taką możliwość). Użyteczne? -> dla mnie marginalne, ale tak jak pisałem wcześniej, każdy może sobie wybrać co chce.

kemot55 napisał:

W tym rzecz, że ja też miałem i mam makro do policzenia wartości rejestrów dla UART (i nie tylko). Dawniej wyliczało sobie precyzyjnie "mantysę" i "frakcję" - całe trzy skomplikowane linie (bazowałem trochę na SPL . A teraz to już jest jedna, krótka linia.
Biblioteka używa na to 2k kodu i działa (w wyniku) tak samo .

Ten temat jest akurat ciekawy, bo te wyliczenia baudrate z dokumentacji są totalnie besensu - w uproszczeniu to równanie to jest po prostu magistrala/baudrate i nie ma ŻADNEJ różnicy między wynikami takiego jednego dzielenia i tymi z mantysami, frakcjami i tym podobnymi bzdurami... Nie wiem w ogóle po co oni to tak opisali w manualu...

Zupełnie inną sprawą jest to, że tak czy siak takie obliczenia da się zrobić optymalnie, a że się twórcom SPL nie chciało... Po co, skoro wrzyscy użytkownicy SPL są wręcz wniebowzięci [; W swoich przykładowych projektach mam gdzieś funkcję wyliczającą w poczwórnie zagnieżdżonej pętli ustawienia PLL dla stm32 connectivity-line i podobnie zakręcone obliczenia dla LPC17xx - wyliczenia baudrate są prostsze (nawet tym bzdurnym sposobem z manuala), a te moje funkcje zajmują bardzo mało (; Gdzie im do 2kB [;

4\/3!!

A tak swoją drogą - SPL SPLem, miał ktoś do czynienia z analogiczną biblioteką od NXP? Może jest lepiej (chociaż sądząc z tego jak w jakimś innym topicu Freddie się krzywił, to niekoniecznie)?
A takie TI np.? Bo z tego co wiem też ma swoją bibliotekę do Stellarisów, jak będę miał chwilkę na zabawę Launchpadem LM4F120 to obadam co oni tam nawywijali (póki co OpenOCD skompilowałem pod ich jtaga )

alagner napisał:

A tak swoją drogą - SPL SPLem, miał ktoś do czynienia z analogiczną biblioteką od NXP? Może jest lepiej (chociaż sądząc z tego jak w jakimś innym topicu Freddie się krzywił, to niekoniecznie)?

Czy jak powiem, że plik źródłowy z funkcjami dla GPIO ma 782 linijki, a dla UARTa 1367 to wystarczy za komentarz?

4\/3!!

W moim przypadku to wygląda tak, że mam wypracowaną własną warstwę abstrakcji sprzętu. Przykładowo do SPI jest maszyna stanów co mieli strumień bajtów danych + nagłówek z kolejek (typu FIFO jako bufor cykliczny). Pod to callbacki do sprzętu (open, write, read, close, ioctl), i rybka czy w środku jest if (queue) wyslij czy na przerwaniach. Nagłówek zawiera tylko potrzebne pola, jak adres do funkcji machania CS. W projekcie mam folder arch (Zynq, STM32, LPC1xxx i itp..), i tylko makrem załatwiam podmianę sprzętu i trach wszystko działa A tak (przykładowo) bym musiał kombinować i mieszać między różnymi SPL'ami, stykiem między obsługą czegoś a sprzętu, nie potrzebne kłopoty i duży rozrost kodu. A tak mam wszystko ujednolicone W callback'ach do sprzętu jest tylko odwołanie bezpośrednie do rejestrów.

Coś takiego:

C to piękny język, a C++ to poezja w świecie embedded Efekt nie do uzyskania w assemblerze, bo niby jak ?

Ostatnio trafiła mi się robota przepisania softu na pewien sprzęt...
Poprzedni soft w oparciu o SPL zakatował biednego STM32F105 tak, że nie wyrabiał się z powierzonymi mu zadaniami: przepełniały mu sie kolejki, były zwiechy, częste restarty...
Procek popędzony na 36MHz (czyli max dla HSI) pożerał baterię jak tylko mógł, żeby choć trochę postarać się wykonywać zadania, jak niewolnik pracować z bateryjnego zasilania i mimo to dawać z siebie wszystko...

Powstał ekwiwalentnie działający kod pisany "przy sprzęcie". Bez wykorzystywania SPL, sterty, nadmiernej ilości mutexów i semaforów, RTOSowych kolejek, i koszmarnych ilości stosu. Kod klepany w czystym C, i tylko i wyłącznie dłubanina przy rejestrach. Maksymalne wykorzystanie mozliwości procesora (bit banding, przerwania zagniezdzone dla time critical data, DMA...)
Efekt: procesor ma wakacje nawet z zegarem 16MHz; kosztem tylko zwiekszenia statycznie zuzywanego RAMu o jakies 30%...

Nie, nie chwalę się. Zadajcie sobie pytanie dlaczego chociażby stare wersje Quake (2 lub 3A) potrafily chodzić na trup sprzętach płynnie, a następnie odpowiedzcie sobie na to pytanie czytając książkę Michael Abrash's Graphics Programming Black Book...