[OT] Schede Linux embedded

Dico la mia, opinione che espressi anche 1 anno fa quando uscì la Due.
Questa scheda è anacronistica. E' fuori dal tempo. E' uscita troppo tardi. Se usciva nel 2011 aveva un suo perché, ma nel 2012 un chip ARM a 84 MHz che non fa girare nessun SO non è né carne né pesce, è poco più di una Mega più veloce.
Se devo prendere una scheda da 46€, ne investo qualcuno in più e mi prendo una scheda capace di far girare un SO embedded. La Beaglebone Black e la Rasp costano sui 50€... voglio dire....
e se si arriva sui 60/70 si accede a fior fiori di schede tipo la Cubieboard 2.

leo72:
e se si arriva sui 60/70 si accede a fior fiori di schede tipo la Cubieboard 2.

Concordo al 100%, inoltre la Cubie, sia V1 che V2, ha una dotazione di periferiche che non ha nulla da invidiare a quelle della Mega/Due, oltretutto sono presenti anche la ethernet 10/100, due USB HOST High speed, una USB OTG High speed, tutte cose che con Arduino occorrono le shield per averle, per non parlare della comodità di poter utilizzare delle economicissime key WiFi/Bluetooth per il wireless :slight_smile:

:stuck_out_tongue: :smiley: ... vedremo quanto verra' a costare ... :grin: :smiley:

Etemenanki:
:stuck_out_tongue: :smiley: ... vedremo quanto verra' a costare ... :grin: :smiley:

Poco meno di 100 Euro, sconsiglio l'acquisto del primo lotto di produzione, per queste schede è sempre meglio aspettare il secondo, se non il terzo, lotto perché immancabilmente qualche piccolo bug hardware c'è sempre.

astrobeed:

leo72:
e se si arriva sui 60/70 si accede a fior fiori di schede tipo la Cubieboard 2.

Concordo al 100%, inoltre la Cubie, sia V1 che V2, ha una dotazione di periferiche che non ha nulla da invidiare a quelle della Mega/Due, oltretutto sono presenti anche la ethernet 10/100, due USB HOST High speed, una USB OTG High speed, tutte cose che con Arduino occorrono le shield per averle, per non parlare della comodità di poter utilizzare delle economicissime key WiFi/Bluetooth per il wireless :slight_smile:

cos'è l'usb otg? :grin:

OTG sta per On The Go. La connessione USB può avvenire in maniera diretta fra 2 dispositivi compatibili USB OTG senza la presenza di un computer nel mezzo perché un dispositivo USB OTG può fungere sia da host che no, cioè può svolgere sia il ruolo di master (quindi di host) sia di slave (quindi di dispositivo ospite).

