Newsgroup: it.hobby.elettronica.digitale
Titolo: micro arm

Salve!
Mi domandavo se puo' avere senso usare in una applicazione dove tutto 
funziona regolarmente con un normale microcontrollore ad 8 bit della 
microchip usare al suoposto un processore con archittettura ARM, insomma 
vorrei capire quando conviene usare un micro a 16 bit invece di uno ad 8 
oppure usare come detto prima processori ARM 

Enzo ha scritto:

Su progetti nuovi io valuterei per bene la possibilità di utilizzare almeno un 
ARM7 che costano ormai veramente poco. Certo è che se la tua applicazione è 
molto semplice, potresti rimanere ad 8 bit, ma l'ARM ti permette una 
flessibilità non paragonabile.
A quanto mi risulta, i micro a 16 bit sono destinati a morire presto.
Tieni presente che esiste anche una famiglia della Freescale molto reclamizzata 
ultimamente, dovrebbe chiamarsi Flexis o qualcosa del genere, che ha micro a 8 e 
32 bit perfettamente compatibili tra loro, quindi puoi iniziare la tua 
applicazione a 8 bit ed eventualmente estenderla con un micro a 32 bit. Comunque 
non è un ARM.
Quando conviene passare ad un micro a 32 bit ed abbandonare quelli ad 8 bit?
Sicuramente quando hai bisogno di un sistema operativo (per esempio, per gestire 
uno stack completo TCP/IP oppure filesystem con tutta semplicità).

 microchip usare al suoposto un processore con archittettura ARM
ha senso eccome !
però devo premettere che la definizione di micro "normale" è
artificiosa: prendi un chip a cui hai bruciato lo stadio analogico di
ingresso degli AD... bè, non è detto che quel micro  riesca comunque a
svolgere bene gli altri compiti, conteggiare gli impulsi, sommare i
registri, mandare a memoria le locazioni.
Sono in atto grandi sforzi per integrare questi micro diversamente
abili nelle applicazioni più disparate: apricancello, antifurto moto,
contatempo per partite di squash, lettori mp3, pure.
Comunque, tornando intopic, se vuoi portare la tua applicazione da un
8 bit ad un ARM, non vedo particolari problemi. Prevedi solo una
learning curve adeguata, che comunque può essere significativamente
ridotta leggendo i manuali. Io mi premunirei anche di un paio di
barattoli di crema Glisolid: la programmazione degli ARM richiede
esercizio, polpastrelli sensibili e almeno 350 messaggi al gruppo.
Saluti,
simone.bern

esercizio, polpastrelli sensibili e almeno 350 messaggi al gruppo.
Non si programmano in-circuit con interfacce di tipo Jtag? 

 semplicità).
non solo. Puo' essere conveniente la' dove devi fare qualche applicazione
semplice ma magari e' necessario fare un po' di conti o si necessita di 
qualche
prestazione maggiore...
brix

 gestire uno stack completo TCP/IP oppure filesystem con tutta semplicità).
Sono pienamente d'accordo, è il caso più comune.
Ci sono poi applicazioni dove magari non è fondamentale l'interfaccia di
comunicazione, ma magari il sistema deve avere una responsività maggiore, alte
prestazioni su più processi concorrenti, ed allora anche un RTOS può avere
vantaggio dal microcontrollore più potente.
Così anche tutte quelle applicazioni che per il /number crunching/ diventano
troppo laboriose su un 8 bit.
~ Lou

 qualche prestazione maggiore...
Beh, sicuramente sì, anche se lui ci sguazza bene con l'8 bit, quindi non penso 
avrà queste grandi esigenze computazionali.

 che una rivoluzione nel design.
Perfettamente d'accordo... come dicevo nell'altro post l'ho citata solo per 
completezza.

E' un evidente recupero di un progetto male ingegnerizzato dallo sviluppatore.
Non solo questo.
Potrebbe anche consentire delle successive evoluzoni del software senza dover
fare nuovi investimenti sull'hardware.
Oppure consentire lo sviluppo di un unico hw nel quale si possono usare i due
cores a seconda del tipo di applicazione.
Insomma io non la vedo così male questa possibilità.
Vedo molto peggio altri aspetti come il costo dell'ambiente di sviluppo, per il
quale non credo che userò mai Freescale.
--
ciao
  Stefano

 quale non credo che userò mai Freescale.
Nota che in fondo può essere solo un limite di applicazione.
Se usi le parti fino a 32 kiB, insieme all'ambiente di sviluppo gratuito,
potresti essere ben felice così. E come dicevo, è un ottimo ambiente di
sviluppo, per chi ama gli ambienti molto integrati e automatizzati (vedi ad
esempio anche quelli di Cypress) -- io preferisco ancora i Makefile, pensa un po'.
~ Lou

 penso avrà queste grandi esigenze computazionali.
A meno che non voglia testare una CPU piu' pontente ;-)
Brix

 Se la CPU ha una MMU, potrebbe anche girarci, ma qui Linux e' meglio.
Allora ricordavo bene, uClinux è nato sui Freescale. Quindi esiste anche tutta 
la toolchain GNU per questi processori.
Non direi che il supporto è proprio scarso...