CMSIS vs HAL vs Standard Peripherals Library

Zmieniam więc PIC na ARM i kupiłem płytę odkrywczą STM32F4. Jak dotąd rozumiem, że aby go zaprogramować, możesz albo uzyskać dostęp do wszystkich rejestrów bezpośrednio w pamięci (oczywisty sposób), a także istnieją 3 główne biblioteki, których możesz użyć, aby ułatwić Ci życie. Teraz moje pytanie brzmi: który z tych 3 (CMSIS, HAL, Std Peripherals Lib) jest najbardziej NISKI? to znaczy. ten z mniejszym kosztem. Moim celem jest poznanie wewnętrznego działania kontrolera i nie ułatwienie mojego życia (tylko trochę), dlatego chciałbym wiedzieć, który z nich jest bliżej rdzenia, bez uciekania się do montażu.

Zdecydowanie CMSIS. To nie jest dokładnie biblioteka, zawiera głównie definicje różnych rejestrów.

To jest dokładnie to, czego trzeba, aby łatwo uzyskać dostęp do rejestrów mikrokontrolera, aby zaimplementować własny HAL. Nie ma narzutu, ponieważ po prostu uzyskujesz dostęp do rejestrów.

Należy pamiętać, że CMSIS, w przeciwieństwie do pozostałych dwóch, jest zdefiniowany przez ARM, a nie ST. Oznacza to, że różne biblioteki CMSIS dla różnych mikrokontrolerów są dość podobne, co znacznie ułatwia przenoszenie.

Co więcej, CMSIS jest prostszy, więc jest (IMO) najbardziej wszechstronny i najbardziej niezawodny, z prawdopodobnie mniejszą liczbą błędów (lub ich brakiem). Niektóre biblioteki hal dla różnych mcu, z których korzystałem, są dość niesławne ze względu na swoje błędy.

Z drugiej strony CMSIS wymaga od ciebie znacznie więcej pracy. Jest to jednak mój osobisty wybór, ponieważ wolę inwestować czas w tworzenie bibliotek wysokiej jakości, które odpowiadają moim potrzebom, i zrozumienie, jak działa układ, po prostu spędzanie czasu na naukę nowej biblioteki.

Aby dowiedzieć się, jak to działa, nie chcesz używać żadnego z powyższych. Pobierz kompilator z ramieniem krzyżowym i dokumentację od st, gotowe. Zacznij kodować. te układy są na ogół bardzo łatwe do zaprogramowania. dokumentacja mówi ci, jakie bity w jakich rejestrach robią co.

Każda / wszystkie z tych bibliotek mają na celu usunięcie tego zrozumienia / obciążenia / pracy i sprawienie, że poczujesz się jak zwykłe wywołanie aplikacji podobnej do interfejsu API. Tego właśnie chce wielu ludzi. Możesz użyć wszystkich źródeł dla tych bibliotek, aby pomóc zrozumieć, ale gdy stajesz się lepszy, możesz znaleźć dziury i problemy w bibliotekach, czasami bardzo przerażający kod. kod zrzucony razem, napisany ogólnie i z grubsza przeniesiony z jednego układu do drugiego, być może funkcje wspierające, których nie ma twój układ itp. I wszystkie mają nadmierny narzut. 10 do 100 razy za dużo kodu do zadania, na pewno wiele z nich może się zoptymalizować, ale dlaczego w ogóle tam jest?

Niezależnie od tego, czy korzystasz z własnej biblioteki, czy korzystasz z jednej z tych bibliotek, powinieneś nadal szukać źródła bibliotek, których używasz, aby sprawdzić, czy czujesz się dobrze z tym, co robią, jeśli ma to sens, pasuje do dokumentacji chipa itp. Kiedy coś idzie źle, prawdopodobnie musisz przekopać się przez ich rzeczy tak samo jak twoje, aby dowiedzieć się, dlaczego.

Pamiętaj, że dokumentacja chipowa też nie jest idealna, to część zabawy.

Nie rozumiem, dlaczego montaż pojawia się w dyskusji na temat programowania bez systemu metalowego. Możesz sobie poradzić przy bardzo małym montażu. W przypadku tych układów cortex-m technicznie potrzebujesz tylko tyle asm, aby zostać uruchomionym:

.globl _start
_start:
.word 0x20001000
.word main

Nie możesz polegać na danych ani bss i nie możesz powrócić z głównego z minimalną ilością asm. Ale to wszystko, czego POTRZEBUJESZ za najsłabszy metal. Teraz, jeśli chcesz robić przerwania, potrzebujesz więcej wpisów w tabeli wektorów. więcej linii .word. Polecam więcej asm, ale może 10 lub 20 linii więcej.

zwykle jest to cały asm, którego używam.

.cpu cortex-m0
.thumb
.thumb_func
.global _start
_start:
stacktop: .word 0x20001000
.word reset
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.thumb_func
reset:
    bl notmain
    b hang
