Salve a tutti. Visto che l'Arduino Due il 32 dicembre del duemilamai avrei intenzione di iniziare a lavorare da solo sul SAM3U. Qualcuno mi può dare qualche dritta su qualche libro, guida o quello che è (a parte l'ovvio datasheet) su dove studiarmi questo microcontrollore?
Avevo cercato anche io in rete e si trova ben poco... a meno non ti prendi un kit di sviluppo ultra costoso con il suo ide e parti dagli esempi...
Janos:
Salve a tutti. Visto che l'Arduino Due il 32 dicembre del duemilamai avrei intenzione di iniziare a lavorare da solo sul SAM3U. Qualcuno mi può dare qualche dritta su qualche libro, guida o quello che è
Sul SAM3U non troverai altro che la documentazione ufficiale Atmel, cioè il data sheet e qualche application note, sul core Cortex M3 utilizzato da questa MCU si trova molta documentazione e manualistica in lingua inglese, un ottimo testo è questo, se lo prendi in formato elettronico (Elsevier non usa DRM) non hai spese di spedizione.
dai un occhio al netduino, è un altro mondo.
è un ambiente stabile, a differenza di arduino. ovvio che devi imparare il C# o con la 4.2 il VB.net
poi adesso è uscito il netduino GO.
PS: costa come una uno...
Quando sento parlare di C# o .NET mi viene l'orticaria....
hreplo:
è un ambiente stabile, a differenza di arduino
Cosa intendi per "ambiente stabile"? Perché l'Arduino non lo è, secondo il tuo punto di vista?
hreplo:
dai un occhio al netduino, è un altro mondo.
è un ambiente stabile, a differenza di arduino. ovvio che devi imparare il C# o con la 4.2 il VB.net
poi adesso è uscito il netduino GO.PS: costa come una uno...
Sono d'accordo con leo, per di più usare C sharp o Visual Basic che sono entrambi linguaggi di programmazione ad altissimo livello in una MCU mi sembra poco serio 
ratto93:
hreplo:
dai un occhio al netduino, è un altro mondo.
è un ambiente stabile, a differenza di arduino. ovvio che devi imparare il C# o con la 4.2 il VB.net
poi adesso è uscito il netduino GO.PS: costa come una uno...
Sono d'accordo con leo, per di più usare C sharp o Visual Basic che sono entrambi linguaggi di programmazione ad altissimo livello in una MCU mi sembra poco serio
poi comunque ogniuno è libero di fare come meglio crede, questo non lo metto in dubbio..
astrobeed:
Janos:
Salve a tutti. Visto che l'Arduino Due il 32 dicembre del duemilamai avrei intenzione di iniziare a lavorare da solo sul SAM3U. Qualcuno mi può dare qualche dritta su qualche libro, guida o quello che èSul SAM3U non troverai altro che la documentazione ufficiale Atmel, cioè il data sheet e qualche application note, sul core Cortex M3 utilizzato da questa MCU si trova molta documentazione e manualistica in lingua inglese, un ottimo testo è questo, se lo prendi in formato elettronico (Elsevier non usa DRM) non hai spese di spedizione.
E quindi mi conviene studiarmi separatamente il processore e poi applicarlo alla MCU?
AH, un'altra cosa: posso programmarlo in C++, vero? Ovvero almeno le classi...
Janos:
E quindi mi conviene studiarmi separatamente il processore e poi applicarlo alla MCU?
Sicuramente si, anche perché lo stesso core lo trovi in vari modelli di mcu di diversi produttori, quello che cambia è solo l'hardware di contorno quali periferiche disponibili e quantità di memoria.
AH, un'altra cosa: posso programmarlo in C++, vero? Ovvero almeno le classi...
Il mio consiglio è sempre lo stesso, evitare il C++ sulle MCU, tutte, fa sprecare un sacco di risorse e rallenta non poco l'esecuzione del software, un esempio su tutti la digitalWrite di Arduino che per cambiare lo stato di un pin ci mette circa 2 us contro i 65 -130 ns (1 o 2 cicli macchina a seconda delle operazioni di contorno) necessari per farlo in C ANSI.
Ma per fare software un po' più complessi la programmazione ad oggetti risulta comodissima... Preferisco spendere 1€ in più su un hardware più potente che diventare matto per programmare senza oggetti.
Un progetto che ho realizzato per dove lavoro è composto da 4 lame indipendenti, se realizzo una classe la uso 4 volte e sono a posto...
Ma è molto diverso il Cortex-M3 dalle ATmega come gestione delle periferiche e programmazione? Ad esempio gli I/O sono ancora gestiti dai registri DDRx, PORTx e PINx? Inoltre, a parte la convenienza, non mi hai detto se è possibile programmarlo in C++ o no... XD
sì, la cortex la programmi anche in C++.
oltre al cortex ultimamente mi attrae i stm32f4, esiste una developer board "stm32f4 discovery" che costa quanto un'arduino.
però ha una potenza molto superiore, è a 32bit, FPU, e sembra essere abbastanza diffusa (e quindi documentata)
tutti i microcontrollori sicuramente li puoi usare a livello di registri (anche se cambiano nome e modalità di utilizzo), però non tutti offrono libreria più ad alto livello come quelle arduino.
Janos:
se realizzo una classe la uso 4 volte e sono a posto...
Se realizzi una funzione dedicata, che poi è lo stesso lavoro per creare una classe, la usi quante volte vuoi esattamente come fai con le classi con la differenza che a livello di compilazione la cosa è molto più efficiente e richiede meno risorse.
Ma è molto diverso il Cortex-M3 dalle ATmega come gestione delle periferiche e programmazione? Ad esempio gli I/O sono ancora gestiti dai registri DDRx, PORTx e PINx?
Mai usato, preferisco gli NXP come core ARM agli Atmel, di sicuro avrai periferiche che si usano allo stesso modo degli AVR a 8 bit e altre in modo diverso, però questa è una cosa che ci metti poco ad accertare, basta che dai un'occhiata al data sheet e vedi subito le eventuali differenze tra registri.
Inoltre, a parte la convenienza, non mi hai detto se è possibile programmarlo in C++ o no... XD
Per ogni micro/mcu trovi sempre vari compilatori per differenti linguaggi, se lo programmi con gcc, c'è la versione per ARM, ovviamente puoi scrivere sia in C ANSI che in C++, però gcc per ARM fa veramente pena se usi le librerie di cross compiling native, ci sono compilatori commerciali low cost (< 300 Euro) per ARM basati sul GCC con librerie di cross compiling proprietarie che vanno abbastanza bene.
Se devi realizzare software su micro ARM per motivi di lavoro ti consiglio caldamente di acquistare uVision MDK ARM di Keil (circa 1600 Euro), c'è una versione demo/free che ti permette di provarlo con unico limite la dimensione massima del compilato, ottima per prendere confidenza col prodotto e fare i primi esperimenti di programmazione senza spendere un Euro.
Ok, grazie mille. Vedrò un po' quale strada scegliere ma il stm32f4 francamente mi ispira... =)
ti avviso a priori che la quantità di informazioni su internet è molto maggiore per la cortex che per la stm, ma se non sei principiante questo non dovrebbe essere un grosso problema (al massimo una perdita di tempo)
Proprio principiante non sono ma quello che so l'ho imparato all'università dove ci hanno spiegato gli ATmega. Questa sarebbe la prima MCU che imparo da solo, quindi preferisco andare su un prodotto dove trovo un po' più di documentazione...
Grazie mille per le dritte.
Ora non voglio fare polemica, ancora di più se si tratta di Astro.
La digitalWrite impiega tanto tempo anche perchè fa una cosa che richiede tempo, ora ho un ricordo lontano ma mi pare che legga dalla flash per ricavare i dati delle porte.
Io non credo che il C++ sia tanto più lento rispetto al C, dipende tutto da cosa ci fai e come lo fai, esiste la possibilità di scrivere codice fatto male sia in c che c++, quindi alla fine se si è in grado di scrivere buon codice in c o in c++ le differenze di velocità di esecuzione e minima. Spesso scrivere codice facile da usare comporta una lentezza in esecuzione, arduino core ne è l'esempio. Nota che anche in c può essere usato il paradigma della programmazione ad oggetti. Leggi questo libro Design Patterns for Embedded Systems in C: An Embedded Software Engineering ... - Bruce Powel Douglass - Google Libri
Arm e avr32 possono essere programmati in C++ con le Qt lib di Nokia, tramite l'ide qtcreator e così è possibile scegliere tra tante classi efficienti, certo se usi una lista di mappe ovviamente questo è codice che richiede tempo per essere eseguito, però grazie alle qt le stringhe, mappe e altre classi sono di tipo implicit shared e questo a fronte di un consumo di ram in più porta velocità e flessibilità di uso.
Non ho un arm e neanche un avr32 ma uso le qt da tempo e ne ho studiato il codice interno almeno in parte e se avessi la necessità di usare un arm lo farei con su un kernel linux e le qt.
Ciao.
Questa cosa della digitalWrite mi ha incuriosito e sono andato a guardarmi il codice.
La digitalWrite esegue prima una conversione tra numero del pin passato come parametro e pin fisico del micro mediante delle macro, poi nel caso sia un pin agganciato ad un timer, spenge l'eventuale segnale PWM, poi disattiva gli interrupt, modifica lo stato del pin, ed infine riattiva gli interrupt.
Insomma, un bel po' di lavoro. Ecco perché alla fine è così lenta. Ma si tratta tutte di operazioni necessarie per come è strutturato l'Arduino, che è tutto "sui generis" e non deve dare nulla per scontato.
Se io manipolo i pin del micro, sono ad un livello di competenza tale per cui so anche le implicazioni che ha sullo stato del pin la presenza di un segnale PWM. Ma se io non so neanche come lo genero, questo segnale PWM, come posso sapere che se ho un timer agganciato a quel pin, ho un segnale ad onda quadra che esce da lì? Quindi "dietro le quinte" il core mi stacca in automatico quel segnale, mi controlla varie cose e mi fa apparire tutto bello e preciso come voglio io, 0V se metto LOW e 5V se metto HIGH. Ovviamente al costo di diverse operazioni compiute senza che l'utente se ne accorga.
In effetti c'è il modo di fare quello che fa la digitalWrite in modo preventivo e poi usare le macro per impostare la porta, questo torna utile quando c'è la necessità di cambiare stato di uno o più bit molto più velocemente di come lo fa digitalWrite.
Cioè si tratta di scrivere codice per fare la cosa in due fasi, ricavi l'indirizzo della/e porta/e e su questi operi con bitwise, questo non significa che digitalWrite è codice cattivo, piùttosto è il reference ad essere pessimo perchè non fa menzione al tempo impiegato da ogni funzione e non spiega come aggirare i vari problemi ecc, e questo mi sta bene anche perchè da modo di publicare libri con buona probabilità di acquisto.
Certo che usare un ARM senza un sistema operativo è compito duro e devi avere un valido motivo per farlo. Su un arm c'è spazio per i thread, processi, eventi ecc.
Chissa se c'è un RTOS per arm in GPL o equivalente?
Ciao.
Cioè mi stai consigliando che sarebbe meglio installare un kernel linux anche sulla SAM3U, che è un microcontrollore?