Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Kategoria: Kamery IP / Alarmy / Automatyka Bram
Montersi
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

STM32, jak zacząć przygodę z nimi?

mas24 18 Cze 2015 08:09 5844 85
  • #1 18 Cze 2015 08:09
    mas24
    Poziom 16  

    Witam,

    Chcę zacząć przygodę z STM32. Zakupiłem już nawet płytkę STM32Discovery-Disco z prockiem Cortex M4, ale kolega "postraszył mnie", że na początek mogę sobie z tym nie poradzić i doradził "mniejsze" procki z tej rodziny. W związku z tym mam kilka pytań:
    1. Czy rzeczywiście jest duża różnica w programowaniu pomiędzy CortexM0 i M4?
    2. Gdybym zdecydował się na początek na M0, np. STM32F051R8T6, to:
    a. Czy środowisko programistyczne jest takie samo? np. Eclipse?
    b. Czy do programowania wystarczy ST-LINK 2 wbudowany w płytkę Discovery?
    c. Przy programowaniu tego procka, czy można się spodziewać jakichś trudności, bugów czy innych pułapek?

  • #2 18 Cze 2015 08:28
    tadzik85
    Poziom 38  

    1. Różnica jest, ale znikoma. Dla początkującego ledwo zauważalna.
    2. a. środowisko to samo. Keil, Eclipse lub co sobie wybierzesz.
    b. Wystarczy, z takiego nucleo np można STlinka odłamać i używać jako zwykłego debugera.
    c. Trudności owszem. To już nie AVR. Tu pewne niuanse zaczynają mieć znaczenie. Np. czyszczenie flag przerwań.


    Na początek radzę poczytać tutoriala, materiały w sieci. Zapoznać się ze stroną Freddiego. Informacji nie brakuje.

  • #3 18 Cze 2015 09:30
    michalko12
    Specjalista - Mikrokontrolery

    mas24 napisał:
    1. Czy rzeczywiście jest duża różnica w programowaniu pomiędzy CortexM0 i M4?
    tadzik85 napisał:
    1. Różnica jest, ale znikoma. Dla początkującego ledwo zauważalna.
    Dla osoby początkującej w uC lub przechodzącej z AVR to rzeczywiście różnica jest niezauważalna, bo obydwa procesory to ta sama architektura, jest tylko jedna niewielka różnica - dokumentacja. Do CM0 jest dużo mniej stron do ogarnięcia na wstępie niż do CM4. Nie wyobrażam sobie zaczynania pisania programów na CMx bez jako takiego ogarnięcia zasady działania rdzenia. Do projektowania własnego urządzenia trzeba ogarnąć całą dokumentację, która dla CM0 jest o wiele prostsza i krótsza. Dla osób które siedzą już w Cortexach to wszystko jest łatwe, ale wiedzy na ten temat już łatwo oddać nie chcą, bo wiedzą ile czasu trzeba było poświęcić na ogarnięcie tego wszystkiego, jakieś jedno zagadnienie wyjaśnić to już pisać się nie chce bo można na ten temat referaty pisać. Pomoc w postach najczęściej sprowadza się do lakonicznych odpowiedzi w stylu "wszystko jest w manualu, poczytaj sobie". Na AVR jest pełno projektów DIY, pełno stron które opisują od początku do końca jak co jest zrobione, jak napisane itp. a na Cortexy co jest? Zdjęcie STM32Discovery z linkiem do githuba lub mbed i ot cały poradnik. Początkujący przesiadając się z AVR na CMx zderzy się z taką ilością nowych i innych rozwiązań w tych uC, że tylko nieliczni będą w stanie jako tako połapać się w tym i zrozumieć to.

    tadzik85 napisał:
    Informacji nie brakuje.

    W większości to przedruki z dokumentacji.

  • #4 18 Cze 2015 10:37
    mas24
    Poziom 16  

    No dobra, teraz jak zacząć od początku? Z tego, co mam to STM32Discovery-Disco z ST-LInkiem i prockiem,(którego na razie lepiej ni używać :) ), oraz surowego Eclipsa-Luna ściągniętego z jego strony domowej, którego mogę gdzieś sobie rozpakować, co dalej?

    Czy utworzyć sobie najpierw środowisko programistyczne w Eclipse i próbować chociaż kompilować jakieś przykłady z netu na sucho?

    Czy kupić jakiegoś procka STM32F1xx, zmajstrować sobie pod niego płytkę z LEDami, guzikami i innymi drobiazgami (ewentualnie zakupić gotowy zestaw ewaluacyjny)?

  • #5 18 Cze 2015 10:43
    tadzik85
    Poziom 38  

    mas24 napisał:
    No dobra, teraz jak zacząć od początku? Z tego, co mam to STM32Discovery-Disco z ST-LInkiem i prockiem,(którego na razie lepiej ni używać :) ), oraz surowego Eclipsa-Luna ściągniętego z jego strony domowej, którego mogę gdzieś sobie rozpakować, co dalej?

    Czy utworzyć sobie najpierw środowisko programistyczne w Eclipse i próbować chociaż kompilować jakieś przykłady z netu na sucho?

    Czy kupić jakiegoś procka STM32F1xx, zmajstrować sobie pod niego płytkę z LEDami, guzikami i innymi drobiazgami (ewentualnie zakupić gotowy zestaw ewaluacyjny)?


    Możliwości bez liku. ST niedawno wypuściło własne środowisko oparte na eclipse, można korzystać, choć opinia jest nie najlepsza.
    Jest wtyczka GNU ARM PLUGIN autorstwa liviu. Popularna.
    Zaawansowani używają makefile.

    Zapoznaj się z jakimś tutorialem. Nawet tu na forum ich nie brak. Bo znów wyważymy otwarte drzwi.

    Dodano po 2 [minuty]:

    michalko12 napisał:
    tadzik85 napisał:
    1. Różnica jest, ale znikoma. Dla początkującego ledwo zauważalna.
    Dla osoby początkującej w uC lub przechodzącej z AVR to rzeczywiście różnica jest niezauważalna, bo obydwa procesory to ta sama architektura, jest tylko jedna niewielka różnica - dokumentacja. Do CM0 jest dużo mniej stron do ogarnięcia na wstępie niż do CM4. Nie wyobrażam sobie zaczynania pisania programów na CMx bez jako takiego ogarnięcia zasady działania rdzenia. Do projektowania własnego urządzenia trzeba ogarnąć całą dokumentację, która dla CM0 jest o wiele prostsza i krótsza. Dla osób które siedzą już w Cortexach to wszystko jest łatwe, ale wiedzy na ten temat już łatwo oddać nie chcą, bo wiedzą ile czasu trzeba było poświęcić na ogarnięcie tego wszystkiego, jakieś jedno zagadnienie wyjaśnić to już pisać się nie chce bo można na ten temat referaty pisać. Pomoc w postach najczęściej sprowadza się do lakonicznych odpowiedzi w stylu "wszystko jest w manualu, poczytaj sobie". Na AVR jest pełno projektów DIY, pełno stron które opisują od początku do końca jak co jest zrobione, jak napisane itp. a na Cortexy co jest? Zdjęcie STM32Discovery z linkiem do githuba lub mbed i ot cały poradnik. Początkujący przesiadając się z AVR na CMx zderzy się z taką ilością nowych i innych rozwiązań w tych uC, że tylko nieliczni będą w stanie jako tako połapać się w tym i zrozumieć to.


    Dobrze powiedziane, lecz zanim przeszedłbym to niuansów rdzenia zapoznałbym się z podstawowymi peryferiami. Po co większa wiedza o rdzeniu jak ktoś jeszcze nawet pinem w MCU nie potrafi zamachać? Początkującym to wcale nie rdzeń sprawia problemy a peryferia.

  • #6 18 Cze 2015 10:52
    Steryd3
    Poziom 31  

    tadzik85 napisał:
    b. Wystarczy, z takiego nucleo np można STlinka odłamać i używać jako zwykłego debugera.

    Odpowiedź jest prawdziwa, z tym, że nie na to pytanie. Pytanie bowiem brzmiało:
    mas24 napisał:
    b. Czy do programowania wystarczy ST-LINK 2 wbudowany w płytkę Discovery

    Odpowiedź na nie TAK. Wszystkie płytki discovery z ST mają już na pokładzie STlinka którym można i programować i debbugować- jedyne co potrzebne to kabelek mini USB.
    michalko12 napisał:
    Na AVR jest pełno projektów DIY, pełno stron które opisują od początku do końca jak co jest zrobione, jak napisane itp. a na Cortexy co jest?

    Nie wiem czemu kolega ciągle o tych AVRach -owszem są one fajne do rozpoczęcia przygody z mikro-kontrolerami, dużo na nie przykładów...ale pytający nawet słowem się o nich nie zająkną.

    Co do wyboru środowiska...osobiście na początek chyba wybrał bym uVision od Keila. Może nie ma takiego fajnego interfejsu jak Eclipse ale za to po zainstalowaniu działa a nie trzeba się zmagać z problemami jeszcze na długo przed mrugnięciem diodą LED na mikrokontrolerze. Dużo przykładów na STM32 to projekty z Keila które jednym kliknięciem można w tym środowisku uruchomić zamiast odprawiać "chocholi taniec" jak ma to miejsce w Eclipse. Pewnie wielu się ze mną nie zgodzi stwierdzając, że zwyczajnie się na Eclipse nie znam ale jak ktoś jest zielony i dopiero wchodzi w jakiś temat to wystarczy mu walka z samym mikrokontrolerem zamiast z mikrokontrolerem i środowiskiem. Później oczywiście Eclips jak najbardziej. Warto też nadmienić, że uVision do STM32F0 jest bezpłatnie dostępny jako "nieokrojony".

  • #7 18 Cze 2015 11:14
    michalko12
    Specjalista - Mikrokontrolery

    tadzik85 napisał:
    Początkującym to wcale nie rdzeń sprawia problemy a peryferia.

    Ta... a potem pierwszy problem to HardFault bo stos nie ustawiony, drugi problem to zegary, trzeci to SPL i czwarty to magia w trakcie debugowania.

    Steryd3 napisał:
    Nie wiem czemu kolega ciągle o tych AVRach -owszem są one fajne do rozpoczęcia przygody z mikro-kontrolerami, dużo na nie przykładów...ale pytający nawet słowem się o nich nie zająkną.

    Po pierwsze, pisałem ogólnie o początkujących i nie zachęcałem do używania AVRów na początek. A po drugie to wiem, że kolega mas24 używa teraz intensywnie AVRa xmega, więc bez sensu byłoby wciskanie mu na początek AVR. Coś źle doczytałeś..

  • #8 18 Cze 2015 11:57
    mas24
    Poziom 16  

    Czyli idąc od początku, czyli wyboru środowiska, uVision wydaje się być prostym i skutecznym rozwiązaniem. Zaraz zobaczę co z tym i jak. Z postu wywnioskowałem, że nie ma on ograniczenia kodu?

  • #9 18 Cze 2015 12:21
    Steryd3
    Poziom 31  

    Keil uVison nie ma ograniczenia kodu ale tylko dla mikrokontrolerów z rodziny STM32F0 (trzeba tego poszukać) dla rodzin F1, F3, F4,... ograniczenie występuje choć nie przeszkadza ono w pisaniu prostych programów. Ogólnie do STM32 jest wiele środowisk... z tych nie opartych na Eclipse są chyba tylko właśnie Keil i IAR. Jedyną w pełni legalną i darmową wersją bez ograniczeń to środowisko Eclipse. Warto się z pewnością mu później przyjrzeć bo sam kod pisze się w nim wspaniale.

  • #10 18 Cze 2015 12:26
    mas24
    Poziom 16  

    Kolega dał mi się pobawić CooCox'em. To wygląda prawie jak Eclipse. uVision ściągnąłem ze strony Keila, ale ma ograniczenia kodu. Będę zaczynał od M0 (na początku wątku wymieniony procek przeze mnie został), więc wersja bez ograniczeń by się przydała. Nie tyle, ze będę na początek pisał długie programy, a raczej przechowywał we Flash dużą ilość danych.

  • #11 18 Cze 2015 13:47
    alagner
    Poziom 25  

    CooCox swego czasu był dość (jest?) zabugowany i działa(ł) średnio.

    Na początek proponowałbym Eclipse+EmbsysRegview+ARM Plugin. Do tego ref. manual i dokumentacja core'a oraz dokumentacja gcc ;)

  • #12 18 Cze 2015 13:57
    Freddie Chopin
    Specjalista - Mikrokontrolery

    mas24 napisał:
    No dobra, teraz jak zacząć od początku? Z tego, co mam to STM32Discovery-Disco z ST-LInkiem i prockiem,(którego na razie lepiej ni używać ), oraz surowego Eclipsa-Luna ściągniętego z jego strony domowej, którego mogę gdzieś sobie rozpakować, co dalej?

    Odpowiadam standardowo:
    http://www.elektroda.pl/rtvforum/topic1313509.html
    http://www.elektroda.pl/rtvforum/topic1339518-0.html

  • #13 18 Cze 2015 14:30
    mas24
    Poziom 16  

    OK, czyli od tego zacznę. Ten drugi wątek jest jakby uzupełnieniem pierwszego, powinno być OK. Jak będę miał jakieś problemy, napiszę w tym wątku.

  • #14 18 Cze 2015 18:08
    BlueDraco
    Specjalista - Mikrokontrolery

    Dla początkujących zdecydowanie polecam Keila - żadnych problemów z konfiguracją, uruchomieniem, tworzeniem projektu (w tym stosami), na które nadziejesz się w każdym innym środowisku DIY i nie-DYI.

    W Elektronice Praktycznej masz od blisko 2 lat serię artykułów o STM32 dla bardzo początkujących.

    uC z M0 i M4 nie różnią się specjalnie. W końcu nikt Ci nie każe pisać wielkich programów używających dziesiątek peryferiów, więc co za różnica, ile masz w uC nieupywanych modułów? Omijaj serię STM32F1, bo to ciut starsze i mniej udane układy.

  • #15 18 Cze 2015 19:21
    ostrytomasz
    Poziom 22  

    BlueDraco napisał:
    Omijaj serię STM32F1, bo to ciut starsze i mniej udane układy.


    Niby dlaczego mniej udane?
    Porównując STM32F103 do STM32F042 - efektywnie dwa razy większa wydajność transmisji USB, szybszy sam rdzeń i więcej pamięci, ADC bez buga z prądem upływu, łatwiej dostępny i tańszy w detalu.

  • #16 18 Cze 2015 19:25
    tadzik85
    Poziom 38  

    ostrytomasz napisał:
    BlueDraco napisał:
    Omijaj serię STM32F1, bo to ciut starsze i mniej udane układy.


    Niby dlaczego mniej udane?
    Porównując STM32F103 do STM32F042 - efektywnie dwa razy większa wydajność transmisji USB, szybszy sam rdzeń i więcej pamięci, ADC bez buga z prądem upływu, łatwiej dostępny i tańszy w detalu.


    Fakt porównując M0 z M3 to faktycznie dowiodłeś czegokolwiek.
    M3 rzadko jest już stosowany w nowych projektach. I na pewno nie jest tańszy od M0

  • #17 18 Cze 2015 19:59
    ostrytomasz
    Poziom 22  

    tadzik85 napisał:

    M3 rzadko jest już stosowany w nowych projektach. I na pewno nie jest tańszy od M0


    Dysponujesz jakimikolwiek danymi na poparcie tezy że M3 jest już rzadko stosowany?

    Odnośnie cen: jeszcze raz, piszę o detalu. Znajdź mi mini-kita z STM32F042/072 (lub innym z USB) w cenie poniżej $4 za sztukę lub sam STM32F0x2 (lub ekwiwalent spoza STM32F1) w cenie $1.60.

  • #18 18 Cze 2015 20:25
    tadzik85
    Poziom 38  

    ostrytomasz napisał:
    tadzik85 napisał:

    M3 rzadko jest już stosowany w nowych projektach. I na pewno nie jest tańszy od M0


    Dysponujesz jakimikolwiek danymi na poparcie tezy że M3 jest już rzadko stosowany?

    Odnośnie cen: jeszcze raz, piszę o detalu. Znajdź mi mini-kita z STM32F042/072 (lub innym z USB) w cenie poniżej $4 za sztukę lub sam STM32F0x2 (lub ekwiwalent spoza STM32F1) w cenie $1.60.


    Danymi? wystarczy to forum. Nie detal napędza rynek. Zresztą wystarczy spojrzeć kiedy ostatnio cokolwiek zmieniło opartego na tym rdzeniu. 2-3 lata lekko mówiąc.
    Widziałeś jakąś nowość opartą ma M3?

    PS. O jakim bugu ADC mowisz?

  • #19 18 Cze 2015 20:45
    adamusx
    Poziom 27  

    Zgadzam się z @ostrytomasz - skąd teoria, że M3 jest już rzadko stosowany?
    To trochę wprowadzane nowicjuszy w błąd.
    M3 jest znacznie bardziej wydajny niż M0, ale oczywiście mniej wydajny niż M4.

    Wybór procesora powinien zależeć od aplikacji. W przypadku STM ja bym to podzielił tak:
    M0 -> Tam gdzie zależy nam na niskim poborze prądu oraz cenie.
    M3 -> Gdy potrzebna jest dobra wydajność i dobra cena.
    M4(F3) -> Tam gdzie potrzebna jest większa wydajność i dobra cena.
    M4 -> Tam gdzie potrzebna największa wydajność, a cena nie gra takiej roli.

    Co ciekawe - jeśli cena nie jest tak istotna - w aplikacjach low-power zamiast M0/L0 sami specjaliści z ST rekomendują stosowanie M4 (szczególnie najnowszych wersji) bo posiadają one lepszy stosunek poboru prądu w relacji czasu wykonywania operacji.
    Inna sprawa - w urządzeniach narażonych na duże zakłócenia (automatyka itp.) bardziej odporny może okazać się taki STM32F1 niż F4 z racji innego procesu technologicznego.

    tadzik85 napisał:

    Danymi? wystarczy to forum. Nie detal napędza rynek. Zresztą wystarczy spojrzeć kiedy ostatnio cokolwiek zmieniło opartego na tym rdzeniu. 2-3 lata lekko mówiąc.
    Widziałeś jakąś nowość opartą ma M3?


    Jeśli forum ma być odzwierciedleniem tego co stosują obecnie producenci w swoich rozwiązaniach (gdzie liczy się często sprawdzony układ oraz cena) to ja nie mam pytań .. ;)

  • #20 18 Cze 2015 20:55
    tadzik85
    Poziom 38  

    adamusx napisał:
    Zgadzam się z @ostrytomasz - skąd teoria, że M3 jest już rzadko stosowany?
    To trochę wprowadzane nowicjuszy w błąd.
    M3 jest znacznie bardziej wydajny niż M0, ale oczywiście mniej wydajny niż M4.

    Wybór procesora powinien zależeć od aplikacji. W przypadku STM ja bym to podzielił tak:
    M0 -> Tam gdzie zależy nam na niskim poborze prądu oraz cenie.
    M3 -> Gdy potrzebna jest dobra wydajność i dobra cena.
    M4(F3) -> Tam gdzie potrzebna jest większa wydajność i dobra cena.
    M4 -> Tam gdzie potrzebna największa wydajność, a cena nie gra takiej roli.

    Co ciekawe - jeśli cena nie jest tak istotna - w aplikacjach low-power zamiast M0/L0 sami specjaliści z ST rekomendują stosowanie M4 (szczególnie najnowszych wersji) bo posiadają one lepszy stosunek poboru prądu w relacji czasu wykonywania operacji.
    Inna sprawa - w urządzeniach narażonych na duże zakłócenia (automatyka itp.) bardziej odporny może okazać się taki STM32F1 niż F4 z racji innego procesu technologicznego.


    Cp za ludzie. Bzdury. M3 dawno przestał być rozwijany przez producentów. Teraz jakbym mial wybierać to M0/M0+ lub M4.
    L4 lepsze od L0? tylko wydajnością. Ale po co mi wielka wydajności w większości low powerowych aplikacji tylko by przepłacić? A cena 411/401 na pewno będzie niższa od F1.
    F1 istnieje, jest tani i popularny bo powstało na nich wiele projektów nadal w produkcji. Samo ST nawet nie odświeżyło rdzenia do ostatniej rewizji.
    Wystarczy spojrzeć na innych producentów chociaż, nie którzy nie mają niczego opartego na M3 do dziś, tylko M4 i M0.
    Dodano po 3 [minuty]:
    adamusx napisał:

    tadzik85 napisał:

    Danymi? wystarczy to forum. Nie detal napędza rynek. Zresztą wystarczy spojrzeć kiedy ostatnio cokolwiek zmieniło opartego na tym rdzeniu. 2-3 lata lekko mówiąc.
    Widziałeś jakąś nowość opartą ma M3?


    Jeśli forum ma być odzwierciedleniem tego co stosują obecnie producenci w swoich rozwiązaniach (gdzie liczy się często sprawdzony układ oraz cena) to ja nie mam pytań .. ;)


    Bo produkt jest rozwijany przez ostatnie 5 lat? Bo taki part number firma stosuje zwiększając jedynie ilość kupowaną? Bo się inżynierowi nie chce uczuć nowych peryferiów? Taka sama historia jak z 51...

    L4? Nie ma czegoś takiego jak nowszych wersji skoro ledwo co wyszły pierwsze sztuki. A każdy producent reklamuje ostro każdą nowość.

    I skąd informacja ze niby F1 miałoby być w innym procesie technologicznym?
    Wszystko 90nm, F7 planują w 40nm. L0, L2 i L4 to inna bajka, 110nm zdaje się z podwójna wyspą.

  • #21 18 Cze 2015 21:03
    ostrytomasz
    Poziom 22  

    tadzik85 napisał:

    Danymi? wystarczy to forum. Nie detal napędza rynek.


    Nie widzę związku między forum a rynkiem. Gdybym patrzył na rynek profesjonalny tak jak potrafię, przez pryzmat swojej pracy, to nie byłoby tam nic poza DSP, FPGA i ARM z MMU, dlatego pytam o jakiekolwiek dane które miałyby poprzeć tezę że STM32F1 nie są już stosowane. W zastosowaniach amatorskich widzę coś przeciwnego - wysyp tanich STM32F103.

    tadzik85 napisał:

    Zresztą wystarczy spojrzeć kiedy ostatnio cokolwiek zmieniło opartego na tym rdzeniu. 2-3 lata lekko mówiąc.
    Widziałeś jakąś nowość opartą ma M3?


    Gdyby coś miało się zmieniać w rdzeniu to nie nazywałby się on już M3 jak zresztą się stało.
    Odnośnie implementacji: ogłoszone tydzień temu, wystarczająco nowe?
    http://www.maximintegrated.com/en/products/digital/microcontrollers/MAX32555.html
    EFM32, SAM3X - czy one są już stare?

    tadzik85 napisał:
    PS. O jakim bugu ADC mowisz?


    Tutaj go opisałem: http://www.elektroda.pl/rtvforum/viewtopic.php?p=14456594,, szukałem też wyjaśnienia na forum STM, w każdym razie nieco się zawiodłem.

    tadzik85 napisał:
    Bo się inżynierowi nie chce uczuć nowych peryferiów? Taka sama historia jak z 51...


    Jaki związek mają peryferia z rdzeniem? Lekko licząc 3/4 kodu obsługi peryferiów mogę przenieść między STM32F0/1/3 bez zmian. Peryferia zmieniają się między producentami, w mniejszym stopniu w obrębie producenta.

  • #22 18 Cze 2015 21:07
    tadzik85
    Poziom 38  

    ostrytomasz napisał:
    tadzik85 napisał:

    Danymi? wystarczy to forum. Nie detal napędza rynek.


    Nie widzę związku między forum a rynkiem. Gdybym patrzył na rynek profesjonalny tak jak potrafię, przez pryzmat swojej pracy, to nie byłoby tam nic poza DSP, FPGA i ARM z MMU, dlatego pytam o jakiekolwiek dane które miałyby poprzeć tezę że STM32F1 nie są już stosowane. W zastosowaniach amatorskich widzę coś przeciwnego - wysyp tanich STM32F103.

    tadzik85 napisał:

    Zresztą wystarczy spojrzeć kiedy ostatnio cokolwiek zmieniło opartego na tym rdzeniu. 2-3 lata lekko mówiąc.
    Widziałeś jakąś nowość opartą ma M3?


    Gdyby coś miało się zmieniać w rdzeniu to nie nazywałby się on już M3 jak zresztą się stało.
    Odnośnie implementacji: ogłoszone tydzień temu, wystarczająco nowe?
    http://www.maximintegrated.com/en/products/digital/microcontrollers/MAX32555.html
    EFM32, SAM3X - czy one są już stare?

    tadzik85 napisał:
    PS. O jakim bugu ADC mowisz?


    Tutaj go opisałem: http://www.elektroda.pl/rtvforum/viewtopic.php?p=14456594,, szukałem też wyjaśnienia na forum STM, w każdym razie nieco się zawiodłem.


    To i tam ci odpowiem bo chłopie zabawne rzeczy wygadujesz.

    Co do zmiany w rdzeniu ST nadal w F1 nie stosuje ostatniej rewizji rdzenia w pozostałych rodzinach zastosował. Hobbystycznie nadal są tam samo popularne jak reszta. Bo w detalu łatwo dostępne. Choć tematy na ich temat ostro zanikły.
    I nie mowie o stosowaniu a wyborze do nowych zastosowań.

  • #23 18 Cze 2015 21:11
    adamusx
    Poziom 27  

    tadzik85 napisał:


    C za ludzie. Bzdury. M3 dawno przestał być rozwijany przez producentów. Teraz jakbym mial wybierać to M0/M0+ lub M4.


    No to co, że przestał być rozwijany? To znaczy, że nie można go zastosować, mimo, że jest tańszy i sprawdzony?

    tadzik85 napisał:

    L4 lepsze od L0? tylko wydajnością. Ale po co mi wielka wydajności w większości low powerowych aplikacji tylko by przepłacić? A cena 411/401 na pewno będzie niższa od F1.


    Większa wydajność po to, by szybciej wykonać dane operacje i uśpić układ. Są porównania L0 z F4, stosunek czasu pracy/poboru prądu jest korzystniejszy dla F4. Oczywiście nie zawsze pędzienie układu z większą częstotliwością ma sens, jeśli opóźnienia są po stronie zewnętrznych peryferiów.

    tadzik85 napisał:

    F1 istnieje, jest tani i popularny bo powstało na nich wiele projektów nadal w produkcji.

    ...
    Bo produkt jest rozwijany przez ostatnie 5 lat? Bo taki part number firma stosuje zwiększając jedynie ilość kupowaną? Bo się inżynierowi nie chce uczuć nowych peryferiów? Taka sama historia jak z 51...


    No pewnie, bo lepiej zmieniać co rok układy i spędzać nad nowymi X godzin więcej wyszukując nowe bugi producentów ;)

    A 51 jeśli sprawdzają się w pewnych aplikacjach to dlaczego dany inżynier nie miałby ich zastosować?
    Jest dużo krytycznych aplikacji / urządzeń, gdzie niezawodność (od której może nawet zależeć ludzkie życie) gra kluczową rolę i myślę, że wówczas producent sięgnie po sprawdzone rozwiązanie.

  • #24 18 Cze 2015 21:17
    tadzik85
    Poziom 38  

    adamusx napisał:
    tadzik85 napisał:


    C za ludzie. Bzdury. M3 dawno przestał być rozwijany przez producentów. Teraz jakbym mial wybierać to M0/M0+ lub M4.


    No to co, że przestał być rozwijany? To znaczy, że nie można go kupić, mimo, że jest tańszy i sprawdzony?

    Tańszy od czego? M0? A kupować sobie możesz nawet przez 10 lat. I tylko z tego powodu mam go wybierać?

    adamusx napisał:

    tadzik85 napisał:

    L4 lepsze od L0? tylko wydajnością. Ale po co mi wielka wydajności w większości low powerowych aplikacji tylko by przepłacić? A cena 411/401 na pewno będzie niższa od F1.


    Większa wydajność po to, by szybciej wykonać dane operacje i uśpić układ. Są porównania L0 z F4, stosunek czasu pracy/poboru prądu jest korzystniejszy dla F4. Oczywiście nie zawsze pędzienie układu z większą częstotliwością ma sens, jeśli opóźnienia są po stronie zewnętrznych peryferiów.

    W Low power rzadko kiedy chodzi o szybkość wykonania. W low power istotny jest prąd statyczny a nie ten na Mhz.
    adamusx napisał:

    tadzik85 napisał:

    F1 istnieje, jest tani i popularny bo powstało na nich wiele projektów nadal w produkcji.

    ...
    Bo produkt jest rozwijany przez ostatnie 5 lat? Bo taki part number firma stosuje zwiększając jedynie ilość kupowaną? Bo się inżynierowi nie chce uczuć nowych peryferiów? Taka sama historia jak z 51...


    No pewnie, bo lepiej zmieniać co rok układy i spędzać nad nowymi X godzin więcej wyszukując nowe bugi producentów ;)

    A 51 jeśli sprawdzają się w pewnych aplikacjach to dlaczego dany inżynier nie miałby ich zastosować?
    Jest dużo krytycznych aplikacji / urządzeń, gdzie niezawodność (od której może nawet zależeć ludzkie życie) gra kluczową rolę i myślę, że wówczas producent sięgnie po sprawdzone rozwiązanie.


    I za czym ma to przemawiać?

  • #25 18 Cze 2015 21:24
    adamusx
    Poziom 27  

    tadzik85 napisał:


    Tańszy od czego? M0? A kupować sobie możesz nawet przez 10 lat. I tylko z tego powodu mam go wybierać?

    I za czym ma to przemawiać? Ze jesteś starym prykiem który nie ma ochoty na dalszą naukę?


    Tańszy od M4 rzecz jasna. A od M0 wydajniejszy. Ja Tobie nic nie zabraniam, to wg. Twojego rozumowania nie powinno się kupować M1 bo nie są już rozwijane..

    Na naukę trzeba mieć czas, na co nie zawsze można sobie pozwolić w pracy i poza nią.
    Poza tym widzę, że brakuje argumentów,a zaczynają się osobiste wycieczki...Także kończe dyskusję.

  • #26 18 Cze 2015 21:33
    tadzik85
    Poziom 38  

    adamusx napisał:
    tadzik85 napisał:


    Tańszy od czego? M0? A kupować sobie możesz nawet przez 10 lat. I tylko z tego powodu mam go wybierać?

    I za czym ma to przemawiać? Ze jesteś starym prykiem który nie ma ochoty na dalszą naukę?


    Tańszy od M4 rzecz jasna. A od M0 wydajniejszy. Ja Tobie nic nie zabraniam, to wg. Twojego rozumowania nie powinno się kupować M1 bo nie są już rozwijane..

    Na naukę trzeba mieć czas, na co nie zawsze można sobie pozwolić w pracy i poza nią.
    Poza tym widzę, że brakuje argumentów,a zaczynają się osobiste wycieczki...Także kończe dyskusję.


    To ile układów mam stosować? 10? 20?

    Potrzebuje wydajności biorę M4. Chce tanio biorę M0. Tyle.
    Wg strony producenta. F1 jest ledwie 10centow tańszy od M4. Porównane dla 100pinów i 256kB flash. 0,10 różnicy przy 3,4$ Straszne.

  • #27 18 Cze 2015 22:20
    michalko12
    Specjalista - Mikrokontrolery

    I znowu jakieś mało istotne sprawy są tu poruszane. CM3 istnieją i będą istnieć do póki będzie popyt. Producent nie produkuje uC pod dyktando forumowych amatorów więc te wasze dywagację są mało ważne. Dla masowego odbiorcy różnica ceny na poziomie centów ma już znaczenie i wtedy będzie widoczna różnica między CM0,3,4,7... W detalu rządzą inne prawa. Co do wdrażania nowych CM3 to NXP całkiem niedawno wypuścił LPC1500, najwyraźniej opłacało im się.

    A tak na marginesie to dyskusja zrobiła się nie na temat.

  • #28 18 Cze 2015 22:38
    BlueDraco
    Specjalista - Mikrokontrolery

    W moim ostrzeżeniu przed F1 nie chodziło o to, że jest to M3, a o to, że:
    1. Jest to archaiczna wersja rdzenia M3 z pewną niestandardową i niemiłą cechą, której nie mają żadne inne Cortex M żadnych innych producentów.
    2. Peryferiale są dość dziwaczne (współczesne STM F0 i F4 mają nowsze i podobne do siebie peryferiale).
    3. Niezbyt fortunnie rozwązano w F1 przypisywanie wyprowadzeń do peryferiali.

    Nowsze uC STM32 są wyraźnie przyjemniejsze w użyciu niż seria F1.

  • #29 18 Cze 2015 22:44
    tadzik85
    Poziom 38  

    BlueDraco napisał:
    W moim ostrzeżeniu przed F1 nie chodziło o to, że jest to M3, a o to, że:
    1. Jest to archaiczna wersja rdzenia M3 z pewną niestandardową i niemiłą cechą, której nie mają żadne inne Cortex M żadnych innych producentów.
    2. Peryferiale są dość dziwaczne (współczesne STM F0 i F4 mają nowsze i podobne do siebie peryferiale).
    3. Niezbyt fortunnie rozwązano w F1 przypisywanie wyprowadzeń do peryferiali.

    Nowsze uC STM32 są wyraźnie przyjemniejsze w użyciu niż seria F1.


    Otóż to...

  • #30 19 Cze 2015 07:15
    mas24
    Poziom 16  

    Poczytałem tą dyskusję, i jedna rzecz mnie nieco przestraszyła: jakieś anomalie w ADC. Po Xmega mam już ich dosyć (bezsensowny offset, niestabilne pomiary), więc chciałbym się ustrzec przed tego typu prockami, czyli są to M3?

    Mam jeszcze kilka pytań:
    1. Czy w STM32Fxxx peryferia są na stałe przyporządkowane do pinów, jak to było w AVR? Bo słyszałem gdzieś,że tutaj jest dowolność w konfiguracji.
    2. Patrząc na pinout w ARMach, widzę, że jest tam niezła kaszana. Porty nie lecą po kolei, tylko po 2, po 3 piny jednego portu, by zaraz dać piny innego portu. Ciekawe, co przyświecało inżynierom, by taki bałagan stworzyć?
    3. Pod jakie piny podłączyć ST-Linka do programowania? Ile potrzeba przewodów? Link do jakiegoś schematu by się przydał.

    Próbuje instalować wg. opisu Freddiego, i w Eclipse po zaznaczeniu opcji "GNU Elf Parsers", żadne ścieżki dostępu mi się nie pokazują, pod spodem jest pusto. Tutaj utknąłem. Mam Eclipse Luna Service Release 2 (4.4.2)

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