tmf napisał: 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 napisał: - 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...
0
