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.

Zestaw uruchomieniowy USB 3.0

sentes1 30 Cze 2013 18:37 2775 25
  • #1 30 Cze 2013 18:37
    sentes1
    Poziom 2  

    Moglibyście polecić jakiś zestaw uruchomieniowy + programator + mikrokontroller na początek do nauki. Mam lapka tylko z USB 3.0 i chciałbym programować w atmel studio 6 w C.

    0 25
  • #3 30 Cze 2013 22:40
    BlueDraco
    Specjalista - Mikrokontrolery

    To co zawsze - seria płytek STM32xxDISCOVERY

    0
  • #4 01 Lip 2013 09:36
    tmf
    Moderator Mikrokontrolery Projektowanie

    BlueDraco napisał:
    To co zawsze - seria płytek STM32xxDISCOVERY


    Zapomniałeś o warunku "chciałbym programować w atmel studio 6 w C." :)
    Z ciekawości zapytam - kupię Discovery po dumpingowej cenie, a co dalej? Niestety koszty użycia tych procków w realnym układzie już nie są takie fajne.

    0
  • #5 01 Lip 2013 09:53
    BlueDraco
    Specjalista - Mikrokontrolery

    No fakt, w AtmelStudio to raczej nie poprogramujesz. Tzn. na upartego da się, ale trochę z tym zachodu będzie - trzeba skopiować headery itd...
    A niby dlaczego koszty "nie fajne"? Ceny w niewielkich ilościach są raczej niższe niż podobnych, a sporo słabszych AVR.

    0
  • #6 01 Lip 2013 10:45
    piotrva
    Moderator na urlopie...

    Zapominasz niestety o kwestii kompilatora - albo mamy znośne, ale drogie środowisko (Atollic, Keil), albo łatane i kapryśne Eclipse, które działa jak działa.
    Mimo to w rozrachunku końcowym STM32 wypadają lepiej niż AVR (sporo większe możliwości), ale jak zawsze piszę początkującym - większe możliwości = większe skomplikowanie.

    0
  • #8 01 Lip 2013 12:43
    BlueDraco
    Specjalista - Mikrokontrolery

    Dlaczego kapryśne? Ja używam dwóch gotowych środowisk bazujących na Eclipse i jestem z nich zadowolony.

    Kabel USB A-miniB kupisz w każdym sklepie z akcesoriami komputerowymi.

    Wiesz, że ten zestaw kosztuje więcej, niż płytka z Cortexem z 0.5 MiB Flash, 64 KiB RAM, Ethernetem, USB i kolorowym, graficznym wyświetlaczem LCD z panelem dotykowym?

    0
  • Pomocny post
    #10 01 Lip 2013 12:45
    tmf
    Moderator Mikrokontrolery Projektowanie

    sentes1 napisał:
    Wiecie może czy do takiego zestawu jest od razu kabelek USB?
    http://www.kamami.pl/index.php?ukey=product&productID=188016
    Bo tak jak patrzyłem to na http://www.kamami.pl/ jakoś nie ma w sprzedaży takich kabelków (chyba, że źle szukałem :P). Napisałem maila do Kamami, ale na razie cisza :P.


    Nie, zestaw jest sprzedawany bez kabelka. Kabelek to zwykłe USB A-mini-USB.
    Zobacz ew. czy w Seguro nie jest ten zestaw taniej (nie pamiętam).

    0
  • #11 01 Lip 2013 12:46
    BlueDraco
    Specjalista - Mikrokontrolery

    Przepraszam, ale ja żadnego Eclipse samodzielnie nie składałem. Używam gotowych CodeRed LPCxpresso i CooCox.

    0
  • #12 01 Lip 2013 12:52
    tmf
    Moderator Mikrokontrolery Projektowanie

    BlueDraco napisał:
    Dlaczego kapryśne? Ja używam dwóch gotowych środowisk bazujących na Eclipse i jestem z nich zadowolony.

    Kabel USB A-miniB kupisz w każdym sklepie z akcesoriami komputerowymi.

    Wiesz, że ten zestaw kosztuje więcej, niż płytka z Cortexem z 0.5 MiB Flash, 64 KiB RAM, Ethernetem, USB i kolorowym, graficznym wyświetlaczem LCD z panelem dotykowym?


    Tylko czy do tego cortexa też czasem nie mamy "darmowego" kompilatora do 32 kB kodu?
    No i kwestia przykładów i supportu - Atmel do wymienionej płytki daje kilkaset przykładów. Wsparcie dla AVR na forach ogromne - a cortex? Fajny, tylko na dzień dobry trzeba poznać bebechy kompilatora i IDE, żeby sobie środowisko robocze poskładać, a wsparcie... ty, może ze dwie osoby jeszcze.
    Jest jeszcze jedna sprawa - cena. Płytki mają ceny dumpingowe, jak sobie ktoś sprawdzi ceny komponentów to suma wychodzi kilka razy wyższa niż cena devboard. Czyli w realnych projektach nie jest tak pięknie. Druga sprawa -jeśli ktoś potrzebuje ARM-power :) to musi się liczyć z płytkami wielostronnymi i lutowaniem gęstych rastrów. Jasne, są ARMy z TQFP48, tylko, że one nie mają jakiejś super mocy - raz że są masakrycznie okrojone z peryferii, Fmax też niezbyt imponujące (zazwyczaj do 48 MHz), natomiast zostaje wszystko to co upierdliwe - czyli środowisko i jego konfiguracja + stopień skomplikowania ARMów.

    0
  • #13 01 Lip 2013 13:18
    BlueDraco
    Specjalista - Mikrokontrolery

    Mamy darmowy do 32 K, darmowy do 128 K i z 5 darmowych bez ograniczeń.

    żadnego środowiska składać nie trzeba, ale jeśli ktoś lubi - to może to zrobić. Mi się dotychczas nie chciało i nie miałem takiej potrzeby - używam kilku gotowych środowisk, a parę lat już z nimi pracuję. Nie wiem, skąd się wzięły przesądy o kłopotach ze środowiskami do ARM.

    W TQFP64 dostaniesz Cortexa > 160 MHz ze 192 K RAM i 1 MB Flash, za jakieś 50 zł. Mało? Te 48-nóżkowe za < 10 zł mają zwykle 2 UARTy, min. 2 SPI i ok. 10 timerów, łącznie kilkanaście kanałów PWM.

    Przykłady oczywiście są, kilka dużych typu webserver i ze 30 na poszczególne kawałki.

    0
  • #14 01 Lip 2013 14:08
    tmf
    Moderator Mikrokontrolery Projektowanie

    <10zł to kupię XMEGA mocno bardziej wyposażony w peryferia niż ten ARM. Z kolei Cortex >160MHz to wiesz, że nawet na 2-stronnej PCB będzie kłopot umieścić, żeby to wszystko było zgodnie ze sztuką. Już nawet nie mówię o wyprowadzaniu sygnałów o takich częstotliwościach. To wszystko fajnie brzmi, ale dla amatora zaprojektowanie układów na takie częstotliwości jest niebanalne nie tylko z powodu wymaganej wiedzy, ale także uwarunkowań technicznych. A już na początek to zostają tylko devboardy, tylko co dalej? Jak to przenieść na wykonany własnoręcznie układ?
    Co do środowisk - może mam pecha, ale albo są proste i nawet fajne, ale tylko pseudodarmowe, albo ściągamy IDE, kompilator, cuda i to składamy do kupy.

    0
  • #15 01 Lip 2013 15:13
    BlueDraco
    Specjalista - Mikrokontrolery

    Znów przesądy. Używam dwustronnych płytek, mam poprawnie prowadzone zasilanie. przecież te 100 i więcej MHz jest tylko wewnątrz kostki - na zewnątrz jest kwarc 8 MHz, więc żadne zabiegi związane z wysokimi częstotliwościami nie są potrzebne. Nie widzę jakieś specjalnej różnicy pomiędzy projektem płytki pod ATmega i pod Cortexy.

    0
  • #16 01 Lip 2013 15:49
    sentes1
    Poziom 2  

    Dzięki tmf :) w seguro 21 zł taniej

    0
  • #17 01 Lip 2013 15:53
    Ostry23
    Poziom 18  

    Zgadzam się z BlueDraco. Przecież na płytce nie ma nigdzie 100MHz. tmf, zauważ, że STM32F4DISCOVERY jest płytką dwuwarstwową i jakoś nie ma problemu z podkręceniem jej MCU do 168MHz. Co do skomplikowania - ja bym nie dramatyzował. Akurat do serii Discovery wsparcie jest świetne - kilka pdf'ów + kilkadziesiąt przykładów do każdej z płytek. Wystarczy postawić sobie (na początek) Atollic True Studio (bo jest świetne, poza tym oparte na Eclipse CDT, więc potem przesiadka na w pełni darmowe Eclipse jest dużo łatwiejsza), które ma co prawda w darmowej wersji ograniczenie kodu do 32kB, ale za to można w nim b. szybko zapoznać się z MCU (przykłady od ST są przygotowane m.in. dla tego IDE). A gdy już się pozna kontroler, wystarczy przekonwertować przykłady do projektu dla w pełni darmowego Eclipse i uzyskuje się darmowe środowisko dla ARM'ów, bez ograniczania się do jednego producenta kości.
    Przyznaję, nie jest to tak wygodne z stosowaniu jak Atmel Studio z ASF, ale też nie trzeba się od razu rzucać na "czyste" Eclipse.
    Co do wsparcia - tmf, tu się również nie zgodzę, że go nie ma. Nawet na elektrodzie jest coraz więcej tematów dotyczących ARM'ów. W necie jest mnóstwo tutoriali opisujących jak połączyć Eclipse, gdb i openocd (chociażby słynny już tutorial Freddie Chopina), więc z brakiem wsparcia nie trafiłeś.
    Eclipse ma też jedną zasadniczą zaletę - nie dotyczy go tzw. vendor lock-in.
    A co do wspomnianych przez ciebie max. 48 MHz dla tańszych ARM'ów. No i co z tego? Może MIPS'ów będzie "tylko" 1,5 razy tyle co w XMEGach, ale DMIPS'ów na pewno będzie dużo więcej (porównywałeś sobie listę rozkazów AVR i Cortex-M3?)
    XMEGi są wygodne, przyjazne, sam bardzo je lubię, ale właśnie jestem w trakcie przesiadania się na Cortex-y (zresztą nie tylko od ST, używam również SAM3S od Atmela) i biorąc pod uwagę stosunek możliwości do ceny, raczej rzadko będę wracał do XMEG.
    Może warto zacząć pisać książkę o Cortex-ach? :)

    0
  • #18 01 Lip 2013 17:15
    tmf
    Moderator Mikrokontrolery Projektowanie

    Nawet jeśli to 100 MHz jest w środku to ilość kondensatorów odsprzęgających, wymogi co do ich położenia, czy płaszczyzna masy pod MCU powodują, że tak pięknie to nie jest. Z drugiej strony, można się zastanowić, a co jeśli chciałbym to wyprowadzić i sterować z MCU układami zewnętrznymi? Już muszę myśleć jak ograniczyć szybkości narastania/opadania zboczy, routowaniu sygnałów itd. Także szybszy procesor to nie tylko więcej MIPSów, to także realne problemy. Gdyby tak nie było to przecież mógłbym sobie wsadzić i7, prawda? W końcu na zewnątrz żadne GHz nie wychodzą :) Także wybór wypaślaka z setkami MHz do przysłowiowego migania diodą z wielu względów nie jest optymalny.
    Zainstaluje pseudodarmowe środowisko z oganiczeniami i co dalej? Po miesiącu mam się przesiąść na co? Są tutoriale jak ożenić różne samoróby i mieć mercedesa z odpadów poklejonych taśmą, problem w tym, że to dla mnie bez sensu. Jestem amatorem, a to pociąga pewne konsekwencje. Mam czasu ile mam i chciałbym go spędzić na zabawie z mikrokontrolerem a nie przekonywaniu go do współpracy. Stąd też, aby realizować swoje hobby kupuję oryginalne narzędzia (bo wychodzi mnie to taniej niż zabawy w różne handmade substytuty), używam środowiska instalującego się od strzału, bo nie mam tygodnia na konfigurację i przebijanie się przez tutoriale.
    I teraz tak, powiedzmy, że to wszystko poinstaluję, a jak będzie problem to co? Pisząc o wsparciu mam na myśli dużo szerszy aspekt niż tylko instalacja openOCD. Kto na elce zna się na ARMach? Na palcach jednej ręki można policzyć, szczególnie jeśli się uwzględni osoby, które ostatnio się udzielają. FreddieChopin wpada sporadycznie.
    Co do tych DMIPSów, fajnie jeśli są potrzebne i jeśli mam operacje 32-bitowe. Bo na 8 bitach to kolosalnych różnic bym się nie spodziewał. Z drugiej strony ja lubię peryferia i mnie interesuje aby były wypasione. Niestety proste ARMy mają proste peryferia. A z częstotliwością akurat mam inny problem. Wrzuciłem na tapetę ARMa z Freescale, 48 MHz max, problem w tym, że te MHz potrzebuje do taktowania transmisji SPI. I co? I okazuje się, że SPI chodzi mi tylko trochę szybciej niż w XMEGA (24 vs. 16 MHz). Tak więc muszę wsadzić coś szybszego, ale szybsze to już nie tqfp48.
    Nie chcę kolejnego flejma zaczynać, po prostu rzeczy które robię świetnie działają na 8-bitowcach i nie widzę powodu dla którego miałbym czytać tony dokumentacji, aby na końcu osiągnąć to samo co już dostałem w sposób max wygodny. Oczywiście zdaję sobie sprawę, że nie wszyscy robią tak proste rzeczy jak ja, pewnie na elce jest wiele projektów megazaawansowanych do których ARMy są wręcz niezbędne. Dlatego wszędzie tam zachęcam do korzystania z nich.

    0
  • #19 01 Lip 2013 17:51
    Ostry23
    Poziom 18  

    tmf napisał:
    Nawet jeśli to 100 MHz jest w środku to ilość kondensatorów odsprzęgających, wymogi co do ich położenia, czy płaszczyzna masy pod MCU powodują, że tak pięknie to nie jest.

    Akurat plane masy stosować należy zawsze. Odsprzęganie też i to świadomie. Nikomu bym nie polecał kładzenia MCU na płytkach jednowarstwowych, a na dwuwarstwowych da się już porządnie poprowadzić plane masy a na Top dobrze doprowadzić zasilanie.

    tmf napisał:
    Z drugiej strony, można się zastanowić, a co jeśli chciałbym to wyprowadzić i sterować z MCU układami zewnętrznymi? Już muszę myśleć jak ograniczyć szybkości narastania/opadania zboczy, routowaniu sygnałów itd.

    To zdanie sugeruje, że możliwości tych kontrolerów znasz z haseł, nie z realnego używania. Na szczęście producenci MCU zdają sobie sprawę z tego, że EMI trzeba ograniczać, więc umożliwiają programową redukcję czasów narastania/opadania zboczy.
    Przykład dla STM32F407: Rejestr GPIOx_OSPEEDR. Zdefiniowane masz pola OSPEEDRy[1:0], gdzie:
    00: 2 MHz Low speed
    01: 25 MHz Medium speed
    10: 50 MHz Fast speed
    11: 100 MHz High speed on 30 pF (80 MHz Output max speed on 15 pF)

    [quote="tmf"]Także szybszy procesor to nie tylko więcej MIPSów, to także realne problemy. Gdyby tak nie było to przecież mógłbym sobie wsadzić i7, prawda? W końcu na zewnątrz żadne GHz nie wychodzą :)]/quote]
    Kompletnie nie rozumiem porównywania MCU z najszybszymi obecnie konsumenckimi CPU Intela. Dwa totalnie odległe światy.
    Poza tym, nie trzeba przecież w swoim układzie stawiać szybkiego STM32F2, czy F4 a wystarczy F1 lub nawet F0, gdzie masz, tak jak wspominałeś, częstotliwość taktowania rdzenia do 48MHz.

    tmf napisał:
    Także wybór wypaślaka z setkami MHz do przysłowiowego migania diodą z wielu względów nie jest optymalny.

    Kolejne nietrafione porównanie. Nikt tu nie mówił o takim zastosowaniu. Zresztą, XMEGi też bym nie pakował do przysłowiowego migania diodą.

    tmf napisał:
    Zainstaluje pseudodarmowe środowisko z oganiczeniami i co dalej? Po miesiącu mam się przesiąść na co? Są tutoriale jak ożenić różne samoróby i mieć mercedesa z odpadów poklejonych taśmą, problem w tym, że to dla mnie bez sensu.

    Przesiadka z czegoś opartego na Eclipse na "czysty" Eclipse naprawdę nie jest trudna. Po prostu wystarczy tych narzędzi używać świadomie a nie na zasadzie "jak kliknę to pole w tej zakładce, to mi działa, nie wiem czemu, ale niech tak zostanie. Aha, nie odróżniam makefile'a od make a kompilatora od linkera". Postawienie w pełni funkcjonalnego środowiska (i wstępne zapoznanie się z nim), z którym zaznaczam, nie muszę walczyć, zajęło mi dzięki tutorialom (dzięki Freddie) 1 dzień. Reszta, to "zabawa z mikrokontrolerem".

    tmf napisał:
    Kto na elce zna się na ARMach? Na palcach jednej ręki można policzyć, szczególnie jeśli się uwzględni osoby, które ostatnio się udzielają. FreddieChopin wpada sporadycznie.

    Nie wiem skąd bierzesz swoje dane, ale IMHO mocno odbiegają od prawdy.

    Co do czytania ton dokumentacji - to kolejna "urban legend". PDF jest co prawda dłuższy (faktycznie, 1,5k stron vs. 400 dla XMEG), ale jeśli potrzebujesz uruchomić dany moduł, to czytasz rozdział o nim i tyle. Nigdy w życiu nie czytałem żadnego manuala w całości.

    tmf napisał:
    Co do tych DMIPSów, fajnie jeśli są potrzebne i jeśli mam operacje 32-bitowe. Bo na 8 bitach to kolosalnych różnic bym się nie spodziewał.

    DMIPSy to DMIPSy, nie mówią nic o architekturze jaka wykonuje algorytmy Dhrystone. Pierwsza rzecz, która przychodzi mi do głowy, a na której dużo się czasowo zyskuje, to obsługa ADC i DAC, które nawet w ośmiobitowcach już od dawna najczęściej mają 10 lub 12 bitów.

    Podsumowując - ja też nie namawiam nikogo do stosowania dla prostych urządzeń koniecznie Cortex-ów bo są tak samo tanie a dużo więcej mogą. Natomiast w urządzeniach rozwojowych, gdzie nie chcemy się martwić, czy za rok dwa, gdy funkcjonalność "spuchnie", wystarczy nam mocy obliczeniowych, zawsze warto wybrać MCU z odpowiednim zapasem.

    0
  • #20 01 Lip 2013 21:00
    tmf
    Moderator Mikrokontrolery Projektowanie

    No tak, kwestie w których musiałbyś mi przyznać rację sprytnie ominąłeś :) Niech tak będzie.
    Co do odsprzęgania, owszem, muszę stosować je zawsze, ale błędy prędzej wyjdą przy procku taktowanym 100 MHz, niż przy procku taktowanym 32 MHz. W tym pierwszym przypadku wymogi są większe i już samo 100nF na pin zasilania może nie wystarczyć, a przyda się dać np. 100, 1nF i np. 100 pF. O tych limitach na pinach to ja doskonale wiem, a teraz popatrz na to z punktu widzenia osoby początkującej. Taka konfiguracja to nie jest żadne feature godne uwagi, tylko po prostu kolejny ból przez który musi osoba rozpoczynająca przygodę przebrnąć. W dodatku często bez zrozumienia po co owe limity wprowadzać. Ale za to jakie nowe ciekawe możliwości niedziałania układu wprowadzają :)
    Co do migania diodą to miałem na myśli różne projekty, nie tylko dosłowne miganie diodą. Ile widziałeś na elce projektów, wymagających czegoś więcej niż AVRa taktowanego minimalnym zegarem? Zaryzykowałbym twierdzenie, że żadnego :)
    Co do IDE - znowu patrzysz na to z punktu widzenia osoby, która co to jest makefile wie. Ale po to korzystam z IDE, żeby właśnie co to jest makefile nie musieć wiedzieć, ani co to jest make, ani w ogóle co pod tym IDE siedzi. Owszem, to może nawet jest i istotne, ale nie dla osoby rozpoczynającej z mikrokontrolerami, a przypomnę, że piszemy w dziale mikrokontrolery początkujący. Jeśli mam dla jednej rodziny IDE działające od strzału, a dla drugiej rodziny nie mam to IMHO wybór jest oczywisty.
    Co do tych osób znających ARMy, to wymienisz chociaż z 5 aktywnych na elce? Bo mnie przychodzi do głowy z 5 w ogóle, z czego 3 rzadko tu bywają.
    BTW, a propos mocy obliczeniowej. Robiąc przykłady do książki (niektóre całkiem skomplikowane), na jakieś 150 przykładów może w 4 potrzebowałem dla XMEGi taktowania 32 MHz, a to też nie ze względu na moc obliczeniową lecz na peryferia, które musiały odpowiednio szybko działać. W całej reszcie taktowanie wynosi 2 MHz. Pytanie więc brzmi, po co mi 100 MHz procesor? To co jest mi potrzebne to odpowiednie peryferia, które sprzętowo realizują to do czego owe 100 MHz musiałbym wykorzystać, gdybym je emulował softwarowo.
    Z drugiej strony, jak już kiedyś pisałem, jeśli używam C czy innego języka wysokiego poziomu to rdzeń CPU mnie praktycznie nie interesuje, interesuje mnie wyłącznie to co jest dookoła niego.
    Dobra, odbiegliśmy od tematu, więc na tym kończę, bo wyjdzie (już wyszedł) z tego kolejny bezsensowny flame.

    0
  • #21 01 Lip 2013 23:33
    BlueDraco
    Specjalista - Mikrokontrolery

    tmf: teoretyzujesz. Zaprojektowałem ponad 30 płytek pod Cortexy zgodnie z zaleceniami producentów. 100 nF na każdą parę nóżek i pojedynczy większy ceramiczny załatwiają odsprzęganie. Nie widzę żadnej różnicy w projektowaniu płytek pod 8-bitwce w kwadratowych obudowach i pod Cortexy. żadnych zakłóceń, żadnych problemów elektrycznych.

    A ostatnio zacząłem się bawić LPC810 w DIL8 - śliczności - właśnie do "migania diodami", i ma na pokładzie DWA UARTy - taki lepszy, szybszy i tańszy ATtiny... ;)

    0
  • #22 02 Lip 2013 07:48
    94075
    Użytkownik usunął konto  
  • #23 02 Lip 2013 08:31
    BlueDraco
    Specjalista - Mikrokontrolery

    Albertb:

    Teoretycznie oczywiście masz rację, a praktycznie w ok. 10 projektch użyłem procesorów w obudowach LQFP32 wyłącznie dlatego, że te w mniejszych miały tylko jeden UART. Potrzebowałem dwóch UARTów i dwóch wyjść bitowych... W innych projektach robiłem softwareowy UART, bo potrzebowałem trzech (i prawie nic poza tym) - LPC812 ma 3 w obudowie TSSOP20. To tyle o teorii i praktyce. ;)

    0
  • #24 02 Lip 2013 08:41
    94075
    Użytkownik usunął konto  
  • #25 02 Lip 2013 12:01
    Ostry23
    Poziom 18  

    tmf napisał:
    No tak, kwestie w których musiałbyś mi przyznać rację sprytnie ominąłeś :) Niech tak będzie.

    To nie tak :). Po prostu miałem mało czasu na napisanie postu i musiałem go trochę skompresować. tmf, ja bardzo sobie cenię Twoją wiedzę w dziedzinie AVR 8-bit, naprawdę. Ja po prostu chciałem podyskutować, wiesz, żeby się coś działo ;). Nie miało być napastliwie, czy złośliwie i sorry, jeśli tak wyglądało. W każdym razie dla mnie to nie był flejm, tylko żywa dyskusja :)
    Masz rację, że odbiegliśmy "nieco" od głównego tematu, dlatego jeszcze tylko jedną rzecz napiszę:
    rozumiem, że w swoich przykładach nie potrzebujesz więcej niż 2MHz zegara CPU. Ale jak mniemam, przykłady wykorzystują tylko konkretny moduł, do konkretnego zadania (popraw mnie, jeśli się mylę). Za to u mnie, w realnych aplikacjach, jest jednak trochę wielowątkowości - szybka akwizycja z ADC (często z nadpróbkowaniem), parsowanie telegramów z CAN czy UART, wymagana wysoka responsywność w sensie szybkości odpowiedzi na zapytania itp.; dużo innych rzeczy, które trzeba przeliczyć. Wszystko naraz a np. trzeba co 1ms wysłać raport. No i tu szybki zegar jest już koniecznością. Oczywiście, mądre peryferia tylko pomagają (chociażby DMA, które baaardzo ułatwia życie), ale samo CPU, przynajmniej w moich firmware'ach, też musi zrobić sporo rzeczy.
    Poza tym - jeśli chcesz postawić sobie wyświetlacz graficzny typu 320x240x16bit i jeszcze coś w miarę szybko na nim odświeżać, to bez kontrolera zewnętrznych pamięci i szybkiego CPU z odpowiednio dużym RAMem można zapomnieć. To takie typowe hobbystyczne zastosowanie jak dla mnie (zwłaszcza patrząc na ceny modułów typu HY-MINI itp.). I tu mądry Cortex pociągnie to duuużo lepiej niż XMEGA.
    No ale masz rację - wszystko zależy od potrzeb. Natomiast nie zgadzam się, że na elektrodzie praktycznie nie ma projektów, które wymagałyby mocy obliczeniowej Cortex'ów. Ktoś tu nawet prezentował WebServer, jeśli dobrze pamiętam

    tmf napisał:
    Z drugiej strony, jak już kiedyś pisałem, jeśli używam C czy innego języka wysokiego poziomu to rdzeń CPU mnie praktycznie nie interesuje, interesuje mnie wyłącznie to co jest dookoła niego

    Nie mogę, nie mogę :) Pamiętam wątek, w którym to pisałeś i pamiętam, że mocno się z tym nie zgadzałem. Nawet w C pewne szczegóły rdzenia jednak cię dotyczą:
    - jak są realizowane przerwania (np. w Cortex'ach masz sprzętowe odkładanie rejestrów na stos, w XMEGach nie - musisz to wiedzieć pisząc ISR, no chyba, że masz już makra, takie jak ISR() dla AVR'ów)
    - czy przerwania są priorytetyzowane? Czy jest wywłaszczanie przez przerwania o wyższym priorytecie. W Cortexach masz przecież preempting, tail-chaining, late-arrival i inne tego typu rzeczy, o których musisz wiedzieć, analizując jak może zadziałać twój program. To wszystko są kwestie rdzenia.
    - czy jest jednostka MPU - możesz przecież chcieć ją wykorzystać,
    - czy procesor ma różne tryby pracy, jak choćby privileged i unprivileged?
    - itd. itp.

    W ARM7 było jeszcze lepiej, bo miałeś przecież tryb ARM i tryb thumb.
    Od znajomości rdzenia się prędzej, czy później nie ucieknie. Oczywiście, do pewnego momentu możesz się nim nie interesować za bardzo, zwłaszcza gdy masz gotowe biblioteki i skrypt linkera, ale w pewnym momencie jakiś nieprzewidziany problem Cie dopadnie (np. exception) i co wtedy?

    0
  • #26 02 Lip 2013 13:15
    tmf
    Moderator Mikrokontrolery Projektowanie

    Ależ ja wcale nie odbieram tej dyskusji jako napastliwej, czy złośliwej, stąd uśmieszek na końcu tego co napisałem.
    Co do przykładów - są różne, niektóre wykorzystują sporo peryferii - odtwarzanie muzyki, współpraca z kartą SD z FAT, obsługa TP i LCD. Co nie zmienia faktu, że są zastosowania do których 8-bitowce się słabo nadają. Niemniej dzięki peryferiom zapotrzebowanie na moc obliczeniową nie jest tak duże. DMA + SPI praktycznie nie obciążają procka przy transmisji, do tego timer z rejestrami buforowymi lub DAC powodują, że dane z SDHC idą na timer w trybie PWM lub DAC bez udziału MCU. Robię transmisję bezprzewodową, gdzie np. wszystko jest szyfrowane AES bo mam sprzętowy moduł kryptograficzny. Transmituję dane do PC przez RS przy pomocy DMA, CRC liczone sprzętowo przy okazji transferu DMA. Oczywiście to są szczególne przypadki, ale powszechne. Nagle okazuje się, że program i rdzeń służą tylko do inicjalizacji peryferii. Takim sztandarowym przykłądem jest generowanie kolorowego obrazu video - zrobiłem sobie 800x600 8bpp, gdzie XMEGA robi wszystko sprzętowo, CPU śpi, budzi się co 1/70 sekundy, żeby przeładować rejestr adresowy. Bynajmniej nie dlatego, że rdzeń AVR jest taki wspaniały, ale mam fajne peryferia. A jak chcę odtwarzać mp3 to i tak koprocesor zewnętrzny jest potrzebny, bo ani 8-bitowiec, ani w miarę prost ARM softwarowo dekodowania nie zrobią. Czyli widać, że granica pomiędzy zastosowaniami wypasionych 8-bitowców i okrojonych ARMów jest bardzo płynna i to bardziej kwestia osobistych preferencji.
    Co do twojego przykładu z LCD - jasne, ARM jest szybszy, ale to też zależy. Jak połączę LCD przez SPI to w obu przypadkach będzie porównywalnie. Z drugiej strony jeśli podłączę LCD przez EBI z XMEGA to będę miał niezłego kopa i sterowanie takim LCD już ślamazarne nie będzie. Tu właśnie wracam do tego co pisałem wcześniej - ograniczeniem dla mnie akurat w takim projekcie było wolne SPI, które uniemożliwia mi uzyskanie odpowiednich transferów z SDHC, ale tu ARM okazał się takim samym niewypałem, musiałbym właśnie go popędzać ze 100 MHz, żeby uzyskać odpowiednią szybkość SPI do karty.
    Co do WebServera - ja bym sobie kupił po prostu np. Raspberry Pi i na tym postawił Apache :) Jakoś nie ufałbym homemade serwerom podłączanym do Internetu.
    Co do znajomości rdzenia - przy jakiś specyficznych aplikacjach pewnie tak. Ale nie przesadzajmy - to czy rejestry są odkładane sprzętowo czy nie to załatwia kompilator, programista nie musi nawet o tym wiedzieć. Inne sprawy to kwestia peryferii, kontroler przerwań też bardziej jest układem peryferyjnym niż częścią rdzenia.

    0