logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Przesiadka na AtMega 64 - występują jakieś "kruczki"?

tehaceole 11 Cze 2012 08:22 6061 30
  • #1 10988889
    tehaceole

    Poziom 28  
    Witam Kolegów

    Do tej pory w swoich projektach wykorzystywałem młodszych "braci" sześćdziesiątki czwórki: m8, m16, m32. Jednak "nadejszla wekopomna chfyla"... Czas sięgnąć po coś z większą ilością pinów, pamięci programu, RAM, EEPROM.
    Póki co wybór mój padł na AtMegę 64 - nie twierdzę, że jest to wybór optymalny. Stąd prosiłbym Kolegów, którzy już mieli do czynienia z większymi procesorami serii AVR Mega o odpowiedź na poniższe pytania:
    - czy AtMega 64 to dobry wybór pod względem możliwości / cena przy przesiadce z mniejszych procesorów? Czy warto rozejrzeć się za jakąś alternatywą dla 64?,
    - czy w pinologii 64 są jakieś "kruczki"? Doczytałem na Forum, że np. w m128 najczęstszą przyczyną problemów podczas pierwszych zabaw jest poprawne podłączenie pinów ISP, wynikające z wprowadzających w błąd opisów w datasheet. Czy 64 również "kryje" w sobie tego typu niespodzianki?

    Bardzo prosiłbym Szanownych Kolegów o:
    - nie odbieganie od tematu - mówimy o serii Mega, nie XMega, nie ARM, nie PIC itp.,
    - powstrzymanie się od zdawkowego "poczytaj datasheet" - DS to podstawa przy jakichkolwiek zabawach z naszymi "mnogokończynowymi zwierzątkami" elektronicznymi. Więc tego typu "porada" niczego konstruktywnego do dyskusji nie wniesie.

    Dziękuję Kolegom serdecznie za okazanie zainteresowania tematem.

    Pozdrawiam!
  • #2 10989133
    tmf
    VIP Zasłużony dla elektroda
    Jeśli nie chcesz mówić o innych seriach, w tym innych AVR to twoje pytanie czy M64 to dobry wybór traci sens. Bo jeśli nie dobry to co? Porzucić mikrokontrolery?:)
    M64 jest ok, ale w stosunku do M32 niewiele wnosi - więcej pamięci i interfejs XMEM. Pinologicznie i problematycznie jest to to samo co M128. Procesor jest już dosyć starawy i warto pomyśleć o nowszym odpowiedniku. Cenowo i możliwościowo ciekawsze są XMEGA, jest to duży postęp jeśli chodzi o peryferia i wygodę posługiwania się nimi.
  • Pomocny post
    #3 10989164
    dondu
    Moderator na urlopie...
    Witaj,

    Nie obraź się, ale Twoje pytanie:

    tehaceole napisał:
    Do tej pory w swoich projektach wykorzystywałem młodszych "braci" sześćdziesiątki czwórki: m8, m16, m32. Jednak "nadejszla wekopomna chfyla"... Czas sięgnąć po coś z większą ilością pinów, pamięci programu, RAM, EEPROM.
    Póki co wybór mój padł na AtMegę 64 - nie twierdzę, że jest to wybór optymalny.

    jest nieco bez sensu, skoro miałeś do czynienia z m32, a chcesz stosować m64 :)

    Weź wyszukiwarkę Atmela na jego stronie w menu po lewej i tam ustaw tylko 8-bitowce, a otrzymasz tabelkę parametrów wszystkich uC i wtedy wybieraj.
    Tabelkę będziesz mógł zapisać także jako CSV i zaimportować do pliku Excela patrz załącznik poniżej.

    Może wybierzesz jakiś dedykowany do USB lub PWM lub inny, a może jednak XMega jak radzi kol. Tmf.

    Moderowany przez _Robak_:

    Wyłączyłem punkty za plik.

  • Pomocny post
    #4 10989237
    mirekk36
    Poziom 42  
    Jeśli chodzi o wybór podyktowany zwiększeniem ilości pinów to czemu nie ? ATmega64 to dobry wybór. Masz dodatkowo jeszcze jeden Timer 16-bitowy ;) .... a jeśli chodzi o przeniesienie kodu to żadna różnica i to jest fajne w porównaniu do przesiadania się zaraz na Xmega.

    Poza tym są jeszcze takie jakby nieco większe wersje procków z serii ATmega2560/2561 - jedne w obudowie 100 pinów drugie też 64 piny jak ATmega64 no ale zasobów sprzętowych więcej jeśli chodzi o Timery, po 4 UART'y nawet i inne - chociaż poczciwa ATmega64 też ma dwa - to też ładnie.

    Reasumując - czemu nie? ;) .... to kolejny klocek lego AVR ...
  • Pomocny post
    #5 10989444
    tmf
    VIP Zasłużony dla elektroda
    Może źle odebrałem pytanie. Jeśli chodzi tylko o większą liczbę pinów IO to M64/128/256 są jak najzupełniej ok. Wygodne, bo to to samo co kolega tehaceole już zna. Jeśli chodzi o coś więcej to przesiadłbym się właśnie na XMEGA, bo przy tej samej cenie oferują znacznie więcej, ale co ważniejsze, peryferia mają fajnie "poukładane". No i o wiele bardziej rozbudowane, np. takie timera to niebo i ziemia. Ale jeśli jednym z argumentów jest duża liczba pamięci (>128kB) to w ogóle odradzałbym AVRy. To jednak 8-bitowce i >128kB RAM praktycznie nic nie wspiera. Niby C, czy Bascom mają jakąś tego obsługę ale to kpina, a nie coś co można wykorzystać. W każdym razie próba wykorzystania >128kB FLASH nauczy co najwyżej złych nawyków i przeklinania :)
  • #6 10989539
    tehaceole

    Poziom 28  
    dondu napisał:
    Weź wyszukiwarkę Atmela na jego stronie w menu po lewej i tam ustaw tylko 8-bitowce
    Korzystałem z wyszukiwarki na AVR Freaks.
    mirekk36 napisał:
    Jeśli chodzi o wybór podyktowany zwiększeniem ilości pinów to czemu nie ? ATmega64 to dobry wybór. Masz dodatkowo jeszcze jeden Timer 16-bitowy .... a jeśli chodzi o przeniesienie kodu to żadna różnica i to jest fajne w porównaniu do przesiadania się zaraz na Xmega.

    Myślałem nad korzystaniem z M32 i jakiegoś ekspandera IO po I2C. Jednak po ostatnim projekcie stwierdziłem, że oprócz większej ilości pinów przyda mi się także "ciut" więcej flasha. Dlaczego? Ano trafił mi się bardzo wymagający klient, dla którego w pamięci flash zapisana jest caaaała maaasa komunikatów służących do interakcji z tą osobą. Ilość RAM nie jest krytyczna, zawsze staram się, aby wykorzystywać jak najmniej (swoją drogą chyba dobry nawyk). Ale jednak flash 64kB bardzo by się przydał.
    Póki co procesorów wyższych od m64 (m128 itp) nie biorę pod uwagę - nie widzę zastosowania (jak narazie) w swoich projektach przysłowiowej "armaty".
    mirekk36 napisał:
    Poza tym są jeszcze takie jakby nieco większe wersje procków z serii ATmega2560/2561 - jedne w obudowie 100 pinów drugie też 64 piny jak ATmega64 no ale zasobów sprzętowych więcej jeśli chodzi o Timery, po 4 UART'y nawet i inne - chociaż poczciwa ATmega64 też ma dwa - to też ładnie.

    No właśnie czytałem wiele opinii, że m64 już z lekka "trąci myszką", stąd ciekaw jestem jakiejś alternatywy dla niej. Dlatego wolę zapytać Kolegów, którzy już się bawili z m64 lub jakimś jej nowszym odpowiednikiem, niż "na pałę" robić projekt pod m64 a później pluć sobie w brodę.

    Póki co dla Kolegów leci "pomógł". :) A ja czekam na dalsze opinie.

    Właśnie z ciekawości robię sobie zestawienie we wspomnianej "szukajce" z avrfreaks. Hmm przyzna szczerze, że wcześniej nie robiłem porównania m64 z m128. Tak jak Kolega tmf napisał - różnica chyba praktycznie tylko w ilości flasha i eeprom.
  • #7 10989554
    tmf
    VIP Zasłużony dla elektroda
    To trąci myszką to w sensie chyba, że to stara konstrukcja, prądożerna, ograniczona do 16 MHz. Masz "nowsze" te z 3 cyframi w nazwie.
  • #8 10989577
    Krauser
    Poziom 26  
    Kolega tmf ma rację. Pora porzucić Atmega8, 32 itd. Są nowe mikrokontrolery, oszczędne z rozwiniętymi peryferiami np. Atmega88PA, Atmega644PA, Atmega6450P.
  • #9 10989639
    tehaceole

    Poziom 28  
    Hmm... Obecnie przyglądam się AtMega 645 i AtMega 1281. Pinowo wyglądają na zgodne. Wg porównywarki prezentują się znacznie atrakcyjniej niż m64 i m128. Cenowo też zbliżone do 64 i 128.
    Idę w dobrym kierunku?

    Co do XMega - podejrzewam, że ta czy inna rodzina będzie naturalnym rozwojem moich "zabaw". Jednak póki co nie widzę sensu stosowania superszybkich i ultra naszpikowanych peryferiami procesorów w zastosowaniach, w których moimi wymogami są:
    - względnie duża ilość pamięci flash,
    - praca z oscylatorem max 16MHz ,
    - duża ilość IO ograniczona jedynie wielkością obudowy (najlepiej do 64 pinów),
    - kwestia zasilania i trybów oszczędzania energii nie jest krytyczna, procesor będzie w urządzeniach zasilanych sieciowo.
    Zastosowanie czegoś jeszcze większego byłoby moim zdaniem najzwyczajniejszym marnotrawstwem. :)
  • Pomocny post
    #10 10989654
    mirekk36
    Poziom 42  
    Ale jeśli sobie możesz pozwolić na tą samą ilość pinów co w m32 to zobacz jako alternatywę bardzo dobry PICO powerowy ATmega644PA , którego także z lubością używam - a to dlatego że pinologicznie zgodny z m32 ;) a flasha , RAM'u i EEPROM'a ma tyle samo co ATmega64. Więcej ma nawet dwa UART'y ;) .... tylko niestety nadal jeden Timer16-bit - ale coś za coś jak to mówią.... Na prawdę fajny procek no i co ciekawe wcale niedrogi ;)
  • #11 10989717
    tehaceole

    Poziom 28  
    Rzeczywiście wygląda sympatycznie :) No i cenowo spooora różnica względem choćby m645. Zaczynam się zastanawiać nad zaprojektowaniem PCB w taki sposób, żeby w zależności od potrzeb montować uP w obudowie TQFP44 lub 64. Wtedy byłaby pełna elastyczność. :)
    Do czego zmierzam? Chodzi mi o stworzenie jakby to nazwać płyty bazowej, na której w zależności od potrzeb montuję konkretne przewidziane peryferia, lub pozostawiam dane pola nie obsadzone elementami. Dlaczego tak? Wszyscy wiemy jakie są ceny jednostkowego wykonania serii np 10 - 20 płytek. Zamiast dla każdego projektu z osobna robić nową płytkę, która i tak zostanie opakowana w tę samą obudowę - pomyślałem o stworzeniu czegoś w miarę skalowalnego. A jedynie w specyficznych przypadkach wymagającego tworzenia PCB na nowo. W ten sposób znacząco zredukowane zostałyby koszty wdrożenia urządzenia. Poprostu na poczekaniu miałbym zapas PCB i mógłbym przystępować do montażu niejako "od ręki".
    Stąd moje rozważania nad modelami atmeg z których warto skorzystać. Wybór uP (1 lub kilku modeli) zaważy na dalszych pracach projektowych.
  • Pomocny post
    #12 10989811
    LordBlick
    VIP Zasłużony dla elektroda
    tehaceole napisał:
    Zamiast dla każdego projektu z osobna robić nową płytkę, która i tak zostanie opakowana w tę samą obudowę - pomyślałem o stworzeniu czegoś w miarę skalowalnego.
    Też mam taki pomysł, tylko w inną stronę - zamiast żonglować procesorami, planuję użyć procesor na wyrost, który jest niedrogi (przykładowo LPC1313 48pin kupiłem na farnellu w okolicy 10 zł netto).
  • #13 10989921
    tehaceole

    Poziom 28  
    LordBlick - Twój pomysł jest bardzo ciekawy, tym bardziej że cena podzespołu, który stanowi "serce" układu jest rewelacyjna. W moim przypadku przesiadka z rodziny Mega na inną Atmela lub nawet innego producenta wymagałaby poznania nowej rodziny, inwestycji w stosowne programatory itp. Stąd na chwilę obecną pozostaję przy Mega. Jak już wcześniej wspomniałem, absolutnie nie wykluczam dalszego rozwoju o nowe rodziny w przyszłości - to naturalna kolej rzeczy. Ale obecnie jest mi to po prostu nie na rękę :)
  • Pomocny post
    #14 10990285
    LordBlick
    VIP Zasłużony dla elektroda
    tehaceole napisał:
    W moim przypadku przesiadka z rodziny Mega na inną Atmela lub nawet innego producenta wymagałaby poznania nowej rodziny, inwestycji w stosowne programatory itp. Stąd na chwilę obecną pozostaję przy Mega.
    W moim przypadku na tym sprzęcie dopiero "mrygam LED", bo bieżąca robota ma pierwszeństwo, więc nie jestem tak do przodu... ;).
    Z tą inwestycją w programator to bym nie przesadzał, z reguły znajdzie się w okolicy przejściówka na RS-232. Układ ma fabryczny bootloader (wystarczy w trakcie resetowania kostki przywrzeć odpowiedni pin do GND). Oczywiście najlepiej jest mieć SWD na podorędziu, czy to w wyrobach Frediego, czy też LPCXpresso.
    Jest sobie na El-ce nawet prosty przykład z LCD i 1Wire:
    https://www.elektroda.pl/rtvforum/topic1793794.html
    Absolutnie nie namawiam, tylko nadmieniam jako ciekawostkę 48-pin.
  • #15 10992630
    tehaceole

    Poziom 28  
    LordBlick napisał:
    W moim przypadku na tym sprzęcie dopiero "mrygam LED", bo bieżąca robota ma pierwszeństwo, więc nie jestem tak do przodu...

    Oooj tam. :) Każdy od czegoś zaczynał. Powiem Ci, że zaintrygował mnie ten scalak. Nie mam absolutnie nic przeciwko poczciwym 8-io bitowcom. Jednak po tym co widać ostatnio w cenach podzespołów... Powoli rzeczywiście trzeba myśleć o przesiadce na ARM. No przecież to paranoja, żeby AVR kosztował 2-4 razy więcej niż bijący go na głowę ARM. Aż chce się rzec: !#%#@# prawa rynku!

    Ja teraz kombinuję jak koń pod górę, nad uniwersalnym HW do którego w miarę potrzeb wstawiam odpowiedni procesor - cięcie kosztów produkcji. Ale przyznać muszę, że Twoje rozwiązanie jest o niebo lepsze od mojego pomysłu. Przy takich znacznych różnicach w stosunku cena / możliwości używanie AVR zaczyna być po prostu nonsensowne z ekonomicznego punktu widzenia. Oczywiście w większości projektów możliwości Twojego procesora będą używane w max 5%. Tylko co z tego, jeżeli jego cena i tak jest niższa od jakiegoś "dopasowanego" do wymagań AVR. :) Więc po co "migać diodą" AVR za 30zł jak można to zrobić ARM za 10. :) hehe

    Reasumując: po zebraniu opinii Kolegów (za które bardzo serdecznie dziękuję!) wstępnie wybór mój pada na:
    - ATmega644PA,
    - AtMega 645,
    - AtMega 1281,
    - do tego prawdopodobnie coś mniejszego w TQFP44 (o ile uda się jakoś logicznie zaprojektować wspólny socket dla TQFP64 i 44).

    "Zaposiądę" niedługo powyższe scalaczki do testów i zobaczę co z tego wyjdzie. Przede wszystkim wykonać muszę prace "badawczo rozwojowe" nad poprawną pinologią.

    A dzięki "zaszczepieniu" przysłowiowej "zajawki" przez Kol. LordBlick planuję niedługo rozpocząć raczkowanie z ARM. :) Najzwyczajniej w świecie warto ten temat zacząć rozgryzać. Tym bardziej jeżeli okaże się, że za 3-5 lat cena AVR będzie jeszcze bardziej nieproporcjonalna do ceny ARM.
    Dodatkowym atutem jest możliwość spięcia wszystkiego z Eclipse. Tu podziękowania dla Kol. mirekk36 - dłuuugo przymierzałem się do przesiadki z AVR Studio na Eclipse. Początki były niemalże bolesne. Ale opłaciło się! Teraz już nie wyobrażam sobie powrotu do AVR Studio. :) Nieocenione jest posiadanie jednego narzędzia w którym można pisać dla AVR, ARM i PIC. A wszystko to dzięki Jego zaangażowaniu. :)
  • Pomocny post
    #16 10992754
    Mateusz-me-1990
    Poziom 16  
    tehaceole napisał:
    W moim przypadku przesiadka z rodziny Mega na inną Atmela lub nawet innego producenta wymagałaby poznania nowej rodziny, inwestycji w stosowne programatory itp.


    Tutaj mogę Ciebie pozytywnie zaskoczyć, bo patrzę też wspomniałeś o ARMach. Sprawa wygląda inaczej, bo podstawą jest tutaj JTAG i z tej racji przeraża to czasem miłośników AVRa. Wystarczy, że zakupisz czy też sam wykonasz sobie taki jeden programator i potem już bez problemu zaprogramujesz nim i ARMy Atmela, ST, czy też jakieś z NXP oraz masę innych cudów nie widów :). Jeśli posiadasz jeszcze port lpt to można stworzyć prostego Wigglera, bądź rozejżeć się za jakimś układem na usb choć będzie on już ciut droższy (np. J-Link, albo też JTAG od Kolegi Freddiego Chopina).
  • #17 10992997
    tehaceole

    Poziom 28  
    Mateusz-me-1990 - LPT całkowicie wykluczam. :) Już od paru lat nie korzystam z komputera stacjonarnego. A kilka przejściówek USB / LPT jakie swego czasu testowałem z Willemem jakoś nie za bardzo chciało ze mną współpracować. Przeglądałem projekty Freddiego. Bardzo zgrabnie Mu to wyszło. Gdy nabiorę nieco chęci (czytaj $$$ :) ) zwrócę się do Niego z chęcią zakupu płytki.

    No właśnie AVR ma tę przewagę, że programatory są do nich bajecznie proste. Sam używam do dziś USBAsp, którego kilka ładnych lat temu złożyłem na zasadzie: "aaa sprawdzę czy to wogóle działa". I jak się okazało prowizorki są najtrwalsze... Dziś płytka (mniejsza od połowy pudełka zapałek) zalana jest dla bezpieczeństwa czarnym silikonem na gorąco. I pomimo posiadania Dragona - USBAsp jest używany na codzień a Dragon jako rozwiązanie awaryjne używany jest w wyjątkowych sytuacjach.
    I dobrze mówisz:
    Mateusz-me-1990 napisał:
    Sprawa wygląda inaczej, bo podstawą jest tutaj JTAG i z tej racji przeraża to czasem miłośników AVRa.
    To właśnie jest to czego najbardziej się do tej pory obawiałem. Powiem szczerze: byłem święcie przekonany, że dla każdego producenta ARM będę musiał posiadać osobny programator. Polałeś miód na moje uszy. :) Jeżeli rzeczywiście jest tak, że do obsłużenia większości ARM (różnych producentów) wystarczy jeden programator - to po prostu bajecznie to wygląda! :)
    W razie czego z pewnością Kolegów poinformuję o pierwszym "mryganiu diodą" na ARM. :) Póki co plan na najbliższy okres jest taki: nabyć wspomniane w poprzednim poście procesory Mega, dokonać testów "pajęczynowych", przeanalizować zebrane informacje, spróbować zaprojektować jakiś zmyślny socket.

    Tak na marginesie: w szufladzie mam jeszcze kilka egzemplarzy "dziadziusia" AT89C2051. Miło popatrzeć jak w ciągu zaledwie paru lat technika skoczyła do przodu. Z rozrzewnieniem wspominam nieprzespane noce, gdy dziergałem na ten sympatyczny układzik kody w assemblerze... Ehh... Aż się człowiekowi łezka kręci w oku. :)

    Wobec takiego rozwoju dyskusji, moje stwierdzenie:
    tehaceole napisał:
    nie odbieganie od tematu - mówimy o serii Mega, nie XMega, nie ARM, nie PIC itp.,
    straciło już rację bytu.
  • #18 10993114
    mirekk36
    Poziom 42  
    Dokładnie - jeśli potrzebne są jeszcze większe procki jak wspomniany ARM to ja też powiem, że warto zainwestować w programator od Freddie Chopina ;) .... sam go mam, wygląda solidnie i profesjonalnie. Tylko też jeszcze czeka na swój czas. Ale przynajmniej od dawna też wiem że mam już dobre narzędzie ;) gdy będę zmuszony sięgnąć po lepszy procek niż 8-bitowy AVR'ek
  • #19 10993160
    tehaceole

    Poziom 28  
    mirekk36 - Ty bardzo dobrze wiesz jak idą moje zabawy z AVR. :) Na obecną chwilę szkoda by mi było kończyć tę przygodę i organizować skok do technologii ARM. Tym bardziej, że naprawdę miło mi się na tych AVR pracuje. Jednakże skok taki za jakiś tam (narazie bliżej nieokreślony) czas będzie nieunikniony. Jeżeli uda mi się zrealizować to co chcę w oparciu o wspomniane powyżej typy procesorów AVR, to moja przygoda z nimi będzie trwać tak długo jak długo będą względnie przystępne cenowo. Mimo wszystko warto zacząć poznawać nowe technologie, żeby za jakiś czas, gdy np. przyjdzie jakieś ciekawe zlecenie, nie obudzić się z za przeproszeniem "ręką w nocniku".

    PS. mirekk36 - wgryzam się właśnie w drugi tom... :) Recenzję wkrótce zamieszczę w tym wątku. Ale spokojnie, nie masz powodów do obaw. :)
  • #20 10993227
    mirekk36
    Poziom 42  
    tehaceole napisał:
    mirekk36 - Ty bardzo dobrze wiesz jak idą moje zabawy z AVR. :) Na obecną chwilę szkoda by mi było kończyć tę przygodę i organizować skok do technologii ARM. Tym bardziej, że naprawdę miło mi się na tych AVR pracuje. Jednakże skok taki za jakiś tam (narazie bliżej nieokreślony) czas będzie nieunikniony. Jeżeli uda mi się zrealizować to co chcę w oparciu o wspomniane powyżej typy procesorów AVR, to moja przygoda z nimi będzie trwać tak długo jak długo będą względnie przystępne cenowo.


    No tak się składa, że chyba w tym zakresie mamy podobne poglądy, ja również zwykle mam coś do zrobienia co spokojnie udaje mi się opanować na AVR'kach i tylko z tego względu nie sięgam po większe procki. Absolutnie nie dlatego że ich nie lubię czy coś.... Ale na pewno dlatego że lubię konkretnie AVR'ki i można z nich dużo wycisnąć. .... Więc jak piszesz - nieuniknione jest też to że przyjdzie i takie zlecenie gdzie AVR'ek sobie nie poradzi - to co ? mam z takiego zlecenia zrezygnować ? NIE - wtedy sięgnę po większy procek.

    tehaceole napisał:
    Mimo wszystko warto zacząć poznawać nowe technologie, żeby za jakiś czas, gdy np. przyjdzie jakieś ciekawe zlecenie, nie obudzić się z za przeproszeniem "ręką w nocniku".


    To tak jak ja np teraz na stare lata zaczynam się uczyć Androida - zobaczymy co z tego wyjdzie - chociaż na razie są pierwsze fajne efekty i wkrótce też pokaże to i owo co mi się udało spłodzić ;)
  • #21 10995581
    tplewa
    Poziom 39  
    Powiem ci tak czasami warto patrzec pod innym katem nic AVR czy ARM :) Czasami UART czy Timer to malo i warto patrzec na specjalizowane hardware do jakiegos celu np. sterowanie silnikow itp. Duzo to ulatwia itd. Praktycznie cala linia AVR-ow nie wnosi jakis wiekszych zmian (poza Xmega ale to inna bajka i tutaj wybral bym raczej inne procki). Tak samo do wielu zastosowan taki AVR spokojnie wystarczy i nie ma co pchac jak to sie mowi armaty na muche, maja tez fajna zalete jak potrzeba aby procek wspolpracowal z logika TTL - a to jeszcze dosc czesto jest potrzebne...

    Poza samymi ARM-ami warto zerknac tez na PIC-e i dsPIC-e... w ofercie Cypress-a tez mozna znalezc czasem cos fajnego - albo i dac sobie troche luzu i dac czasem FPGA zamiast typowego procesora. Osobiscie nie mam jakiejs jednolitej odpowiedzi, wszystko zalezy od tego jakie dana aplikacja ma wymagania.
  • Pomocny post
    #22 10995731
    tymon_x
    Poziom 30  
    tehaceole napisał:
    I dobrze mówisz:
    Mateusz-me-1990 napisał:
    Sprawa wygląda inaczej, bo podstawą jest tutaj JTAG i z tej racji przeraża to czasem miłośników AVRa.
    To właśnie jest to czego najbardziej się do tej pory obawiałem. Powiem szczerze: byłem święcie przekonany, że dla każdego producenta ARM będę musiał posiadać osobny programator. Polałeś miód na moje uszy. :) Jeżeli rzeczywiście jest tak, że do obsłużenia większości ARM (różnych producentów) wystarczy jeden programator - to po prostu bajecznie to wygląda! :)

    Może dla ścisłości, z tych które korzystałem mają fabryczny bootloader po RS232, czyli STMicro STM32 oraz NXP LPC1xxx. Więc jeśli pod programator rozumiesz samo programowanie uC, to wystarczy samo FTDI (albo MAX) + terminal :P Natomiast JTAG służy też do debugowania i obecne obsługują większość układów, należy też zwrócić uwagą na dwu-przewodowy interfejs SWD. Takim low-cost JTAG/SWD/Programatorem jest Versaloon.
    Uniwersalny programator / debugger (JTAG/SWD) "Versaloon".

    Co do pinologi, to w STM32 jest pełna zgodność między peryferiami oraz sekcjami zasilania. I nie musisz kombinować z jakimiś adapterami, po prostu kupujesz uC w innej obudowie i lutujesz. Nie ma różnic nawet w rejestrach jeśli chodzi o te same układy peryferyjne między kolejnymi modelami. Proste i wygodne. Niektórych może razić rozstrzelone porty na pinach uC, pewnie marzą się im GPIOA na zachód, GPIOB na południu ... :P

    mirekk36 napisał:
    Dokładnie - jeśli potrzebne są jeszcze większe procki jak wspomniany ARM to ja też powiem, że warto zainwestować w programator od Freddie Chopina .... sam go mam, wygląda solidnie i profesjonalnie. Tylko też jeszcze czeka na swój czas. Ale przynajmniej od dawna też wiem że mam już dobre narzędzie gdy będę zmuszony sięgnąć po lepszy procek niż 8-bitowy AVR'ek

    Hehe, pewnie 21 grudnia 2012 :P
  • #23 10995773
    tehaceole

    Poziom 28  
    A więc tak - temat "uni socketu" tqfp44/64 jest IMHO do ogarnięcia. Nawet patrząc na ofertę Kamami widać, że powinno się to udać. Przy czym ich płytki to wyprowadzenie wszystkich kończyn procka "na wprost". Ja chcę zrobić coś takiego, aby np wszystkie piny portu A były ze sobą połączone itd. Czyli lutuję tqfp44 - mam dajmy na to 3 porty dostępne, lutuję tqfp64 - zwiększam ilość IO a jednocześnie nie muszę przerabiać softu bo pozostałe piny są w tych samych miejscach.

    Tak przeglądam ofertę zestawów ewaluacyjnych ARM różnych producentów i... Mam mętlik w głowie. =/ Tego jest taaaaka masa, że nie wiadomo na co się na początek zdecydować. Urzekł mnie ten zestaw - tak jestem wzrokowcem i ten kolorowy wyświetlacz to "niezła bajera". :) Tylko kurka opis produktu jest co najmniej dwuznaczny - raz piszą:
    Cytat:
    Zestaw uruchomieniowy z mikrokontrolerem LPC1768 firmy NXP (Cortex-M3), debugerem JLink i 3,2-calowym wyświetlaczem dotykowym
    a za chwilę w dalszej części:
    Cytat:
    Podstawowe właściwości:

    Mikrokontroler LPC1768 z rdzeniem ARM Cortex-M3, 512 kB Flash, 64 kB SRAM, Ethernet,
    (....)
    złącze kolorowego wyświetlacza LCD modTFT32T

    Chyba muszę do nich napisać, żeby się określili czy w końcu ten wyświetlacz jest w zestawie czy trzeba go dokupić osobno.
    tplewa napisał:
    Powiem ci tak czasami warto patrzec pod innym katem nic AVR czy ARM Czasami UART czy Timer to malo i warto patrzec na specjalizowane hardware do jakiegos celu np. sterowanie silnikow itp. Duzo to ulatwia itd. Praktycznie cala linia AVR-ow nie wnosi jakis wiekszych zmian (poza Xmega ale to inna bajka i tutaj wybral bym raczej inne procki). Tak samo do wielu zastosowan taki AVR spokojnie wystarczy i nie ma co pchac jak to sie mowi armaty na muche, maja tez fajna zalete jak potrzeba aby procek wspolpracowal z logika TTL - a to jeszcze dosc czesto jest potrzebne...

    Dobrze piszesz. Tylko, że ja już mam wizję jak ma wyglądać projektowany układ pod względem peryferiów, IO itp. Dlatego AVR mi w nim w zupełności wystarczy. Jedynym kłopotem było wybranie właściwych modeli atmeg. No i ewentualne "kruczki" np. z isp o których czytałem gdzieś na Forum. Na chwilę obecną ARM byłby tam najzwyczajniej w świecie marnotrawiony - jednak nie zmienia to faktu, że z ekonomicznego punktu widzenia okazuje się iż ARM pasujący mi pod względem założeń (i oferujący wiele większe możliwości) jest najczęściej tańszy od AVR. Barierą jest w tej chwili to, że AVR mam już dobrze opanowany (wcale jednak nie twierdzę, że jestem jakimś super specem od AVR - daleko mi do pyszałkowatości) a ARM to na razie nieznany obszar.

    tymon_x - nooo ten jtag wydaje się sympatyczny... Jeżeli można użyć sprzętowego bootloadera żeby wgrać bootloader autora projektu a następnie z jego pomocą wgrywać właściwy firmware - to byłaby bajka. :) Do tego AVR także obsługuje. :) Dzięki za baaardzo przydatny link!
  • #24 10996080
    tplewa
    Poziom 39  
    To jesli ci starcza wydajnosc AVR-a to w sumie chyba nie ma potrzeby, natomiast nad ARM-ami mozna sobie siedziec w wolnej chwili i tez warto poznac. Ograniczanie sie do jednej rodziny procesorow po prostu nie jest zbyt dobrym wyjsciem. ARM-y sa niby tansze - ale najczesciej nie tylko cena samego procka decyduje o finalnym koszcie :) Ja w kilku przypadkach bralem sobie taka ATmege128 i wiele spraw obliczeniowych np. tablicowalem, wiec i wydajnosc jakas wielka nie byla potrzebna.

    Odnosnie podstawowych ARM-ow to mi akurat troche trudno znalezc zastosowanie (akurat w tym co robie). W sumie jak potrzebuje cos wiekszego to zazwyczaj musze miec kontroler pamieci i koprocesor - ewentualnie jakies specjalizowane peryferia, do mniejszych projektow spokojnie wystarczaja mi AVR-y, dsPIC-e itp. No ale tak jak mowie wszystko nalezy dobierac pod katem danego projektu - i nie sugerowac sie tylko cena (to czasem jest zgubne) - potem wychodzi np. ze na PCB, dodatkowe uklady, narzedzia wydamy wiecej :)

    Natomiast na poczatek do ARM-ow mozna popatrzyc za czyms od ST (plytki discovery) - nie sa drogie i ma sie na pokladzie komplet do rozpoczecia zabawy (moze nie idealny - ale na poczatek spokojnie wystarczy i nie trzeba w nic wiecej inwestowac).
  • #25 10996380
    LordBlick
    VIP Zasłużony dla elektroda
    W Kamami są ceny pilnego zakupu, więc nie dla mnie. ;)
    Cała zaletą w ARM jest to, że poszczególni producenci konkurują między sobą, czyli ceny w gorę raczej tak nie skoczą. Przesiadka z jednej platformy na drugą opłaca się najbardziej, gdy mamy prawdopodobieństwo, graniczące z pewnością, że projektowane urządzenie sprzedamy w większej ilości egzemplarzy. Przy jednostkowym urządzeniu to naprawdę nie ma sensu, lepiej tworzyć taki projekt na "obcykanym" sprzęcie.
    Ja osobiście zaczynam od NXP na LPCXpresso, do którego cokolwiek podpiąć to już nie jest problem. Planuję docelowo przenieść swoje dochodowe projekty na tą platformę, gdyż większe możliwości pozwalają zaoferować klientom więcej możliwych bajerów (ciekawsza interakcja z użytkownikiem urządzenia, ciekawsza wizualizacja na wyświetlaczu, obsługa osób niepełnosprawnych), za które można z kolei uzyskać dodatkowe monety... ;)
    Starter LPCXpresso zawiera zintegrowany prosty programator, jest dostępne do niego gotowe środowisko programistyczne do 128KB darmowe.
    Z kolei Freddie ma w ofercie też niedrogie podobnej klasy starterki STM23 STDISCOVERY z wbudowanymi procesorkami różnych rodzin(CM0, CM3, CM4).
  • #26 10996461
    tehaceole

    Poziom 28  
    Hmm... No na początek może to być dobry zestaw. Tym bardziej, że posiada zintegrowany programator. Swoją drogą urzekł mnie ten programator. Poprostu rewelacja :) Gdyby tylko jeszcze PIC'e gryzł... :) Co do cen w Kamami - no niestety muszę się zgodzić, potrafią być zabójcze...


    Wracając do AVR: czy dobrze interpretuję sposób podłączenia ISP?

    1) m644 (tqfp44)
    mosi pb5 pin1
    miso pb6 pin2
    sck pb7 pin3
    reset pin4

    2) m325 / m645 (tqfp64)
    mosi pb2 pin12
    miso pb3 pin13
    sck pb1 pin11
    reset pin20

    3) m1281 / m2561 (tqfp64)
    mosi pe0 pin2
    miso pe1 pin3
    sck pb1 pin11
    reset pin20
  • #27 10996583
    tplewa
    Poziom 39  
    Jesli chodzi o jtag-i to jest troche tego - mozesz zerknac na projekt Freddiego oparty o FTDI. Kiedys poskladalem za grosze - z tym ze niestety do niektorych celow FTDI jest wolny, ale z prockami poradzi sobie ok. Wspominajac tez Kamami mozna tam dorwac JLINK-a EDU - nie wiem na ile konkurencyjna jest tam cena. Ale jest to jakas alternatywa dla klonow z Allegro (ktore czasem potrafia napsuc nerwow).

    Odnosnie programowania wszystkiego przez dany programator to raczej bym uwazal, za zwyczaj takie rozwiazania sa mniej wygodne i na dluzsza chwile zaczynaja czlowieka irytowac :)

    No i odnosnie ST Discovery - warto patrzec co firma organizuje... czasami mozna wyrwac takie bajery za free :)

    A i odnosnie jeszcze tych dokumentacji i wspomnianego ATmega 128 - nie pamietam czy byl tam jakis blad w SPI, ale to malo istotne. Niestety takie wpadki ze jest babol w dokumentacji, a czasem i samym procku spotyka sie dosc czesto i trzeba sie do tego przyzwyczaic.
  • #28 10996600
    tehaceole

    Poziom 28  
    tplewa napisał:
    A i odnosnie jeszcze tych dokumentacji i wspomnianego ATmega 128 - nie pamietam czy byl tam jakis blad w SPI, ale to malo istotne. Niestety takie wpadki ze jest babol w dokumentacji, a czasem i samym procku spotyka sie dosc czesto i trzeba sie do tego przyzwyczaic.
    Właśnie dlatego wolę upewnić się o m.in. tej kwestii przed rozpoczęciem projektowania PCB. :)

    Zapraszam Kolegów siedzących już coś niecoś w ARM i używających na codzień Eclipse do tego wątku.
  • #29 10996691
    mirekk36
    Poziom 42  
    tehaceole napisał:

    1) m644 (tqfp44)
    mosi pb5 pin1
    miso pb6 pin2
    sck pb7 pin3
    reset pin4


    Ja tylko tak nadmienię bo wcześniej pisałeś o m644p a teraz napisałeś m644 , że to dwa różne procesory ;) .... tzn np m644p ma dwa UART'y a m644 tylko jeden. Ale w obydwu przypadkach nie ma żadnych tricków z pinami ISP przy nich.
  • #30 10998948
    tplewa
    Poziom 39  
    tehaceole napisał:
    Właśnie dlatego wolę upewnić się o m.in. tej kwestii przed rozpoczęciem projektowania PCB. :)


    Ja o ile jest taka mozliwosc staram sie prototyp budowac na plytkach uniwersalnych/stykowych. Natomiast jak nie ma takiej szansy (wysokie czestotliwosci magistrali itp.) to za zwyczaj boli jak trzeba kolejna wersje czterowarstwowego druku zamawiac :) Tutaj masz akurat luz bo AVR-y spokojnie mozna skladac na pajaka :)
REKLAMA