SMT32 vs Xmega - Co po Atmega?

Witam,
Stoję przed problemem z jakim boryka się pewnie wielu programistów popularnych Atmeg.
Chcę rozpocząć zabawę z jakąś wydajniejszą i bardziej rozwojową rodziną procesorów a wybór jest bardzo duży.
Jestem amatorem i rozpracowanie Atmeg zajęło mi trochę czasu. Mam więc świadomość, że nie nauczę się szybko podstaw obsługi kilku różnych procesorów aby wybrać najbardziej mi odpowiadający.
Chciałbym aby przesiadka była z jednej strony jak najłatwiejsza, ale nie chcę jednocześnie zabrnąć w ślepą uliczkę i za jakiś czas stanąć przed tym samym problemem.
Stąd moja prośba do osób doświadczonych prockami różnej maści o pomoc w wybraniu odpowiedniej rodziny na podstawie moich rozterek:
-Nie potrzebuję wielkich możliwość, chodzi o lepsze osiągi od poczciwej Atmegi przy korzystnej cenie. Przyznam, że swoje porównania zawęziłem do ATXmeg i STM32, może źle?
-Brnąc w te dwie rodziny to wydajność do ceny przemawia na korzyść STM32 ( 16 kontra 32 bity, zegary też wyższe)?
-Czy dla kogoś kto porusza się w Atmegach przesiadka na Xmega będzie na tyle prostsza niż na zupełnie nieznane army że jednak warto pozostać w stajni ATMEL-a?
-Czy jednak warto zrobić większą rewolucję w nauce programowania ze względu na większą wydajność i jak sądzę rozwojowość (dostępne bardzo wydajne pokrewne modele)
-Co z programatorem czy do Xmeg wystarczyłby JTAG ICE mk1, który posiadam czy itak musiałbym kupić coś innego?
-Które układy mają bogatsze wsparcie książki, poradniki, kursy blogi itp.?
-A może zupełnie inne procesory dla hobbysty-amatora z ambicjami?

Proszę o sugestie.

Ja troszkę odsunę się od odpowiedzi. I powiem tak:

Jeśli poznasz dobrze jedną architekturę w raz z całą otoczką, tzn sposobami debugowania, posługiwania się narzędziami. Nauczysz się dobrze kodzić i nie mam tu na myśli napisania czegoś co działa, bo to dopiero 20% sukcesu. Bo niezawodność czytelność kodu i łatwość modyfikowania jest również ważna i sztuką jest tak napisać kod. I co uważam za istotne zaraz za znajomością architektury, to znajomość funkcjonowania kompilatora i narzędzi z tym związanych to żadna powtarzam żadna nowa architektura nie będzie ci straszna.

Bo np weźmy na tapetę taki licznik, może pracować w kilku trybach:
licznik, timer, input capture PWM. Większość z nich to zapewnia. A wszystko często rozbija się o inne nazwy bitów.

Przerwania, co za różnica czy AVR czy STM32. Jeśli umiesz je wykorzystywać wykorzystasz na dowolnej platformie.

Dlatego uważam, że warto poznawać nowe architektury, ale nie warto tego robić bez poznania przynajmniej jednej dogłębnie jako odniesienia.

ARMy to nie fizyka kwantowa więc da się ogarnąć. Im więcej architektur liźniesz tym lepiej dla Ciebie - będziesz wiedział w co nie brnąć. Kup sobie jakąś płytkę rozwojową z cyklu STM32DISCOVERY czy jakiegoś KWIKSTICKA, będziesz miał tam wszystko czego potrzebujesz na początek. Tutorial z neta i na początek starczy.

A co do Xmeg - procki jak procki, trochę odgrzewane kotlety, ale dają jeszcze jako tako radę.

Są ciekawsze architektury, ale dla hobbysty poza zasięgiem finansowym, czasowym lub wiedzowym.

Nie. Xmega w obliczeniach nie jest szybsza niż stare AVR8. Większość wprowadzonych w niej rozwiązań ma za zadanie odciążyć rdzeń od liczenia czegoś, co nie jest potrzebne do liczenia. Np. zamiast CPU nadzorować pracę ADC i UART kopiując "manualnie" dane między rejestrami to xmega wykorzysta event system z dma i oprócz wstępnej konfiguracji rdzeń procesora będzie bezczynny (a dokładniej - będzie absolutnie i wyłącznie do dyspozycji programu głównego, czy to przeliczania danych w locie, czy sprawdzania warunków, czy też po prostu przełączania kanałów DMA i ustawiania pinów wyjściowych).
Tyle jeśli chodzi o Atmega vs Xmega względem możliwości.
Dalej - przykłady - tutaj na Xmega jest naprawdę ubogo. Mikrokontroler dawno powinien wyprzeć wszystko starszej generacji, a tu zonk. Znacząca część użytkowników jednak woli stare dobre mega8 czy 16. Ale dla nich ARM nie oferuje zupełnie nic czego pożądają. ARM ma przykładów całkiem przyzwoicie, ale ... dość często z wykorzystaniem np. SPL, mbed, arduino.

Cenowo i wydajnościowo - tutaj jest przepaść. Xmega nawet nie może marzyć o wydajności równych ceną ARM, a co najwyżej ma podobnej jakości peryferia (12bit adc 2msps).

Jeśli kolega się boi ARM (bo np. konfigurując od zera można się zaplątać), a jednocześnie i tak preferuje "gotowce" tj. soft z kompletną obsługą większości interfejsów i peryferiów - to nic tylko brać np. nucleo od STM - pisać można łatwo i przyjemnie w C++, a duży plik wynikowy i narzut procesora i tak znikną w możliwościach platformy (mam nucleo stm32f411re z 512KB flash i 128kb sram, max 100MHz - 40zł z hakiem za procek z wyprowadzeniami, dodatkowo programator z debuggerem i zintegrowanym virtual com). A do konkurowania z xplained są discovery - w równie dobrych cenach. Zatem dla kogoś kto jednak nie ma dużych wymagań xmega oferują parę ciekawostek, które warto przebadać, ale jeśli ktoś potrzebuje jednak wydajności to ARM będzie lepszym wyborem.

tronics wrote:

Dalej - przykłady - tutaj na Xmega jest naprawdę ubogo. Mikrokontroler dawno powinien wyprzeć wszystko starszej generacji, a tu zonk. Znacząca część użytkowników jednak woli stare dobre mega8 czy 16.

Oj, znowu trzeba dementować takie wnioski. Twój punkt widzenia jest obarczony ... Twoim punktem widzenia, a nie moim, czy milionów innych projektantów. Każdy mikrokontroler znajdzie nabywcę i zastosowanie co ładnie udowadnia rodzina 8051.

