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.

AVR,ARM - Czy Atmega32 "da radę"?

BartekWB 06 Sie 2013 22:12 2031 14
  • #1 06 Sie 2013 22:12
    BartekWB
    Poziom 27  

    Witajcie.
    Mam zamiar wykonać mały tracker GPS z GSM (moduł ma wbudowany stos TCP/IP) z wysyłaniem danych po GPRS za pomocą TCP/IP, projekt ma robić tylko to. Najchętniej bym wykonał to na ATMega32 (pisałem na niego pod BASCOMem i ogólnie znam go od strony sprzętowej), jednak nie wiem czy ten mikroprocesor da sobie radę z tym projektem, czy lepiej wybrać ARM? Mam zerowe doświadczenie w pisaniu w C na obu platformach (docelowo program ma być w C) i mam zamiar się zacząć uczyć tego języka dla mikrokontrolerów właśnie na tym projekcie.
    Moja rozterka jest taka: czy zacząć zagłębiać się w C dla AVR czy dla STM (chodzi mi ściśle o ten projekt)? Nie chcę, aby potem się okazało, że AVR "nie da sobie rady" a ja zmarnuje masę czasu na zaczynaniu wszystkiego od nowa dla ARM.
    Za AVR też do mnie przemawia masa dostępnej literatury, biblioteki i ogromne wsparcie w sieci.
    Mam dostęp do obu platform rozwojowych więc sprzęt do nauki nie stanowi problemu.

    0 14
  • #2 07 Sie 2013 00:17
    piotrva
    Moderator na urlopie...

    Witaj,
    Po pierwsze powiedz co to za moduł - bo jeśli ma wbudowane stosy i systemy komunikacji to może się okazać, że wystarczy tylko wysłać do modułu parędziesiąt komend i potem procesor może iść spać - wtedy na 100% AVR starczy. W przeciwnym wypadku trzeba przeanalizować ile danych i w jakim czasie ma zostać przetworzonych przez uC.
    Bez modelu tego urządzenia GPS/GSM nic Ci nie doradzimy.

    Ogólnie popieram rezygnację z Bascoma, teraz tylko pytanie - jak Ci idzie i czy w ogóle korzystałeś z datasheetów procesorów AVR?

    Co do wyboru rodziny AVR vs ARM i języka C
    Język C jest dla obu uC taki sam - C to C - są może różnice w tym jak definiujemy obsługę przerwań, jak robimy wstawki asm itp, ale sama logika języka pozostaje ta sama.

    Za to spore różnice są w samej obsłudze procesora i jego modułów.
    Tu pewnie zaraz zacznie się po raz setny dyskusja "AVR vs ARM na początek nauki C", ale ja postaram się po krotce przedstawić za i przeciw każdego z wyborów:

    ---ARM---
    +zwykle są szybsze i wydajniejsze niż AVR
    +mają duuuużo bardziej rozbudowane peryferia
    +ogólnie możliwości są nieporównywalnie większe (ale wszystko zależy też od konkretnego modelu)
    -z powodu powyższych plusów są to układy bardziej rozbudowane - co za tym idzie opcji konfiguracji każdej "pierdółki" kilkukrotnie więcej niż w AVR - czasem (ale nie zawsze) taki natłok i mnogość opcji może być problematyczny dla początkującego
    -brak dobrej literatury (przynajmniej na pewno po polsku)


    ---AVR---
    +obiektywnie bardzo proste do nauki i dobre jako wprawka
    +spora ilość literatury, przykładów, poradników (niestety niektóre z błędami merytorycznymi)
    +wystarczają do wielu czynności
    -dużo wolniejsze i uboższe niż ARM z podobnych półek cenowych
    -relatywnie droższe

    Ogólnie na tej podstawie porównaj sam, co Ci bardziej odpowiada ogólnie. Jeśli liczysz na super szybką i bezproblemową naukę - to polecam AVR. Jeśli zaś masz dużo cierpliwości, samozaparcia, umiesz rozwiązywać problemy - nie zastanawiaj się i ucz się ARM - bo ten projekt na pewno zrobisz na odpowiednim ARM'ie (np. Stm32), a znajomość tej architektury i choćby jednej rodziny procesorów z rdzeniami ARM da Ci szersze perspektywy niż AVR (zresztą nawet gdybyś potrzebował to przesiadka ARM->AVR jest prostsza niż w druga stronę).

    Na chwilę obecną z mojej strony tyle wywodów i apeluję do obu stron potencjalnej dyskusji - nie zaczynajmy znów tematu co jest lepsze, bo myślę, że większość za i przeciw obiektywne wymieniłem.

    0
  • #3 07 Sie 2013 09:58
    alagner
    Poziom 25  

    Na STM32 to akurat lepiej nie, bo one świetnie zakłócają tor RF.
    Ale STM32 to nie jedyny ARM, wybór jest spory.

    0
  • #4 07 Sie 2013 10:19
    Freddie Chopin
    Specjalista - Mikrokontrolery

    alagner napisał:
    Na STM32 to akurat lepiej nie, bo one świetnie zakłócają tor RF.

    Przesadzasz... Nawet jeśli, to problem nie dotyczy już nowszych wersji (np. F4).

    4\/3!!

    0
  • #5 07 Sie 2013 10:38
    BartekWB
    Poziom 27  

    Raczej nie chce tutaj wszczynać walki, bo AVR i ARM to dwie zupełnie inne technologie o zupełnie innych możliwościach, tego jestem świadom.
    Za AVR do mnie przemawia też to o czym wspomniał alagner, na elektrodzie zapoznałem się z wątkiem opisującym ten problem (jakby ktoś szukał: https://www.elektroda.pl/rtvforum/topic1541960.html ), pierwotnie właśnie chciałem zbudować to na jakimś STM32, jednak to zakłócanie go skreśla a do innych ARM bardzo ciężko z literaturą (właśnie te wszystkie szczególiki o których wspomniałeś mnie przerażają najbardziej).
    Z AVR radzę sobie dość dobrze, do datascheet zaglądałem bardziej z ciekawości niż z potrzeby (BASCOM raczej wszystko podawał na tacy). Programuję w C++ i zaczynam jave, więc mogę powiedzieć, że jako tako daję sobie radę w temacie programowania.

    Moduł to Simcom Sim908 ( http://www.kamami.pl/index.php?productID=187841 ), z tego co wyczytałem posiada wbudowany stos.

    0
  • #6 07 Sie 2013 10:44
    Freddie Chopin
    Specjalista - Mikrokontrolery

    BartekWB napisał:
    Za AVR do mnie przemawia też to o czym wspomniał alagner, na elektrodzie zapoznałem się z wątkiem opisującym ten problem (jakby ktoś szukał: https://www.elektroda.pl/rtvforum/topic1541960.html ), pierwotnie właśnie chciałem zbudować to na jakimś STM32, jednak to zakłócanie go skreśla

    I tak właśnie rodzą się mity...

    4\/3!!

    0
  • #7 08 Sie 2013 17:10
    BartekWB
    Poziom 27  

    Ponoć STM potwierdziło ten problem więc coś musi być na rzeczy.
    Więc finalnie mam się decydować na AVR?

    0
  • #8 08 Sie 2013 17:16
    BlueDraco
    Specjalista - Mikrokontrolery

    Co "ponoć potwierdziło" ST? Wysoki poziom zakłóceń we wszystkich układach rodziny STM32F, czy tylko w wychodzącej z użycia serii STM32F1?

    Stosując taką logikę, ponieważ kiedyś zdarzyło się, że jakaś seria ATmega8 "ponoć" miała błędy, powinieneś wobec tego unikać wszelkich układów firmy Atmel.

    Jeśli lubisz drogie zabytki - Twoja sprawa, nie dorabiaj jednak do tego ideologii. Używaj sobie czego chcesz, ale podejmuj decyzje projektowe bazując na realnych danych, a nie na zabobonach.

    0
  • #10 08 Sie 2013 20:20
    felekfala
    Poziom 19  

    BlueDraco napisał:
    czy tylko w wychodzącej z użycia serii STM32F1?

    Skąd informacje o wychodzącej rodzinie STM32F1 ?

    0
  • #11 08 Sie 2013 23:07
    BlueDraco
    Specjalista - Mikrokontrolery

    Z produkcji nie wychodzi, ale w porównaniu z nowszymi seriami STM32F1 ma same wady (dziwna wersja rdzenia, dziwna konfiguracja nóg dla peryferiali, spory pobór mocy), więc po co się z tym męczyć w nowych projektach?

    0
  • #12 09 Sie 2013 07:55
    felekfala
    Poziom 19  

    Ja sobie chwalę STM32F1 i nie uważam żeby jego używanie było męczarnią..
    Dla czego dziwna wersja rdzenia ?
    Dziwna konfiguracja nóg dla peryferii to prawda niestety. W zasadzie takim naturalnym zamiennikiem F1 jest chyba szybszy F2.

    0
  • #13 09 Sie 2013 09:54
    BlueDraco
    Specjalista - Mikrokontrolery

    Dziwna wersja, bo jako jedyna seria uC z rdzeniem Cortex ma domyślnie wyłączone wyrównanie stosu (do czego doszliśmy jakiś czas temu z kol. Freddiem) i w związku z tym jako jedyny Cortex wymaga pisania przy procedurach wyjątków "attribute interrupt", bo bez tego potrafi spłatań niezłego psikusa w bardziej złożonych programach. Obecnie mamy F0, F2, F3 i różne L1, wszystkie bez tego defektu i z poprawionymi peryferialami.

    0
  • #15 12 Sie 2013 12:54
    BartekWB
    Poziom 27  

    Dziękuję wszystkim za wypowiedzi, postanowiłem, że spróbuję na AVR, na pewno będzie to łatwiejszy start, a potem się zobaczy.

    0