.thumb_func
hang:   b .
.align
.thumb_func
.globl PUT16
PUT16:
    strh r1,[r0]
    bx lr
.thumb_func
.globl PUT32
PUT32:
    str r1,[r0]
    bx lr
.thumb_func
.globl GET32
GET32:
    ldr r0,[r0]
    bx lr
.thumb_func
.globl GET16
GET16:
    ldrh r0,[r0]
    bx lr
.thumb_func
.globl dummy
dummy:
    bx lr
.end

Tak, mówi cortex-m0, ale to jest faktyczny bootstrap dla mojego kodu m4. Wolę, żeby to był kciuk, a nie kciuk2. I po prostu ponownie używam tego kodu z jednej kory-m na drugą, zmieniając odpowiednio adres wskaźnika stosu, aby działał dla m0, m3 i m4. Nie mam jeszcze m7 ani nie badałem go zbyt wiele.

Włączenie procesora może wymagać kilku dodatkowych linii asm, ponieważ potrzebne są szczegółowe instrukcje. Ale nie chodzi o to, by programować na niskim poziomie i asm. C ma wszystko, czego potrzebujesz, aby skonfigurować układ, a także napisać aplikację. Biblioteki, o których mówisz, są napisane w C nie asm, więc oczywiście nie muszą używać asm.

Jeśli chcesz nauczyć się wewnętrznych mechanizmów, napisz własny kod. Nie używaj tych bibliotek innych niż jako odniesienie. Czasami łatwiej jest po prostu zhakować go, niż spróbować przeczytać jego kod. (nie tylko ST, ale wszyscy dostawcy. Jeden z dostawców miał wiersz kodu, więc niepokojące jest to, że używam go jako pytania do rozmowy kwalifikacyjnej, nie zamierzam go tutaj zamieszczać).

ST zdecydowanie, ale także inni dostawcy, aby oszczędzać energię, mają włączanie zegara dla części układu, więc zanim wejdziesz i spróbujesz mrugnąć diodę, musisz znaleźć bit włączania dla tego bloku gpio i sprawdzić, czy wyjdzie reset resetu włączony, jeśli nie, włącz go, rozmawiając z logiką gpio bez włączonego zegara, po prostu zawiesza procesor, czekając na odpowiedź logiki, która nigdy nie zareaguje. Nie zawsze mówią ci o tych możliwościach. Po włączeniu czasami przeprowadzają cię przez inicjację dla określonego urządzenia peryferyjnego. Dokumenty ST są całkiem dobre. Pochodząc z mikroczipa, który dostaje dość kiepską ocenę dokumentacji, nie powinieneś mieć problemu.

Korzystałem zarówno z dostępu do rejestrów typu bare metal, jak i ze standardowej biblioteki urządzeń peryferyjnych. Łatwiej jest mi zajmować się rejestrami. Również jeśli używasz debugera, możesz wyświetlić rejestry i potwierdzić, że zawierają one to, co zaprogramowałeś. Myślę, że w ten sposób dowiadujesz się więcej o działaniu układu.

Pochodząc ze świata 8-bitowego zawsze byłem przyzwyczajony do programowania urządzeń peryferyjnych za pomocą rejestrów. Arkusze danych mikrokontrolera (tj. Podręczniki STM32) opisują urządzenia peryferyjne wyłącznie w notacji rejestru. Ponieważ programista musi przeczytać tę samą dokumentację, aby wiedzieć o funkcjach i funkcjach peryferyjnych, zanim zostanie podjęta jakakolwiek próba ich użycia, wydaje mi się, że rozpoczęcie programowania rejestrów wydaje się naturalne. Dzięki ostrożnemu układowi kodu i komentowaniu, kod można przyjemnie przeczytać i zmodyfikować nawet po powrocie do niego kilka miesięcy później.

Do tej pory korzystałem z definicji CMSIS i bezpośrednio korzystałem z rejestrów. Tymczasem korzystałem z bibliotek HAL w kilku projektach. Miało to znaczący wpływ na czas działania kodu, więc go rzuciłem. Mimo że CMSIS służy mi zainteresowaniem, w dzisiejszych czasach będę fanem libopencm3 . To jest jak LLbiblioteki dostarczone przez ST. Obejmuje jednak więcej mikrokontrolerów, nawet w rodzinach ST:

Projekt libopencm3 (wcześniej znany jako libopenstm32) ma na celu stworzenie darmowej / libre / open-source biblioteki oprogramowania dla różnych mikrokontrolerów ARM Cortex-M3, w tym ST STM32, Toshiba TX03, Atmel SAM3U, NXP LPC1000 i innych.

proszę to zanotować:

Pomimo nazwy libopencm3 obsługuje również inne „powiązane” mikrokontrolery ARM Cortex, takie jak na przykład Cortex-M0 lub Cortex-M4 / Cortex-M4F.

listę obsługiwanych mikrokontrolerów można znaleźć tutaj .