@arturromarr
Atmel także ma ARM-y: http://www.atmel.com/products/microcontrollers/arm/

Quote:

Twój punkt widzenia jest obarczony ... Twoim punktem widzenia, a nie moim, czy milionów innych projektantów

Nie sądzę by przeszkodą była cena, by przeszkodą było max 3.6Vcore, by przeszkodą były dodatkowe peryferia. Przeszkodą natomiast jest to, że trzeba od nowa peryferia oprogramować gdy do Atmegi było zilion przykładów na uarty, adc, spi, i2c czy nawet onewire z/bez przerwań. Jak dobrze poszukam to znajdę gotowce na xmega, ale nie jest tego tyle co gotowców dla atmega, arm czy nawet pic!

Dziękuję za Wasze opinie.
Nie mam tyle czasu na programowanie ile bym chciał (dom, rodzina wiadomo dlatego jak wezmę jakiś procek "na warsztat" to skupię się tylko na nim, dlatego zależy mi na właściwym wyborze.
Szkoda, że Xmegi zrobiły niewielki postęp bo myślałem, że będzie to najprostsza droga od ATmeg, ale jeśli zysku ma być niewiele to chyba lepiej jak sięgnę po army.
Myślałem o SMT32 bo w wielu miejscach je widzę, odnoszę wrażenie,że są popularne.
Podobało mi się to kiedyś w ATmegach , bo łatwo było o książki, przykłady, pomoc w internecie, czy na to samo można liczyć dziś w SMT32?

tronics wrote:

Quote:

Twój punkt widzenia jest obarczony ... Twoim punktem widzenia, a nie moim, czy milionów innych projektantów

Nie sądzę by przeszkodą była cena, by przeszkodą było max 3.6Vcore, by przeszkodą były dodatkowe peryferia. Przeszkodą natomiast jest to, że trzeba od nowa peryferia oprogramować gdy do Atmegi było zilion przykładów na uarty, adc, spi, i2c czy nawet onewire z/bez przerwań. Jak dobrze poszukam to znajdę gotowce na xmega, ale nie jest tego tyle co gotowców dla atmega, arm czy nawet pic!

To znowu jest Twój punkt widzenia. Ktoś inny ma zupełnie inny punkt widzenia i priorytety. Gdyby tak było jak z Twojego punktu widzenia, to nie powstawały by nowe rodziny żadnych mikrokontrolerów, także tych które wymieniłeś.

Cofnij się w czasie np. o 20 lat i powiedz to samo co powiedziałeś (bo przecież Twój pogląd jest ponad czasowy) i następnie popatrz jak się zmieniło do dnia dzisiejszego

arturromarr wrote:

Szkoda, że Xmegi zrobiły niewielki postęp bo myślałem, że będzie to najprostsza droga od ATmeg, ale jeśli zysku ma być niewiele to chyba lepiej jak sięgnę po army.

To nie tak, XMega wypełnia tylko lukę pomiędzy mega a ARM Atmela. W ten sposób producent daje szeroką gamę możliwości projektantom.

tronics wrote:

Nie. Xmega w obliczeniach nie jest szybsza niż stare AVR8.
...
Dalej - przykłady - tutaj na Xmega jest naprawdę ubogo.

Jeśli chodzi o szybkość rdzenia to jest dwukrotnie większa niż klasycznych AVR - co wynika z zegara 32MHz, a więc dwukrotnie wyższego niż ATMega8. Lecz główne przyśpieszenie wynika z peryferii, tak jak wspomniałeś - event system i DMA, oraz różnych wspomagaczy, np. modułu kryptograficznego, czy innej budowy portów IO, dzięki czemu operacja RMW na M8 to co najmniej 3 instrukcje, a XMEGA - jedna. Więc dostęp do IO potrafi być 3-krotnie szybszy i tyle samo krótszy. W efekcie w dobrze napisanych aplikacjach uzyskana realna wydajność jest znacznie większa. Przy obsłudze USART, SPI, ADC może być kilkakrotnie wyższa niż dla klasycznych AVR.
Co do przykładów, obecnie do każdego peryferium wygooglasz przykład dla XMEGA, pomijam moje ksiązki, ale mamy też dobry kurs na LeonInstruments, pełno przykładów w necie:
http://mikrokontrolery.blogspot.com/2011/02/wstep-do-mikrokontrolerow-xmega-spis-tresci.html
Nominalnie nie jest ich tak dużo jak np. dla M8, ale to wynika z tego, że np. stron poświęconych obsłudze ADC na XMEGA znajdziesz kilka, na M8 pewnie kilka tysięcy, tyle, że to będzie kilka tysięcy razy powielone to samo. Do tego jest ponad 2 tys. przykładów w samym Atmel Studio. Dla STM też nie ma aż tak wiele przykładów, które nie są oparte na firmowych bibliotekach. Dodatkowym problemem jest to, że są dziesiątki ARMów i każdy ma praktycznie zupełnie inne peryferia, a pomiędzy producentami różnice są tak kosmiczne, że zmiana producenta to praktycznie nauka od nowa. Bo akurat rdzeń pisząc w C nie ma żadnego znaczenia, ale sposób konfiguracji np. zegarów, peryferii, czy ogólnie dostępność peryferii jest zupełnie inna.

Co do pytania autora - wszystko zależy ile więcej potrzebujesz. Jeśli 2-4 razy więcej to XMEGA jest ok, jeśli to ma być zmiana jakościowa i np. chcesz się zająć analizą obrazu, współpracą z kamerą, zaawansowanymi algorytmami wymagającymi dużych mocy obliczeniowych to z pewnością ARM.
Posiadany przez ciebie JTAGICE nie zadziała, zresztą nie jest już nawet wspierany przez Atmel Studio, ale np. Atmel ICE:
http://mikrokontrolery.blogspot.com/2011/03/Programator-debugger-Atmel-ICE.html
jest ok, tani i fajny, współpracuje ze wszystkim prockami Atmela, łącznie z Atmelowskimi ARMami.
Niewątpliwie zaletą przesiadki na XMEGA jest to, że masz to samo środowisko i dużo rzeczy, które już znasz z AVR, dla ARM przesiadka będzie trwała dłużej, oczywiście jak pisałem szybkość przez nie oferowana też jest o wiele większa. Warto jednak pamiętać, że większa moc obliczeniowa to praktycznie jedyna zaleta mocniejszych mikrokontrolerów, peryferia są zupełnie podobne.

@tmf - zgadzam się z wszystkim co napisałeś, ale (powtórzę się jeszcze raz) - jeśli weźmiemy tanią platformę jak STM32F411RE Nucleo to w porównywalnej cenie nie znajdziesz nic wystarczająco uniwersalnego i mocnego w świecie 8bit. Sam zdziwiłem się, że ARM z takimi możliwościami może być TAK TANI.
@dondu

Quote:

To znowu jest Twój punkt widzenia. Ktoś inny ma zupełnie inny punkt widzenia i priorytety.

Prawda, niemniej nie licząc punktów które ja podałem - jakie Twoim zdaniem priorytety skutkują wyborem Attiny zamiast stm32 w tej samej obudowie? Albo np. atmega88 zamiast xmega32e5? Albo atmega1284 zamiast xmega128a1? Nie chcę zbytnio tutaj wdawać się w utarczki słowne, sam xmega używam, ale też widzę, że u mnie to bardziej przywiązanie do samego AVR, którego poznałem wcześniej niż ARM niż rzeczywista chłodna kalkulacja możliwości.

tronics wrote:

... jakie Twoim zdaniem priorytety skutkują wyborem Attiny zamiast stm32 w tej samej obudowie? Albo np. atmega88 zamiast xmega32e5? Albo atmega1284 zamiast xmega128a1?

Takie: http://mikrokontrolery.blogspot.com/2011/04/jaki-mikrokontroler-wybrac-do-projektu.html

tronics wrote:

Nie chcę zbytnio tutaj wdawać się w utarczki słowne, sam xmega używam, ale też widzę, że u mnie to bardziej przywiązanie do samego AVR, którego poznałem wcześniej niż ARM niż rzeczywista chłodna kalkulacja możliwości.

I to jest OK, ale nie można tego rozszerzać na wszystkich projektantów i ich projekty, i tylko o to mi chodziło

@Marek_Skalski Podałeś przykłady peryferii, które są istotne jeśli mamy dużo danych, czyli dużo obliczeń. I wtedy tak jak napisałem ARM jest ok. Po co mi USB HiSpeed jeśli przesyłam pojedyncze dane np. z czujników typu termometr, czy barometr? Podobnie to, że DMA kradnie cykle CPU też niekoniecznie musi być tragedią. Brak SHA1, czy innych funkcji skrótu też niekoniecznie jest problemem, bo zastosowania dla nich są dosyć specyficzne. Zdecydowanie częściej (a amatorsko i tak rzadko) zajdzie potrzeba szyfrowania przesyłanych danych a nie sprawdzania podpisów. 4 kanały enkoderów to też nie wszystkie ARMy mają, a XMEGA ma dwa a nie jeden. Podobnie jak ma komparator z programowanym napięciem odniesienia i dyskretnie programowalnym wzmocnieniu. Ale to wszystko nieistotne, bo ciągle jedyną istotną różnicą jest szybkość. Jak już kiedyś pisałem istotne są tylko te parametry, które wykorzystujemy w projekcie. Co mi z I2S jeśli nigdy nie miałem potrzeby wykorzystać ten interfejs?
Tak dla przypomnienia, to nie dyskusja o wyższości jednego nad drugim, lecz autor określił swoje wymagania i potrzeby. Skoro jak pisze nie ma za wiele czasu, to dla niego pewnie naistotniejszym argumentem przy wyborze platformy będzie właśnie czas potrzebny na jej opanowanie.

tronics wrote:

Jeśli kolega się boi ARM (bo np. konfigurując od zera można się zaplątać), a jednocześnie i tak preferuje "gotowce" tj. soft z kompletną obsługą większości interfejsów i peryferiów - to nic tylko brać np. nucleo od STM - pisać można łatwo i przyjemnie w C++, a duży plik wynikowy i narzut procesora i tak znikną w możliwościach platformy (mam nucleo stm32f411re z 512KB flash i 128kb sram, max 100MHz - 40zł z hakiem za procek z wyprowadzeniami, dodatkowo programator z debuggerem i zintegrowanym virtual com). A do konkurowania z xplained są discovery - w równie dobrych cenach. Zatem dla kogoś kto jednak nie ma dużych wymagań xmega oferują parę ciekawostek, które warto przebadać, ale jeśli ktoś potrzebuje jednak wydajności to ARM będzie lepszym wyborem.

Tu się nie zgodzę. Taktyka, typu odwalam kichę, bo procek jest szybki i mogę sobie na to pozwolić IMHO nie jest dobra. W końcu tej mocy ci zabraknie, albo będziesz tworzył rozwiązania wymagające 10x mocniejszego procka za wielokrotnie wyższą cenę. Ale co gorsze - zły program to zły program. Trzeba się poduczyć, a nie liczyć, że jakoś to będzie. Magiczny STM też wszystkiego nie załatwi - wymieniony przez ciebie stm32f411re kosztuje w farnellu 33 zł + VAT, to jaki jest sens go używać, jeśli np. 99% projektów na elce można zrobić na procku za 2-3 zł? Niekoniecznie AVR, bo tu zawsze BlueDraco wpada ze sławnym STM za 2zł Nie ma się co podniecać MHz'ami, setkami kB pamięci, lepiej jest się nauczyć programować tak, żeby nie były one potrzebne Przy okazji zapytam - co wy takiego robicie, że wam jest potrzebne 100 MHz i kilkaset kB RAM/FLASH? Marek to wiem co, ale on się zawodowo tym zajmuje.

Marek_Skalski wrote:

- interfejsy USB-OTG czy USB Hi-Speed. Za szybkie dla 8-bitowców.

Nie do końca to stwierdzenie jest prawdziwe FTDI rodzina FT51 stary poczciwy rdzeń 51 pogania aż miło z "USB2.0 Full-Speed/Low-Speed peripheral controller"
http://www.ftdichip.com/Products/ICs/FT51.html
http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT51.pdf

Marek_Skalski wrote:

A jeżeli przy okazji same układy są tańsze, to po co przepłacać?

No właśnie niekoniecznie. Jak kol. Albertb zauważył, jako argument na taniość ARM pokazuje się ARMy CM0, które głowy nie urywają. A już wspomniany powyżej STM kosztuje netto 33 zł, czyli jeśli ktoś naprawdę nie ma potrzeby go użyć, to taniej wyjdzie coś innego, chociażby CM0. Z kolei XMEGA ma peryferia bijące na głowę większość implementacji CM0+. A już napewno Atmelowskie SAM z CM0+. Za cenę 1/3 CM4 mamy w XMEGA praktycznie wszystkie peryferia lub nawet więcej niż w CM4, oczywiście ciągle przy ograniczonej prędkości co wynika z rdzenia. Dla porównania wspomniany wcześniej stm32f411re (33 zł netto) vs. XMEGA128A1U (12 zł):
- USB full speed/OTG -> USB full speed
- 6 timerów 16 bitowych + 2 32-bitowe -> 8 timerów 16 bitowych z możliwością dowolnego łączenia tworząc dłuższe,
- DMA 16 kanałów -> 4 kanały,
- USART - 3 (z IrDA) -> 8 (też z IrDA),
- SPI - do 5 SPI/I2S -> 8 SPI bez I2S,
- ADC 1x12 bit, 2,4 Msps -> 2x12-bit 2 Msps
- AES/DES/3DES - brak -> jest
- event system - brak -> 8 kanałów
- DAC - brak - > 2x 2-kanałowy 10-bitowy DAC
- zużycie prądu z trybie PD - do 30 uA -> do 1 uA,
- zużycie prądu dla RTC - do 12 uA -> do 2 uA

Jak widać to co będzie lepsze zależy od aplikacji.

Marek_Skalski wrote:

Zachwyt związany z zegarami i pamięcią ma swoje uzasadnienie. Jeżeli tylko ktoś chce wykorzystać uC w połączeniu z TFT, to bardzo szybko wychodzi brak pamięci albo ślamazarność 8-bitowców. Mając 32-bitowy rdzeń, 16 lub 32-bitową komunikację z zewnętrzną pamięcią i ew. bezpośredni interfejs do TFT, można robić dużo lepsze rzeczy. I nie zakładajmy z góry, że tylko nieliczni zrobili odtwarzacz multimedialny na prostym uC. Może właśnie ktoś potrzebuje tego impulsu do działania, prototypu, który w drodze ewolucji pozwoli zdobyć wiedzę, doświadczenie, może pracę, może własną firmę? A to tylko jedna z wielu możliwości.

Marku, obecnie za ułamek ceny i prosto kupuję FT801 lub FT813 (pojemnościowy TP), który ma sprzętową obsługę wszystkiego co związane z grafiką i pewnie tu bije na głowę nawet najbardziej wypasione ARMy. FT813 ma dodatkowo streaming video, czy sprzętową obsługę gestów na TP. Masz to wszystko z "pudełka" za parę złotych. Programowanie super - programujesz prawie jak pod OpenGL, prosty interfejs SPI/QSPI i każdy procek staje się demonem grafiki z niezłą oprawą multimedialną. Powiesz, że to wszystko możesz zrobić na wypasionym ARM - owszem, ale:
- wyjdzie to drożej,
- żaden rozsądny ARM nie ma tyle RAM, żeby pomieścić bufor ramki nawet dla LCD 320x240, czyli konieczność dodania zewnętrznej pamięci, wyboru procka z interfejsem do tej pamięci, w dodatku takiego, który będzie mógł jednocześnie sterować matrycą LCD,
- potrzebujesz kawał softu, a żeby go napisać musisz sporo wiedzieć o tworzeniu grafiki.
Obecnie jest co raz więcej specjalizowanych układów tego typu - kolejny przykład to np. popularny ESP8266. Potrzebujesz WiFi - masz je za $2. Przy wielu innych bardzo specjalistycznych rozwiązaniach też często prościej stosować dedykowane układy, np. dla wspomnianego USB OTG - FTDI VNC. Nie chodzi o to, żeby pokazać że coś jest lepsze niż inne, ale że mamy potężny wybór i to co jest najlepsze zależy od wielu okoliczności.

Marek_Skalski wrote:

Odpowiadając na pytanie STM32 vs Xmega --> STM32 (ST) lub SAM (Atmel). Tak czy inaczej, rdzeń ARM
@KeinXor
Nie chodzi o jakieś USB, ale o USB OTG, czyli możliwość pracy jako Device lub jako Host, w miarę możliwości z dynamiczną zmianą roli. Dlaczego? Podłączam urządzenie do PC i zgłasza się jako device (pamięć masowa + urządzenie audio + HID). Ale moje urządzenie może też działać jako host dla pamięci masowej i wtedy jest odtwarzaczem muzyki.
Inną sprawą jest prędkość łącza. LS i FS to dzisiaj nie problem, ale jeżeli chcę przesyłać obraz, to potrzebuję HS. Inaczej to tylko slide show.
Układy, które linkowałeś nie mają tego, a ponadto mają bardzo małe bufory danych: 504 bajty w trybie isochronous, to trochę dziwne, kiedy standard przewiduje max. 1023. Więc te urządzenia nie są w pełni zgodne ze specyfikacją USB 2.0.

Wszystko prawda, pokażesz na elce jakiś projekt tego typu? Ba, w Internecie? Dla 99,9% amatorów to o czym piszesz to kosmos.

tmf wrote:

Wszystko prawda, pokażesz na elce jakiś projekt tego typu?

Ludzie, którzy to robią, zajmują się robieniem, a nie pisaniem o tym

Ja w swojej karierze przerobiłem już od '51, przez AVR8, potem PIC24, dsPIC, następnie ARMy. I tak zostało. Nie ma za bardzo gdzie pójść.
Raczej nie w PIC32 - errata która potrafi osiągnąć rozmiar datasheeta (przynajmniej mnie) istotnie odstrasza.
Egzotyczne architektury typu ColdFire czy SuperH Renesasa są raczej niestrawne dla amatorów i półprofesjonalistów, i szczerze mówiąc, nie mają nic ciekawego na codzien potrzebnego, co by ARMy nie miały.
'51 to przeżytek - owszem, istnieją nowoczesne implementacje tego rdzenia, ale są one często propertiary. I pisanie na taki rdzen konczy się lock-in'em tak samo w kwestii procka, jak i kompilatora.
Z AVR sprawa wygląda podobnie. Nie dosyć że lock-in, to raczej niczym nie zadziwiają...

tmf wrote:

- USART - 3 (z IrDA) -> 8 (też z IrDA),
- SPI - do 5 SPI/I2S -> 8 SPI bez I2S,

...kto potrzebuje 8 UARTów? Bez ofensywy - ale jak wyobrażasz sobie obsługę wszystkich 8 jednocześnie na "tak wolnym" rdzeniu z sensownymi prędkościami? Więc generalnie, oprócz pewnej formy wygody ta niespotykana ilość wcale nie powala. 5 SPI generalnie nie ma sensu, po to jest CS, żeby SPI multipleksować. Rdzen i tak ma niewielkie szanse obsłużyć wszystkie jednocześnie. Ilość, jak wspomniałem wyżej, to tylko pewne udogodnienie ułatwiające pisanie kodu (i to też nie zawsze).
XMEGA może niby zawalczyć timerami, ADC i DAC. Ale... projektów zrobiłem multum, a taki DAC był potrzebny raz - chciałem lepszą jakość niż PWM ale gorszą niż 16/44k, do "pierdziafki" odtwarzającej MODy na plastikowym głośniczku.
ADC - jeden pies. Jak się chce bardzo duże rozdzielczości lub bardzo wysoki fs, i tak potrzeba zewnętrzny. Takie 12 bit @ 2Msps generalnie nie ma specyficznych zalet - do analogowego czujnika typu MCP7900 czy prostego VU-metru jest za dobry, do termopary za mała rozdzielczość, do oscyloskopu - za wolny; nawet do FFT audio - za mała rozdzielczość...
Za to i ten DAC, i ADC w tym procku aż się pcha do aplikacji SMPS. Tylko rdzeń trochę ślamazarny...

O co mi chodzi:
1) vendorzy pchają 2Msps ADC (i to jeszcze x2) do spółki z rdzeniem, który choćby bardzo chciał, jest za wolny żeby coś sensownego zrobić ze strumieniem 4 milionów próbek na sekundę...
2) vendorzy pchają wiele sztuk UARTów czy SPI do spółki z rdzeniem, j.w. Rozumiem jeszcze 3 lub 4, ale 8? Po co?...
3) Peryferia są na wyrost. F105 ma poważny problem z przepchnięciem (niemal) surowego ruchu z dwóch CANów 1Mbaud przez vendor specific klasę USB. Na szczęscie jednak można zwalić na przekombinowaną bibliotekę.

