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

Czym różnią się mikrokontrolery AVR DB od rodziny DA?

tmf 23 Sie 2020 16:15 4494 41
  • #1 18884977
    tmf
    VIP Zasłużony dla elektroda
    No i mamy nową rodzinę AVR - tym razem o nazwie DB (w przeciwieństwie do wypuszczonej niedawno rodziny DA).
    Co nowego? Przede wszystkim sporo nowych fajnych rzeczy, dla osób, które łączą cyfrówkę z techniką analogową. Ale w skrócie:
    - FLASH 32-128KB z możliwością zmapowania w jedną przestrzeń adresową z RAM
    - SRAM 4-16 kB
    - EEPROM 512 bajtów
    - zasilanie 1,8-5,5V i tu największa nowość - dedykowany pin VDD2 na który możemy podać napięcie 1,8-5,5V zasilający PORTC mikrokontrolera. W efekcie mamy MCU pracujący z dwoma różnymi napięciami - przydatne jeśli w układzie są elementy wymagające 3,3 lub 5V.
    - taktowanie 24 MHz, ale niektóre peryferia mogą być taktowane do 48 MHz,
    - prąd IO na pinie +/-50 mA, z diodą zabezpieczającą +/-20 mA.
    - 3 opampy, które można łączyć w różnych konfiguracjach, z programowym wzmocnieniem, kalibracją offsetu itd.
    - DAC
    - 12-bitowy ADC o bardzo dobrych parametrach (znacznie poprawionych w stosunku do starszych AVR), z możliwością sprzętowej decymacji i oversamplingu, dodatkowo superfajna funkcja komparatora okienkowego,
    - szereg wbudowanych napięć referencyjnych,
    - 6 bloków programowalnej logiki
    - do 8 timerów o różnych funkcjach
    - do 6 UARTów
    - 10 kanaów event system
    - RTC z korekcją odchyłki kwarcu,
    - dwupoziomowy kontroler przerwań,
    - i wiele innych.
    Ogólnie wydaje się, że fajne układy, bardzo mocna analogówka, szkoda, że nie mają DMA (swoją drogą ciekawe dlaczego?). Ze względu na peryferia układy tej serii pewnie będą dobrym wyborem w systemie, w któym mamy prostą analogówkę - sterowanie backEMF BLDC, jakieś kondycjonowanie sygnału itd.
  • #3 18885716
    Klima
    Poziom 31  
    Z zachwytami poczekajmy może aż przeczytamy erratę...
    Ja uważam, że to fajnie, że zarówno DA jak i DB są dostępne w obudowie DIP28.
  • #4 18887576
    Konto nie istnieje
    Poziom 1  
  • #5 18891259
    Klima
    Poziom 31  
    Jest już errata. Jeden z pinów ma niepodłączony bufor wejściowy...
    Jakichś bardzo dużych problemów nie ma, w porównaniu z erratą do DA.
  • #6 18891270
    Konto nie istnieje
    Poziom 1  
  • #7 18891299
    Klima
    Poziom 31  
    atom1477 napisał:
    Klima napisał:
    Jest już errata.

    Była i 23 sierpnia jak piałeś poprzedni post.
    Ale nie czepiałem się bo napisałeś:

    To musiałem być ślepy, ale nie zauważyłem jej wtedy. Ale ostatecznie liczy się treść, a tu wygląda na to, że udało im się zepsuć mniej niż w AVR DA. Nie mówiąc o ATmega4809.
  • #8 18892874
    Marek_Skalski
    VIP Zasłużony dla elektroda
    tmf napisał:
    Co nowego? Przede wszystkim sporo nowych fajnych rzeczy, dla osób, które łączą cyfrówkę z techniką analogową.

    Zasadniczą różnicą jest umieszczenie 3 wzmacniaczy operacyjnych w DB, kosztem usunięcia modułu obsługi dotyku, który jest w DA. Drugą różnicą jest zmniejszenie ilości dostępnych pinów I/O w DB w małych obudowach, 28 i 32. Cała reszta jest dokładnie taka sama.
    W MCP pierwsza errata wiosny nie czyni. Trzeba poczekać na przynajmniej trzecią wersję, ponieważ wtedy przyjdą błędy z realnych testów u klientów. Dzisiaj jeszcze DA ma status preliminary. Za rok będzie można coś powiedzieć.
  • #9 18893318
    tmf
    VIP Zasłużony dla elektroda
    Marek_Skalski napisał:
    Zasadniczą różnicą jest umieszczenie 3 wzmacniaczy operacyjnych w DB,

    3 wzm. op. to jedno, ale fajne jest, że mają programowalne wzmocnienie i możliwość łączenia w różnych konfiguracjach. Patrząc na parametry elektryczne też wyglądają nieźle. Znacznie też poprawili parametry ADC - nieliniowość, szumy itd. Sporo źródeł referencyjnych - tylko dziwi mnie, że piszą np. 4,096V ale dokładność 1%. Przy tej dokładności to raczej jest to ledwie 4,09 V. Swoją drogą dziwi mnie, że nie ma DMA - moim zdaniem to duża wada. A IMHO jeszcze dziwniejsze jest umieszczenie hardware do CRC i CRC32, który może liczyć tylko z FLASH, ale już nie może z podanych wartości (w XMEGA można było podawać wartości lub dokleić CRC do DMA). Też uwstecznili się jeśli chodzi o driver IO - jest tylko pull up, nie ma pull down, nie ma wired-OR. No ale za to są dwie domeny zasilania.
    Tak jak piszesz - czas pokaże jaka będzie errata.
  • #10 18903005
    tmf
    VIP Zasłużony dla elektroda
    No i mamy kolejne zabawki z tej rodziny - tym razem o oznaczeniu AVR DD. Na pierwszy rzut oka niczym szczególnym się nie różnią od DB, trochę jakby mają mniej peryferii, ale za to chyba będą tańsze. A w zanadrzu kolejni członkowie tej rodziny....
  • #11 18922408
    dondu
    Moderator na urlopie...
    AVR-y uległy microchip-izacji :)

    Czyli stało się coś co zawsze pasowało mi w aplikacjach, w których stosowałem mikrokontrolery microchipa - różne dodatkowe możliwości upraszczające tworzenie konkretnych projektów.

    Co do DMA to nie zdziwię się, gdy w niektórych mikrokontrolerach pojawi się DMA lub coś do niego zbliżonego, tak jak jest to w niektórych mikrokontrolerach microchipa.
  • #12 18922725
    tmf
    VIP Zasłużony dla elektroda
    @dondu Od strony profesjonalnej to pewnie jest fajne - przy dużych seriach można obniżyć cenę wybierając procka spełniającego minimalne wymagania projektowe. Jeśli jeszcze procki są zunifikowane od strony rejestrów hardwarowych, tak jak to ma miejsce w przypadku XMEGA i procków na bazie tej rodziny, m.in. DA, DB i DD, to wygląda to fajnie. Ale patrząc jako hobbysta - muszę poświęcić więcej czasu, żeby wybrać procek mający to co potrzebuję. Dla mnie lepsze jest użycie procka mającego wszystko, nawet jeśli w finalnym projekcie korzystam z 10% zasobów.
    Brak DMA mnie naprawdę martwi - to było narzędzie piekielnie ułatwiające obsługę interfejsów typu UART, SPI itd. Podobnie załamujący jest brak USB.
    Mam nadzieję, że do tego wrócą. A to co mi się marzy - kiedyś były FPSlic - AVR z FPGA. Przydałby się taki procek - rdzeń dowolny, chociażby AVR + np. gotowe konfigi peryferiów - użytownik wybierałby sobie peryferia jakie potrzebuje, do wypełnienia pojemności FPGA. Wiem, że są takie cuda - tylko chodzi mi o to, żeby ktoś to opracował w końcu tak user frendly - jedno proste IDE, prosty konfigurator i masz procka z peryferiami na życzenie. Jest już pewna namiastka w AVR - bloki custom logic, tyle, że ciągle mało ich i możliwości ograniczone w praktyce do pojedynczych look up table lub pojedynczych przerzutników. Ledwie odpowiednik jednej, dwóch cel z CPLD.
  • #13 18922781
    Konto nie istnieje
    Poziom 1  
  • #14 18922792
    kaczodp
    Poziom 14  
    tmf napisał:
    A to co mi się marzy - kiedyś były FPSlic - AVR z FPGA. Przydałby się taki procek - rdzeń dowolny, chociażby AVR + np. gotowe konfigi peryferiów - użytownik wybierałby sobie peryferia jakie potrzebuje, do wypełnienia pojemności FPGA. Wiem, że są takie cuda - tylko chodzi mi o to, żeby ktoś to opracował w końcu tak user frendly - jedno proste IDE, prosty konfigurator i masz procka z peryferiami na życzenie.

    Już coś takiego jest. Co prawda nie jedno środowisko ale. Quartus z NIOS-II + Eclipse. Można sobie peryferia wybierać, przebierać, robić swoje. Peryferia mogą być konfigurowalne bądź nie. Jest VGA, jest HDMI.
  • #15 18922942
    _lazor_
    Moderator Projektowanie
    Uruchamiałem na fpga Risc-v i cortex-m0. Nic przyjemnego, nie dziwię się takie pomysły nie są popularne. Ludzie mają problem z uruchomieniem gotowego uart, a co jak przyszło by im synchronizować peryferium na fpga? ;)

    Chyba jeszcze cypress się ostał oraz Zynq i w sumie nawet są user frendly, gorzej że próg wejścia jest wysoki i dla fpga taki pozostanie bo taka technologia to już jest.
  • #16 18922990
    Konto nie istnieje
    Poziom 1  
  • #17 18923164
    tmf
    VIP Zasłużony dla elektroda
    Jasne, można sobie kupić FPGA całkiem nietaniego, z setkami wyprowadzeń, po to, aby w nim zsyntetyzować soft-CPU - pomysł kompletnie z czapy. Ja pisałem o dodaniu prostego FPGA, aby można było dodać to co potrzebuję. Np, mam procek, który mi oferuje 8 timerów 16-bitowych i 8 UARTów, a potrzebuję np. 15 timerów 8-bitowych. Więc kasuję z opisu te timery i procki i dodaję gotowy moduł timera 8-bitowego. Gdyby to było ładnie i prosto zrealizowane w jakimś IDE, to ludzie by z tego chętnie korzystali. Oczywiście patrzę na to z punktu amatora i relatywnie prostych projektów. Przydałby się procek o elastycznie dostosowywanych peryferiach + możliwość realizacji glue logic, niekoniecznie potrzebuję zaraz dużego FPGA zużywającego masę prądu, z którego 80% zasobów zużyję na syntezę CPU.
  • #18 18923315
    kaczodp
    Poziom 14  
    tmf napisał:
    Ja pisałem o dodaniu prostego FPGA, aby można było dodać to co potrzebuję. Np, mam procek, który mi oferuje 8 timerów 16-bitowych i 8 UARTów, a potrzebuję np. 15 timerów 8-bitowych. Więc kasuję z opisu te timery i procki i dodaję gotowy moduł timera 8-bitowego.

    Prosty FPGA = CPLD.
    Jaki problem do AVR podłączyć przez magistralę CPLD w którym będzie UART czy co tam potrzeba? Prawie zawsze UART, TIMER, TWI, raz ustawiony nie jest zmieniany. Zmieści się w CPLD za 10zł. No tak, 10zł. Za połowę tego mam niemałego STM32G0. Mimo, że 90% peryferiów się nie używa to taniej wziąć ARM niz AVR+CPLD. Przy okazji w G0 mam ADC ze sprzętowym oversamplingiem, uart ze sprzętowym wykrywaniem końca ramki, cpu dużo szybszy niż w AVR.
    Może ze względu na to, że AVR sa drogie nie ma AVR z FPGA bo cena byłaby jeszcze wyższa? Kto kupi powolny jak na dzisiejsze czasy AVR za kilkadziesiąt złotych jak za 2-4 razy mniejsze pieniądze ma ARM?

    Dodano po 1 [minuty]:

    tmf napisał:
    Jasne, można sobie kupić FPGA całkiem nietaniego, z setkami wyprowadzeń, po to, aby w nim zsyntetyzować soft-CPU - pomysł kompletnie z czapy

    Z tym się nie zgadzam. Jeśli nie potrzeba milionów sztuk nietypowego układu to taniej wziąć FPGA niż zamawiać układ według własnych wymagań.
    Z drugiej strony jakie mogą to być wymagania, którym nie sprosta STM32?Z pewnością dosyć nietypowe. AVR może nie da rady ale STM32 raczej da. To chyba tłumaczy dlaczego nie ma AVR z FPGA. Nie są potrzebne bo taniej wziąć AVR mimo, ze 50% zasobów lezy odłogiem.
  • #19 18923363
    dondu
    Moderator na urlopie...
    kaczodp napisał:
    Kto kupi powolny jak na dzisiejsze czasy AVR za kilkadziesiąt złotych jak za 2-4 razy mniejsze pieniądze ma ARM?

    Myślisz tylko swoimi kryteriami, ale Microchip jak każdy producent podejmuje decyzje na bazie znacznie szerszych danych. Skoro w 2013 roku (jeszcze przed przejęciem Atmela) sprzedawał ponad miliard mikrokontrolerów rocznie, to wie co robi.

    https://www.elektroda.pl/rtvforum/topic2557115-30.html#14603826

    A wolumen sprzedaży w segmencie mikrokontrolerów po przejęciu Atmela wzrósł prawie 3 krotnie (dane za 2019r.):

    Czym różnią się mikrokontrolery AVR DB od rodziny DA?
  • #20 18923384
    Konto nie istnieje
    Poziom 1  
  • #21 18923664
    tmf
    VIP Zasłużony dla elektroda
    baseemitercollector napisał:
    Nikt nie mowi o zastepowaniu AVRow za pomoca FPGA. Zazwyczaj w projektach gdzie trzeba stosowac takie rozwiazania (jak konfigurowalna logika) to cena raczej ma male znaczenie (koszt czesci jest znikomy w skali ceny calego produktu) i wtedy umieszczanie FPGA lub HPS+FGPA ma sens.

    Tak, ale zauważ, że ja nie pisałem o tym segmencie, bo takie rozwiązania są. Mnie chodzi o przeniesienie tego na grunt prostych układów, takich jak AVR, czy CM0+, dodając im elastyczne możliwości, a jednocześnie zostając w prostych 20-48 pinowych obudowach. Nawet takie połączenie AVR z CPLD byłoby fajne i znacznie zwiększyłoby możliwości MCU. Tyle, że pewnie jest tak jak pisał @atom1477 - dodanie takich elementów pochłania o wiele więcej zasobów niż znaczne zwielokrotnienie ilości dostępnych peryferii. Jednak jakiś kierunek to jest - tego typu elementy w uproszczeniu są w AVR wprowadzane - event system, czy dostępne układy custom logic. Odpowiednio sprytnie podchodząc do problemu można za ich pomocą hardwarowo rozwiązać problemy, których rozwiązania softwarowe wymagałyby o wiele szybszego procka i nie byłyby łatwe.
  • #22 18924202
    Konto nie istnieje
    Poziom 1  
  • #23 18932953
    Janusz_kk
    Poziom 38  
    kaczodp napisał:
    Kto kupi powolny jak na dzisiejsze czasy AVR za kilkadziesiąt złotych jak za 2-4 razy mniejsze pieniądze ma ARM?

    Ten kto nie chce się babrać arm-ami? bo rodzą one nowe problemy jak nowe ide, zegary, przerwania, wszystko jest prawie inne niż w avr-ach.
    Co do nowych avr to dziwi brak dma, uważam to za poważny błąd tym bardziej że już było to w atxmega więc technologię mają, więc zamiast robić pierdyliad rs-ów gdy wystarczą dwa, mogliby pakować domyślnie do wszystkiego dma.
  • #24 18933061
    Konto nie istnieje
    Poziom 1  
  • #25 18933071
    yego666
    Poziom 33  
    Janusz_kk napisał:
    kaczodp napisał:
    Kto kupi powolny jak na dzisiejsze czasy AVR za kilkadziesiąt złotych jak za 2-4 razy mniejsze pieniądze ma ARM?

    Ten kto nie chce się babrać arm-ami? bo rodzą one nowe problemy jak nowe ide, zegary, przerwania, wszystko jest prawie inne niż w avr-ach.
    Co do nowych avr to dziwi brak dma, uważam to za poważny błąd tym bardziej że już było to w atxmega więc technologię mają, więc zamiast robić pierdyliad rs-ów gdy wystarczą dwa, mogliby pakować domyślnie do wszystkiego dma.
    Nie zapominajmy, że AVRy są procesorami Low Performance pomimo ich architektury, stąd chyba nie opłaca się robić zbyt wielkich inwestycji w rozbudowę takiej architektury. Wobec gigantycznej ekspansji architektur ARMo podobnych za psie pieniądze, 8-bitowy segment rynku będzie zanikał. Może nie do zera, ale jednak ekonomia ma swoje prawa.
    Co do stopnia komplikacji architektury ARMów, to jest zylion narzędzi wspomagających początkujących programistów w procesie uczenia się niuansów i zaawansowanych zagadnień. Na przykład firma ST ma całkiem niezłe IDE ( STM32CubeIDE ) które robi prawie całą konfigurację wstępną niemalże automatycznie. Ceny procesorów STM32 zachęcają do prób, nawet jeśli się "kocha" AVRy. Myślę że warto spróbować.

    Moderowany przez tmf:

    Przypominam, że to nie jest temat o ARMach, lecz nowych procesorach AVR. Wszelkie dyskusje nie na temat będą usuwane.

  • #26 18933426
    Janusz_kk
    Poziom 38  
    atom1477 napisał:
    Skąd założenie że wystarczą 2 RSy?
    Właśnie to jest główny problem przy robieniu bardziej skomplikowanych projektów. Brak odpowiedniej ilości interfejsów.


    Robię bardzo skomplikowany i mi nie brakuje, podobnie jak oglądam różne urządzenia to rzadko wiedzę żeby było więcej, więc bez przesady co nie zmienia faktu że może być wersja z większą ilością, bardziej na myśli miałem powierzchnię krzemu, zajmowaną przez np: rs-y czy to nie było powodem wycięcia dma.
  • #27 18933601
    Konto nie istnieje
    Poziom 1  
  • #28 18934100
    tmf
    VIP Zasłużony dla elektroda
    atom1477 napisał:
    W przypadku prostego procesora dochodzi też taki problem że trzeba się wcinać w normalne transfery robione przez CPU. Co wprowadza konieczność dodania logiki sterującej do tego.

    Tak, tyle, że w XMEGA już to wszystko zrobili, więc blokadą nie jest konieczność zaprojektowania tych układów. Wiele rzeczy w tych nowych rodzinach jest niby tak jak w XMEGA, tyle, że wygląda to jak dwa kroki do przodu i trzy do tyłu:
    - niższe taktowanie (24 vs. 32 MHz) - można zrozumieć, bo mamy za to zasilanie do 5V,
    - brak USB, które było w części XMEG,
    - brak DMA,
    - uproszczona konfiguracja pinów IO - brak pull down, wired OR itd.,
    - brak AES i CRC dla danych, tylko CRC dla FLASH,
    - ale za to lepiej rozwiązany podział FLASH na aplikację i biootloader (można płynnie ustawiać granicę),
    - niektóre mają dwie domeny zasilania, fajne do łączenia układów zasilanych 5V i np. 3,3V,
    - rozbudowany komparator analogowy z programowo regulowanym wzmocnieniem
    - kilka innych bajerów.
    A w kwestii UART i timerów - to IMHO nigdy za wiele. Piszę prostą apkę, w której wykorzystuję UART w trybie SPI do modułu radiowego, mam pod kolejny podpiętą pamięć dataFLASH, do tego UART do RS485, kolejny do WiFi (ESP), jeden w trybie SPI do karty SD i jeden jako master one wire. Od biedy mógłbym połączyć te elementy, które pracują na SPI, ale mało wygodne to jest, bo urządzenia mają różne częstotliwości maksymalne taktowania SPI. Timerów też nigdy za wiele - zwykle wykorzystuję 4, a czasami więcej. Wiele różnych cudów można na timerach zrobić, szczególnie jeśli da się to tak jak w XMEGA elastycznie sprząc z innymi podsystemami.
  • #29 18934420
    Konto nie istnieje
    Poziom 1  
  • #30 18934488
    tmf
    VIP Zasłużony dla elektroda
    atom1477 napisał:
    Dając DMA przy braku USB, uniemożliwili by też używanie biblioteki VUSB.

    Są AVRy z DMA i bez USB, więc to nie to. Zresztą niesądzę, aby ktoś projektował MCU pod kątem softwarowego USB. No i nie ma przymusu korzystania z DMA, można przecież go nie włączyć i cieszyć się stałymi timingami. Z tym USB to przypuszczam, że mieli problem jako konsekwencję zasilania do 5V procesora. Widać, że wpłynęło to na max tekatowanie (24 MHz), USB potrzebuje 48 MHz, pewnie nie dało się tego pogodzić z zasilaniem 5V.

Podsumowanie tematu

Mikrokontrolery AVR DB różnią się od rodziny DA głównie poprzez wprowadzenie trzech wzmacniaczy operacyjnych oraz poprawionych parametrów ADC, co czyni je bardziej odpowiednimi do zastosowań analogowych. AVR DB oferują FLASH od 32 do 128 KB, SRAM od 4 do 16 kB, oraz EEPROM 512 bajtów. Nowością jest dedykowany pin VDD2, umożliwiający zasilanie PORTC napięciem 1,8-5,5V, co pozwala na pracę z różnymi napięciami. W porównaniu do DA, DB mają mniej pinów I/O w mniejszych obudowach oraz brak modułu obsługi dotyku. Użytkownicy zauważają również brak DMA, co jest postrzegane jako istotna wada, oraz problemy z USB. Nowe modele, takie jak AVR DD, również zostały wspomniane, ale ich różnice w stosunku do DB są na razie niejasne.
Podsumowanie wygenerowane przez model językowy.
REKLAMA