Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

STM32F4DISCOVERY rozpoczęcie programowania

felekfala 26 Nov 2011 16:37 15574 68
Computer Controls
  • #31
    bury104
    Level 13  
    Zostawmy temat podkręcania procesorów, jest to temat dla dwóch szkół: starej, która mówi jasno "nie, nie powinno się tego robić", oraz nowej szkoły, która mówi jasno: "tak do pewnego stopnia i w szczególnych przypadkach".

    Oczywiście nie należy tego wykorzystywać do obrażania kogokolwiek, jest to karygodne!!!
    Do niczego tym sposobem nie dojdziemy.

    Czyli teze "nie należy podkręcać procesorów powyżej tego co wyznaczył producent" - należy traktować jako pewien stereotyp elektroniki. Jedni w to wierzą uparcie drudzy nie.
    Koniec na ten temat, są do tego inne tematy i fora.

    Co do testów:

    Myślę, że do pomiarów należałoby zastosować nie płytkę STM32F4DISCOVERY, o której tutaj szczególnie mówimy, ale płytkę z najsłabszym procesorem z nadrzędnej serii STM32F4 czyli pewnie STM32F405RG i do tego dobrać zbliżony STM32 M3 np. STM32F103RB.

    I to by były platformy porównawcze. Wówczas nikt nam nie będzie mógł zarzucić, że wybraliśmy np. "najlepszy procesor" w najwyższej półki i porównujemy go do "najsłabszego procesora" z najniższej półki. :-)))

    Co do tego "wąskiego gardła" - widzę, że należy to wyjaśnić. Termin ten powstał, aby określić miejsca w których procesor musi zwolnić, aby dokonać operacji np. procesor z zegarem 168MHz musi coś odczytać z pamięci, która pracuje wyłącznie z częstotliwością 24MHz - wówczas procesor musi zwolnić, w konsekwencji nie pracuje efektywnie z częstotliwością 168MHz (a z 24MHz)itd...

    Czyli jeśli, ktoś dalej tego nie rozumie szukamy wad procesora z STM32F4, miejsc gdzie tak naprawdę jego praca jest spowolniona i daleka od normalnej. Następnie porównujemy je z procesorami z rdzeniem M3.

    Oczywiście procesory STM32F4 mają takie miejsca znane i dostrzeżone przez ST, jednak w materiałach promocyjnych nikt się nimi nie chwali.

    Jak coś reklamujemy to podajemy wyłącznie zalety naszego produktu, a nie wady - to chyba jest dla wszystkich jasne.

    Czyli szukamy programów, które:
    - nie używają DSP - o czym już mówiliśmy
    - łatwo je zaaplikujemy zrówno do STM32 M3 jak i M4, na tym samym kopilatorze.
    - pokazują istotne wady zarówno rdzenia M3 i M4 firmy ST.
    - objektywnie podchodzą do tematu - czyli wiadomo, że 4 razy droższy procesor z serii STM32F4 będzie miał lepsze peryferia, które nie powinny być przedmiotem szczegółowych testów np. jeden będzie miał 32bitowe liczniki a drugi tylko 16bitowe - to jest jasne za coś extra płacimy.
    - szukamy konkretnych różnic i pokazujemy je na konkretnych przykładach a nie na podstawie broszur reklamowych.

    Myśle, że tyle wystarczy, reszta zależy od was. Nad doborem programów trzeba pomyśleć, co konkretnie chcemy objektywnie pokazać. W sieci jest dużo takich programów - trzeba poszukać.
  • Computer Controls
  • #32
    VanThor
    Level 19  
    marcinlas wrote:
    michalko12 napisał:

    >"A ja się pytam po co te podkręcanie? Bo procek nie wyrabia? To dupa z ciebie bo nie potrafiłeś dobrać procesora na etapie projektowania, a jeśli tak dla zasady to napisz to i dopisz, że nikt nie powinien tak postępować. "

    Mój drogi zupełnie się z tobą nie zgodzę, jednak tu na forum obowiązują pewne normy - nikt tu nikogo nie obraża. Dziwię się, że moderator tego nie wyrzucił.

    Każdy przedstawia swój punkt widzenia, można go przedyskutować ale na pewnym poziomie słownictwa i intelektu.


    A co Cię tak obraziło?

    Podkręcać to można, ale:
    - dla zabawy -> hobbysta,
    - przy maksymalnie kilku sztukach jakiegoś gadżetu zrobionego dla siebie/znajomych ("ot, taki procesor był pod ręką"),
    - dla testów -> producent żeby zweryfikować parametry graniczne.
    Tylko jedno zastosowanie jest profesjonalne i raczej nas na tym forum nie dotyczy. Znasz jakieś inne sensowne przypadki?

    Jak sprzedajesz urządzenie to gwarantujesz, że jest sprawne i powinno działać poprawnie. Jak nie działa, bo zignorowałeś parametry graniczne/zalecane to jest to Twój problem i Ty płacisz za jego usunięcie. Pół biedy jak to jest gadżet, gdy można go wyrzucić i nabyć kolejną sztukę za grosze. Gorzej, jak z powodu takiego niedbalstwa wyrządzisz komuś krzywdę - wtedy w grę wchodzi odszkodowanie, a w skrajnych przypadkach odpowiedzialność karna. I nie będzie żadnej taryfy ulgowej - bo zrobiłeś to świadomie.

    Spróbuj sprzedać setki, tysiące czy większy wolumen urządzeń z tak podrasowaną elektroniką to poznasz na własnej skórze, dlaczego tak się nie robi. Z partii na partię parametry mogą się zmieniać. To że masz 10, 20 czy 100 sztuk pracujących przy podkręceniu, nie oznacza, że w nowej zakupionej partii (i kolejnych) znajdziesz choć jedną taką. A jak producent zmieni proces wytwarzania układów to może być koniec interesu.

    Reasumując - ktoś kto projektuje urządzenia z podkręconymi procesorami do sprzedaży to dupa, nie inżynier. Niestety, coraz więcej takich "lewych inżynierów" cokolwiek projektuje i potem mamy specjalne kursy "jak układać palce trzymając telefon, żeby mieć zasięg"...

    marcinlas wrote:
    Autor, który napisał te artykuły na łamach "Elektroniki Praktycznej" o podkręcaniu procesorów na pewno by się z tobą nie zgodził, a ja nie zamierzam z tobą dyskutować na takim poziomie.


    Jeśli dla kogoś wyrocznią i jedynym wartym zaufania jest jakiś autor z gazetki, która hurtowo tłumaczy noty aplikacyjne na język polski to faktycznie - dyskusja nie ma sensu...

    Z innej beczki - a skąd wiesz, że by się nie zgodził? Czy jego firma sprzedaje układy z podkręconymi procesorami? A może artykuł był ciekawostką, a część osób wbrew intencji autora odczytała to jako zalecenie stosowania takich praktyk? ;)

    Dodano po 29 [minuty]:

    bury104 wrote:
    Czyli szukamy programów, które:
    ...
    - pokazują istotne wady zarówno rdzenia M3 i M4 firmy ST.
    - objektywnie podchodzą do tematu - czyli wiadomo, że 4 razy droższy procesor z serii STM32F4 będzie miał lepsze peryferia, które nie powinny być przedmiotem szczegółowych testów np. jeden będzie miał 32bitowe liczniki a drugi tylko 16bitowe - to jest jasne za coś extra płacimy.


    A zastanowiłeś się, że w świetle tych założeń te testy chyba nie mają sensu?

    Chcesz testować same rdzenie? A jaką informację chcesz uzyskać w ten sposób - że wykona jakiś Twój wymyślony fragment programu w jakimś czasie? Rdzenie nie są projektowane przez ST, a na stronie ARMa są wyniki, jakie mogą osiągnąć, gdy nic nie będzie ich spowalniać -> dostęp do pamięci i urządzeń peryferyjnych! Może się mylę, ale żeby porównać same rdzenie wystarczy poczytać - zestaw instrukcji jest znany i czasy wykonywania też (i w większości takie same dla obu).
    Poza tym - jak przetestujesz sam rdzeń - pamięć mu odłączysz na czas testów i "będzie wykonywał program z powietrza"? ;)

    Urządzenia peryferyjne odrzuciłeś, zostają ewentualne dostępy do pamięci Flash + RAM (wydajność samych pamięci z usprawnieniami ART oraz magistral łączących z rdzeniem). Wydaje się, że wydajność samych pamięci jest znana ("wait states" chociażby dla Flasha). Zatem pozostają magistrale i ART? Ale w porównaniu do F1xx za ART, jakby nie patrzeć, płacisz, bo to coś ekstra.
  • #33
    michalko12
    MCUs specialist
    Niech ktoś w ogóle poda jakiś sensowny powód takich testów porównawczych. Czemu one mają służyć? Dlaczego nikomu do tej pory nie przyszło do głowy porównywanie CM0 i CM3?

    Dodano po 8 [minuty]:

    marcinlas wrote:
    michalko12 wrote:

    A ja się pytam po co te podkręcanie? Bo procek nie wyrabia? To dupa z ciebie bo nie potrafiłeś dobrać procesora na etapie projektowania, a jeśli tak dla zasady to napisz to i dopisz, że nikt nie powinien tak postępować. "

    Mój drogi zupełnie się z tobą nie zgodzę, jednak tu na forum obowiązują pewne normy - nikt tu nikogo nie obraża. Dziwię się, że moderator tego nie wyrzucił.

    Nie bierz tego do siebie, to było ogólne stwierdzenie.
  • #34
    Krotki
    Level 14  
    Wracając do tematu, czyli STM32F4DISCOVERY rozpoczęcie programowania.

    Chciałem sprawdzić działanie FPU wykonując proste dodawanie, mnożenie itd. float'ów w przerwaniu od timera. Ku mojemu zdziwieniu przy każdym wykonaniu instrukcji na float'ach wywala mi HardFault. Gdy wyłączyłem w opcjach korzystanie z FPU wszystko hula.

    Używam Keil'a w wersji dla ubogich na razie. Czy FPU wymaga jakiś dodatkowych/innych ustawień kompilatora żeby to zadziałało ?
  • Computer Controls
  • #35
    felekfala
    Level 19  
    U mnie w Keilu dla ubogich wszystko działa normalnie. Natomiast gdy korzystałem z jakiś wartości w programie które nie były ani zdefiniowane ani w formie zmiennych/stałych to musiałem je rzutować na float bo domyślnie kompilator traktuje je jako double (kompilator w formie warninga informuje o domyślnej konwersji typu do double) a wtedy obliczenia trwają dłużej.
    Korzystasz z wersji 4.22?
  • #36
    Krotki
    Level 14  
    Tak Keil 4.22 + j-link

    Kod wygląda mniej więcej tak:
    Code: c
    Log in, to see the code


    Oczywiście wywala się na dodawaniu.

    Czy mógłbym prosić o podanie dyrektyw kompilatora jakich używacie ?
  • #38
    Krotki
    Level 14  
    To f na końcu informuje kompilator żeby liczbę traktował jako float a nie double :)

    float32_t to tylko typ biblioteki st i jest to bezpośrednio float.

    Sprawdziłem jeszcze na innym projekcie przeznaczonym dla stm32f4discovery i jest to samo. Coś mi mówi ze muszę przeinstalować Keila.

    -------

    Okazuje się że nie Keil winien, a jak zawsze błąd ludzki. W projektach przykładowych do STM32Discovery ściągniętych ze strony ST po prostu nie jest inicjalizowany FPU.

    Rozwiązaniem jest wykozystanie CMSIS'a lub dodanie kodu do SystemInit() w pliku system_stm32fxx.c kodu:
    Code: c
    Log in, to see the code
  • #39
    x-soldier
    Level 1  
    Przepraszam jeśli moje pytanie wydaje Wam się niemądre ale dopiero chciałbym zacząć przygodę z uC - czy płytka opisywana w wątku ma wbudowany programator? Jeśli nie to czy możecie polecić stosunkowo tanie (jak ta) płytki ewaluacyjne posiadające własny programator? Nie chciałbym inwestować na samym początku w J-linka lub wybierając inny uC niż ARM np. MKII albo Pickit'a 3.
    Mam jeszcze pytanie o miejsce zamówienia, ponieważ znalazłem płytkę w polskiej dystrybucji za cenę ponad 90zł - czy osoby podające cenę ok. 50zł zamawiały na miejscu czy za granicą?
  • #40
    Freddie Chopin
    MCUs specialist
    x-soldier wrote:
    Nie chciałbym inwestować na samym początku w J-linka

    Pamiętaj tylko, że świat nie kończy się na Keilu i JLinku [;

    Co do Twojego głównego pytania - wystarczy wpisać w google nazwę płytki, kliknąć w pierwszy link i przeczytać (drugi akapit).

    4\/3!!
  • #42
    bednyk
    Level 12  
    Odgrzewając lekko temat - czy STM32F4 Discovery jest waszym zdaniemiem dobrym zestawem do rozpoczęcia przygody z procesorami ARM ? Zastanawiam się jeszcze nad płytką z prockiem STM32 oraz JTAG-lock-pick tylko że ty byłby już kilkukrotnie większy wydatek ..
  • #43
    Freddie Chopin
    MCUs specialist
    Jeśli zdecydujesz, że moja wypowiedź może zostać uznana za obiektywną (w końcu sprzedaję zarówno JTAG-lock-pick jak i STM32F4DISCOVERY...), to czytaj dalej [;

    STM32F4DISCOVERY jest ciekawe do poznania danego układu i scalaków zamontowanych na płytce, wbudowany ST-LINK też fajny, ale nie użyjesz go do wszystkiego, bo nie wszystkie ARMy można debuggować przez SWD - w ARM7, ARM9 itd. nie ma przecież SWD i wtedy przydałby się jednak JTAG... Prawda jest taka, że samo STM32F4DISCOVERY nie załatwi Ci wszystkich potrzeb jakie będziesz miał w przyszłości i w stosowaniu jako JTAG jest mało poręczne (goła elektronika na wierzchu, 4x większa niż potrzeba, zapewne brak buforowania/konwersji poziomów, tylko SWD, brak jakiejś podstawy żeby płytka nie jeździła po stole).

    Czy STM32F4 jest dobre do rozpoczęcia? To zależy jak czujesz się w programowaniu i - nazwijmy to tak - ogólnej wiedzy komputerowo-elektronicznej. Na pewno STM32F4 jest bardzo zaawansowanym ARMem o bardzo dużych możliwościach, ale osoba "zielona" w tych kwestiach może przeżyć mały szok obcując z takim sprzętem (; Jeśli np znasz bardzo dobrze jakąś inną rodzinę mikrokontrolerów i zagadnienia programowania małych układów nie są Ci obce, to można zacząć od czegokolwiek. Pierwszy kontakt z mikrokontrolerami czy elektroniką cyfrową - hmm... tak sobie, zależy od wielu czynników... STM32F4 jest też bardzo "nowy", a więc ilość informacji w necie, pomocy jaką można otrzymać nie jest specjalnie duża w porównaniu do np STM32F1, które jest popularne i dostępne na rynku od kilku lat...

    Na koniec dodam, że ja osobiście niezbyt lubię makiety [;

    4\/3!!
  • #44
    McMonster
    Level 32  
    Freddie Chopin wrote:
    Na koniec dodam, że ja osobiście niezbyt lubię makiety [;


    Opatentowałeś wpinanie TQFP i BGA bezpośrednio do płytki stykowej? :>

    Akurat sam mam F4 Discovery, ale jeszcze nie znalazłem czasu na dłuższą zabawę. I to samo dotyczy ARMów jako takich (wcześniej prawie dwa lata zabawy z AVRami), z tym że dodatkowo mam JTAG Freddiego i jeszcze jedną makietę, ZL26ARM z STM32F107. Zaletą Discovery jest prostota niczym budowa ruskiego czołgu niemal. Wystarczy ściągnąć środowisko Atollic, podłączyć Discovery i można od razu programować. Więc potwierdzam opinię Freddiego tak w skróci, jeżeli jakieś doświadczenie z mikrokontrolerami masz, to dobry wybór, ale z zaznaczeniem ograniczeń.

    Opcja z osobnym JTAGiem i np. Eclipse jako środowisko też nie jest zła, ale trzeba poświęcić jeden weekend na rozgryzienie, jak to działa. Jak się już przygotuje sobie środowisko, to też nie jest to zła opcja.

    W każdym wypadku jednak zostaje kwestia złożoności ARMów, ale tego już się nie uniknie pracując z nimi. ;)
  • #45
    bednyk
    Level 12  
    Heh, nic pomyślę nad tym intensywniej i podejmę decyzję. Dzięki za rzeczowe uwagi ;]
  • #46
    slqa
    Level 11  
    Mam pytanie odnośnie tego układu.
    Myślicie koledzy, że nada się on do wykorzystania w sterowaniu silnikiem krokowym?
    Mam pisać pracę inżynierską na ten temat i się tak zastanawiam czego użyć, bo przydałby się jakiś procesor sygnałowy do mojego wykorzystania. Myślałem, żeby podłączyć do niego jakiś moduł z klawiaturą i wyświetlaczami 7seg albo TFT. Myślicie, że taki procesor da radę obsłużyć takie wymagania?
  • #47
    gaskoin
    Level 38  
    Chyba żartujesz? Masz wbudowany kontroler do matryc

    felekfala wrote:
    U mnie w Keilu dla ubogich wszystko działa normalnie. Natomiast gdy korzystałem z jakiś wartości w programie które nie były ani zdefiniowane ani w formie zmiennych/stałych to musiałem je rzutować na float bo domyślnie kompilator traktuje je jako double (kompilator w formie warninga informuje o domyślnej konwersji typu do double) a wtedy obliczenia trwają dłużej.


    Wystarczy dodać flagę -fsingle-precision-constant do kompilacji i czary mary wszystkie zmiennoprzecinkowe consty są floatami.
  • #48
    stanleysts
    Level 27  
    @slqa

    Wszystko to, no poza moze TFT da sie spokojnie upchnac na 8bitowym procesorku . Chyba ze jakis kosmos ma byc w tym sterowaniu silnikiem krokowym, ale z tego co wiem to to jest naprawde proste. Tak wiec w zupelnosci wystarczy stm32f4, nawet to jest przerost formy nad trescia, pytanie jeszcze po co Ci tam DSP?
  • #49
    felekfala
    Level 19  
    gaskoin wrote:
    Chyba żartujesz? Masz wbudowany kontroler do matryc

    felekfala wrote:
    U mnie w Keilu dla ubogich wszystko działa normalnie. Natomiast gdy korzystałem z jakiś wartości w programie które nie były ani zdefiniowane ani w formie zmiennych/stałych to musiałem je rzutować na float bo domyślnie kompilator traktuje je jako double (kompilator w formie warninga informuje o domyślnej konwersji typu do double) a wtedy obliczenia trwają dłużej.


    Wystarczy dodać flagę -fsingle-precision-constant do kompilacji i czary mary wszystkie zmiennoprzecinkowe consty są floatami.


    Może i banalne pytanie, ale w którym miejscu w Keilu dodaję tą flagę?
  • #50
    spuki
    Level 13  
    Cześć,

    Mi to wygląda na flagę kompilatora GCC a nie RealView.
    Jeśli korzystasz z GCC to spróbuj ją dodać w "Project-> Options for Target... -> C/C++ -> Misc Controls".

    Pozdrawiam.
  • #52
    spuki
    Level 13  
    Faktycznie, nie zauważyłem tego.
    Przy kompilacji czegoś takiego:
    Code: c
    Log in, to see the code

    Kompilator zamieni zmienną na double, doda liczbę double o wartości "1.5" i całość przerobi z powrotem na floata.

    Pomaga dodanie litery "f" na końcu liczby:

    Code: c
    Log in, to see the code


    Tym razem Realview nic nie pozamieniał a całość wykonał na oko ze 4 razy szybciej.

    Pozdrawiam.
  • #54
    slqa
    Level 11  
    stanleysts wrote:
    @slqa

    Wszystko to, no poza moze TFT da sie spokojnie upchnac na 8bitowym procesorku . Chyba ze jakis kosmos ma byc w tym sterowaniu silnikiem krokowym, ale z tego co wiem to to jest naprawde proste. Tak wiec w zupelnosci wystarczy stm32f4, nawet to jest przerost formy nad trescia, pytanie jeszcze po co Ci tam DSP?


    Chciałbym na nim zrobić sterowanie IFOC takiego silnika i do tego przydałby się jakiś szybki procesor. Jeszcze myślałem dodać jakieś zabezpieczenia i interfejs użytkownika do tego i dlatego myślałem o czymś szybkim i za rozsądną cenę.
  • #55
    felekfala
    Level 19  
    IFOCa do silnika krokowego? Nie słyszałem, żeby sterowania wektorowego używało się do tego rodzaju silników ale być może tak.
    Ja wykorzystałem go do sterowania silnikiem indukcyjnym. Algorytm sterujący to modyfikacje DTC, także i do IFOCa spokojnie starczy. Mam co prawda na razie bardzo ubogi interfejs użytkownika ale i bardziej rozbudowany też spokojnie obsłuży.
  • #56
    slqa
    Level 11  
    felekfala mam pytanko do Ciebie jak używałeś DSP poprzez biblioteki CMSIS i DSP_Lib? A jeśli tak to jak oceniasz te biblioteki warto z nich korzystać?
  • #57
    felekfala
    Level 19  
    slqa wrote:
    felekfala mam pytanko do Ciebie jak używałeś DSP poprzez biblioteki CMSIS i DSP_Lib? A jeśli tak to jak oceniasz te biblioteki warto z nich korzystać?


    Nie bardzo rozumiem o co Ci chodzi "jak używałeś DSP". CMISa używam do ustawiania przerwań. Jeśli chodzi o bibliotekę DSP_Lib, to z niej nie korzystałem, więc nie mam o nie zdania.
  • #58
    slqa
    Level 11  
    Błąd logiczny oczywiście chodziło mi o "funkcje DSP" w tym procesorze. Może ktoś inny używał i ma jakieś zdanie na ich temat?
  • #59
    felekfala
    Level 19  
    W zasadzie większość rozkazów DSP realizowanych w jednym cyklu zegara dotyczy tylko stałoprzecinkowych rozkazów. Np. rozkaz MAC na stałym przecinku zajmuje 1cykl, a w arytmetyce zmiennoprzecinkowej 3 cykle. Arytmetyka zmiennoprzecinkowa nie obsługuje też rozkazów SIMD.

    Ja w zasadzie korzystam tylko z rozkazów zmiennoprzecinkowych gdzie przykładowe rozkazy trwają:
    - moduł – 1 cykl,
    - dodawanie/odejmowanie – 1 cykl,
    - mnożenie – 1 cykl,
    - mnożenie z akumulacją – 3 cykle,
    - dzielenie – 14 cykli,
    - pierwiastek kwadratowy – 14 cykli.

    Na razie do samego sterowania silnikiem spokojnie starczy.
  • #60
    zelu90
    Level 11  
    Witajcie. Będę używał tej płytki do swojej pracy dyplomowej. W tej chwili jestem na etapie zbierania dokumentacji. itd. Lada dzień rozpoczynam zabawę z ta płytką będę programował przez Coocox ponieważ jest darmowy. Mam pytanie do was jakiego interfejsu użyć przy połączeniu wyświetlacza z Płytką ?