A i tak wszelkie rozważania kończymy stwierdzeniem, że do każdej aplikacji trzeba znaleźć pasującego procka. ARM czy AVR czy SuperH czy Blackfin - wszystko jedno, ważne do czego użyjesz. Migać LEDem potrafi każdy z nich, czy to MCU, czy DSP.

Ja robiłem tak - miałem zarys projektu, próbowałem oszacować co jest porzebne, i następnie tą architekturę zagłębiałem. ARMy na razie bezwzględnie wygrywają w kwestii stosunku czasu nauki do efektu koncowego, gdyż każdy Cortex-M jest generalnie taki sam. Te rdzenie są oparte o tą samą ideę i łatwo się między nimi przełączać, dodatkowo są setki ich implementacji z przeróznymi peryferiami.
Pokażcie jakąkolwiek inną architekturę na tyle kompatybilną w przód i w tył, będącą jednocześnie niezależną od vendora scalaka...

nsvinc wrote:

A i tak wszelkie rozważania kończymy stwierdzeniem, że do każdej aplikacji trzeba znaleźć pasującego procka.

... a jako argument to potwierdzający przykład PIC z Angular Timer, dedykowany na przykład do ... wyświetlaczy widmowych:




a do kompletu ma jeszcze:

Math Accelerator with Proportional-Integral-Derivative (PID):
- Four operation modes
- Add and multiply
- Simple multiplier
- Multiply and Accumulate
- Programmable PID controller

