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

STM32 - Czy zabierać się za ARM

pikantnyketchup 05 Kwi 2013 23:42 8028 58
  • #1 05 Kwi 2013 23:42
    pikantnyketchup
    Poziom 9  

    Witam!
    Jestem w posiadaniu STM Discovery F0. Nie miałem styczności wcześniej z AVR, a czytałem, że procesory ARM są dość trudne do ogarnięcia. I tu pojawia się pytanie czy są szansę, że pojmę tą "tajemniczą" wiedzę jaką jest programowanie ARM'ów?
    Jak Panowie sądzą?

    0 29
  • #2 05 Kwi 2013 23:57
    piotrva
    Moderator na urlopie...

    Na to pytanie nie da się udzielić odpowiedzi, bo wszystko zależy od Ciebie.
    Są osoby, którym wielkie trudności sprawia zrozumienie zasady działania prostych układów logicznych, a są osoby, które opanowują programowanie danej rodziny w parę tygodni od praktycznie zerowej wiedzy.
    Powiem tylko, że WARTO zająć się STM32, nie są one może, jak piszesz, najprostsze, ale gwarantuję, że jak przez to przejdziesz, to potem będzie już tak samo trudno, albo raczej tylko łatwiej.

    Podsumowując - spróbuj, nie zniechęcaj się, skoro masz zestaw to siadaj do nauki i po paru tygodniach sam ocenisz, czy dasz sobie radę, czy nie.

    0
  • #3 06 Kwi 2013 00:25
    stanleysts
    Poziom 27  

    Programowałeś jakiś uC wcześniej kiedykolwiek? Jeśli nie to nie polecam od razu ARM, tylko coś prostszego i najlepiej zacząć od jakiejś książki niekoniecznie do ARM, aby zrozumieć zasadę działania uC. No chyba, że wszystko ode zera jesteś w stanie szybko pojąć.

    0
  • #4 06 Kwi 2013 09:00
    BlueDraco
    Specjalista - Mikrokontrolery

    żeby zamigać diodą na STM32F0 potrzebujesz o jedną linijkę kodu więcej niż na AVR. Im bardziej złożone rzeczy będziesz programował, tym bardziej kod na Cortex będzie krótszy od kodu na AVR. Wydajnościowo jest to nieporównywalne - coś jak 10x szybciej przy tej samej częstotliwości zegara. Możliwości peryferiali o niebo większe. Ponadto ARM mają jednolitą przestrzeń adresową, więc nie musisz używać zaklęć takich jak PROGMEM i pgm_read_byte(), niezbędnych przy programowaniu AVR. Układy z Cortex są zwykle tańsze od AVR, przy znacznie większych możliwościach. W Cortex masz możliwość łatwego programowania i debugowania z zaglądaniem do środka procesora z poziomu PC. Jeśli nie musisz debugować - nie musisz też używać programatora ani robić do niego interfejsu na pytce, bo większość Cortexów ma bootloader umożliwiający ładowanie programu przez UART lub USB.

    A zaraz odezwą się Koledzy, który będą pisali, że tylko AVR jest dobry dla początkujących...

    Co jakiś czas wstawiam tu fragmenty wprawek dla STM32F0 - przeszukaj forum i sam oceń, czy Ci się podobają.

    0
  • #5 06 Kwi 2013 11:37
    tmf
    Moderator Mikrokontrolery Projektowanie

    BlueDraco: wiele razy o tym dyskutowaliśmy i nigdy nie udało ci się udowodnić żadnej z tych tez. Gdybyś napisał, że ARMy mogą być 10-razy szybsze niż AVR to ok, ale 10-razy szybsze przy tej samej częstotliwości zegara? Ja ci też podam kontrprzykład, że AVR może być 10-razy szybszy dla tej samej częstotliwości taktowania.
    Poza tym:
    1. Możliwości peryferii nie są o niebo większe, a porównanie np. XMEGA vs. tanie ARMy pokazuje, że jest odwrotnie.
    2. Jednolita przestrzeń adresowa. Obecnie nie ma to znaczenia, nie trzeba już korzystać z pgm_xxx, więc pisząc w c przestrzeń można "spłaszczyć".
    3. Nie zawsze Cortex jest tańszy. Jeśli mówimy o cenach to tanie są proste ARMy o czasami wręcz prymitywnych peryferiach.
    4. AVR też ma możliwość debugowania i łatweego programowania z zaglądaniem do środka, a nawet ma tą możliwość lepiej rozwiązaną. Debugger do ARM w większości to wariacja kiepskiego gdb, z wręcz prymitywnym wyświetlaniem zawartości owych wnętrzności. Możemy porównać screenschooty.
    5. AVRy też mają bootloader, to, że na elce większość używa starej M8 nie znaczy, że nic lepszego AVRy nie oferują.
    Bynajmniej nie namawiam do AVR, ale wybór to nie wybór pomiędzy ciemną a jasną stroną mocy, a raczej odcieniami szarości.

    0
  • #6 06 Kwi 2013 12:22
    alagner
    Poziom 25  

    Cytat:

    4. AVR też ma możliwość debugowania i łatweego programowania z zaglądaniem do środka, a nawet ma tą możliwość lepiej rozwiązaną. Debugger do ARM w większości to wariacja kiepskiego gdb, z wręcz prymitywnym wyświetlaniem zawartości owych wnętrzności. Możemy porównać screenschooty.

    To ja bym poprosił, bo serio chciałbym poznać te niezwykle znaczące różnice. Piszę totalnie bez złośliwości, bo używam zarówno Atmel Studio pod AVRy (8bitowe) jak i Eclipse'a pod inne procki [MSP430 oraz ARM] i wyświetlanie rejestrów peryferyjnych działa super w obu środowiskach, takoż wyświetlanie pamięci. Natomiast fakt, że pod ARMy trzeba sobie środowisko skonfigurować żeby to działało ok, zdecydowanie przemawia na korzyść AVR, gdzie wszystko działa od strzału zaraz po instalacji.

    Cytat:

    2. Jednolita przestrzeń adresowa. Obecnie nie ma to znaczenia, nie trzeba już korzystać z pgm_xxx, więc pisząc w c przestrzeń można "spłaszczyć".

    pgmspace.h i PROGMEM poleciały? W 8bitach czy tylko xmegach? Ew. jakiś update mnie ominął bo AVRów ostatnio bardzo rzadko używam.

    Pozdrawiam

    0
  • #7 06 Kwi 2013 13:30
    Marek_Skalski
    Moderator Projektowanie

    Do autora pytania:
    Masz możliwość rozpoczęcia nauki programowania struktur 32-bitowych i skorzystaj z tego. Jeżeli zaczniesz od 8-bitowych AVR czy PIC, to wyrobisz sobie schematy myślenia, które nie działają, a skutecznie ograniczają w pracy z ARM. Mówię to z własnego doświadczenia, ponieważ zaczynałem od 6502, a przez pracę z C51 i AVR tylko utrwaliłem to wszystko co ogranicza w pracy z ARM.
    Zawsze będą zwolennicy/sympatycy tej czy innej rodziny, ale trzeba spojrzeć z perspektywy czasu i swoich potrzeb. Bawić można się zawsze, ale czasami przypadkowy wybór decyduje o tym jak zarabiamy na chleb. Dzisiaj systemy embedded są stawiane na ARM albo FPGA. Struktury 8-bitowe są raczej dla urządzeń masowych, tanich, prostych, krótkoterminowych.
    Dzień ma tylko 24 godziny. Można się nauczyć pracy z 8-bitowcami, można się nauczyć programowania w C lub .asm i być w tym naprawdę dobrym pisząc programy w kilka dni, ale jak trzeba się przesiąść na inny układ, to często jest dramat. W tym samym czasie możesz się nauczyć programowania w C (C++) na ARM i tworzyć dobre aplikacje w kilka godzin. Nie zrażaj się, nie czekaj... czytaj, działaj i ucz się. Po kilku tygodniach/miesiącach sam ocenisz czy nadal Cię to interesuje. Ale jeżeli nie spróbujesz, to nigdy się nie dowiesz. Masz zestaw, więc tylko wyobraźnia i czas jest ograniczeniem.
    Powodzenia!

    0
  • #8 06 Kwi 2013 13:46
    tmf
    Moderator Mikrokontrolery Projektowanie

    Jeśli znasz Atmel Studio to może screenschoty nie są potrzebne :) Ale dołączam poniżej.
    STM32 - Czy zabierać się za ARM
    Chodzi mi o niuanse, typu pokazanie konfiguracji w rozbiciu na bity z opisem, czy też opisowe w postaci pól bitowych. GDB tego nie ma, po prostu wyświetla gołe rejestry IO, co najwyżej dołączając kompletny opis rejestru. Ale np. pól bitowych sobie comboboxem nie wybierzesz wg opisu.
    Co do PROGMEM i pgmspace - ciągle można z nich korzystać, ale nie trzeba. Obecne wersje gcc (>=4.7) udostępniają przestrzenie adresowe, to też działa z ARM, gdzie możesz sobie np. stworzyć przestrzeń dla zewnętrznego dataFLASH i odwoływać się do tam umieszczonych zmiennych bez żadnych cudów - cuda za ciebie wywoła kompilator.

    0
  • #9 06 Kwi 2013 14:15
    Freddie Chopin
    Specjalista - Mikrokontrolery

    tmf napisał:
    Chodzi mi o niuanse, typu pokazanie konfiguracji w rozbiciu na bity z opisem, czy też opisowe w postaci pól bitowych. GDB tego nie ma, po prostu wyświetla gołe rejestry IO, co najwyżej dołączając kompletny opis rejestru. Ale np. pól bitowych sobie comboboxem nie wybierzesz wg opisu.

    We wtyczce embsysregview tak właśnie to działa (;

    0
  • #10 06 Kwi 2013 15:04
    pikantnyketchup
    Poziom 9  

    Ładny OFF się tu zrobił.

    Dziękuję wszystkim za odpowiedź.

    stanleysts napisał:
    Programowałeś jakiś uC wcześniej kiedykolwiek?

    Tak, były to procesory 8051 w języku C z pomocą Keil'a.

    Tak jak Panowie piszecie, spróbuję czy dam radę.

    Zakupiłem sobie jeszcze płytkę stykową, kilka diod, czujnik temperatury, kondensatory, rezystory, tranzystory i wyświetlacz 7segm. I postaram się na nich chwilę podziałać jeśli ogarnę co nieco.

    A jakąś literaturę Panowie polecacie? Wyczytałem, że Reference manual to podstawa - Uff 750 stron (troszkę odstrasza).
    Czytałem też, że niema dobrej książki o ARM'ach. Widziałem książkę pana Paprockiego, ale nie wiem czy się w nią zaopatrywać, niektórzy odradzają.

    Pozdrawiam.

    0
  • #11 06 Kwi 2013 15:49
    Jado_one
    Poziom 22  

    Marek_Skalski napisał:

    Masz możliwość rozpoczęcia nauki programowania struktur 32-bitowych i skorzystaj z tego. Jeżeli zaczniesz od 8-bitowych AVR czy PIC, to wyrobisz sobie schematy myślenia, które nie działają, a skutecznie ograniczają w pracy z ARM. Mówię to z własnego doświadczenia, ponieważ zaczynałem od 6502, a przez pracę z C51 i AVR tylko utrwaliłem to wszystko co ogranicza w pracy z ARM.

    A co takiego ze starych procków skutecznie ogranicza w pracy z nowymi procesorami?

    0
  • #12 06 Kwi 2013 16:15
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Zamiłowanie do zbędnych optymalizacji, wstręt do liczb zmiennoprzecinkowych i inne cudowne-cuda których nie ma sensu robić na takich układach. Schematy tworzenia oprogramowania ("RTOS na pewno jest zbyt ciężki, zrobimy wiec pętlę główną!", "Nie, C++ na pewno zajmie zbyt dużo..." oraz "Najlepiej napisać to w assemblerze" [; ). Nie zaprzeczysz, że inaczej pisze się program na PC a inaczej na mikrokontroler. Nie wiem więc czemu chcesz zaprzeczyć istnieniu różnic między programami na małe i wolne układy 8-bitowe a "potężne" układy 32-bitowe. Skoro są różnice, to nie trudno założyć, że "schematy" które powodują te różnice "wchodzą w nawyk". Nie trudno również stwierdzić, że pewne z tych "schematów" są totalnie głupie na układach które osiągają częstotliwości rzędu 100MHz (np. uwielbiany przez wszystkich na całym świecie delay na pętli).

    4\/3!!

    0
  • #13 06 Kwi 2013 16:30
    alagner
    Poziom 25  

    Zaraz powiesz Freddie, że SPL nie jest zły :P
    (Ale jakby się zastanowić to sam w sobie nie jest, problemy biorą się z nieczytania datasheetów).

    EDIT:
    @tmf
    Tak wygląda plugin do Eclipse'a (nieodpalony akurat to i stanów nie wyświetla, ale możesz mi na słowo wierzyć, że działa dobrze ;) ):
    STM32 - Czy zabierać się za ARM

    Co do opisów poszczególnych bitów to jest tak - w ramach CMSIS dostępne są opisy rejestrów+ich adresy itd, bez poszczególnych pól. Natomiast community robi dokładne opisy, z polami bitowymi itd., chyba nawet z komentarzami do płytek ewaluacyjnych [bo o ile pamiętam można w setupie EmbsysRegview wybrać opcję "board" aczkolwiek nie miałem potrzeby z tego korzystać].

    0
  • #14 06 Kwi 2013 17:09
    Jado_one
    Poziom 22  

    Freddie Chopin napisał:
    Nie wiem więc czemu chcesz zaprzeczyć istnieniu różnic między programami na małe i wolne układy 8-bitowe a "potężne" układy 32-bitowe. Skoro są różnice, to nie trudno założyć, że "schematy" które powodują te różnice "wchodzą w nawyk". Nie trudno również stwierdzić, że pewne z tych "schematów" są totalnie głupie na układach które osiągają częstotliwości rzędu 100MHz (np. uwielbiany przez wszystkich na całym świecie delay na pętli).
    4\/3!!

    Ja nie zaprzeczam, tylko jestem ciekawy jakie konkretnie nawyki z procków 8-bitowych uniemożliwiają mi nauczenie się tych 32-bitowych...
    I czy jest to proces nieodwracalny ;-)

    0
  • #15 06 Kwi 2013 17:14
    Freddie Chopin
    Specjalista - Mikrokontrolery

    No ale przecież nikt nie napisał, że te nawyki coś uniemożliwiają (; To po prostu taka "kula u nogi" (;

    4\/3!!

    0
  • #16 06 Kwi 2013 17:33
    Jado_one
    Poziom 22  

    No własnie - bo ja jakoś nie zauważyłem, żeby mi trudniej było się nauczyć ARM'ów, przez to że znałem wcześniej 8-bitowce.
    A może problem polega na tym, że własnie tego się nie zauważa i nieświadomie stosuje się wcześniej utrwalone złe schematy.
    Gdzie jest zatem podręcznik programowania 32-bitowców, w optymalny (ale nie do przesady) dla nich sposób, który pozwoli zauważyć mi i wyeliminować moje złe, nieświadome nawyki ;-)
    Taki, podręcznik, który nie opisuje rejestrów, rdzenia i biblioteki SPL, tylko czyste techniki programistyczne.
    Nowicjusze jak widać wybierają nieświadomie od razu optymalną, idealną drogę programowania.
    My zepsuci assemblerem musimy dokonywać niesamowitych wysiłków, żeby się z jego szponów wyrwać ;-)

    0
  • #17 06 Kwi 2013 17:40
    pikantnyketchup
    Poziom 9  

    Jado_one napisał:
    Nowicjusze jak widać wybierają nieświadomie od razu optymalną, idealną drogę programowania.
    Mój wybór padł na ARM z powodu iż od dawna chciałem się zabrać za nowocześniejsze procesory niż 8051, a że w między czasie wygrałem zestaw Discovery to postanowiłem dowiedzieć się czy warto od razu zagłębiać się w ARMy czy może spróbować wcześniej AVRy.
    Co do lektury doradzicie coś dobrego?

    0
  • #18 06 Kwi 2013 20:31
    tmf
    Moderator Mikrokontrolery Projektowanie

    Freddie Chopin napisał:
    Zamiłowanie do zbędnych optymalizacji, wstręt do liczb zmiennoprzecinkowych i inne cudowne-cuda których nie ma sensu robić na takich układach. Schematy tworzenia oprogramowania ("RTOS na pewno jest zbyt ciężki, zrobimy wiec pętlę główną!", "Nie, C++ na pewno zajmie zbyt dużo..." oraz "Najlepiej napisać to w assemblerze" [; ). Nie zaprzeczysz, że inaczej pisze się program na PC a inaczej na mikrokontroler. Nie wiem więc czemu chcesz zaprzeczyć istnieniu różnic między programami na małe i wolne układy 8-bitowe a "potężne" układy 32-bitowe. Skoro są różnice, to nie trudno założyć, że "schematy" które powodują te różnice "wchodzą w nawyk". Nie trudno również stwierdzić, że pewne z tych "schematów" są totalnie głupie na układach które osiągają częstotliwości rzędu 100MHz (np. uwielbiany przez wszystkich na całym świecie delay na pętli).

    4\/3!!


    Ale to co piszesz to są mity niekoniecznie związane z 8-bitowcami. Warto z nimi walczyć niezależnie czy ktoś siedzi na 8 czy 32 bitach. Co do zmiennego przecinka - jeśli ARM nie ma FPU to jest to tak samo prawdziwe dla ARM jak i AVR.

    0
  • #19 06 Kwi 2013 20:46
    Freddie Chopin
    Specjalista - Mikrokontrolery

    tmf napisał:
    Co do zmiennego przecinka - jeśli ARM nie ma FPU to jest to tak samo prawdziwe dla ARM jak i AVR.

    Bezedura (; Po co mam kombinować bezsensownie jak coś policzyć na liczbach całkowitych, skoro układ ma prawie 100MHz i nawet bez FPU mogę sobie takich operacji wykonywać kilkadziesiąt-kilkaset tysięcy na sekundę? Kiedyś pisałem dosyć skomplikowany algorytm, który na liczbach typu float zajmował 18-35 tysięcy cykli (zależnie od danych wejściowych). Operacje to różnorodne przekształcenia geometryczne, trygonometria i równania kwadratowe. No i teraz skoro układ wykonuje siedemdziesiąt dwa MILIONY operacji na sekundę, to czemu nie mogę sobie wrzucić algorytmu który mógłby się w kółko wykonywać przynajmniej 2000x w ciągu tej sekundy? A moje największe zapotrzebowanie to było 1000x na sekundę, wiec zostaje mi "tylko" trzydzieści sześć MILIONÓW operacji na sekundę na pozostałe cele... Błagam... Ten strach przed float jest tak samo nieuzasadniony jak strach przed C++...

    P.S. Na liczbach double ten algorytm działał zaledwie 2x wolniej i też by mogło tak być...

    P.P.S. Układ bez FPU oczywiście, zwyczajne STM32F1x

    4\/3!!

    0
  • #20 06 Kwi 2013 21:21
    pikantnyketchup
    Poziom 9  

    Po raz trzeci pytam Panów o literaturę.

    0
  • #21 06 Kwi 2013 21:22
    excray
    Poziom 39  

    Reference Manual. Zalecam zapoznać się jeszcze przed zakupem bo może Ci się odechcieć programować w ARM.

    0
  • #22 06 Kwi 2013 21:36
    pikantnyketchup
    Poziom 9  

    Pisałem wyżej. Wiem że reference manual to podstawa, a jest to 750str. STM'a już mam bo go wygrałem.

    0
  • #23 06 Kwi 2013 21:50
    nibbit
    Poziom 19  

    Freddie Chopin napisał:
    tmf napisał:
    Co do zmiennego przecinka - jeśli ARM nie ma FPU to jest to tak samo prawdziwe dla ARM jak i AVR.

    Bezedura (; Po co mam kombinować bezsensownie jak coś policzyć na liczbach całkowitych, skoro układ ma prawie 100MHz i nawet bez FPU mogę sobie takich operacji wykonywać kilkadziesiąt-kilkaset tysięcy na sekundę? Kiedyś pisałem dosyć skomplikowany algorytm, który na liczbach typu float zajmował 18-35 tysięcy cykli (zależnie od danych wejściowych). Operacje to różnorodne przekształcenia geometryczne, trygonometria i równania kwadratowe. No i teraz skoro układ wykonuje siedemdziesiąt dwa MILIONY operacji na sekundę, to czemu nie mogę sobie wrzucić algorytmu który mógłby się w kółko wykonywać przynajmniej 2000x w ciągu tej sekundy?


    Jak zwykle offtop i jak zwykle to najciekawsze w dyskusji. Widzisz to że Tobie w projektach to wystarczyło to nie znaczy, że używanie floata na ARMach jest zawsze słuszne bo to 32 bity i powiedzmy 100 MHz. Zapewne w większości aplikacji tak jest, ale w często na to trzeba uważać. No chyba, że podchodzimy do tematu na zasadzie, że na tym procku floaty się nie wyrabiają to biorę szybszego ;]. Ponadto trzeba zwrócić uwagę na dużą zaletę fixed pointa - nie tracimy precyzji.

    Do autora, to co do literatury na książki nie licz. Wystarczy szukać przykładowych kodów do evali czy to z SPLem czy bez. Mamy demokrację, zrobisz jak uważasz ;]. Z pomocą RM-a szybko złapiesz.

    0
  • #24 06 Kwi 2013 22:10
    Freddie Chopin
    Specjalista - Mikrokontrolery

    nibbit napisał:
    Zapewne w większości aplikacji tak jest, ale w często na to trzeba uważać.

    Przecież nikt nie pisze tutaj o filtrach cyfrowych czy FFT. Niemniej jednak widać na forum tendencję, że nawet JEDNORAZOWE obliczenie czegoś na float to ogromny problem, bo "przecież można to zrobić na liczbach całkowitych, przez co program uruchomi się o 13 mikrosekund szybciej". Ja myślę, że słowo "większość" w Twoim cytacie trzeba by zastąpić "99,666% przypadków" (;

    nibbit napisał:
    Ponadto trzeba zwrócić uwagę na dużą zaletę fixed pointa - nie tracimy precyzji.

    Podałeś zaletę, podam więc wadę - może nie tracisz precyzji, ale też jej nie masz. Ciekawy jestem jak policzysz na stałym przecinku coś takiego: 100000.1 * 0.000001 (abstrahując od tego czy ten przykład ma sens, myślę że widać na czym polega problem stałego przecinka). No tak - nie da się... I teraz dla jednej głupiej operacji trzeba kombinować i z jednego mnożenia zaraz zrobi się kilka funkcji, które za parametr będą przyjmować jakieś dziwne liczby złożone... Po co?

    Podstawowa zasada optymalizacji jest taka - najpierw się robi "wprost", jak jest zbyt wolno i na 100% z powodu implementacji "wprost" to się ją zmienia. W świecie mikrokontrolerów (sam nie jestem "bez winy") zasada ta w ogóle nie funkcjonuje - założenie jest takie, że trzeba optymalizować wszystko, wszędzie, zawsze itd. Nawet jeśli przez 100 lat pracy sprzętu optymalizacje oszczędzą 3 minuty czasu, to wymyślenie tych optymalizacji trwało dłużej... A układ zamiast używać 20% swojej mocy to używa 19%... Teraz robię kolejny projekt w którym jest sporo liczenia, oczywiście wszystko na float i układ znów nie ma FPU, za to ma tylko 24MHz (STM32 VL). Na razie super-ciężki RTOS którego zastosowałem podaje, że zajmuję aż 20% mocy układu - czy już powinienem zacząć przerabiać setki obliczeń na stały przecinek? A obliczeń i tym razem jest sporo, choć mniej niż w tamtym projekcie - 100x na sekundę odpalane jest kilka funkcji monitorujących które operują oczywiście na parametrach które zarówno "są" jak i "obliczone są z użyciem" typu float...

    Premature optimization is the root of all evil - taką koszulkę sobie zrobię (;

    EDIT: Dla uzmysłowienia - zauważ, że w moim poście podałem konkretne wartości i konkretne wymagania - algorytm mógł działać minimum 2000x na sekundę, mnie potrzeba 1000x na sekundę, wiec "wystarcza". I taka jest prawidłowa kolejność - zrobić, sprawdzić, jak jest źle to poprawić. Tymczasem w świecie mikrokontrolerów fazę "zrobić" i "sprawdzić" się pomija, bo "na pewno się nie wyrobi" i od razu "optymalizujesz" (cudzysłów, bo optymalizacja wymaga czegoś nieoptymalnego, a nie polega na tworzeniu czegoś od zera)... Tak jakby każdy tutaj liczył całymi dniami FFT...

    4\/3!!

    0
  • #25 06 Kwi 2013 22:12
    pikantnyketchup
    Poziom 9  

    Oki.
    Będę walczył, aż się krew poleję. Jak się zaprę to się nauczę. Czyli z książką Paprockiego dam sobie spokój i zacznę studiować ref.man.

    0
  • #26 06 Kwi 2013 22:23
    tmf
    Moderator Mikrokontrolery Projektowanie

    Freddie Chopin: Ale przecież użycie fixed point to nie żadna premature optimization. Raczej zastanowienie się nad sensem obliczeń i wyborem optymalnego algorytmu. To imho przypomina raczej wybór pomiędzy uint8_t a uint16_t.
    Podałeś przykład z mnożeniem niedostosowanych do FFP liczb, to ja podam kontrprzykład:
    for(float i=0;i<10;i+=0.00000001);
    Zadziała z float? Oczywiście nie. O czym to świadczy? Wyłącznie o tym, że programując trzeba myśleć.

    0
  • #27 06 Kwi 2013 22:40
    nibbit
    Poziom 19  

    Freddie Chopin napisał:

    Podałeś zaletę, podam więc wadę - może nie tracisz precyzji, ale też jej nie masz. Ciekawy jestem jak policzysz na stałym przecinku coś takiego: 100000.1 * 0.000001

    Nie mówiłem, że fixed-point jest bez wad ;]

    Co do reszty, każdy rozum ma i wie co mu się przyda najlepiej. Bez przesady żeby popadać ze skrajności w skrajność ale chciałem po prostu zwrócić uwagę, że optymalizacja nie musi za wsze polegać na tym, że ma być szybciej. Wszystko ma swoje wady i zalety.

    A przykład tmf żywcem z praktyki wzięty jak float może 'brzydko' wpłynąć na np. interpolację przebiegu.

    0
  • #28 06 Kwi 2013 22:48
    Jado_one
    Poziom 22  

    Zdaje się, że teraz mamy nowy swiatowy trend pt. "Po co się męczyć z jakąkolwiek optymalizacją kodu, jak wszystkie nasze niedbałości załatwi rosnąca moc obliczeniowa procesorów".
    Sooo, SPL is cool ;-)
    A niektórzy się denerwują, ze taki Microchip nie zezwala w swoim (nie do końca) darmowym GCC ustawienie poziomu optymalizacji większej niż -o1 :D

    0
  • #29 06 Kwi 2013 22:56
    Freddie Chopin
    Specjalista - Mikrokontrolery

    tmf napisał:
    Podałeś przykład z mnożeniem niedostosowanych do FFP liczb, to ja podam kontrprzykład:
    for(float i=0;i<10;i+=0.00000001);
    Zadziała z float? Oczywiście nie. O czym to świadczy? Wyłącznie o tym, że programując trzeba myśleć.

    Rozwiązanie problemu który przedstawiłeś zajmuje jakieś 3 sekundy - wystarczy zastosować typ double (lub po prostu zmienić wartości, ale trzymajmy się problemu). Chętnie dowiem się jak równie szybko rozwiązać problem który przedstawiłem ja (; Moim skromnym zdaniem liczby typu float są akurat bardziej ogólnym typem, bo jednak sytuacja w której trzeba pomnożyć/podzielić coś małego przez coś dużego wydaje mi się częstsza niż sytuacje w której utrata miliardowych części jedynki jest problemem (przedstawiona pętla to przykład całkowicie abstrakcyjny (; )...

    nibbit napisał:
    A przykład tmf żywcem z praktyki wzięty jak float może 'brzydko' wpłynąć na np. interpolację przebiegu.

    Hmm... Jeszcze nie zdarzyło się w mojej praktyce wpaść/trafić na pomysł zastosowania float jako licznika pętli z inkrementacją o jedną stomilionową... (;

    Jado_one napisał:
    Zdaje się, że teraz mamy nowy swiatowy trend pt. "Po co się męczyć z jakąkolwiek optymalizacją kodu, jak wszystkie nasze niedbałości załatwi rosnąca moc obliczeniowa procesorów".
    Sooo, SPL is cool

    Trochę mieszasz sprawy. W SPL nie chodzi o to że jest wolny czy duży (pamięci flash jest sporo), tylko o to (przynajmniej mi), że jest po prostu BEZNADZIEJNIE napisany (wystarczy zerknąć do pierwszej lepszej funkcji), nieintuicyjny (żeby go użyć to muszę przeczytać zarówno RM jak i dokumentację tej pseudo-biblioteki) a do tego niesamowicie rozwlekły. Nie wiem którą z tych wad widzisz też w stosowaniu liczby typu float do policzenia czegoś co jest ułamkiem na 32-bitowym układzie... Poza tym wymagania jakie stawia się bibliotece są definitywnie odmienne od tych stawianych "aplikacji". Akurat biblioteka powinna być zoptymalizowana... Pomijasz też tutaj taką drobną sprawę, że SPL ma też funkcje w których wywołanie i powrót zajmują więcej czasu niż "zawartość" - ustawienie pinu, odczyt z rejestru danych SPI - i używanie do tego osobnej funkcji jest po prostu paranoją...

    Poza tym problemem jest rozumienie słowa "optymalizacja". Wydaje mi się, że oryginalnie chodziło o przyspieszenie programu który jest ZBYT WOLNY, poprzez poprawę miejsca które marnuje najwięcej czasu. Tymczasem w świecie mikrokontrolerów znaczenie tego słowa jest mniej więcej takie "najgłupsza rzecz musi być superoptymalna i jeśli 3 dni pracy pozwolą zaoszczędzić 1 cykl zegara na 10000000000000000 to należy to zrobić".

    No bo czemu stosowanie liczby typu float czy funkcji typu sinf() jest nagle "niedbałością"? Może stosowanie C też nią jest, przecież w assemblerze na pewno "by było szybciej"? Sam używasz PIC32, czy to przez niedbałość? Projekty które robisz pewnie dałoby się zrobić na dsPIC33, PIC24, PIC18 i to jeszcze w assemblerze, a nie w tym "języku nieudaczników którzy nie umieją programować" (;

    4\/3!!

    0
  • #30 06 Kwi 2013 23:38
    Jado_one
    Poziom 22  

    pikantnyketchup napisał:
    Oki.
    Będę walczył, aż się krew poleję. Jak się zaprę to się nauczę. Czyli z książką Paprockiego dam sobie spokój i zacznę studiować ref.man.

    Książka Paprockiego to w dużej części przetłumaczone fragmenty manuala i przykłady oparte na SPL. Jeżeli nie zamierzasz korzystać z SPL'a, to ta książka początkowym przejrzeniu będzie robić to samo co mój egzemplarz - stać na półce i kurzyć się.
    Po kilku latach, gdy wejdą na rynek nowsze procesory, jej wartość zmniejszy się tylko do wartości historycznej (może już się to nawet stało).
    Oczywiście - gdy ktoś nie ma wystarczającej znajomości angielskiego, żeby czytać bezpośrednio manuala, to ta książka może być jedyną szansą dla tej osoby.
    A producenci prześcigają się w wypuszczaniu na rynek coraz to nowszych procesorów, z lepszymi peryferiami, zegarami, zasobami i tylko manual bezposrednio pozwala na nadążenie za nimi.
    Aczkolwiek hobbysta nie musi uczestniczyć w tej pogoni :-)

    Dodano po 24 [minuty]:

    Freddie - tu chyba działa u Ciebie jakiś stereotyp "starego assemblerowca", który walczy o każdy cykl/bajt pamięci niezależnie od sensu takiego działania.
    Ja w każdym razie nie jestem takim "pedantem kodu" :-)
    Co nie znaczy, że sensownie/czysto/rozsądnie napisany kod z dobrymi komentarzami nie cieszy oka ;-) Ale to po prostu wynika z dobrych nawyków programistycznych, doświadczeń, które każdy z nas zdobywa (no chyba, że nie zdobywa ;-) )
    Sam piszesz, że Ci sie nie podoba SPL - i słusznie :-)
    I nie mam nic do float - jak potrzeba to się stosuje :-)
    Mnie tylko zaciekawiła teza że "znajomość procesorów 8-bitowych i doświadczenia z tym związane, przeszkadzają w programowaniu procesorów 32-bitowych".
    I chciałem się dowiedzieć jakie to nawyki - bo może przypadkiem i ja nim ulegam :-)
    Jak na razie wynika z dyskusji, że "nadmierna skłonność do optymalizacji" jest jedną z takich wad.
    A także "zbyt silne przywiązanie do artymetyki stałopozycyjnej"...
    What else?

    0