Do tej pory w AVR większe zasilanie to było większe taktowanie.
Więc na 5V było by im łatwiej zrobić taktowanie 48MHz. No oczywiście kosztem poboru prądu.
Dopiero stosując inną technologię można zrobić i większą prędkość i mniejszy pobór prądu, przy niższym napięciu (tyle że był by przymus pracy przy tym niższym napięciu, i już nie miało by opcji pracy na 5V).
Jak to jest z tymi nowymi AVR-ami bo nie mogę nabrać do nich przekonania . Chwilami odnoszę wrażenie że to wilk w owczej skórce czyli pic lekko podciągnięty pod AVR-a . W każdym razie nie wiedzieć czemu jestem ostrożny w zachwytach i osądzaniu tego co nam proponują , a ponieważ stare jest dobre i sprawdzone nie mam potrzeby sięgać po nowe . Ale chętnie usłyszał bym czego nie da się na staruszku a da się na tym nowym .
No na papierze wyglądają te nowe AVRy ciekawie nie powiem ale xmegi też wyglądały ciekawie na papierze. Ciekawi mnię czy poprawili ten spartolony przetwornik ADC z xmeg który w zasadzie ciężko było wykorzystać nawet do tak prozaicznych zadań jak odczyt stanu potencjometrów, za to całkiem dobże sprawdzał się jako generator liczb pseudolosowych. Ogólnie xmega byłaby dla mnie fajną alternatywą dla poczciwych klasycznych AVRów gdyby nie ten nieszczęsny ADC właśnie. Ale w sumie gdyby nie to pewnie bym się nie zainteresował innymi MCU takimi jak np Psoc5 od cypressa który w zasadzie ma wszystko o czym wspomniano w postach powyżej tj proste cpld, przejżysty i przyjemny w obsłudze zestaw narzędzi, DMA, USB, zarządzanie zegarami + sporo innych możliwości do tego jest MCU 32bitowym. Jedyne wady to dostępność w PL i cena choć ta jak na oferowane możliwości moim zdaniem nie jest wygórowana a fakt posiadania na pokładzie MCU logiki programowalnej nieco wywraca sposób myślenia o projektowaniu do góry nogami;) Z pewnością nabędę i pobawię się którymiś z nowych AVR bo mam w sumie spory sentyment do tej rodziny i jeżeli faktycznie będą takie jak obiecują to pewnie powstaną jakieś projekty na nich oparte Ciekawa jest ta opcja z dwunapięciowym zasilaniem Można by gonić cpu na 5V a pod port zasilany 3.3V wpiąć bez problemu jakieś FPGA.
PS.
Quote:
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.
Proponuję rzucić okiem na PSoC Creator i wspomnianą wyżej rodzinę PSoC5 od Cypress-a. W mojej opinii jest to zestaw bliski temu marzeniu i aż żal ze nie jest bardziej popularny. Masz tam bardzo przyjazny interfejs i gotowe peryferia do włożenia na schemat. Cześć jest implementowana w wewnętrznym PLD a część jest sprzętowymi blokami przy czym nic nie stoi na przeszkodzie aby np. zrobić sobie więcej timerów niż jest w blokach sprzętowych wkładając dodatkowe w PLD. Można nawet twożyć własne peryferia w językach opisu sprzętu. Jedyne wady to takie że PLD jest stosunkowo małe a same makrokomórki są nieco uboższe niż w klasycznym FPGA. No ale coś za coś ...
Ciekawi mnię czy poprawili ten spartolony przetwornik ADC z xmeg który w zasadzie ciężko było wykorzystać nawet do tak prozaicznych zadań jak odczyt stanu potencjometrów, za to całkiem dobże sprawdzał się jako generator liczb pseudolosowych.
Problemy z ADC były tylko w serii U1 (pierwszej jaka wyszła), w A1U (tańszy następca, z poprawionym także EBI i dodanym USB), problemów nie ma żadnych. Jedyny kłopot dla wielu osób to strasznie rozbudowane funkcjonalności, kilka różnych trybów pracy i ten mylący tryb unsigned z offsetem. Niemniej całość działa bardzo dobre i z tym ADC problemów nie miałem żadnych. Natomiast 12-bitowy ADC z A1U, z pipeline, wyciągający 4 Msps to raczej niezły wypas jak na 8-bitowca.
BTW, widzę, że jest kolejna seria tych aVR - EA. Na szybko - coś tam okroili, nic istnie nie zmienili w stosunku do pozostałych serii D.
Zastanawiam się tylko czy będą obsługiwane na STK600 po dokupieniu podstawki bądź karty rotującej . No i oczywiście na Atmel Studio . Bo nie mam zamiaru instalować kolejnego IDE dla kilku układów . Pytanie kolejne czy kompilator będzie obsługiwał asembler bo nie mam zamiaru się C-ackać z kilkoma nowymi .
No i oczywiście na Atmel Studio . Bo nie mam zamiaru instalować kolejnego IDE dla kilku układów . Pytanie kolejne czy kompilator będzie obsługiwał asembler bo nie mam zamiaru się C-ackać z kilkoma nowymi .
W AS działąją. Trzeba tylko uaktualnić pliki w pack menagerze. Kompilator też obsługuje, mają taką samą listę rozkazów jak inne AVR.
A STK600 będzie je obsługiwać ? Mam bardzo dużo oryginalnych narzędzi JTAG ice MK2 , AVR ONE, STK 600 . Miło by było jak bym czymś to nadal programował a nie kupował nowe narzędzie ...
A STK600 będzie je obsługiwać ? Mam bardzo dużo oryginalnych narzędzi JTAG ice MK2 , AVR ONE, STK 600 . Miło by było jak bym czymś to nadal programował a nie kupował nowe narzędzie ...
Najprościej to podglądnąć plik opisu procesora (pdsc) i tam masz m.in. wymienione programatory/debuggery z którymi współpracuje w AS. Ponirważ one obsługują UPDI, więc na dzisiaj lista wygląda tak:
Ciekawa jest ta opcja z dwunapięciowym zasilaniem 
Można by gonić cpu na 5V a pod port zasilany 3.3V wpiąć bez problemu jakieś FPGA.
Coś mnie zaćmiło.