nsvinc wrote:

Raczej nie w PIC32 - errata która potrafi osiągnąć rozmiar datasheeta (przynajmniej mnie) istotnie odstrasza.
Egzotyczne architektury typu ColdFire czy SuperH Renesasa są raczej niestrawne dla amatorów i półprofesjonalistów, i szczerze mówiąc, nie mają nic ciekawego na codzien potrzebnego, co by ARMy nie miały.

Jedna istotna zaleta co do Renesasa to, że nie mają erraty albo mają bardzo minimalną (a przynajmniej tak się chwalą na organizowanych szkoleniach). Miałem przyjemność bawić się RX610 i powiem, że architekturą/możliwościami rdzenia, peryferami oraz trochę jakością bibliotek do procka to biją Cortexy M. Może nie na głowę, ale gdybym robił duży projekt od nowa to bym się nad tą firmą zastanowił. Ale tak jak mówisz trzeba znaleźć pasującego procka.

nsvinc wrote:

..kto potrzebuje 8 UARTów? Bez ofensywy - ale jak wyobrażasz sobie obsługę wszystkich 8 jednocześnie na "tak wolnym" rdzeniu z sensownymi prędkościami?
[ ... ]
5 SPI generalnie nie ma sensu, po to jest CS, żeby SPI multipleksować. Rdzen i tak ma niewielkie szanse obsłużyć wszystkie jednocześnie. Ilość, jak wspomniałem wyżej, to tylko pewne udogodnienie ułatwiające pisanie kodu (i to też nie zawsze).

