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.

Pisanie programów i używanie bibliotek w C i Asemblerze

kamyczek 10 Wrz 2016 12:13 8049 260
  • #212 10 Wrz 2016 12:14
    tmf
    Moderator Mikrokontrolery Projektowanie

    michalko12 napisał:
    tmf napisał:
    Ale, żeby się przyczepić - czy przed chwilą na uwagi kol. Kameczek dotyczące możliwości upakowania kodu w mniejszy i tańszy MCU, nie odpowiadaliście, że cena MCU w waszych projektach jest bez znaczenia? Bo stanowi ułamek ceny końcowej urządzenia i nie robicie milionowych serii? Czyżby jakaś niekonsekwencja?

    Ale to była tylko i wyłącznie odpowiedź na Twoje wątpliwości. Ja na cenę procesora zwracam uwagę, ale nie ma znaczenia czy będzie on kosztował 5$ czy 15$. Ważne są możliwości i widząc takie dwa przypadki nigdy nie zdecydowałbym się na tego Xmega mimo, że całkowicie by mi wystarczył. Po drugie to Atmel, nie raz już pokazali gdzie mają klientów, a historia jak widać powtarza się.


    Owszem, ważne są możliwości i to co jest nam potrzebne. Mnie z grubsza zwisa czy rdzeń jest 8- czy 32-bitowy bo w C tego nie widzę. Natomiast w moich projektach istotne są peryferia. A tu wcale nie jest tak różowo. Np. wymieniony przez ciebie STM32F410RBT6 do sterowania silnikami się kompletnie nie nadaje, a umieszczone w nocie "One 16-bit advanced motor-control timer" zakrawa na kpinę z klienta. Pomijając już timery i ich niedostosowanie do sterowania np. BLDC, to brak np. komparatorów analogowych też jest problemem. Oczywiście są ARMy, które to mają, ale może się okazać, że niekoniecznie wyjdą taniej niż dedykowany 8-bitowiec. Tym bardziej, że np. ostatnio Microchip wypuścił jakieś procki z dedykowanymi peryferiami do sterowania BLDC i komutacji bezsensorowej.
    Z drugiej strony to co mi się nie podoba w ARMach i jest grzechem przeniesionym ze starych 8 bitowców to niekonsekwencja w peryferiach. Znowu przykład wymienionego przez ciebie procesora - 6 typów, różniących się zastosowaniem timerów. Kompletny bezsens, bo znowu prowadzi do konieczności myślenia jaki timer użyć.
    IMHO jakakowiek generalizacja, że dany MCU/rodzina MCU jest najlepsza jest bez sensu. Bo w zastosowaniach embedded mamy tyle wąskich specjalizacji, że można mówić tylko i wyłącznie o tym jaki procesor jest najlepszy w konkretnym projekcie.

  • #214 10 Wrz 2016 12:21
    tmf
    Moderator Mikrokontrolery Projektowanie

    michalko12 napisał:


    Znam to i próbowałem używać. Swego czasu myślaem o Kinetisach, mam kilka płytek, ale mi przeszło. Procki jak na moje potrzeby zbyt ubogie w peryferia. Samo środowisko takie sobie. Po okresie próbnym wyłączyło się kilka dodatków, m.in. kreator konfiguracji procka i dałem sobie z tym spokój.

    Dodano po 1 [minuty]:

    Piotrus_999 napisał:
    tmf napisał:
    ARM to też odgrzewany kotlet. Największa siła MCU to właśnie peryferia. To one decydują o wszystkim. Jeśli wytniesz peryferia, to nie zostaje nic - do obliczeń są lepsze i szybsze procesory niż ARMy.


    Nie rozumiem tej złotej myśli - troche poszedłeś po bandzie. W myśl tej logiki jak okroimy Twoją ulubioną Xmegę z peryferiów to porównując z okrojonym ARM-em nie zostanie już z niej zupełnie nic.


    MCU to CPU+peryferia. Jeśli odetniemy peryferia to zostanie samo CPU, a mamy o wiele szybsze i lepsze CPU niż ARMy. W tym sensie z obu rodzin istotnie nie zostanie nic interesującego.

  • #215 10 Wrz 2016 12:24
    2675900
    Użytkownik usunął konto  
  • #216 10 Wrz 2016 12:29
    tmf
    Moderator Mikrokontrolery Projektowanie

    michalko12 napisał:
    tmf napisał:
    czywiście są ARMy, które to mają, ale może się okazać, że niekoniecznie wyjdą taniej niż dedykowany 8-bitowiec.

    LPC1500 i inne...

    http://www.kinetis.pl/node/265


    Czyli to o czym pisałem, w Farnellu >>30 zł. Dedykowane 8-bitowce są tańsze.

    Dodano po 3 [minuty]:

    Piotrus_999 napisał:
    tmf napisał:
    IMHO jakakowiek generalizacja, że dany MCU/rodzina MCU jest najlepsza jest bez sensu. Bo w zastosowaniach embedded mamy tyle wąskich specjalizacji, że można mówić tylko i wyłącznie o tym jaki procesor jest najlepszy w konkretnym projekcie.


    Racja 100%. Tylko że Kolego zawsze wracasz do obrony Xmegi.
    tmf napisał:
    Mnie z grubsza zwisa czy rdzeń jest 8- czy 32-bitowy bo w C tego nie widzę

    A ja widze - np po rozmiarze integera - żeby daleko nie szukać. Zmiana podejścia do krótszych (8 , 16 bit).
    tmf napisał:
    STM32F410RBT6 do sterowania silnikami się kompletnie nie nadaje

    Masz ogromny wybór procesorów, które sa do tego zastosowania zaprojektowane - np produkowane przez TI czy NXP.
    tmf napisał:
    a umieszczone w nocie "One 16-bit advanced motor-control timer" zakrawa na kpinę z klienta

    Bo to nie wyspecjalizowany procesor, tylko "ogólnego zastosowania".


    Kto tu czegoś broni. Bo to wyspecjalizowany procesor jest (swoją drogą ciekawe do czego jest wyspecjalizowany), bo są inne, np. produkowane przez TI czy NXP. Hmm, czy to nie brzmi jak na siłę przekonywanie, że musi być rdzeń ARM bo niesie on jakieś magiczne wartości dodane?
    W C od dawna używam typów np. uint8_t, uint16_t, uint32_t i długość inta na danej architekturze mi powiewa.

  • #217 10 Wrz 2016 12:37
    2675900
    Użytkownik usunął konto  
  • #218 10 Wrz 2016 12:42
    tmf
    Moderator Mikrokontrolery Projektowanie

    Piotrus_999 napisał:
    tmf napisał:
    W C od dawna używam typów np. uint8_t, uint16_t, uint32_t i długość inta na danej architekturze mi powiewa.


    No wesz ... obluga tych typów się "deczko" różni w procesorach 32 i 8 bitowych - i dobrze sobie z tego zdawać sprawę


    O, to coś nowego. A czym się różni?

  • #219 10 Wrz 2016 12:51
    dondu
    Moderator Mikrokontrolery Projektowanie

    Widzę, że dyskusja z ASM vs C przekształciła się w odwieczny spór - który procesor jest lepszy :D:D:D

    Odpowiedź jest prosta: To zawsze jest KOMPROMIS PANOWIE! :)

    Kompromis:
    - parametrów urządzenia docelowego,
    - ilości urządzeń do wyprodukowania,
    - ceny mikrokontrolera,
    - jego dostępności,
    - dostępności wiedzy jego dotyczącej (przykładów, ilości tematów na forum, itp.),
    - dostępu do bibliotek własnych lub obcych,
    - poziomu znajomości angielskiego,
    - czasu na poznanie nowej rodziny,
    - technologi montażu,
    - poziomu wiedzy z zakresu elektroniki,
    - przyzwyczajeń,
    - wymogów odbiorcy,
    - posiadanych licencji na narzędzia,
    - posiadanego zaplecza technicznego danej rodziny mikrokontrolerów,
    - ...
    - i pewnie wielu, wielu innych czynników ...


    Zestawienie kryteriów technicznych o największym znaczeniu
    dla producentów urządzeń wykorzystujących mikrokontrolery


    Pisanie programów i używanie bibliotek w C i Asemblerze

    Dlatego można zaklinać rzeczywistość np tak:

    Piotrus_999 napisał:
    Kolega tmf po prostu nie chce przyjąć do wiadomości że czas procesorów 8 bitowych juz minął.

    tylko że jest to nieprawda co udowadniają producenci mikrokontrolerów wprowadzając na rynek coraz nowsze 8-io bitowce nawet z tak zamierzchłej rodziny jak 8051.

  • #220 10 Wrz 2016 13:54
    2675900
    Użytkownik usunął konto  
  • #221 10 Wrz 2016 14:39
    tmf
    Moderator Mikrokontrolery Projektowanie

    Piotrus_999 napisał:
    tmf napisał:
    O, to coś nowego. A czym się różni?
    Choćby kosztem.

    W 32 bitowcach musisz użyć dodatkowych operacji aby zagwarantować zgodność z długością typu: np uxth czy uxtb (a raczej kompilator musi).

    Czyli dostajesz "penalty" za użycie typów krótszych niż 32bit. Szczególnie ważne przy zmiennych sterujacych w pętlach np. Jezeli zmienne w funkcji będą w rejestrach to nie warto ich mieć innych niz 32bit.

    Podobnie przy przekazywaniu parametrów i wartości zwracanej przez funkcje.


    No jakbym kol. Kamyczka słyszał i jego argumenty o asemblerze. Nie po to używam C, żeby się przejmować takimi rzeczami. Jakbym chciał liczyć takty to bym właśnie użył asemblera, a nie np. C. Z mojego punktu widzenia procesor albo ma wystarczającą moc obliczeniową aby podołać zadaniu, albo jej nie ma. A jesli ma to zwisa mi na ile instrukcji i jakich jest tłumaczony kod.
    Zresztą twój przykład jest nizbyt trafiony, bo przy większości operacji uxth, czy uxtb nie są potrzebne, gdyż mamy możliwość wykonywania operacji na 8-bitowych i 16-bitowych częściach rejestru, bez konieczności ich rozciągania do 32-bitów. Jeśli więc kompilator to robi (w co szczerze wątpię) to świadczy to tylko o jakimś błędzie w kompilatorze.

  • #222 10 Wrz 2016 14:43
    2675900
    Użytkownik usunął konto  
  • #223 10 Wrz 2016 14:46
    tmf
    Moderator Mikrokontrolery Projektowanie

    Piotrus_999 napisał:
    tmf napisał:
    No jakbym kol. Kamyczka słyszał i jego argumenty o asemblerze. Nie po to używam C, żeby się przejmować takimi rzeczami.


    Nie - chodzi o to aby sie przestawic z myslenia 8 bitowego na 32 bitowe. Nie chodzi o liczenie taktów.


    A to już jakieś hokus pokus. Możesz wyjaśnić co miałeś na myśli? Bo jeśli chcesz powiedzieć, że wszystkie zmienne powinny mieć 32-bity, bo mamy 32-bitowy procesor to tylko się zaśmieję.

  • #224 10 Wrz 2016 15:17
    2675900
    Użytkownik usunął konto  
  • #225 10 Wrz 2016 15:53
    kamyczek
    Poziom 34  

    No panowie do czajnika to najlepiej 64bitowy

  • #226 10 Wrz 2016 16:15
    grko
    Poziom 33  

    @kamyczek W czajniku to nawet nie warto 8-bitowca ;) Zresztą po tym co napisałeś jak zabierałbyś się za soft do takiego czajnika/tostera to jestem szczęśliwy, że posiadam te urządzenia bez mikrokontrolerów.

  • #227 10 Wrz 2016 19:16
    2675900
    Użytkownik usunął konto  
  • #228 10 Wrz 2016 20:13
    tmf
    Moderator Mikrokontrolery Projektowanie

    Piotrus_999 napisał:
    tmf napisał:
    A to już jakieś hokus pokus. Możesz wyjaśnić co miałeś na myśli? Bo jeśli chcesz powiedzieć, że wszystkie zmienne powinny mieć 32-bity, bo mamy 32-bitowy procesor to tylko się zaśmieję.


    @tmf Trochę zaczynasz argumentować nie na swoim poziomie, nie piszmy o błedach kompilatorów.

    Jezeli nie masz jakiegoś specjalnego powodu aby je mieć krótsze to tak.

    Załączam stronę z poradnika dla migrujących z 8 i 16 bitowych procków autorstwa TI.

    Pisanie programów i używanie bibliotek w C i Asemblerze

    Możesz co prawda użyć typów fast np uint_fast8_t ale używać ich trzeba z dużą ostrożnością bo nie ma sprawdzania czy wartość mieści się we właściwym zakresie dla tego typu. np:
    Pisanie programów i używanie bibliotek w C i Asemblerze

    tmf napisał:
    gdyż mamy możliwość wykonywania operacji na 8-bitowych i 16-bitowych częściach rejestru
    Widać o czymś nie wiem.


    Ale czego to ma dowieść? Że tracimy parę taktów w określonych sytuacjach? No i co z tego. To nie asembler, jeśli tak cie te kilka taktów boli, to porzuć C, być może zaoszczędzisz więcej. Pisałeś o różnicach w obsłudze typów, spodziewałem się, że jakąś nową matematykę poznam, a tu mi z jakimś premature optimization wychodzisz :) Jeśli mnie to będzie bolało to sobie zrobie typedef super_hiper_optymalizacja będący aliasem do int16 lub int32 w zależności od architektury i znowu będę cieszył się spokojem jaki tylko osoby studiujące tajemnice asemblera mogą zaznać :) Aj, już to ktoś wymyślił i są typy fast. Jeśli mamy fast z określeniem szerokości to mamy gwarancję, że tym ma co najmniej podaną liczbę bitów więc tu nie ma problemu.
    Ale wytłumacz mi w jaki sposób zaburzy to działanie mojego programu w C?

  • #229 10 Wrz 2016 21:52
    kamyczek
    Poziom 34  

    No dobra Piotruś arm jakiej firny ? Tomek Xmega i C ja AVR i asembler , ktoś coś wypicuje na picu? No to jeszcze ST i Frescale i będziemy mieli całkiem fajny przekrój mikrokontrolerów z rynku . Zapraszam koledzy takiego tematu nie było porównamy jak się koledzy zmobilizują kilka podejść na różnych platformach do tego samego zagadnienia . Kto coś skrobnie proszę o deklaracje .

  • #230 10 Wrz 2016 22:22
    2675900
    Użytkownik usunął konto  
  • #231 11 Wrz 2016 08:14
    tronics
    Poziom 37  

    @Piotrus_999 przydałby się pomiar poziomu cieczy, albo przynajmniej czujnik, że jest minimalna ilość :) Chociaż poziom byłby lepszy dla PIDa (bo można założyć proporcjonalny wzrost inercji). Przewidywany czas zaparzenia na WWW ;) Przypominajka jak któryś raz z rzędu podgrzewa...

  • #232 11 Wrz 2016 09:15
    2675900
    Użytkownik usunął konto  
  • #233 11 Wrz 2016 09:35
    tmf
    Moderator Mikrokontrolery Projektowanie

    Piotrus_999 napisał:
    tmf napisał:
    Ale czego to ma dowieść? Że tracimy parę taktów w określonych sytuacjach? No i co z tego.

    W sumie nic. Tylko chodzi o zmianę podejścia. Nie wymaga to niczego poza pamiętaniem że się ma 32 bity do dyspozycji i jest to naturalna wielkość danych i bez potrzeby nie trzeba tego zmniejszać.

    W AVR-ach wszystko co ma więcej niz 8 bit jest kosztowne. W 32 bitowcu to co ma mniej niż 32. Nie wiem co w tym jest do takiego ataku na mnie. Jeżeli to taka wiedza tajemna i szczególizm to ja przepraszam za zakłócenie spokoju.


    Moim celem nie był atak na ciebie. Więc tego tak nie odbieraj. Po prostu - pisałem, że jak piszę w C to większość magii związana z rdzeniem CPU jest przede mną ukryta. To, że da się napisać optymalniej program znając właściwości rdzenia i np. listę rozkazów asemblera jake są do dyspozycji to sprawa oczywista. Przy ARM są bardziej spektakularne optymalizacje niż promocja wszystkiego co się da do typów 32-bitowych. Np. operacje przesunięć bitowych. Na AVR są piekielnie kosztowne, na ARM nie kosztują nic. Stąd też na AVR program je wykorzystujący musi być bardzo przemyślany i o ile się da, nie należy przesuwać o więcej niż jeden bit na raz, na ARM mamy pełną swobodę. Z kolei inne rdzenie ARM np. mają operacje wspomagające pracę na typach upakowanych, inne nie mają. Czyli znowu w C można program napisać nieco inaczej. Tyle, że to wszystko ma zastosowanie w bardzo specyficznych sytuacjach, drobnych fragmentach programu, gdzie liczy się wydajność. I tu warto znać asembler danego rdzenia i to jak kod kompiluje kompilator, żeby albo wstawić wstawkę w asemblerze, albo tak napisać kod C, żeby maksymalnie ułatwić życie kompilatorowi, aby mógł wygenerować optymalny kod asemblerowy.

    Dodano po 8 [minuty]:

    kamyczek napisał:
    No dobra Piotruś arm jakiej firny ? Tomek Xmega i C ja AVR i asembler , ktoś coś wypicuje na picu? No to jeszcze ST i Frescale i będziemy mieli całkiem fajny przekrój mikrokontrolerów z rynku . Zapraszam koledzy takiego tematu nie było porównamy jak się koledzy zmobilizują kilka podejść na różnych platformach do tego samego zagadnienia . Kto coś skrobnie proszę o deklaracje .


    Tylko, że na takim trywialnym przykładzie nie pokażesz żadnych specyficznych właściwości procka. Do tego trzeba by mieć kilka specyficznych przykładów i wtedy okazałoby się, że do pewnych zastosowań doskonale nadaje się procek X, a do innych procek Y. Tu nie będzie żadnej istotnej różnicy pomiędzy ATTiny, czy XMEGA, i chyba kompletnie żadnej pomiędzy ARMami różnych firm. Różnica pomiędzy AVR a ARM będzie zapewne w tym, że implementacja PIDa na ARM będzie efektywniejsza i krósza.
    Swoją drogą, jeśli tendencje cenowe AVRów się utrzymają, to istotnie warto będzie się przerzucić na jakieś ARMy. Nie ma znaczenia czy procek kosztuje 8 czy 10zł, ale jeśli widzę, że w moim projekcie XMEGA kosztuje ponad 40zł, a podobny ARM mogę kupić za 10zł, to już robi mi to różnicę. Tym bardziej, że wiele miłych bajerów, które są w XMEGA są w Atmelowskich ARMach. Podobnie jak z programatorem/debugerem - Atmel dwukrotnie zwiększył cenę Atmel ICE, strzelając sobie w kolano. Który hobbysta to kupi, jeśli 3-razy taniej można kupić oryginalne narzędzia do ARMów. Jedyne w czym był jakiś postęp to w Xplained, gdzie w końcu umieścili na pokładzie programator/debugger i zaczeli to sprzedawać w rozsądnej cenie (np. z SAM D10 za 40zł, z ATMega328 podobnie). Ale jak i to się zmieni to w całości przyjdzie przyznać rację kolegom ARMowcom. Mimo, że darmowe, w pełni wypasione IDE ciągle kusi.

  • #234 11 Wrz 2016 09:48
    2675900
    Użytkownik usunął konto  
  • #235 11 Wrz 2016 12:24
    kamyczek
    Poziom 34  

    tmf napisał:
    albo tak napisać kod C, żeby maksymalnie ułatwić życie kompilatorowi, aby mógł wygenerować optymalny kod asemblerowy.


    Myślisz ze człowiek jest głupszy od kompilatora który stworzył ?

    tmf napisał:
    Tylko, że na takim trywialnym przykładzie nie pokażesz żadnych specyficznych właściwości procka. Do tego trzeba by mieć kilka specyficznych przykładów i wtedy okazałoby się, że do pewnych zastosowań doskonale nadaje się procek X, a do innych procek Y. Tu nie będzie żadnej istotnej różnicy pomiędzy ATTiny, czy XMEGA, i chyba kompletnie żadnej pomiędzy ARMami różnych firm. Różnica pomiędzy AVR a ARM będzie zapewne w tym, że implementacja PIDa na ARM będzie efektywniejsza i krósza.


    Tomku tu waśnie o to chodzi by nie pokazywać różnicy między mikrokontrolerami a językami w jakich będzie to napisane .

    Piotrus_999 napisał:
    Kolega kamyczek się rozgorączkował tym nieszczęsnym challengem - ja nie zrobię czajnika z tego powodu - zrobię bo pomysł mi się spodobał. A procesor oczywiście użyję taki jaki mam akurat w szufladzie czyli w moim przypadku STM32F446RET, który jest oczywiście o wiele za duży jak na ten projekt.


    Każdy powód dobry by się wycofać , a większość tak pyszczyła jak to szybko i tanio zrobią czajnik na armie w C . Walkower C-ieniasy ;) ?

  • #236 11 Wrz 2016 18:29
    michalko12
    Specjalista - Mikrokontrolery

    kamyczek napisał:
    Myślisz ze człowiek jest głupszy od kompilatora który stworzył ?

    A Ty znowu swoje, już miałeś tutaj jeden przykład. Mam nadzieję, że nie korzystasz z żadnego kalkulatora, zwłaszcza naukowego, bo inaczej to tak, jakbyś przyznałbyś się do tego, że jesteś od niego głupszy.

  • #237 11 Wrz 2016 19:06
    2675900
    Użytkownik usunął konto  
  • #238 11 Wrz 2016 21:23
    tmf
    Moderator Mikrokontrolery Projektowanie

    Piotrus_999 napisał:
    tmf napisał:
    XMEGA kosztuje ponad 40zł, a podobny ARM mogę kupić za 10zł, to już robi mi to różnicę. Tym bardziej, że wiele miłych bajerów, które są w XMEGA są w Atmelowskich ARMach.

    Myślę że to proces ubijania Xmegi. Wg mnie to była ślepa odnoga - w miare rozsądne peryferia na przestarzałym rdzeniu. Trochę jak wypicowana na 20stkę 50-tka


    XMEGi wprowadzono na rynek wiele lat temu, kiedy jeszcze o ARMach myśleli nieliczni. I ciągle są to świetne procesory, które mają peryferia spokojnie konkurujące z peryferiami wypasionych ARMów. Rdzeń nie zawsze jest istotny, popatrz chociażby na preferencje użytkowników, które wstawił kol. Dondu. Moc obliczeniowa plasuje się na dalekich pozycjach. Jeszcze kilka miesięcy temu XMEGA serii E5 można było kupić za 4-6 zł, a to niezła cena za procesor z bardzo dobrymi peryferiami, czy XCL, mogącym pracować jako konfigurowalne glue logic. Za 12 zł była seria A1U, która ma USB i interfejs m.in. do SDRAM. W chwili wprowadzenia na rynek była to mała rewolucja. Czas pokaże co Microchip będzie chciał z tym wszystkim zrobić.

  • #239 11 Wrz 2016 21:58
    kamyczek
    Poziom 34  

    michalko12 napisał:
    A Ty znowu swoje, już miałeś tutaj jeden przykład. Mam nadzieję, że nie korzystasz z żadnego kalkulatora, zwłaszcza naukowego, bo inaczej to tak, jakbyś przyznałbyś się do tego, że jesteś od niego głupszy.


    Wiesz Michałko może wiedzę masz ale kultury za grosz . Dzięki takiemu podejściu dość dużego grona prześmiewców asemblera mam ochotę zamknąć ten temat bo mimo że większość chciała jakiejś konfrontacji asemblera z C i różnych platform przy okazji teraz dyskusja sprowadza się już w zasadzie do wymiany jakiś teorii . Poza tym to powiem ci jedno wolę być jak to napisałeś głupi pisać w asemblerze ale przynajmniej mieć satysfakcję że kod od pierwszej do ostatniej linijki jest mojego autorstwa .

  • #240 11 Wrz 2016 22:02
    tmf
    Moderator Mikrokontrolery Projektowanie

    @kamyczek Oj, zacznij już pisać ten program bo nie zdążysz :) Ja oceniam czas potrzebny na jego napisanie w C na 29 minut. Pamiętaj - DS18b20 i PID do regulacji temperatury. Wstawisz kod, a gwarantuję, że wstawię swój w C :)