uC ATXmega
uC ATXmega
Cześć.
Spotkał sie ktoś z takimi uC AVR jak ATXmega?
Czytałem sobie dzisiaj note katalogową i nie do końca wiem czy są to 8 bitowe czy 16 bitowe układy?
Czym różnią się one od zwykłych ATMega?
Wiem że to żadna nowość na rynku, ale dopiero teraz zacząłem im sie przyglądać?
Używał z Was ktoś ich?
Spotkał sie ktoś z takimi uC AVR jak ATXmega?
Czytałem sobie dzisiaj note katalogową i nie do końca wiem czy są to 8 bitowe czy 16 bitowe układy?
Czym różnią się one od zwykłych ATMega?
Wiem że to żadna nowość na rynku, ale dopiero teraz zacząłem im sie przyglądać?
Używał z Was ktoś ich?
To po prostu linia rozwojowa procesorów ATMega. Są to 8 bitowe procesory AVR, z 16 bitową pamięcią programu.
Niestety ATMEL trochę zaspał z nimi i nie zdobyły takiej popularności jak ATMegi, no i mają inny interfejs programowania jak się nie mylę.
Ogólnie ekspansja tanich ARMów jak STM32 zepchnęła te procesory na margines.
Niestety ATMEL trochę zaspał z nimi i nie zdobyły takiej popularności jak ATMegi, no i mają inny interfejs programowania jak się nie mylę.
Ogólnie ekspansja tanich ARMów jak STM32 zepchnęła te procesory na margines.
Z tego co tak na szybko widzę to w XMega dodano 7 nowych instrukcji jest ich teraz 138 zamiast 131 znanych z ATMegi.
A 8/16Bit to pewnie aluzja że jest to procesor mający cechy 8 i 16 bitowej jednostki. Czyli 8 bitowa architektura, z typową dla 16 bitowych procesorów szerokością przestrzeni adresowej wynoszącą 16MB.
ogólnie procki ciekawe, ale jak dobrze pamiętam w podobnej cenie można upolować AVR32, który ma dużo większe możliwości, a też jest AVRem ale 32 bitowym.
A 8/16Bit to pewnie aluzja że jest to procesor mający cechy 8 i 16 bitowej jednostki. Czyli 8 bitowa architektura, z typową dla 16 bitowych procesorów szerokością przestrzeni adresowej wynoszącą 16MB.
ogólnie procki ciekawe, ale jak dobrze pamiętam w podobnej cenie można upolować AVR32, który ma dużo większe możliwości, a też jest AVRem ale 32 bitowym.
- Aro
- Użytkownik
- Posty: 677
- Rejestracja: 30 paź 2006, 18:49
- Lokalizacja: Świerczyniec | Wrocław
- Kontakt:
"8/16bit AVR CPU",
Tak naprawdę dotyczy to tylko zapisu do rejestrów IO. Wygląda to w taki sposób, że jeden bajt zapisujesz najpierw do rejestru tymczasowego, i później zapisując drugi bajt już do właściwego rejestru IO, jednocześnie zapisany zostaje ten pierwszy (przechowywany w rejestrze tymczasowym). Wygląda to mniej więcej tak:
Oczywiście sam procesor jest 8 bitowy:)
Tak naprawdę dotyczy to tylko zapisu do rejestrów IO. Wygląda to w taki sposób, że jeden bajt zapisujesz najpierw do rejestru tymczasowego, i później zapisując drugi bajt już do właściwego rejestru IO, jednocześnie zapisany zostaje ten pierwszy (przechowywany w rejestrze tymczasowym). Wygląda to mniej więcej tak:
Kod: Zaznacz cały
rejestr 16 bitowy IO
^ ^
| | <--- przepisanie wartości 16 bitowej w jednym cyklu zegarowym
temp |
| | <--- zwykłe kopiowanie 8 bitowe
bajt1 bajt2-
atelszewski
- Użytkownik
- Posty: 143
- Rejestracja: 12 sie 2005, 9:36
- Lokalizacja: Banie
Witam,
Niedawno w EP był cykl o projektowaniu energooszczędnych układów elektronicznych. Z tego co wyczytałem, to 8-bitowce pod tym względem są nie do pobicia, dlatego irytuje mnie wpychanie na siłę 32-bitowca, bo jest tańszy i mocniejszy (ale nie zawsze lepszy w danym rozwiązaniu).
Jeśli chodzi o Xmegi, to dawno temu przeglądałem notę katalogową - mają kilka ciekawych rzeczy, ale zamiast wypisywać i zgadywać, proponuję dokładnie przestudiować notę (mają między innymi sprzętowy DES/AES i system eventów, pozwalający odciążyć CPU).
Niedawno w EP był cykl o projektowaniu energooszczędnych układów elektronicznych. Z tego co wyczytałem, to 8-bitowce pod tym względem są nie do pobicia, dlatego irytuje mnie wpychanie na siłę 32-bitowca, bo jest tańszy i mocniejszy (ale nie zawsze lepszy w danym rozwiązaniu).
Jeśli chodzi o Xmegi, to dawno temu przeglądałem notę katalogową - mają kilka ciekawych rzeczy, ale zamiast wypisywać i zgadywać, proponuję dokładnie przestudiować notę (mają między innymi sprzętowy DES/AES i system eventów, pozwalający odciążyć CPU).
Wiesz nasunąłeś mi pytanie, które chodziło mi od dawna po głowie.
Na podstawie czego twierdzi się że uC 32bitowe są wydajniejsze od 8 bitowych?
Bo jeśli chodzi tylko o częstotliwość taktowania to producent chyba by sobie poradził.
A zobacz że napisanie prostego programu na układ 32bitowy jest o niebo bardziej złożone niż na 8 bitowego np AVRa
Na podstawie czego twierdzi się że uC 32bitowe są wydajniejsze od 8 bitowych?
Bo jeśli chodzi tylko o częstotliwość taktowania to producent chyba by sobie poradził.
A zobacz że napisanie prostego programu na układ 32bitowy jest o niebo bardziej złożone niż na 8 bitowego np AVRa
Są wydajniejsze, szczególnie przy obliczeniach, bo to co w 8 Bitowym procesorze musisz robić niejako na raty tam wykonasz jedną instrukcją. np. dodawanie o siebie 2 liczb 32 bitowych.
Jeżeli chodzi o operacje typowo sterowania, to tu jedynie jest szybszy dostęp do rejestrów np. Timera. Ale to ma znaczenie tylko w przypadku naprawdę szybkich aplikacji, normalnie ten wzrost wydajności, nie jest aż tak istotny. Zresztą 8-bitowiec wyposażony w DMA lub kontroler krzyżowy jak to jest w XMega, potrafi też szybko się z tym uporać.
Co do trudności programowania, to czasy asemblera odeszły do lamusa, byle znasz C/C++ i poradzisz sobie z każdym procem czy będzie 8 bitowy czy 32B czy nawet 128-bitowy.
Jeżeli chodzi o operacje typowo sterowania, to tu jedynie jest szybszy dostęp do rejestrów np. Timera. Ale to ma znaczenie tylko w przypadku naprawdę szybkich aplikacji, normalnie ten wzrost wydajności, nie jest aż tak istotny. Zresztą 8-bitowiec wyposażony w DMA lub kontroler krzyżowy jak to jest w XMega, potrafi też szybko się z tym uporać.
Co do trudności programowania, to czasy asemblera odeszły do lamusa, byle znasz C/C++ i poradzisz sobie z każdym procem czy będzie 8 bitowy czy 32B czy nawet 128-bitowy.
-
atelszewski
- Użytkownik
- Posty: 143
- Rejestracja: 12 sie 2005, 9:36
- Lokalizacja: Banie
Witam,
W sumie racja... Wydaje mi się, że chodzi o wydajność obliczeniową, która jest związana z możliwością przeliczania większej liczby/cykl maszynowy. Dodatkowo, 8-bitowce raczej nie obsługują operacji zmiennoprzecinkowych natywnie i raczej nie zawierają instrukcji umożliwiających np. mnożenie wektora przez wybraną liczbę w jednym cyklu - czyli cech zarezerwowanych dla powiedzmy 32- i więcej bitowców. Wydaje sie więc, że jeśli porównywać by operacje na liczbach 8-bitowych, przy tych samych zegarach oraz nie korzystając z wyrafinowanych instrukcji - wydajność byłaby zbliżona. Tutaj małe wyjaśnienie, dlaczego 8-bitowce są, jakie są, i dlaczego takie będą;)Na podstawie czego twierdzi się że uC 32bitowe są wydajniejsze od 8 bitowych?
To jest koszt ponoszony za większe możliwości. Obecnie bawię się Linuksem embedded i zaświecenie LEDa wygląda zgoła inaczej niż np. w AVR, ale AVR nie obsłuży mi karty SD, ethernetu, USB host i device, rs-232 oraz CAN bez mała w jednym czasie. Odpowiedni procesor do odpowiedniej aplikacji.A zobacz że napisanie prostego programu na układ 32bitowy jest o niebo bardziej złożone niż na 8 bitowego np AVRa
To akurat tak nie do końca jest prawda. Zanim MAXIM kupił DALLSa to opracowano unowocześnione rdzenie 8051, w tym także wyposażony w 32 bitowy kooprocesor arytmetyczny, ale stałoprzecinkowy. Atmel też miał swego czasu wersję 8051 z sprzętowym dekoderem MP3 na pokładzie, czyli czymś wiązanym raczej z dużymi CPU. Oba te CPU co prawda nie zdobyły ani rozgłosu, ani popularności i dzis obie firmy chyba ich już nie produkują, ale są do dziś produkowanie 8051 do zastosowań RTV któr mają 256 KB przestrzeni adresowej i wbudowane układy generowania obrazu, konkretnie OSD.Dodatkowo, 8-bitowce raczej nie obsługują operacji zmiennoprzecinkowych natywnie i raczej nie zawierają instrukcji umożliwiających np. mnożenie wektora przez wybraną liczbę w jednym cyklu - czyli cech zarezerwowanych dla powiedzmy 32- i więcej bitowców.
Co do AVRów to oferują one bajer znany z Z80 czyli dodawanie i odejmowanie liczb 16 bitowych.
Pewnym wyjątkiem są procesory DSP PIC, ale to jednostki 16 bitowe, z 40 bitowym kooprocesorem DSP.