Tu się z tobą nie zgodzę, szczególnie kiedy posiadasz do dyspozycji DMA. Gdyby wszystkie urządzenia z którymi się komunikujesz chodziły na tych samych ustawieniach prędkości, polaryzacjach zegara i bóg wie co jeszcze to fakt nie miałoby to większego sensu. Z moich obserwacji i eksperymentu wynika też, że mnożenie peryferiów ma na celu zmniejszenie użycia energii. Ustawiasz sobie 5 SPI w ustawienia jakie chcesz, ustawiasz DMA i rdzeń idzie spać. W dobie szału na wszelkiego rodzaju urządzenia zasilane bateryjnie to dla producentów i projektantów ma znaczenie.

nsvinc wrote:

1) vendorzy pchają 2Msps ADC (i to jeszcze x2) do spółki z rdzeniem, który choćby bardzo chciał, jest za wolny żeby coś sensownego zrobić ze strumieniem 4 milionów próbek na sekundę...

Po co to robią? Bo mogą niewielkim kosztem. Nikt nie zmusza cię do używania pełnej prędkości próbkowania. Mi się raz przydało - miałem mocno zaszumiony sygnał, który po ośmiokrotnym nadpróbkowaniu, filtracji i decymacji dostałem to co powinienem. AVR raczej by tego nie uniósł, ale na CM4 używając instrukcji (pseudo) DSP jeszcze miałem czas uśpić rdzeń pomiędzy dwoma przerwaniami od DMA.

BeginEnd wrote:

Jedna istotna zaleta co do Renesasa to, że nie mają erraty albo mają bardzo minimalną

Bo Renesas robi procki do automotivu i sterowania maszynami. Na błąd pozwolić sobie nie mogą... ECM w Skodach, VW i Audi stoi na Renesasie. Za to Mercedes juz pcha się w XC4 Infineona. A to juz ARM...

BeginEnd wrote:

Tu się z tobą nie zgodzę, szczególnie kiedy posiadasz do dyspozycji DMA. Gdyby wszystkie urządzenia z którymi się komunikujesz chodziły na tych samych ustawieniach prędkości, polaryzacjach zegara i bóg wie co jeszcze to fakt nie miałoby to większego sensu. Z moich obserwacji i eksperymentu wynika też, że mnożenie peryferiów ma na celu zmniejszenie użycia energii. Ustawiasz sobie 5 SPI w ustawienia jakie chcesz, ustawiasz DMA i rdzeń idzie spać. W dobie szału na wszelkiego rodzaju urządzenia zasilane bateryjnie to dla producentów i projektantów ma znaczenie.

Nie wątpię że nie ma. Ale wszystkie peryferia, które będziesz potencjalnie obsługiwać, to slave. Za to wypluwają one przewaznie sygnał potrafiący obudzić procka. Nie spotkałem się jeszcze z układem, który (oprócz celowych implementacji) byłby masterem dla mcu...

BeginEnd wrote:

Po co to robią? Bo mogą niewielkim kosztem. Nikt nie zmusza cię do używania pełnej prędkości próbkowania. Mi się raz przydało - miałem mocno zaszumiony sygnał, który po ośmiokrotnym nadpróbkowaniu, filtracji i decymacji dostałem to co powinienem. AVR raczej by tego nie uniósł, ale na CM4 używając instrukcji (pseudo) DSP jeszcze miałem czas uśpić rdzeń pomiędzy dwoma przerwaniami od DMA.

I najpewniej nikt tego nie robi, w tym ja, bo w większości zastosowań wysiłek nie przynosi profitów. Ja w swoich projektach gdzie znany jest baseband nawet nie stosuje zewnetrznych filtrów antialias tylko przepuszczam przez średnią kroczącą (i dobieram jej dlugosc) potem dopiero obrabiam dane. Kompensację wzmocnienia i fazy znacznie łatwiej dobrać jeśli analizowany sygnał został wygładzony i nie zawiera ostrych zboczy.

dondu wrote:

a jako argument to potwierdzający przykład PIC z Angular Timer, dedykowany na przykład do ... wyświetlaczy widmowych:

To samo potrafiłby LPC812. Przy znacznie szybszym zegarze, jednak zużywając porównywalną ilość mocy. Zdaję sobie sprawę z przewagi dedykowanego krzemu nad mcu, bo tego przeskoczyć się nie da. Nie zmienia to faktu, że wspominiana 812-tka @12MHz potrafi to samo...

P.S.
I pomóżcie mi z tym Kinetisem, bo zaczynam wątpić. Jeszcze nie wiem w co. Skrzynka piwa temu, kto to rozkmini...

nsvinc wrote:

dondu wrote:

a jako argument to potwierdzający przykład PIC z Angular Timer, dedykowany na przykład do ... wyświetlaczy widmowych:

To samo potrafiłby LPC812. Przy znacznie szybszym zegarze, jednak zużywając porównywalną ilość mocy. Zdaję sobie sprawę z przewagi dedykowanego krzemu nad mcu, bo tego przeskoczyć się nie da. Nie zmienia to faktu, że wspominiana 812-tka @12MHz potrafi to samo...

To samo zrobię na ATmeg8
Podałem tylko przykład potwierdzający część Twojej wypowiedzi.


3 lipca dostałem mail z Atmela z takim dokumentem:

Microprocessor (MPU) or Microcontroller (MCU)?
What factors should you consider when selecting the right processing device for your next design.

a rozpoczyna się od zdania:

Atmel wrote:

Selecting the right device on which to base your new design can be daunting.

dondu wrote:

To samo zrobię na ATmeg8

To samo zrobiłbyś na '51 albo 6086. Tylko jakość tego, co byś wyświetlał (zakładając dobry kod) rósłby wykładniczo ze wzrostem dostępnej mocy obliczeniowej i szerokości słowa. A jakbyś jeszcze dostał dużo RAMu i FPU, to już w ogóle mógłbyś zrobić billboard 3x3 metry z 'impressive' rozdzielczością i ostrością obrazu (bez kpiny!) w full color. Tylko potega rdzenia byłaby czynnikiem, który to umożliwia.

Napiszę po raz drugi:

dondu wrote:

Podałem tylko przykład potwierdzający część Twojej wypowiedzi.

Quote:

Tylko potega rdzenia byłaby czynnikiem, który to umożliwia.

Tak, tmf oczywiście w przypadku porównania peryferiów pominął to co także może się liczyć:
natywne wsparcie dla integer (32bit)
instrukcje dsp-like
sprzętowe fpu (nie trzeba kombinować z protezami fixed point czy żmudnym skalowaniem)
To choćby na początek obrazuje co mocniejszy rdzeń potrafi dla programisty dobrego przynieść.

Quote:

Tu się nie zgodzę. Taktyka, typu odwalam kichę, bo procek jest szybki i mogę sobie na to pozwolić IMHO nie jest dobra.

Nigdzie nie napisałem, że jest to dobre. Ale warto zauważyć, że rzesza hobbystów to nie koderzy z zawodu (czy jak kto woli powołania) - nie każdy zna się na procesie kompilacji, nie każdy potrafi optymalizować kod. Ale każdy chce osiągnąć jakiś swój cel. Chciałem wypróbować moje nucleo 411 (za całe 44zł brutto czyli 11zł kosztował mnie wbudowany ST-Link -programator, debugger i vcom + PCB) - napisałem krótki program w mbed do obsługi czujnika TH02 na I2C przekazujący wyniki na UART (wbudowany virtual com). Po skompilowaniu kilkunastu linijek kodu otrzymałem plik wynikowy o rozmiarze 21KB (tyle flasha to zżera) i bodajże użyciu 128B RAM. Zatem z punktu widzenia programisty jest to dużo, niepotrzebnie dużo. Z punktu widzenia AVRowca jest to tragicznie dużo! Ale teraz z punktu widzenia hobbysty, który pisze w C++ ale w trybie "bascom like" czyli z wszystkim co niezbędne uproszczonym na max i wyciągniętym do użytkownika - rewelacja. Działa i nie zużywa więcej niż 4% procesora (a gdzie tam wykorzystanie DMA!) bez potrzeby linkowania nie wiadomo jakich nagłówków, plików startowych, konfiguracji kompilera, loadera, etc. etc. Ludzie są wygodni i jeśli mogą coś dużo szybciej, dużo łatwiej, z niewiele wyższym kosztem to takie rozwiązanie wybiorą, a hobbystom nikt nie płaci. Nam płacą by szukać lepszych rozwiązań, takich które w setkach tysięcy sztuk przyniosą konkretne oszczędności. Ot taka delikatna różnica. Czasem warto zrozumieć też i drugą stronę, choćby po to żeby zobaczyć jak nieefektywnie używane narzędzia potrafią działać.

To ja przekornie ciut napiszę:

Główny wybór, jakiego trzeba dokonać, i który dla mnie jest oczywisty, to szerokość procesora. Do wiŁkszości zastosowań trzeba mieć 32 bity - i to jednoznacznie eliminuje AVR, XMEGA, 51 i wąskie PICe. Oczywiście znajdzie się kilka aplikacji, gdzie 8 bitów wystaczy, np. jeśli tylko migamy diodami, nic nie liczymy i nie używamy ADC. Znajdzie się też parę zastosowań, gdzie wystarczy 16 bitów - jeśli wystarczy 32 K pamięci.

