Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Programowanie ARM - Płytka Nucleo

kamill_94 12 Sie 2017 10:45 1296 39
  • #1 12 Sie 2017 10:45
    kamill_94
    Poziom 4  

    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.

  • #2 12 Sie 2017 11:36
    Piotrus_999
    Poziom 39  

    Będzie najgorsza bo to bardzo stara rodzina i peryferia STM-a w nowszych są zupełnie inne. Na F1xx szkoda czasu. Kup sobie płytkę z F0, F3 albo F4. Ze wskazaniem na 2 ostatnie. Możesz też z serią Lx - jeżeli planujesz aplikacje energooszczędne. J

  • #3 12 Sie 2017 14:22
    kamill_94
    Poziom 4  

    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?

  • #4 12 Sie 2017 14:29
    Marek_Skalski
    Poziom 33  

    Tutaj jest najlepsze źródło informacji na temat: STM32F4
    Porównania, dokumentacja, szczegółowe opisy i linki do narzędzi.

  • #5 12 Sie 2017 17:05
    Piotrus_999
    Poziom 39  

    Je zeżeli do nauki i poznawania kolejnych peryferiów to ja bym proponował 429Zi jako że jest rozsądna w cenie, a zarazem możesz sobie na niej przećwiczyć praktycznie wszystkie peryferia STM-a włacznie z LCD DMA2D itd.

  • #6 13 Sie 2017 10:38
    BlueDraco
    Specjalista - Mikrokontrolery

    Jeśli Nucleo-64, to proponuję L476 lub nową L452 - znacznie mądrzejsze od F4 i z większą pamięcią RAM

  • #7 13 Sie 2017 10:40
    michalko12
    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ć.

  • #8 13 Sie 2017 11:52
    Piotrus_999
    Poziom 39  

    michalko12 napisał:
    Na początek bierz najprostsze i najtańsze, ale nie chińskie i nieważne czy stare czy nowe.
    Nie słuchaj - przede wszystkim dobrze wybrałeś nucleo bo masz od razu stlink-a w wygodnej postaci. Za 50 zł różnicy w cenie "dużego" nucleo zaoszczędzisz sobie kupowania kolejnych płytek + jako bonus bedziesz miał od razu złącza i interfejsy USB i Ethernet a za to też trzeba zapłacić dodatkwo jak nie ma

  • #9 13 Sie 2017 12:20
    Marek_Skalski
    Poziom 33  

    michalko12 napisał:
    Poczekaj na STM32H7xx,

    Nie trzeba czekać. Są dostępne :)
    Piotrus_999 napisał:
    Nie słuchaj - przede wszystkim dobrze wybrałeś nucleo

    Popieram Kolegę. Nucleo 144 to bardzo dobra baza do prototypowania. Nie tylko ze względu na St-Linka czy zainstalowane interfejsy, np. Ethernet, ale przede wszystkim ze względu na swobodę wykorzystania pinów i możliwość przenoszenie interfejsów, aby uniknąć konfliktów. Przykładowo w Nucleo 64 dość często nie da się wykorzystać żadnego portu szeregowego, poza tym podłączonym do St-Linka. Albo pojawiają się konflikty typu: albo I2C, albo USART. Niestety, niektóre Nucleo 144 nie mają zainstalowanych wszystkich interfejsów.
    Nazbierałem podczas szkoleń płytek Discovery i prawdę mówiąc, są zbyt "sztywne" do projektowania. Niemal wszystkie piny są gdzieś podłączone, co sprawia duże trudności kiedy chcesz podłączyć coś jeszcze. Odłączanie najczęściej tylko z lutownicą.
    Płytki oparte na STM32F103C8, są bardzo tanie, mają wszystko co potrzebne do pracy uC, nie mają St-Linka i mają jedną dużą wadę: przestarzały mikrokontroler. Jeżeli piszesz program na poziomie rejestrów, to przenosząc go na inny (nowszy) uC, wszystko trzeba przepisywać.

  • #10 13 Sie 2017 12:48
    michalko12
    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...

  • #12 13 Sie 2017 12:55
    michalko12
    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ć.

  • #13 13 Sie 2017 13:00
    Marek_Skalski
    Poziom 33  

    Tutaj jest Nucleo-H743ZI. Inna opcja, to pogadać z lokalnym przedstawicielem ST.

  • #14 13 Sie 2017 13:01
    Piotrus_999
    Poziom 39  

    michalko12 napisał:
    i tak może jednemu promilowi kupujących te disco, nucleo itp udaje się cokolwiek na tym samemu odpalić.
    W myśl tej zasady to lepien nawet niczego nie próbować.

  • #15 13 Sie 2017 13:18
    michalko12
    Specjalista - Mikrokontrolery

    Marek_Skalski napisał:
    Tutaj jest Nucleo-H743ZI. Inna opcja, to pogadać z lokalnym przedstawicielem ST.
    Za biedne. Poczekam na disco.

  • #16 15 Sie 2017 15:20
    Marek_Skalski
    Poziom 33  

    @michalko12 To jest lepsze niż disco.
    EVAL
    Jaka wymówka teraz? Za drogie?

  • #18 15 Sie 2017 23:14
    michalko12
    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.

  • #19 17 Sie 2017 17:40
    kamill_94
    Poziom 4  

    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ę.

  • #20 17 Sie 2017 17:55
    Marek_Skalski
    Poziom 33  

    Lepszą opcją jest Nucleo L476RG, ponieważ na stronie ST znajdziesz materiały w formie webinarium (po zarejestrowaniu). Więcej peryferiów znajdziesz w L496ZG. Jeżeli chciałbyś więcej peryferiów analogowych to F303ZE. A jeżeli interesuje Cię wydajność, to polecam F767ZI, ew. F746ZG. Na początek pewnie wystarczy :)

  • #21 17 Sie 2017 18:45
    michalko12
    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
    #22 17 Sie 2017 19:13
    Piotrus_999
    Poziom 39  

    michalko12 napisał:
    Może jednej osobie na 1000 to się udaje.


    To się jest się dowartościować. kol @michalko12 tak myśli. Jeżeli 1% populacji interesuje się uC (bardzo optymistyczny wariant) a tylko 1/1000 z nich jest w stanie opanować ARM-y to ja (m12) zaliczam się do (w najgorszym razie) grupy 1/100000 najwybitniejszych - czyli w Polsce elitarnej 400tki powiedzmy.

    To co piszesz to totalna bzdura, i kol. @kamill_94 niech w ogóle nie czyta tego. Na początek proponuję poradnik kol. Szczywronka - https://www.elektroda.pl/rtvforum/download.php?id=726496,, napisany językiem lekkim ,tłumaczącym podstawy. Nie jest to trudniejsze niż arduino

    michalko12 napisał:
    Sprawdź czy jesteś w stanie zrozumieć co jest tam napisane, bo być może dzięki temu zaoszczędzisz 100zł

    Jakaż w tym zarozumiałość i pogarda dla pytającego.

  • Pomocny post
    #23 17 Sie 2017 20:02
    Marek_Skalski
    Poziom 33  

    @kamill_94
    Jest dużo osób, które radzą sobie z programowaniem uC. ARM, AVR, PIC, 'C51 czy inny rdzeń, to tylko inny zestaw rozkazów. O ile nie piszesz w asemblerze, a dzisiaj to już rzadkość, to naprawdę nie ma większej różnicy. Więcej różnic zauważysz w peryferiach, ich obsłudze i możliwościach systemu jako całości. To nie jest tak, że ARM pozwala na wszystko, to tylko 32-bitowy rdzeń z ograniczonym taktowaniem i peryferiami, ale też z określonym zapotrzebowaniem energetycznym. Szczęśliwie, całkiem dobrze wypada w różnych obszarach i dlatego rośnie popularność uC opartych na rdzeniach Cortex-Mx. Jeżeli napotkasz trudności, to najpierw szukaj odpowiedzi w dokumentacji, a dopiero później pytaj na Forum. Jeżeli pominiesz pierwszy etap, to dostaniesz standardową odpowiedź RTFM :) Dasz radę!

    michalko12 napisał:
    Zanim cokolwiek kupisz dobrze zapoznaj się z dostępną dokumentacją.

    Rozwijając tę myśl, to amatorzy powinni najpierw pisać programy na kartce, bo szkoda miejsca na dysku i czasu na naukę obsługi jakiegoś Eclipsa czy innego IDE. Co nie? Kolego @michalko12, w tym temacie i w wielu tematach arduino stale na coś narzekasz i krytykujesz. Nie jesteś ani trochę pomocny, ani trochę inspirujący i prezentujesz jakiś dziwny typ zgorzknienia. Jaki sens ma dobre zapoznanie się z dokumentacją? Nigdy nie miałem potrzeby studiować specyfikacji (DS,ER) czy instrukcji (PM,RM) w całości; biorę to co potrzebuję i tyle. I działa.
    Nie wiem dlaczego nie przybywa ludzi na Elektrodzie w temacie ARM. Jeżeli Administrator prowadzi statystyki, to pewnie może coś powiedzieć. Z pewnością nie przybywa specjalistów, ponieważ każdy zaczyna jako amator, a z takim wsparciem jakie prezentujesz, to niestety nawet mój entuzjazm spada do zera.

  • #24 21 Sie 2017 23:20
    krisRaba
    Poziom 23  

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

  • #25 22 Sie 2017 00:15
    Piotrus_999
    Poziom 39  

    krisRaba napisał:
    że konfigurując strukturę z SPL
    masz pewność że używasz czegoś prehistorycznego, pełnego błedów i porzuconego przez STM-a lata temu

    Czytelność tych struktur - hmmmmm...... no nie wiem

  • #26 22 Sie 2017 06:56
    krisRaba
    Poziom 23  

    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" :-)

  • #27 22 Sie 2017 08:00
    Freddie Chopin
    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.

  • #28 22 Sie 2017 08:47
    krisRaba
    Poziom 23  

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

  • #29 22 Sie 2017 09:14
    Freddie Chopin
    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.

  • #30 22 Sie 2017 10:06
    krisRaba
    Poziom 23  

    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 :)

 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME