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

[AVR] ATMega ATTiny 0-Series, 1-Series uwagi ogólne

JarekC 10 Kwi 2020 16:09 2148 10
REKLAMA
  • #1 18605748
    JarekC
    Poziom 32  
    Witam,

    Od jakiegoś czasu Atmel/Microchip wprowadził do oferty nowe układy ATMEGA i TTINY z nowych serii określanych jako 0-series 1-series.

    Ponieważ zacząłem wykorzystywać układy z tych serii postanowiłem napisać do nich własny bootloader z szyfrowaniem danych algorytmem AES.
    Założeniem było aby go zmieścić w 768 bajtach kodu (mocno zoptymalizowany kod)
    Pewnie niedługo zaprezentuję go na forum.

    Jednak podczas pisania bootloadera, a dokładnie procedury szyfrowania AES128, natrafiłem na problem, że procedury poprawnie działały na "starych AVR", a na nowym ATTINY817 nie.

    Jednym z elementów algorytmu szyfrowania AES jest przesuwanie wierszy w dwuwymiarowej tablicy, aby zrealizować to szybko i z minimalnym użyciem pamięci kodu. Tablica została umieszczona w pierwszych 16 rejestrach R0-R15,
    co pozwoliło na wykorzystanie instrukcji MOV Rd,Rs.
    Pozostałe operacje na tablicy były wykonywane przy użyciu instrukcji LD/ST/LDD/STD i rejestrów X/Y jako wskaźników.
    W "starych AVRach" działało to poprawnie, bo dostęp do rejestrów R0-R31 jet możliwy poprzez adresację w pamięci RAM, R0 to po prostu komórka 0.

    I tutaj pojawia się jedna z ważnych różnic pomiędzy "starymi AVR" a nowymi 0-series,1-series.

    W nowych rejestry R0-R31 zostały usunięte z przestrzeni adresowej RAM. Nie można się do nich dostać poprzez rozkazy LD/ST/LDD/STD/LDS/STS.

    Piszę o tym, bo inne różnice są mocniej zaznaczone w kartach katalogowych, a o tej jest tylko jedno zdanie, które łatwo przeoczyć o czym przekonałem się sam.
    Cytat:
    The register file is located in a separate address space and is therefore not accessible trough instructions operation on data memory.


    Jeżeli ktoś ma uwagi i doświadczenia związane z nowymi AVR to zachęcam do podzielenia się nimi z innymi.

    Pozdrawiam
    JarekC
  • REKLAMA
  • #2 19127063
    JarekC
    Poziom 32  
    Tym razem uwaga na temat taktowania timera B.
    Timer B ma bardzo zubożony dzielnik zegara gdyż may tylko opcję dzielenia przez 2 lub braku dzielenia.
    Alternatywą może być taktowanie zegarem zapożyczonym z Timera A, (sygnał pobierany zza dzielnika Timera).

    Cytat:
    This peripheral uses the system's peripheral clock CLK_PER. The peripheral has its own local prescaler, or can be
    configured to run off the prescaled clock signal of the Timer Counter type A (TCA).


    Przy czym w karcie katalogowej nie ma nigdzie stricte powiedzianego że aby zegar z Timera A był podawany na Timer B nie wystarczy wybrać wartości dzielnika ale również należy włączyć Timer A, np:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • REKLAMA
  • #3 19176819
    excray
    Poziom 41  
    Attiny212-412 opis wyprowadzeń. Według aktualnego DSa wyprowadzenie UARTA wyglądają tak:
    [AVR] ATMega ATTiny 0-Series, 1-Series uwagi ogólne
    A w rzeczywistości jest tak:
    [AVR] ATMega ATTiny 0-Series, 1-Series uwagi ogólne
    Więc jak ktoś się zastanawia czemu nie działa mu UART, to już ma odpowiedź. Swoją drogą problem znany już co najmniej pół roku i nikt do tej pory nie poprawił tego w DSie.
  • REKLAMA
  • #6 19233744
    excray
    Poziom 41  
    Krytyczne uwagi:
    - bardzo słaby oscylator TOSC. O ile w starych avr-ach uC świetnie sobie radził z LFC startując szybko, pewnie i nawet bez dodatkowych kondensatorów, to tutaj uC radzi sobie fatalnie. Trzeba bardzo zadbać o poprawne wykonanie, dobry dobór kondensatorów i rezystora szeregowego, aby układ w ogóle wstał, a i tak robi to długo (kilka dobrych sekund).
    - nie podoba mi się zachowanie bitu XOSC32KS w rejestrze MCLKSTATUS. Z niezrozumiałego dla mnie powodu pętla testująca ten bit zawiesza uC.
    - pływające piny - pobór prądu. I tutaj tak samo - w starych avr-ach piny pływające podnosiły oczywiście zużycie prądu, ale to były nieznaczne zmiany. O tyle w nowych, nawet jeden pływający pin potrafi zeżreć ekstra kilkaset uA. Jeśli w uśpieniu dany pin nie będzie nam potrzebny np. do wybudzenia, to wystarczy ustawić go w trybie "INPUT_DISABLE" (bity ISC=4 w rejestrze PINCTRL). Gorzej, jeśli pin musi być aktywny ze względu np. na wybudzanie tym pinem uC. Już nieznacznie odbiegające od Vcc i GND potencjały powodują gwałtowny wzrost poboru prądu.
  • #7 20077099
    Karol966
    Poziom 31  
    Czy ta seria ma jakieś szanse na zaistnienie? Zanim dostępność prockow z serii mega-0 spadła do zera można było kupić całkiem fajny układ za mniej niż 5 zł (np 1608). Sam kupiłem ich 1000 sztuk. Procki fajne a to że opierają się o rdzeń xmegi tylko umilą pracę z nimi. Niestety kogo bym nie zapytał to nie slyszał o tych procesorach, być może kilka osób slyszało o 4809 no bo siedzi w curiosity nano a i jakieś płytki do Arduino również na tych prockach są oparte. Osobiście mam nadzieję że te procki nie umrą śmiercią naturalną w najbliższym czasie.
  • REKLAMA
  • #8 20077184
    excray
    Poziom 41  
    Myślę, że one już wygrały ze starymi uC. Szczególnie ze względu na dostępność.
  • #9 20077395
    Karol966
    Poziom 31  
    excray napisał:
    Myślę, że one już wygrały ze starymi uC. Szczególnie ze względu na dostępność.

    W tej chwili jest raczej odwrotnie, jedyne dostępne procki AVR to pewnie 328PB (ew pokrewne) w microsie (po kosmicznych cenach) a serii mega-0 nie znalazłem w tej chwili nigdzie (w znanych mi sklepach, może są jakieś inne źródła?).
  • #10 20077431
    excray
    Poziom 41  
    W TME i w Farnellu są głównie nowe AVRy.
  • #11 20387674
    excray
    Poziom 41  
    W ATMEGA808 (zapewne w innych nowych też występujący) wychwyciłem błąd związany z zachowaniem się RTC po wybudzeniu z uśpienia STANDBY. Mam kod, który w przerwaniu od pinu odczytuje zawartość RTC_CNT. RTC oczywiście ustawiony w trybie RUNSTDBY. Odczyt CNT odbywa się zaraz na początku obsługi przerwania. Okazuje się, że raz na kilkanaście odczytów wartość zwracana jest śmieciowa. Dołożenie opóźnienia kilkunastu us rozwiązuje problem. Najprawdopodobniej zawodzi synchronizacja między fizycznym licznikiem a rejestrem RTC_CNT.
REKLAMA