Piattaforma a microcontrollore di EY.

[TardoFreak]

E' possibile utilizzarlo anche sul PIC32.
Ecco, se si ha intenzione di utilizzare un RTOS ha senso avere una macchina potente!

Se non ricordo male qualche utente di EY l' ha già sperimentato sui PIC32.

[simo85]

Se non ricordo male qualche utente di EY l' ha già sperimentato sui PIC32.

In tal caso meglio, così tra una conoscenza e l'altra, la piattaforma diventa più bella e si imparano cose nuove.

Come al solito, l'unione fa la forza. :)

[TardoFreak]

Ho aggiunto il sondaggio, votate numerosi e, se vi piace, motivate anche la vostra scelta.

Io ho scelto PIC32 per i motivi esposti prima.

[fairyvilje]

Perché non una FPGA? Secondo me sarebbe una buona palestra per chi (io XD) vuole imparare il VHDL

[GuidoB]

Io ho votato ARM Cortex M3 perché leggendo tanti interventi è quello che sembra avere il futuro più roseo. L'architettura ARM certo è complessa ma è potente, molto diffusa e prodotta da tante Case. È utilizzata per gli usi più disparati (inclusi molti smartphone per esempio), i chip sono economici, ben supportati da molti tool e presumibilmente resteranno disponibili per molti anni.
Quindi investire nella conoscenza degli ARM mi sembra particolarmente vantaggioso.

I PIC32 invece non li conosco, non ho elementi per giudicarli.

Direi comunque di stare sui 32 bit e macchine veloci.
Per la decisione finale mi rimetto all'esperienza di TardoFreak .

[GuidoB]

Ho fatto un giro in rete per vedere che schede similari offre il mercato. Questo serve anche per ispirarsi sulle soluzioni e tool da adottare. Ho trovato:

Maple (in tre versioni: normale, Mini e Native) e Oak, che montano un ARM Cortex M3 (STM32). Oak, in particolare, monta anche una FPGA Xilinx, che come dice fairyvilje potrebbe essere utile per imparare il VHDL. Penso comunque che una FPGA si possa aggiungere in una scheda di espansione.
Maple normale (e credo anche Maple Native) hanno dei connettori con disposizione che li rende collegabili alle espansioni (dette "shields") di Arduino. Questa compatibilità può essere comoda per aggiungere e testare rapidamente alcune funzionalità con hardware già disponibile.

Comunque, volendo la compatibilità con gli shields Arduino, non è necessario averne i pin sulla scheda del micro, ma si può sempre fare una scheda adattatore e collegarla sul bus.

Ci sono altre schede "compatibili Arduino" a 32 bit:
Arduino Due, basato su ARM Cortex M3 (Atmel SAM3),
vari chipKIT della Microchip basati su PIC32 (i prezzi sono qui).

Armadillo monta un ARM Cortex M3 (Atmel AT91SAM9263). Dalla web sembra un progetto vecchio di un paio d'anni e abbandonato.
Usa due doppie file laterali di connettori "densi" (passo 1,27 mm) per un totale di 120 pin.

Questo mi ispira una breve digressione "meccanica":
l'avere due file laterali di connettori permette un collegamento elettrico e anche un fissaggio meccanico stabile, adottato anche da Arduino, però limita il layout e possibilmente anche le possibilità di "crescita" delle schede (in altezza dei componenti e nel numero di schede). Forse è meglio tenere separato il collegamento meccanico da quello elettrico.
Con opportuni fori nei quattro angoli della scheda del micro, e fori corrispondenti nelle schede di espansione, si possono inserire lunghe viti con tubetti distanziatori per fissare in modo solido il tutto. Eventualmente con schede grandi si possono fare fori ogni tot millimetri e mantenere un certo "standard" per il collegamento meccanico tra le schede.

