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

Programowanie ARM - Płytka Nucleo

12 Sie 2017 10:45 1815 39
  • Poziom 5  
    Witam. Chcę zapoznać się z programowaniem mikrokontrolerów ARM. Czy płytka
    "STM32 NUCLEO-F103RB - STM32F103RBT6" będzie odpowiednia na początek?
    Czytałem, że najlepiej zacząć naukę właśnie od rdzenia M3.
  • Computer Controls
  • Użytkownik usunął konto  
  • Poziom 5  
    Narazie nie zależy mi na energooszczędności.
    Nie wiem czym dokładnie różnią się te uC.
    Lepiej wziąć F411 czy F401? One różnią się tylko taktowaniem?
  • Computer Controls
  • Poziom 1  
  • Użytkownik usunął konto  
  • Specjalista - Mikrokontrolery
    Jeśli Nucleo-64, to proponuję L476 lub nową L452 - znacznie mądrzejsze od F4 i z większą pamięcią RAM
  • Specjalista - Mikrokontrolery
    Poczekaj na STM32H7xx, nikt już nie będzie narzekać , że coś jest za stare!

    Na początek bierz najprostsze i najtańsze, ale nie chińskie i nieważne czy stare czy nowe. Jak już stwierdzisz, że ogarniasz to co masz, będziesz mógł przebierać w tym co Ci będzie najlepiej pasować.
  • Użytkownik usunął konto  
  • Poziom 1  
  • Specjalista - Mikrokontrolery
    O czym Wy piszecie, zejdźcie na ziemię. Spójrzcie najpierw na posty kolegi kamill_94 i problemy z jakimi się zmaga.
    I niech kolega kamill_94 nie liczy na jakiekolwiek gotowce, aktualne poradniki itp...
    Marek_Skalski napisał:
    Nie trzeba czekać. Są dostępne


    Gdzie? Sample mnie nie interesują. przydałby się jakiś Discovery jak do stm32f769...
  • Użytkownik usunął konto  
  • Specjalista - Mikrokontrolery
    Dla mnie to jest bez różnicy co on kupi i tak może jednemu promilowi kupujących te disco, nucleo itp udaje się cokolwiek na tym samemu odpalić.
  • Poziom 1  
  • Użytkownik usunął konto  
  • Specjalista - Mikrokontrolery
    Marek_Skalski napisał:
    Tutaj jest Nucleo-H743ZI. Inna opcja, to pogadać z lokalnym przedstawicielem ST.
    Za biedne. Poczekam na disco.
  • Poziom 1  
  • Specjalista - Mikrokontrolery
    Marek_Skalski napisał:
    @michalko12 To jest lepsze niż disco.
    EVAL
    Jaka wymówka teraz? Za drogie?

    Nie wiem o co Ci chodzi.
    Wiem o tym zestawie od dawna. Nie potrzebuję wydawać czyjejś kasy tylko po to żeby sobie potestować i potem odłożyć na półkę. Teoretycznie mógłbym zadowolić się F769 disco, ale zależy mi na dp-fpu. Nie śpieszy mi się, poczekam na H7 disco, na razie mam co robić. Procesorów i tak dalej nie ma w sprzedaży, a miały pojawić się w drugim kwartale.
    Piotrus_999 napisał:
    @michalko12 Daj numer karty to zamówię dla Ciebie. Zaoszczędzisz na przesyłce :)
    Zamilknij.
  • Poziom 5  
    michalko12 napisał:

    I niech kolega kamill_94 nie liczy na jakiekolwiek gotowce, aktualne poradniki itp...


    Nie liczę na gotowce. Wiem, że ich nie ma zbyt wiele. Ale chyba jednak są ludzie, którzy umieją programować takie uC i jakoś to ogarnęli?

    Nie chcę na początek wydawać dużo pieniędzy, bo poprostu chcę się zapoznać z ARM i wtedy będę decydował co dalej. Czy w takim przypadku płytka Nucleo z F411 będzie dobrym wyborem w cenie do 100zł? Wiem, że sam mogę sobie porównać uC z tych płytek, ale z ARM nigdy nie miałem styczności i nie wiem dokładnie na co zwracać w nich uwagę.
  • Poziom 1  
  • Specjalista - Mikrokontrolery
    kamill_94 napisał:
    Nie liczę na gotowce. Wiem, że ich nie ma zbyt wiele. Ale chyba jednak są ludzie, którzy umieją programować takie uC i jakoś to ogarnęli?

    Może jednej osobie na 1000 to się udaje. W każdym bądź razie ja nie widzę, żeby na elektrodzie przybywało tych osób.

    Zanim cokolwiek kupisz dobrze zapoznaj się z dostępną dokumentacją. Sprawdź czy jesteś w stanie zrozumieć co jest tam napisane, bo być może dzięki temu zaoszczędzisz 100zł.
  • Pomocny post
    Użytkownik usunął konto  
  • Pomocny post
    Poziom 1  
  • Poziom 27  
    Piotrus_999 napisał:
    Na początek proponuję poradnik kol. Szczywronka - https://www.elektroda.pl/rtvforum/download.php?id=726496,, napisany językiem lekkim ,tłumaczącym podstawy.

    Bardzo fajny poradnik, pisany zrozumiale i z humorem, który mi osobiście odpowiada :D
    Jedno, nad czym się zastanawiam, to ewentualna czytelność kodu, gdy wraca się do niego po dłuższym czasie albo gdy pracuje nad nim więcej osób... Są tam fajne porównania objętości kodu przy użyciu SPL i bez bibliotek - bardzo trafne i podzielam. Nie da się natomiast ukryć, że konfigurując strukturę z SPL i wywołując funkcję init, mamy jak na dłoni co z jakimi ustawieniami hula. Późniejsza zmiana czegokolwiek jest prosta, bo opiera się na zdefiniowanych, czytelnych maskach bitowych. W sumie dodatkowe komentarze są zbędne. Konfigurując pojedyncze bity w rejestrach trzeba albo dobrze komentować kod (czasem zdarzają się potem rozjazdy pomiędzy komentarzem a poprawioną przy testowaniu konfiguracją) albo pod ręką zawsze mieć odpowiednią stronę RM / PM itp. żeby w ogóle wiedzieć co to robiło...
    Jakie Wy macie sposoby, aby kod był czytelny w takiej sytuacji? :)
  • Użytkownik usunął konto  
  • Poziom 27  
    Piotrus_999 napisał:
    masz pewność że używasz czegoś prehistorycznego, pełnego błedów i porzuconego przez STM-a lata temu
    hehehe :-) Przy okazji może spytam, czy z HALem jest cokolwiek lepiej?
    Nie chcę tu oczywiście wznawiać dyskusji "bibliotekarze" kontra... hmm.. jak ich nazwać? "rejestrownicy"? ;-) Pytam szczerze i bez podtekstów :-)

    No i nie odpowiedziałeś na moje kluczowe pytanie jak zwiększyć czytelność "bitoustawiacza" :-)
  • Specjalista - Mikrokontrolery
    krisRaba napisał:
    Jakie Wy macie sposoby, aby kod był czytelny w takiej sytuacji?

    Wystarczy napisać swoje funkcje, czytelniejsze od obydwóch rozwiązań. Funkcje z HAL/SPL są tak słabe, że nie trzeba być żadnym h4x0rem żeby napisać coś lepszego.
  • Poziom 27  
    W sumie fakt - odpowiednie nazwy funkcji i parametrów sporo mogą pomóc :-) A docelowo tworzycie jakiś szereg definicji / aliasów / masek, czy zawsze na żywca poszczególne bity? ;-)
    Z tym ogólnie pewnie jest problem, bo czasami dane ustawienie wymaga zmian w kilku rejestrach, stąd potem funkcje "dekodujące" są takie pokrętne ;-)
    Przy rozpoczynaniu zabawy jest ta trudność, że wiele rzeczy trzeba wyskrobać od zera, na co schodzi dużo więcej czasu, choć oczywiście z czasem sytuacja się polepsza...
  • Specjalista - Mikrokontrolery
    krisRaba napisał:
    A docelowo tworzycie jakiś szereg definicji / aliasów / masek, czy zawsze na żywca poszczególne bity?

    Przecież już są stworzone w nagłówkach od producenta. Nikt tutaj nie proponuje pisania programów w stylu "REGISTER |= 0x35fabc99;" albo "REGISTER |= (1 << 11) | (7 << 3);". Zamiast takich hieroglifów można przecież napisać "SPI1->CR1 = SPI_CR1_SSM | SPI_CR1_SSI | SPI_CR1_SPE | SPI_CR1_BR | SPI_CR1_MSTR;" (przykład - https://github.com/DISTORTEC/distortos/blob/f...v1/STM32-SPIv1-ChipSpiMasterLowLevel.cpp#L487 ) i naprawdę nie jest trudno się domyślić co się tutaj dzieje, bez dodatkowych komentarzy.
  • Poziom 27  
    Freddie Chopin napisał:
    Nikt tutaj nie proponuje pisania programów w stylu "REGISTER |= 0x35fabc99;" albo "REGISTER |= (1 << 11) | (7 << 3);"

    To akurat wiem :D

    Bardziej chodziło mi o coś podobnego do rozwiązań znanych mi z XMEGA, że zamiast pojedynczych bitów xyz_CS_0, xyz_CS_1, xyz_CS_2 ustawianych w rejestrze XYZ dla uzyskania jakiegoś zegara, stosowane są maski typu xyz_CS_CLKDIV8_bm, xyz_CS_CLKDIV16_bm itp. W ten sposób nie każda zmiana wiąże się z wertowaniem datasheeta i szukaniem tabelki jak poszczególne wartości bitów mają się do wynikowej opcji. Osobne bity oczywiście też są zdefiniowane i można sobie ich używać, ale maski mi osobiście bardzo przypadły do gustu :-)
    Chyba że po pewnym czasie używania danego MCU znaczenie poszczególnych bitów staje się tak oczywiste, że i bez manuala wiadomo co robią... pomijam oczywistości typu RXIE, TXIE itp ;) No i szczególnie tam gdzie jest grupa bitów wybierająca jakąś opcję, a nie pojedynczy bit, to maski ułatwiają życie :)

    I dzięki za przykład kodu :)