bellissimo, peccato che non ho dispositivi OTG(la mai android tv ha l'usb OTG) ma quindi posso anche usarla come usb normale? :grin:

Madwriter:
bellissimo, peccato che non ho dispositivi OTG(la mai android tv ha l'usb OTG) ma quindi posso anche usarla come usb normale? :grin:

Una USB OTG può essere utilizzata sia come USB device che USB Host, normalmente su i dispositivi che montano tale porta, p.e. smartphone/tablet, viene utilizzato un connettore mini/micro USB pertanto è indispensabile usare l'apposito cavo USB OTG che non si limita a riportare i vari pin su un connettore USB Host, provvede anche a collegare il quinto pin della mini/micro usb con gnd, questo perché il dispositivo deve sapere se quella porta va usata come device o come host.

Mi associo al parere degli esimi colleghi.

Tra l’altro, da un benchmark da me effettuato, va più veloce la scheda Digilent, clone della mega (MAX32), che non la DUE. Il chip ha poco, pochissimo supporto al di là del mondo Arduino, e ha diverse limitazioni. E poi costicchia.

C’è da dire che il mondo Linux è molto ostico. Ho provato a gestire un piccolo macchinario con una Raspberry ma alla fine l’ho lanciato dalla finestra!

Troppo complicato accedere ai gpio, lunghe righe di configurazione, oppure 'naltro linguaggio con cui prendere dimestichezza (Phyton).

Ora ho ordinato una BeagleBone Black, che ha una gestione Arduinesca dei gpio e molte più porte. Questo in attesa della UDOO, che per noi elettronicheschi promette meraviglie.

Diciamo che per l’Elettronico puro, la Raspberry non è che sia il massimo…

BaBBuino:
Tra l'altro, da un benchmark da me effettuato, va più veloce la scheda Digilent, clone della mega (MAX32), che non la DUE. Il chip ha poco, pochissimo supporto al di là del mondo Arduino, e ha diverse limitazioni. E poi costicchia.

Se è per questo, neanche il core di Arduino supporta tutte le funzioni del core (ti ricordi la mia lib advancedFunctions per usare l'RTC, il TRNG ed il WDT?).

C'è da dire che il mondo Linux è molto ostico. Ho provato a gestire un piccolo macchinario con una Raspberry ma alla fine l'ho lanciato dalla finestra!

Troppo complicato accedere ai gpio, lunghe righe di configurazione, oppure 'naltro linguaggio con cui prendere dimestichezza (Phyton).

Stai parlando di un microcomputer con Linux che è un sistema operativo basato molto sull'uso del terminale, usato probabilmente da un utente di Windows avvezzo a fare tutto da interfaccia grafica :stuck_out_tongue:

Ora ho ordinato una BeagleBone Black, che ha una gestione Arduinesca dei gpio e molte più porte. Questo in attesa della UDOO, che per noi elettronicheschi promette meraviglie.

Diciamo che per l'Elettronico puro, la Raspberry non è che sia il massimo...

Questo purtroppo vale anche al contrario per un Informatico che deve gestire la parte elettronica di un progetto. :sweat_smile:

Si, rammento le tue librerie. Mi dai un link che me le rileggo? Mi servirebbe giusto giusto aggiungere un WatchDog ad un mio software per aumentarne la sicurezza...

Quanto a Linux, hai ragione, all'Elettronico fa venire mal di testa.

Non se ne esce: l'Elettronico cazzia l'informatico perché non capisce una mazza di bit, correnti e frequenze, mentre l'Informatico cazzia l'Elettronico perché non sa una mazza di Costruttori, Classi e riga di comando.

PS hai dato un'occhiata a cosa fa la UDOO?

Ho visto di sfuggita la UDOO perché non è ancora disponibile materialmente.
Ad oggi, se dovessi comprarmi una scheda del genere, andrei sulla Cubieboard 2, mi alletta parecchio.

PS:
Tutti i miei lavori li trovi (anche sparsi sul forum, la maggior parte è in Megatopic) sul mio sito, vedi firma in calce. Lì ci sono le lib che ho scritto e non solo, anche diversi progetti.

Com'è la gestione GPIO della Cubieboard?

E' fatta tramite dei binding per Python.
Ma puoi anche pilotarli direttamente tramite device logici (se non conosci Linux, sono file agganciati a delle periferiche). Mi pare però che per questa opzione si debba ricompilare il kernel con una patch. Non so però se vale per gli ultimi modelli, leggevo delle info qualche settimana fa.

leo72:
E' fatta tramite dei binding per Python.
Ma puoi anche pilotarli direttamente tramite device logici (se non conosci Linux, sono file agganciati a delle periferiche). Mi pare però che per questa opzione si debba ricompilare il kernel con una patch. Non so però se vale per gli ultimi modelli, leggevo delle info qualche settimana fa.

Lascia perdere... come il Raspberry!

Volevo una roba tipo la Beagle che ha un IDE grafico simil-Arduino e un linguaggio altrettanto simile.

Mi sa che devo aspettare la UDOO, che esce tra pochi giorni. Dicono COMPLETAMENTE compatibile con qualsiasi aggeggio arduinesco.

Veramente mi pare di aver letto che è compatibile con l'Arduino DUE, visto che monta un SAM3X8E. Difficilmente sarà compatibile con software specifico per la UNO o comunque per il 328 (es. uno sketch che usa le periferiche di questa MCU).

Comunque la bellezza di queste schede è che sono minicomputer: se li attacchi ad un monitor li usi come un PC di 10 anni fa. Ho visto che hanno Libreoffice, Gimp, Chromium sopra. Programmi insomma che pesano un bel pò. Hanno senz'altro un campo di applicazioni molto diverso rispetto a quello delle schede a cui siamo abituati. Nel senso che mi paiono sprecate per pilotare qualche pin :wink:

leo72:
Hanno senz'altro un campo di applicazioni molto diverso rispetto a quello delle schede a cui siamo abituati. Nel senso che mi paiono sprecate per pilotare qualche pin :wink:

A parte il fatto che hanno delle dimensioni esagerate.
Già la MEGA/DUE mi sta larga. :astonished:

Dimensioni esagerate?
Dipende dalle schede. Alcune, come la Beaglebone Black, mi paiono grandi forse meno della MEGA. Altre sono senz'altro più grandi ma hanno un sacco di roba sopra, e considera comunque che hanno le funzionalità di un PC di qualche anno fa, io direi invece che sono molto compatte per quello che offrono. :wink:

Nel mondo industriale, il cosiddetto Embedded, si stanno affacciando soluzioni Linux based con questo genere di architetture, soppiantando le varie miniATX.

Lo spazio non è quindi un problema, ma lo sono i costi (con un sistema miniATX poi ci vuole una licenza WindowsXP o almeno Windows Embedded/Windows CE). Inoltre il solito maledetto Time-to-market, ovvero il tempo impiegato dalla definizione del progetto al momento della consegna al cliente e/o immissione sul mercato.

Ho diversi progetti aziendali con un oramai obsoleto processore Fujitsu. Piano piano devo migrare su architetture/sistemi più recenti ed efficaci, ma sopratutto che abbiano un certo numero di anni di vita davanti. Rammento però che nel mondo Industriale non si va alla ricerca dell'ultimo ritrovato, anzi. I sistemi sono spesso uno o due, ma anche tre, passi indietro rispetto allo stato dell'arte del mercato.

Per ora sto facendo Ricerca & Sviluppo per trovare qualcosa che deciderò essere definitivo per i prossimi 5 anni.

Purtroppo gestire un sistema Linuk è un'impresa. 1) perchè generalmente un buon Ingegnere elettronico mastica poco programmazione, file system e Linux, mentre al contrario, un buon Informatico fa miracoli con Linux, ma poi ha poca, quando nulla, dimestichezza con l'Harware fisico sottostante. Insomma, il solito annoso problema. E per fare un progetto da piccola-media Azienda, sobbarcarsi il costo di un altro Ingegnere non è cosa fattibile, non di questi tempi e anche se il settore produce ancora ingenti margini.

  1. Inoltre un sistema a più strati software, oltre a rallentare operazioni hardware che devono essere fatte in Real-time (salvo fare salti mortali) ha una probabilità di freezing o malfunzionamento decisamente superiore ad un sistema a MCU, e in sistemi che fanno della SICUREZZA la loro principale prerogativa, poi si incontrano difficoltà di certificazione (stringentissime).

Ci sono alcuni apparati nel petrolifero che hanno ridondanza tripla, ovvero 3 sistemi diversi, con MCU diverse, sviluppate da (si spera ma di solito non è così) diversi programmatori con diversi approcci. In tali architetture diventa importantissimo l'affidabilità del software all'interno della MCU (si usa qualsiasi sistema che dia sicurezza: WatchDog, SafetyClock, Reset protetto, ecc.) perchè il MTBF (medium time between failure) si riduce esponenzialmente.

Quindi ci sono delle situazioni di confine dove un sistema PC puro diventa grosso, ingombrante, poco sicuro, anche se veloce, mentre uno a MCU più sicuro ma anche più lento e meno gestibile da remoto, allora avere una potente macchina Embedded, con un potente Harware a MCU diventa un'opzione molto interessante.

Insomma, dopo Arduino c'è l'evoluzione della specie, e per i Progettisti dell'Elettronica e gli Hobbisti elettronici avanzati, qualcosa come la UDOO (e tutta la Tribù di Cubie-Beagle ecc) è una manna dal cielo.

leo72:
E’ fatta tramite dei binding per Python.

Solo se usi Python :slight_smile:
Su questi sistemi la gestione dei gpio avviene tramite due stadi diversi, il primo è a livello di kernel tramite un file di configurazione denominato script.bin, per poterlo modificare è necessario convertirlo in formato fex (ASCII) tramite apposite utility, dentro questo file sono descritti tutti i GPIO utilizzati e cosa devono fare.
Quasi sempre nei SoC utilizzati su queste board ogni pin di I/O del chip può espletare più funzioni, esattamente come sul 328 di Arduino, tramite il file script.bin si spiega al kernel come vogliamo che questi pin vengano utilizzati, p.e. il TX/Rx di una UART oppure un normale GPIO, da notare che a differenza delle piccole MCU con core Arm dove la corrente disponibile su i pin è fortemente limitata, pochi mA, su questi SoC molti pin possono abilitati per fornire corrente fino a 40 mA, ovviamente il tutto entro i limiti massimi di corrente complessiva prevista dal SoC.
Il secondo stadio è a livello codice utente, in C tutte le periferiche sono dei file e come tale vanno trattati, sulla CubieBoard 1 e 2 non è necessario ricompilare il kernel per poter utilizzare i vari gpio a livello “user space”, adatto nel 99% dei casi, se è necessario farlo a livello “kernel space” (più veloce nella risposta) allora tocca ricompilare introducendo le proprie routine di gestione.
Da notare che da poco è disponibile per la CubieBoard V1 e V2 la distro Cubian stable, si tratta di una implementazione non ufficiale della Debian 6, l’ho provata e va molto bene, è solo versione server, cioè senza dekstop grafico e senza programmi accessori preinstallati come libreoffice, ovviamente è possibile aggiungerlo se necessario.