Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Nowe mikrokontrolery AVR DB i jeszcze nowsze - DD

23 Sie 2020 16:15 2643 36
  • Moderator Mikrokontrolery Projektowanie
    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.
  • Poziom 30  
    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.
  • Poziom 43  
    Nie wymieniłeś najważniejszej cechy:
    Cytat:
    Functional Safety:
    This product is recommended for safety critical applications targeting both industrial and automotive products (IEC 61508 and ISO 26262). Necessary documentation such as FMEDA report and Safety Manual can be provided on request. Certified development tools are also available for this product. Please contact your local Microchip sales office or your distributor for more information.
  • Poziom 30  
    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.
  • Poziom 30  
    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.
  • Admin Sekcji Początkujący
    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ć.
  • Moderator Mikrokontrolery Projektowanie
    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.
  • Moderator Mikrokontrolery Projektowanie
    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....
  • Moderator Mikrokontrolery Projektowanie
    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.
  • Moderator Mikrokontrolery Projektowanie
    @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.
  • Poziom 43  
    Problemem są switchboxy*. To są wielokrotnie bardziej skomplikowane bloki niż bloki LUT.
    Żeby mieć cokolwiek co daje się wykorzystać jako CPLD/FPGA, potrzeba by minimum z 32 LUTy, ale i mniej więcej ze 32 switchboxy. Plus mocny software na PC do projektowania połączeń.
    To jest główny ogranicznik wbudowania bloków logicznych do uC. Bo samo zrobienie LUTów to akurat jest bardzo łatwe.

    *Pewnie mało kto nawet wie co to jest, bo to są bloki niedostępne wprost dla użytkownika (nie wykonują też żadnych funkcji logicznych więc nikt się nimi nie interesuje). Ale od strony budowy wewnętrznej FPGA, to jest podstawa.
  • Poziom 12  
    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.
  • 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.
  • Poziom 18  
    kaczodp napisał:

    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.


    Procz tego istnieje spore wsparcie do takich rozwiazan ze strony Xilinx Vivado - tam sie rysuje bloczki czy to do podlaczenia rdzenia ARM czy soft-cpu Microblaze (plus pare tuzinow roznych peryferiow jak kontrolery pamieci, jakis uarty czy ethernet); podobne rozwiazanie oferuje Microsemi (kiedys Actel) gdzie mozna miec w jednej obudowie rdzen ARM i FPGA fabric lub miec malego Corteksa w postaci soft-core. Altera/Intel chyba bedzie powoli wychodzic z NIOS'a na rzeczy ARMow w ukladach z serii np. CycloneV.
    A jak kto ma dosc duzych korporacji to pozostaje malo znane i swietne srodowisko grlib od Cobham Geisler - gdzie jest gotowy kod procesora LEON3 oraz z roznymi peryferiami, kompilatorem i calym srodowiskiem - i do tego przygotowane paczki pod wszystkie znane plytki ewaluacyjne z FPGA. LEON3 to kolejna wersja procesora zrobionego na zamowienie ESA (Europejska Agencja Kosmiczna) optymalizowana do pracy w trudnych warunkach (promieniowanie itp).
    Microchip to w zasadzie mozna jako ciekawostke przedstawic kawalek FPGA bo nie oferuja nic nowoczesnego z FPGA (choc Atmel mial jakies CPLD ofercie kiedys).
  • Moderator Mikrokontrolery Projektowanie
    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.
  • Poziom 12  
    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.
  • Moderator Mikrokontrolery Projektowanie
    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/viewtopic.php?p=14603826#14603826

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

    Nowe mikrokontrolery AVR DB i jeszcze nowsze - DD
  • Poziom 18  
    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. Ja pisałem o dodaniu prostego FPGA, aby można było dodać to co potrzebuję.


    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.
  • Moderator Mikrokontrolery Projektowanie
    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.
  • Poziom 43  
    tmf napisał:
    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.

    Policzyłem na oko bo ciężko znaleźć takie dane:
    8 bloków LUT4+FF (standardowy blok w większych FPGA): 500..1000 tranzystorów.
    Switchbox który to obsłuży: 10 000 tranzystorów.

    Przy czym nie liczę pamięci konfiguracyjnej, która ma ustawić stan prawie każdego z tych tranzystorów (co 2....4 w LUT4, i dosłownie każdego w switchboxie).
  • Poziom 28  
    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.
  • Specjalista PLD
    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.

  • Poziom 28  
    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.
  • Poziom 43  
    Są różne projekty.
    Może być skomplikowany ale nie używający UARTa w ogóle.
    A może być całkiem prosty ale używający trzech. Np. jeden do modułu GPS albo GSM, drugi do zrobienia komunikacji RS485, a trzeci jako debug do PC.

    UART nie zajmuje sporo powierzchni struktury.
    Za to DMA jest całkiem skomplikowane mimo zewnętrznej prostoty. No jeszcze zależy jakie DMA. Ale jeżeli ma obsługiwać kilka strumieni na raz, to potrzebny jest arbiter oraz bufory na dane. 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.
    W dużym procesorze to już jest (z innych powodów), więc przynajmniej nie trzeba tego dodawać jako coś nowego.
  • Moderator Mikrokontrolery Projektowanie
    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.
  • Poziom 43  
    tmf napisał:
    - brak USB, które było w części XMEG,
    - brak DMA,

    To akurat łatwo zrozumieć.
    DMA rozwala taktowanie CPU.
    A biblioteka VUSB opiera się na przewidywalności szybkości wykonywania każdej instrukcji.
    Dając DMA przy braku USB, uniemożliwili by też używanie biblioteki VUSB.
    Albo musieli by robić specjalne DMA które zawsze ma niższy priorytet niż CPU.
  • Moderator Mikrokontrolery Projektowanie
    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.