Jeśli jednak w większości zastosowań potrzebujemy czegoś z tego: pamięci >32 K, ADC, obliczeń na > 16 bitach - to i tak musimy wejść w 32 bity, a wtedy robienie mniejszych projektów na innej architekturze, które wcale nie jest tańsza, po prostu nie ma sensu.

ARM jest wyborem sensownym ze względu na popularność. Przesiadka z ARM na dowolną inną architekturę 32-bitową jest bezbolesna, bo i tak programujemy w C, a z kolei rzesiadka na innego producenta jest zawsze bolesna, bo każdy producent ma inne peryferia.

Ważne jest również to, że 32-bitowce są przyjazne dla kompilatorów, a 8-bitowce na ogół nie są. SKutek tego jest taki, że różnica wydajności przy takiej samej częstotliwości zegara może sięgać nawet kiludziesięciu razy na korzyść 32-bitowca, bo w celu samego załadowania dwóch zmiennych z pamięci do rejestrów musimy użyć np. 20 instrukcji zamiast 2.

A STM32F411 po wakacjach będzie miał jeszcze jedną nową odsłonę w Polsce - coś w sam raz dla hobbystów i początkujących, jeszcze milsze w kontakcie niż NUCLEO.

nsvinc wrote:

tmf wrote:

- USART - 3 (z IrDA) -> 8 (też z IrDA),
- SPI - do 5 SPI/I2S -> 8 SPI bez I2S,

...kto potrzebuje 8 UARTów? Bez ofensywy - ale jak wyobrażasz sobie obsługę wszystkich 8 jednocześnie na "tak wolnym" rdzeniu z sensownymi prędkościami? Więc generalnie, oprócz pewnej formy wygody ta niespotykana ilość wcale nie powala. 5 SPI generalnie nie ma sensu, po to jest CS, żeby SPI multipleksować. Rdzen i tak ma niewielkie szanse obsłużyć wszystkie jednocześnie. Ilość, jak wspomniałem wyżej, to tylko pewne udogodnienie ułatwiające pisanie kodu (i to też nie zawsze).
XMEGA może niby zawalczyć timerami, ADC i DAC. Ale... projektów zrobiłem multum, a taki DAC był potrzebny raz - chciałem lepszą jakość niż PWM ale gorszą niż 16/44k, do "pierdziafki" odtwarzającej MODy na plastikowym głośniczku.
ADC - jeden pies. Jak się chce bardzo duże rozdzielczości lub bardzo wysoki fs, i tak potrzeba zewnętrzny. Takie 12 bit @ 2Msps generalnie nie ma specyficznych zalet - do analogowego czujnika typu MCP7900 czy prostego VU-metru jest za dobry, do termopary za mała rozdzielczość, do oscyloskopu - za wolny; nawet do FFT audio - za mała rozdzielczość...
Za to i ten DAC, i ADC w tym procku aż się pcha do aplikacji SMPS. Tylko rdzeń trochę ślamazarny...

O co mi chodzi:
1) vendorzy pchają 2Msps ADC (i to jeszcze x2) do spółki z rdzeniem, który choćby bardzo chciał, jest za wolny żeby coś sensownego zrobić ze strumieniem 4 milionów próbek na sekundę...
2) vendorzy pchają wiele sztuk UARTów czy SPI do spółki z rdzeniem, j.w. Rozumiem jeszcze 3 lub 4, ale 8? Po co?...
3) Peryferia są na wyrost. F105 ma poważny problem z przepchnięciem (niemal) surowego ruchu z dwóch CANów 1Mbaud przez vendor specific klasę USB. Na szczęscie jednak można zwalić na przekombinowaną bibliotekę.

Nie twierdzę, że 8 USART to lepiej niż 3 USART To tylko było porównanie, że za niższą cenę możemy mieć mniej więcej takie same peryferia - a propos, że ARMy są zawsze tańsze... nie są. Ja wykorzystuję w projektach zwykle 3-4 USART lub 2-3 jeśli mam USB. Do sterowania np. WS2812, 1-wire itd. W XMEGA narobili tyle peryferii ze względu na sprytny pomysł - żeby na każdym porcie były dostępne te same peryferia, co ułatwia programowanie i routing PCB.

nsvinc wrote:

A i tak wszelkie rozważania kończymy stwierdzeniem, że do każdej aplikacji trzeba znaleźć pasującego procka. ARM czy AVR czy SuperH czy Blackfin - wszystko jedno, ważne do czego użyjesz. Migać LEDem potrafi każdy z nich, czy to MCU, czy DSP.

Święte słowa. Jakby mi się to zmieściło to bym umieścił w podpisie.

Dodano po 3 [minuty]:

tronics wrote:

Quote:

Tylko potega rdzenia byłaby czynnikiem, który to umożliwia.

Tak, tmf oczywiście w przypadku porównania peryferiów pominął to co także może się liczyć:
natywne wsparcie dla integer (32bit)
instrukcje dsp-like
sprzętowe fpu (nie trzeba kombinować z protezami fixed point czy żmudnym skalowaniem)
To choćby na początek obrazuje co mocniejszy rdzeń potrafi dla programisty dobrego przynieść.

Sam rdzeń nic ci nie przyniesie. Z tego wszystkiego trzeba umieć korzystać i mieć potrzebę korzystać. Miganie diodami, czy sterowanie przekaźnikami dosyć typowe na elce nie wymaga 32-bitów. Ba, w swoich książkach pokazałem grubo ponad setkę różnych projektów, w żadnym nie tylko nie były potrzebne 32-bity (co oczywiste, bo ich nie było), ale nawet nie było potrzebne taktowanie 32 MHz. W 95% robiłem to na taktowaniu domyślnym 2 MHz. Ludzie myślą, że jak kupią sobie wypaśny MCU to od razu będą robić lepsze projekty. A to bzdura.

Dodano po 2 [minuty]:

@BlueDraco Kiedyś już o to pytałem, ale jeszcze raz - wymień mi te projekty, które na dzień dobry wymagają 32-bitów? Tylko nie pisz o łaziku marsjańskim Jak patrzę na projekty w DIY to żaden nie wymaga nic ponad '51. Z czegoś co by wymagało większej mocy to może jakaś analiza obrazu, tyle, że kto na elce potrafiłby to ogarnąć od strony algorytmów?

Te 32 bity to w małych projektach wygoda, w dużych - konieczność. Głupia średnia krocząca o głębokości 16 przy 12bit próbkach wymaga akumulatora 16bit. Szybka zamiana wartości z ADC na mV (bez dziwnego dzielenia i floatów) wymaga już więcej (dla Vref=3300 masz (3300*adc_val)>>adc_bits, wykonanie mnożenia wymaga juz 24 bitów). Łatwo się przyzwyczaja do 32 bitów, widzę po sobie; 99% tego co bym chciał policzyć, mieści się. W przypadku 8 czy 16bitowców nad każdym obliczeniem trzeba pokminić, ile bitów potrzeba...

tmf wrote:

W 95% robiłem to na taktowaniu domyślnym 2 MHz.

Oczywiście. Połowa moich projektów chodzi na kilku MHz bo więcej nie potrzeba. Jednak warto zauważyć, że to, co CM0 zrobi przy 1MHz, w przypadku 8bitowca będzie wymagało wielokrotnie szybszego zegara (mam na myśli sensowną funkcjonalność, a nie zegarek z wyświetlaczem 2x16). Potwierdza to stwierdzenie:

BlueDraco wrote:

Ważne jest również to, że 32-bitowce są przyjazne dla kompilatorów, a 8-bitowce na ogół nie są.

tmf wrote:

Z czegoś co by wymagało większej mocy to może jakaś analiza obrazu, tyle, że kto na elce potrafiłby to ogarnąć od strony algorytmów?

Analiza czegokolwiek wymaga mocy. Z przetwarzaniem danych z czujnika PIR w celu rozpoznania wielkości i prędkości ruchu obiektu, LPC11xx radził sobie z trudem.
Również jakiekolwiek sieci neuronowe na 8bitach to pomyłka...

BlueDraco wrote:

przesiadka na innego producenta jest zawsze bolesna, bo każdy producent ma inne peryferia.

Raczej nie bolesna, jeśli czyta się manuale, a nie korzysta z bibliotek vendora. Ostatnio przesiałem się na Kinetis L02 i w kilka godzin procek wstał (pomijam tu osobliwości których cięzko się spodziewać). Wcale nie jest cięzko.
Generalnie każdy UART, SPI, czy timer chodzi tak samo, bo zawsze do tego samego służy. Gorzej z USB, CAN czy Eth - tu każdy vendor kombinuje po swojemu, i tak jak odpalić UART na nowym procku to 15min czytania i 5min pisania, tak uruchomienie USB to cały dzień...

nsvinc wrote:

Te 32 bity to w małych projektach wygoda, w dużych - konieczność. Głupia średnia krocząca o głębokości 16 przy 12bit próbkach wymaga akumulatora 16bit. Szybka zamiana wartości z ADC na mV (bez dziwnego dzielenia i floatów) wymaga już więcej (dla Vref=3300 masz (3300*adc_val)>>adc_bits, wykonanie mnożenia wymaga juz 24 bitów). Łatwo się przyzwyczaja do 32 bitów, widzę po sobie; 99% tego co bym chciał policzyć, mieści się. W przypadku 8 czy 16bitowców nad każdym obliczeniem trzeba pokminić, ile bitów potrzeba...

Niektóre procki mają sprzętowe ułatwienia w tym celu, np. XMEGA E5 ma sprzętową decymację i uśrednianie wyników z ADC. Z drugiej strony jak sobie bierzesz nietypowe napięcie referencyjne (3300 mV), to potem masz problemy obliczeniowe. Wziąłbyś np. 2048 mV (dla 12-bitowego ADC) i wszystko ogranicza się do przesuwania bitów.

nsvinc wrote:

tmf wrote:

W 95% robiłem to na taktowaniu domyślnym 2 MHz.

Oczywiście. Połowa moich projektów chodzi na kilku MHz bo więcej nie potrzeba. Jednak warto zauważyć, że to, co CM0 zrobi przy 1MHz, w przypadku 8bitowca będzie wymagało wielokrotnie szybszego zegara (mam na myśli sensowną funkcjonalność, a nie zegarek z wyświetlaczem 2x16). Potwierdza to stwierdzenie:

BlueDraco wrote:

Ważne jest również to, że 32-bitowce są przyjazne dla kompilatorów, a 8-bitowce na ogół nie są.

tmf wrote:

Z czegoś co by wymagało większej mocy to może jakaś analiza obrazu, tyle, że kto na elce potrafiłby to ogarnąć od strony algorytmów?

Analiza czegokolwiek wymaga mocy. Z przetwarzaniem danych z czujnika PIR w celu rozpoznania wielkości i prędkości ruchu obiektu, LPC11xx radził sobie z trudem.
Również jakiekolwiek sieci neuronowe na 8bitach to pomyłka...

Skoro jak piszesz, połowa projektów chodzi na kilku MHz, to znaczy, że chodziłaby by też na odpowiednio taktowanym 8-bitowcu. Oczywiście wygodniej jest mieć 32-bity, ale nie jest tak, że jest to warunek konieczny.

nsvinc wrote:

BlueDraco wrote:

przesiadka na innego producenta jest zawsze bolesna, bo każdy producent ma inne peryferia.

Raczej nie bolesna, jeśli czyta się manuale, a nie korzysta z bibliotek vendora. Ostatnio przesiałem się na Kinetis L02 i w kilka godzin procek wstał (pomijam tu osobliwości których cięzko się spodziewać). Wcale nie jest cięzko.
Generalnie każdy UART, SPI, czy timer chodzi tak samo, bo zawsze do tego samego służy. Gorzej z USB, CAN czy Eth - tu każdy vendor kombinuje po swojemu, i tak jak odpalić UART na nowym procku to 15min czytania i 5min pisania, tak uruchomienie USB to cały dzień...

Tu się niezgodzę. Przesiadka potrafi być bolesna. Oczywiście nie chodzi o typowe, proste wykorzystanie peryferii, chociaż zmiana w kodzie jakiegoś testowania flag i takich dupereli jest wrażliwa na błędy i czasochłonna. Ale jeszcze gorzej jeśli nietypowo coś wykorzystujesz - np. na XMEGA robię USART z wired-AND z wyjścia timera, dzięki czemu uzyskuję przebieg do sterowania nadajnikiem, przesiadam się na SAM D21, który z jakiegoś magicznego powodu nie ma możliwości konfiguracji IO w wired-AND i mam kaplicę.

Quote:

Sam rdzeń nic ci nie przyniesie. Z tego wszystkiego trzeba umieć korzystać i mieć potrzebę korzystać. Miganie diodami, czy sterowanie przekaźnikami dosyć typowe na elce nie wymaga 32-bitów.

To co piszesz jest prawdziwe, z tym, że zawsze kryje się pewne "ale"
A tu są conajmniej 2:
"ale nic nie stoi na przeszkodzie by przygodę z programowaniem zacząć od migania ledem na 32bit MCU"
oraz
"ale gdy apetyt wzrośnie 8bit zacznie niewyrabiać wcześniej niż 32bit".
Szczerze jeszcze nie dobiłem do limitu 8bit, bo też zajmuję się tym tylko dorywczo, ale z drugiej strony dobrze jest wiedzieć jakie się ma opcje.