Una volta che le schede sono meccanicamente collegate e distanziate di quanto serve (dipendendo dall'altezza dei componenti), il bus di collegamento si può fare (in alternativa a una scheda rigida) con una piattina (flat cable) con fissati i connettori ogni tot, e si ha anche più libertà nel distanziare più o meno e posizionare le schede.
Mi rimetto però all'esperienza di chi ci lavora per decidere su questo fissaggio meccanico, che comunque non è incompatibile con altri metodi (es: si sviluppa con schede connesse elettricamente e meccanicamente da un bus rigido (back panel), e quando la realizzazione è definitiva si sostituisce il back panel con flat cable e viti per maggior compattezza e solidità).

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

Ho trovato poi altre schede, che però esulano un po' da questo tipo di progetto, e accettano monitor video, tastiera USB, una anche il mouse: DuinoMite (con connettori Arduino, basato su PIC32, programmabile in Basic - ma non è ancora defunto? - e C) e Raspberry Pi (basato su ARM11, con Linux, programmabile in Python e altri linguaggi).

[GuidoB]

se si potesse usare FreeRTOS non penso sia una cattiva idea
...
Cosa ne pensate?

Ho cercato in rete e ho trovato una lista impressionante di sistemi operativi in tempo reale. Anche escludendo tutti quelli non-free e che supportano poche architetture, solo per controllare i più interessanti ci vuole un bel po' di tempo.

Allora ho dato un'occhiata solo a FreeRTOS e mi sembra molto ben fatto e con licenza adatta a usi professionali a codice chiuso (non è obbligatorio rivelare i sorgenti del proprio codice), ma ovviamente bisognerebbe approfondire. Ha anche degli "hook" per agganciare macro di tracciamento se necessario.

dimaios, che l'ha usato sia su ARM Cortex M3 (STM32) che su PIC32, forse può darci un parere .

[dimaios]

La scelta che ho fatto riguardo l' STM32F4 era dovuta alla potenza di calcolo necessaria per implementare un controllore multivariabile utilizzando floating point ad alte prestazioni. Quando ho acquistato la Discovery per fare qualche esperimento preliminare il microcontrollore in oggetto era il piu' veloce della categoria sul mercato ed esponeva un gran numero di interfacce di comunicazione ( altra specifica da soddisfare nel progetto ).

Secondo me il primo punto da sviluppare e' la compilazione di una specifica tecnica ove vengono indicate tutte le necessita'.
Una volta redatto questo documento la scelta dei componenti si riconduce ad un' analisi di quanto offre il mercato.

In pratica procederei cercando di rispondere alle seguenti domande ( e' solo un esempio ... ).

[1] Scopo del progetto ( automazione, audio, didattico, ecc. )
[2] Punti di estendibilita'
[3] Potenza di calcolo ( virgola fissa e mobile )
[4] Proprieta' I/O digitale ( tensioni, correnti , numero I/O , protezioni ecc. ).
[5] Proprieta' I/O analogico ( tensioni, correnti, risoluzione, periodo campionamento, parallelismo ecc. )
[6] Canali di comunicazione ( RS232, RS485, CAN , Ethernet ecc )
[7] Tools e linguaggi di programmazione ( costi e funzionalita' richieste soprattutto per il debug )
[8] Costo interfaccia di programmazione
[9] Necessita' di caricare un sistema operativo realtime.
[10] Reperibilita' dei componenti ( previsione del tempo di obsolescenza )
[11] Costo totale dell' hardware con split delle varie sezioni.
[12] Stima dei costi per realizzare le schede complete a livello di prototipo ed in serie
[13] Strategia di sviluppo della scheda
[14] Individuazione ed assegnazione dei compiti per la realizzazione
ecc.

Parlare dei microcontrollori senza un obiettivo comune secondo me rischia di essere molto dispersivo. Infatti in base all' esperienza ognuno propone ( in buona fede ) quanto conosce e alla fine non si riesce a concretizzare un' idea comune che a mio avviso dovrebbe essere la finalita' del progetto e non l' hardware o il software con cui viene realizzato.

Il punto di partenza di ogni progetto e' la condivisione dell'obiettivo ovvero qual'e' il problema ( o l'insieme del problemi ) da risolvere e con che vincoli . Consiglio di non eludere questa regola che si e' sempre rivelata efficace per quanto riguarda la personale attivita' nel campo dell' ingegneria.

[TardoFreak]

[1] Una base hardware minimale con tutto quel che serve per rendere un microcontrollore funzionante, programmabile ed espandibile allo scopo di permettere sperimentazioni sui microcontrollori (didattica) o prototipazione veloce, o realizzazione di apparecchiature uniche. Il tutto deve essere fruibile sopratutto dai principianti.
[2] Non ho capito cosa intendi dire.
[3] Elevata potenza di calcolo, molta flash e molta ram per avere meno vincoli possibile e lavorare senza preoccupazione e che sia sufficiente per implementare progetti sostanziosi. Ricordo che un decoder MP3 si implementa su un micro da almeno 50 MIPS.

Per ora mi fermo qui.
Io lavoro con gli STM32F1xx ed ho anche la discovery con il STM32F4 (micro notevole, una vera potenza) ma non penso siano adatti ai principianti. Il PIC32 è più facile da utilizzare, scrivere il primo programma con un PIC32 è cosa semplice. Altrettanto non si può dire per gli ARM. E' anche molto potente con una marea di periferiche non difficili da utilizzare. Si parla di 6 linee seriali, USB OTG, Ethernet, timers a 32 bit.
Se dovessi dar retta allo spirito tecnico direi subito STM32F4xx ma non è di certo una scelta felice per un principiante.

Edit.
Se è vero che un emulatore per STM32 costa meno di 30 euro è anche vero che gli emulatori per gli altri costano soldi. Quello per i SAM l' avevo pagato 170 euro (se non ricordo male) ed oggi costa 100$ (più IVA e spedizione), il J-Link costa da un minimo 250 euro a ... un' auto usata. E' vero che c'è anche una versione educational del J-link e mi pare che anche digi-key ce l' abbia ma è un caso unico.
Come sistemi di sviluppo free c'è l' atollic ma non permette di fare il debugging. Gli IDE commerciali costano una fucilata ... Non saprei, ma a naso il PIC32 mi sembra più alla portata.

[dimaios]

[2] Non ho capito cosa intendi dire.

Intendevo la possibilita' di espansione del sistema dal punto di vista hardware.
Eventuali schede di espansione potrebbero essere montate piggyback su una piastra madre ma si potrebbe pensare anche all'esposizione su un bus dei canali sincroni ( deterministici ) per connettere evenutali espansioni tramite cavo flessibile.
Un' altra forma di espandibilta' e' rappresentata dalla scalabilita' del processore ovvero la scelta di una serie pin-pin compatible per la eventuale sostituzione. Questo permette di limitare i costi se non serve molta potenza di calcolo. Ho visto in un paio di schede che i microcontrollori non erano pin-pin compatible e tramite una FPGA si redirezionava l' I/O in base alla configurazione ma nel caso in oggetto mi sembra eccessivo.