Hello, world!
Premetto che ho letto un po' di thread a proposito di questo argomento, ma ora ho una domandina un pochettino complessa,
Essendoci stato questo "Boom" diciamo tecnologico, la confusione di noi Arduiniani è salita alle stelle. Quindi per voi, qual è tra le due, quella più idonea (e in pratica, forse, la migliore) per sviluppare progetti con una potente tecnologia quale il processore 32bit (o anche x86), che sia come molti di noi chiedono, una scheda friendly e quindi facile da gestire/programmare?
Perchè avendo letto vari thread vedo che c'è una particolare confusione se effettivamente sono un qualcosa di "rivoluzionario" oppure un qualcosa che ci confonda ancora di piu le idee.
Spero di essere stato chiaro 
. Saluti!
Galileo e TRE sono schede completamente diverse da quelle che trovi oggi sul mercato (2009,UNO,MEGA,DUE).
La Galileo è un mini PC x86 (processore intel) che può far girare un unico applicativo o vari schedulati o un OS, in sostanza è una una sotto steroidi ed anabolizzanti, la CPU controlla direttamente (tramite dei multiplexer e ADCle uscite) oltre alle porte di comunicazione e gestione sd.
La tre monta un processore ARM affiancato ad una MCU, in questo caso puoi usare la CPU principale per l'alaborazione dati e la MCU per la gestione delle periferiche a basso livello (sensori etc..), al di la delle performance è come avere una raspberry pi o beaglebone o similari affiancata ad una UNO.
Cè poi da dire che la maggior parte degli utilizzatori di arduino UNO (nonostante la mia "poca" esperienza mi colloco tra loro) usano il micro a un decimo delle sue potenzialità, è sempre il solito discorso, cosa te ne fai di una panda con motore ferrari ?
Questo per dire che tutto dipende da ciò che vuoi farci, io se devi iniziare ti consiglio la UNO, costa poco, è facilmente "in alcuni casi" riparabile e con questa ti fai le ossa, poi passi a sistemi più performanti.. Spero di non averti fatto più confusione di prima 
ratto93:
Galileo e TRE sono schede completamente diverse da quelle che trovi oggi sul mercato (2009,UNO,MEGA,DUE).
La Galileo è un mini PC x86 (processore intel) che può far girare un unico applicativo o vari schedulati o un OS, in sostanza è una una sotto steroidi ed anabolizzanti, la CPU controlla direttamente (tramite dei multiplexer e ADCle uscite) oltre alle porte di comunicazione e gestione sd.
La tre monta un processore ARM affiancato ad una MCU, in questo caso puoi usare la CPU principale per l'alaborazione dati e la MCU per la gestione delle periferiche a basso livello (sensori etc..), al di la delle performance è come avere una raspberry pi o beaglebone o similari affiancata ad una UNO.Cè poi da dire che la maggior parte degli utilizzatori di arduino UNO (nonostante la mia "poca" esperienza mi colloco tra loro) usano il micro a un decimo delle sue potenzialità, è sempre il solito discorso, cosa te ne fai di una panda con motore ferrari ?
Questo per dire che tutto dipende da ciò che vuoi farci, io se devi iniziare ti consiglio la UNO, costa poco, è facilmente "in alcuni casi" riparabile e con questa ti fai le ossa, poi passi a sistemi più performanti.. Spero di non averti fatto più confusione di prima
No, mi hai decisamente illuminato, io comunque ho iniziato con la DUE, perchè siccome avevo visto due kit, uno con la UNO e l'altro con la DUE a prezzi uguali ho preferito la Due perchè almeno in caso debba, in un qualche futuro, usare tante risorse non dovevo prendere un'altra board.
E tornando all'argomento, mi interessava una delle due schede piu che altro per avere un mini pc "portatile" con cui programmare Arduino ovunque, per cosi dire.
Sia la intel che la arduino con i loro rispettivi prodotti propongono un prodotto che si allontana definitivamente dall'open source, in quanto a difficoltà di utilizzo che solo i professionisti potranno utilizzarlo veramente con le loro effettive potenzialità costruendoci sopra delle board applicative , riservandosi tutto il loro codice applicativo ( non divulgandolo) e vendendo l'intero sistema / apparato ai loro clienti,
intanto chi pensa che sviluppare un applicativo degno di nota su queste main board sia poco più difficile che con UNO o LEONARDO si sbaglia di grosso, però intanto la compra e al massimo ci caricherà qualche progettino inutile fatto tanto per dire che funziona. Che dire , si sono esaltati e questa è la loro risposta a chi li ha accusati di sempliciotteria riferendosi alle prime 15 - 16 schede praticamente tutte uguali ....un pò come i dischi degli AC-DC 
Devo dire che non hai tutti i torti !! allora mi converrebbe aspettare e scoprire se effettivamente la intel e la TI forniranno materiale, perchè effettivamente le poche informazione che sono state pubblicate non sono sufficienti! Inoltre è vero, anche con le schede come Leonardo, Uno, Due sono gia straordinarie di loro e non vengono usate al massimo!
Però chissà, magari questi due nuovi colossi saranno la soluzione per molti Arduiniani! : D
Per il controllore atmel si potra usare il compilatore arduino ma per il processore texas dovranno per forza di cose usare un compilatore texas, essendo un PC a tutti gli effetti lo useranno come raspberry , attacchi il monitor in hdmi , tastiera e mouse, S.O. e compilatore texas e via con la compilazione e esecuzione locale, boh.. in verità non mi sono informato
icio:
boh.. in verità non mi sono informato
Direi proprio di no
Dato che si tratta di sistemi Linux embedded come compilatore puoi usare il gcc, poi se lo usi onboard oppure in cross compiling su un pc è una tua scelta.
La TRE deve ancora uscire sul mercato, in teoria primavera 2014, quindi inutile porsi troppe domande adesso visto che l'hardware non è ancora definitivo.
La Galileo mi sembra più una operazione commerciale per l'immagine che un vero prodotto, la parte di I/O a causa del fatto che è gestita tramite expander I2C a 100 khz è lentissima, massimo 230 Hz come frequenza di commutazione dei pin, la distro Linux utilizzata è più che castrata, ne dico una grossa non c'è apt-get, e limitata.
Insomma per il momento la Galilelo mi pare un bel flop di Intel, forse più avanti quando qualche gruppo di sviluppo porterà sulla scheda una "vera" distro Linux, ovviamente su SD, le cose cambieranno perché comunque il processore ha delle potenzialità, in fin dei conti è sempre un classe Pentium @400 MHz.
Hai proprio ragione Astrobeed, avevo visto che erano tutte due un po' carenti sotto certi punti di vista, però immaginavo che la Galileo aveva un sistema per I/O decisamente più veloce :~ , vuol dire che aspetteremo di vedere come sarà l'esito della Tre! XD
Stavo parlando di Arduino3 , se leggi bene parlavo di un processore TEXAS, come si vede bene sulla scheda ci sono ci sono un centinaio di headers collegati ai pin di i/o di sitara quindi sperando che non abbiano fatto i pidocchiosi come la mega e la DUE sacrificando decine di pin di i/o , appunto sperando cha almeno una 70ina di gpio li abbiano portati su quei headers , e non sono lenti bensì straveloci!!
icio:
appunto sperando cha almeno una 70ina di gpio li abbiano portati su quei headers , e non sono lenti bensì straveloci!!
Immagino che la tua esperienza con sistemi Linux embedded sia minimale, se ti va bene al massimo riesci a far commutare quei pin a 100 kHz, per giunta con molto jitter, un banale 328 arriva senza problemi oltre 1 MHz senza jitter.
L'alternativa è comandare i pin dal kernel space e arrivi a svariati MHz, sempre con molto jitter, ma questa è una cosa che la stragrande maggioranza degli utenti Linux standard non è capace di fare, a partire dal fatto che è necessario modificare e ricompilare il kernel.
La verità è che un sistema Linux embedded, di suo, non serve per comandare i gpio in real time con ben precise tempistiche, questo si fa fare alle mcu, serve per disporre di molta potenza di calcolo, l'accesso ottimale a periferiche complesse come l'ethernet/WiFi, USB host high speed, etc, molta ram a disposizione per calcoli complessi e tante altre cose che con le mcu non puoi fare.
astrobeed:
La verità è che un sistema Linux embedded, di suo, non serve per comandare i gpio in real time
Astro, visto che ce l'hai: la Cubieboard2 come si comporta sotto questo punto di vista? Stessi limiti?
Se prendi una Cubieboard2 (e così le altre) non hai molta scelta, visto che hai un solo chip sulla scheda. 
Non parlo di RT, però. Parlo di uso generale.
Forse non ci intendiamo. Dico che i limiti di cui parla Astro si ripercuotono anche nell'uso normale di questi GPIO?
Io non parlo di farci un PWM in bit-banging oppure di campionare a 1 MHz, parlo ciò che un utente farebbe con questa scheda come se acquistasse una UNO. Mettiamo l'uso di questa scheda in una centralina domotica, a me non me ne importa che campioni a 10 kHz, a me basta che non si intrippi leggendo lo stato di qualche pin ogni secondo. Non so se mi sono spiegato.
Stavo infatti meditando l'acquisto di una Cubieboards2 per fare una piccola centralina con interfaccia a GUI su uno schermo touch. Farei un mio programma che poi piloterei dal touch, e con esso cambierei/leggerei le uscite.
Non vedo problemi nel limite dei 100 kHz, no?
Parlo da profano, perché per ora non ho mai usato sistemi con SoC per cui non ne conosco i limiti.
leo72:
Astro, visto che ce l'hai: la Cubieboard2 come si comporta sotto questo punto di vista? Stessi limiti?
Si certamente, questo vale per qualunque sistema Linux Embedded, il "problema" è proprio il S.O. che "rallenta" questo genere di operazioni.
Ovviamente parliamo dell'uso dei GPIO da user space, che è il modo semplice per il quale spesso vengono fornite librerie, a volte in puro sitle Arduino, dal produttore della scheda embedded.
Se l'accesso al GPIO avviene da kernel space la velocità sale enormemente però è molto più complesso da gestire, nessun produttore di board fornisce driver e libreria per farlo, per ovvi motivi di affidabilità, dato che non sono cose che fanno parte delle distro ufficiali, te li devi scrivere da solo e di conseguenza devi essere capace di modificare e ricompilare il kernel.
Ribadisco il concetto che nel 99.999% delle applicazioni dove si usano schede Linux embedded non serve commutare i GPIO a velocità luce, solitamente si utilizzano per comandare dei led, relè, dare comandi on/off ad altri device, leggere la presenza di una tensione, etc, insomma tutte cose che non richiedono ne il realtime e dove un tempo di risposta medio attorno ai 100us è più che sufficiente.
Diverso è il discorso dei bus di comunicazione, UART/I2C/SPI, etc, se la distro abbinata alla board è fatta bene sono gestiti, dal kernel, tramite DMA il che ti permette di impegnare la cpu solo per poche centinaia di us anche per inviare/ricevere pacchetti dati molto grossi.
Ovviamente a seconda della velocità del bus devi attendere il necessario tempo prima di poter inviare/ricevere un nuovo pacchetto, però nel frattempo continui le normali operazioni senza bloccare l'esecuzione del programma.
astrobeed:
Ribadisco il concetto che nel 99.999% delle applicazioni dove si usano schede Linux embedded non serve commutare i GPIO a velocità luce, solitamente si utilizzano per comandare dei led, relè, dare comandi on/off ad altri device, leggere la presenza di una tensione, etc, insomma tutte cose che non richiedono ne il realtime e dove un tempo di risposta medio attorno ai 100us è più che sufficiente.
Come nell'esempio che ho fatto. Perfetto.
leo72:
Stavo infatti meditando l'acquisto di una Cubieboards2 per fare una piccola centralina con interfaccia a GUI su uno schermo touch. Farei un mio programma che poi piloterei dal touch, e con esso cambierei/leggerei le uscite.
In questo caso ti consiglio l'acquisto della Olinuxino A20, stesso prezzo della Cubie v2 stesso SoC, però ha già predisposto il connettore per il display con touch, Olimex ne ha due versioni, una da 4.3" e un da 7", di buona qualità a basso costo.
Ti allego una foto del display da 7" di Olimex, collegato alla Cubie v2, con un certosino lavoro per collegare tutti i vari wire, dove è visibile il desktop di Lubuntu, così ti rendi conto della qualità.
E' perfetto!
Grazie della dritta, mi sa che per Natale ho trovato i regalini XD XD
Mi sembra che olimex stia progettando anche le schede con gli A31 (CPU quadcore e GPU 8-core).
In effetti Astrobeed ci hai azzeccato :), non ho mai usato linux in qualche progetto, anche se penso che prima o poi bisognerà fare qualcosa, intendevo che potrei usare tutti questi ARM a 32 bits senza un OS , ma come un normale processore non multitasking, usando il compilatore della casa costruttrice o in mancanza di esso un compilatore di terze parti, facendolo girare normalmente come cross-compiler in un sistema windows o linux, alla fine quello che potrei fare (CNC) mi serve solo un buon hardware e velocità
icio:
usando il compilatore della casa costruttrice o in mancanza di esso un compilatore di terze parti, facendolo girare normalmente come cross-compiler in un sistema windows o linux, alla fine quello che potrei fare (CNC) mi serve solo un buon hardware e velocità
Le case produttrici non hanno compilatori loro, salvo rari casi, normalmente ti indicano un compilatore consigliato che supporta il loro micro, tipicamente IAR o Keil per quelli a pagamento.