Newsgroup: it.hobby.elettronica.digitale
Titolo: Quante risorse ho bisogno?

Ciao,
sto cercando una scheda embedded sulla quale girerà linux. L'unica cosa 
che dovrà fare è ricevere dei dati da una seriale e disegnare a schermo 
dei gauge colorati in 2D (es. barre o indici analogici). Eventualmente 
visualizzare bitmap (immaginate un software di navigazione GPS).
Bene... come posso stimare la quantità di risorse necessarie? In 
particolare mi riferisco a velocità del processore e quantità RAM.
Per intenderci qualcosa tipo questo:
http://www.genlogic.com/control_panel_full.jpg
La velocità di refresh dovrebbe essere la più alta possibile per 
permettere un movimento fluido degli indicatori. Ma naturalmente gli 
indici mobili saranno gli unici che si andranno a ridisegnare (ammesso 
che possa sfruttare una grafica a layer... spero di si. QT?)
Avete idea di quale scheda potrebbe essere adatta allo scopo? Ah... 
sarebbe interessante che la memoria di massa sia a stato solido (non un 
classico hard-disk per intenderci).
Ciao!
Marco / iw2nzm

 visualizzare bitmap (immaginate un software di navigazione GPS).
Beh, qui direi che la faccenda diventa molto diversa, soprattutto per avere
pan & zoom in tempi ragionevoli.

 pan & zoom in tempi ragionevoli.
Eh, immaginavo. Ma ad esempio una cosa del genere:
http://www.embeddedarm.com/products/board-detail.php?product=TS-7800
Potrebbe essere sufficiente a spanne?
Non ha l'uscita video, quindi non è adatta... ma è per capire verso cosa 
devo orientarmi...
Ciao!
Marco / iw2nzm

 devo orientarmi...
Ne avanza pure. In turbo pascal con un 8086 pilotavo centinaia di 
bottoni grafici senza problemi.
-- 
Foolproof operation:  All parameters are hard coded.
News 2002 [v 2.1] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net

 devo orientarmi...
Questa forse ti va bene, oltretutto costa molto meno.
http://pcengines.ch/alix3d3.htm
Mai provata personalmente, comunque in passato ho preso da loro
delle WRAP e sono sempre rimasto molto soddisfatto.

 Non ha l'uscita video, quindi non è adatta...
Appunto: avresti un bottleneck tra processore e scheda video.
Io non avrei alcun dubbio: la soluzione proposta da s+r è senz'altro la
migliore.

 del processore e quantità RAM.
Credo che il 90% delle risorse ti serviranno per
fare girare Linux, non per l'applicazione in se.
Tieni presente che con un ARM7 a 16MHz
ci si fanno dei videogame abbastanza avanzati
(quindi non solo grafica, ma anche suono e
algoritmi di controllo), ma senza OS. Se proprio
ce lo devi mettere (non conosco la complessità
della tua applicazione), gestire la grafica sarà la
parte meno complicata ed esigente in termini
di risorse.
A.D.

 di risorse.
Ecco qua il mio errore di valutazione: ero convinto esattamente del 
contrario.
Comunque, l'applicazione avrà un paio di schermate tipo quelle indicate 
dal link iniziale. Quindi grafica 2D con barre o indici scorrevoli, un 
orizzonte artificiale e indicazioni testuali. Premendo un tasto al posto 
di questa schermata verrà visualizzata la cartografia con indicazioni GPS.
Pensavo di dover usare un sistema operativo per poter gestire la grafica 
tramite le librerie (QT come ipotizzato inizialmente).
Nel caso non lo usassi, chi si occupa di generare il segnale VGA? Vi 
saranno comunque anche delle librerie con gli elementi grafici base o 
dovrò crearmele io? Non che sia un grosso problema, ma giusto per sapere 
dove vado a finire...
Grazie e buona domenica!
Marco / iw2nzm

 
http://pcengines.ch/alix3d3.htm
Molto interessante, soprattutto come costo!
Non ha l'ingresso per la tastiera, ma non è un problema in quanto ha 
anche un bus di espansione I2C.
Vedo che c'è la lista di sistemi operativi supportati: immagino che non 
siano però solo quelli... voglio dire, qualsiasi versione di Linux 
Embedded dovrebbe essere adatta (ammesso che ne abbia bisogno, come 
giustamente mi faceva notare A.D.).
Per il prezzo che ha quasi quasi faccio un tentativo!
Grazie della dritta
Marco / iw2nzm

 classico hard-disk per intenderci).
Secondo me, la migliore attualmente è questa:
http://beagleboard.org/
La nostra specializzazione è nello sviluppo di applicazioni con linux 
embedded e qt quindi... se hai qualunque domanda chiedi pure!
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org

 embedded e qt quindi... se hai qualunque domanda chiedi pure!
Sempre gentilissimo :)
Temo proprio che se mi confermano il lavoro qualche aiuto dovrò chiedertelo!
Grazie e buona domenica anche a te
Marco / iw2nzm

 dove vado a finire... 
Vi saranno dove? 

> 
http://beagleboard.org/
Ma si trova solo su Digikey? Me la danno in backorder tra 20 giorni :(
Non mi sembra di aver trovato un altro distributore... spero di 
sbagliarmi...
Marco / iw2nzm

 Vi saranno dove? 
Luogo generico :)
Intendevo dire utilizzando un normale compilatore C senza avere il 
supporto del sistema operativo (e quindi delle librerie tipo QT).
Marco / iw2nzm

 spanne: 1 sec, 10 sec o 1 minuto?
Qui in ufficio ne abbiamo 2: a partire completamente ci mettono 
qualche decina di secondi... ma tieni presente che sono configurate 
come un desktop vero: parte X, KDE e ci sono installate applicazioni 
come Firefox, Thunderbird, etc...
Se aspetti fino a domani ti posso fare anche un video :-)


 sbagliarmi...
Q: I like to order a BeagleBoard from DigiKey. But they seem to be out 
of stock?
A: DigiKey is having IT issues in that they can't handle partial 
shipments against an order, it does not show up in their system. 
Currently, they are receiving > 200 boards a week from the contract 
manufacturer. Typically they will only show a QTY of 1 for EVMs and it 
is not an indication of total quantity they have.
Bah
--
Marco / iw2nzm

 Se aspetti fino a domani ti posso fare anche un video :-)
Non è necessario, era solo per capire l'ordine di grandezza. Grazie lo 
stesso!
--
Marco / iw2nzm


Noi le abbiamo comprate lì... sinceramente non so se li abbiamo altri 
distributori.
Purtroppo in questo periodo sta avendo un vero boom ed è probabile che 
abbiamo dei ritardi nelle consegne.


 stesso!
In ogni caso su youtube è pieno, questa è una demo abbastanza completa:
http://it.youtube.com/watch?v=FuVwh_VrIxk


 a finire...
Il segnale video non lo genera l'OS in ogni caso,
ma un chip o una periferica integrata apposita.
L'OS gestisce solo i controlli grafici e gli eventi.
Se non usi un OS devi prepararti delle piccole
bitmap e disegnare la schermata copiando i
pezzetti di grafica nelle locazioni appropriate
della RAM video, la scansione ed il segnale
video vengono generati automaticamente dal
controller grafico.
A.D.

 controller grafico.
Come giustamente mi faceva notare Bertolazzi. Mi ero bloccato perché non 
consideravo che non c'è solo 'ARM a bordo!
--
Ciao e grazie!
Marco / iw2nzm

 della RAM video
Fermo restando che, se cambi risoluzione dello schermo, devi rifare tutto.
Se devi fare migliaia di pezzi, puoi usare un processore 100 volte più
piccolo e consumoso, ma, visto che i prezzi dell'elettronica sono perlopiù
dettati dalle economie di scala, se usi un x86, avrai le prestazioni 100
volte maggiori che ti occorrono per avere gli stessi tempi di risposta che
con un sistema senza OS allo stesso prezzo, al limite con consumi un po'
maggiori. Che, se parliamo di portatili, è un costo, se invece ti alimenti
dalla rete, sostanzialmente non ti cambia nulla. Anzi, tra le schede
proposte quella ARM necessita di 5V precisi precisi, quella x86 AMD mi pare
volesse dai 7 ai 20 V.
Poi, guardando al lungo termine, è molto probabile che gli ARM si
affermeranno sempre più, e che forse una scheda tipo l'ottima BeagleBoard
diventi uno standard. Che però gli x86 e Linux saranno sempre disponibili e
che siano uno standard che probabilmente ci sopravviverà è certo.

 Fermo restando che, se cambi risoluzione dello schermo, devi rifare tutto.
Perché mai? Non basta ridimensionare la bitmap a seconda della 
dimensione dello schermo?
--
Ciao!
Marco / iw2nzm

 dimensione dello schermo?
Certo, ma solo se per "ridimensionare la bitmap" intendi "ridisegnarla
ex-novo per ogni nuova risoluzione che ti occorre".

 BeagleBoard ci fanno anche il 3D non è il caso di preoccuparsi!
Dov'è che spiegano come farlo? Dove si scaricano le librerie?

 Dov'è che spiegano come farlo? Dove si scaricano le librerie?
Dal sito 
beagleboard.org
 leggo:
"OpenGL ©  ES 2.0 capable 2D/3D graphics accelerator capable of 
rendering 10 million polygons per second "
Quindi immagino che le librerie usate siano le OpenGL. A questo punto la 
domanda per Francesco è inevitabile: se la scheda sembra supportare 
nativamente (?) le OpenGL ha senso usare le QT?


 ex-novo per ogni nuova risoluzione che ti occorre".
No, non intendevo quello. Comunque ho capito cosa intendi tu, ora.
--
Marco / iw2nzm

 nativamente (?) le OpenGL ha senso usare le QT?
Boh, certo che però, se parli di OpenGL, il "peso" di Linux poi ti fa un
baffo...

 quella dell'OS.
Penso che si debba distinguere. In campo embedded esistono due tipologie di
sistemi operativi, e in mezzo scorre il fiume:
-L'OS "leggero", che utilizzi sostanzialmente perché ti fornisce una serie
di primitive e oggetti per la sincronizzazione/accesso alle risorse utili
per il tuo scopo. Di questi ce n'è una caterva, con varie prestazioni e
complessità: Integrity, VxWorks, DSP/BIOS, FreeRTOS, QNX, e chi più ne ha
più ne metta.
-L'OS "completo", che utilizzi sostanzialmente perché ti fornisce un'intera
*infrastruttura* standard, un ambiente di sviluppo familiare, applicativi
di ogni genere già pronti, librerie di ogni genere già pronte, supporto di
tutto l'hardware immaginabile, una comunità di sviluppatori e know-how
sterminati. I contendenti principali sono due, Windows CE/Mobile e Linux.
La tua osservazione è molto più pertinente per il primo tipo di OS, anche
se a dire il vero a me personalmente non è mai capitato di dovermi pentire
di un OS di questo genere perché mi ha complicato la vita. Spesso il solo
fatto di considerare l'utilizzo di un OS implica quasi fatalmente che esso
ti servirà. :)
Impiegare invece Linux o CE ha molto meno a che fare con le syscall e le
facility del kernel. Il loro motivo d'essere è proprio quello di
semplificare - molto e sempre - lo sviluppo di una qualunque applicazione
non banale su hardware non banale. Il motivo per cui in questi ultimi anni
questo genere di soluzioni abbia preso nettamente il sopravvento ha a che
fare con il tempo, in modi diversi. Per piccoli numeri il fattore
determinante sono i costi di sviluppo, e quindi non ti interessa che
l'hardware costi poche decine di euro in più per supportare OS complessi;
per grandi numeri il fattore determinante è il time to market, e grazie
alle economie di scala (l'unica cosa con la parola "economia" nella
descrizione che funzioni ancora) anche il costo dell'hardware per questo
genere di applicazioni di massa ha subito un crollo di conseguenza.
Poi è chiaro che esistono varie eccezioni. Ci sono applicazioni
time-critical dove conviene scriversi tutto da zero, bypassando OS o
usandone uno "leggero"; ci sono altre applicazioni dove i numeri sono così
enormi che può addirittura valer la pena di scriversi il proprio OS e/o
API, vedi ad esempio Symbian o Android o Java ME.
-- 
emboliaschizoide.splinder.com

 Symbian o Android o Java ME.
Si è vero, dipende totalmente dalla tipologia di
applicazione da sviluppare, dai tempi e budget
per lo sviluppo, dal time-to-market, e dai volumi
di produzione. In effetti non si possono fare
discorsi di validità troppo generale, bisognerebbe
giudicare caso per caso in base alle speficiche...
Forse la mia tendenza a non usare OS è dovuta
al fatto che di solito sviluppo sistemi dalle specifiche
un pò "estreme", in cui non ci si può permettere il
lusso di non sapere quando accadono le cose o
di attendere ms per il context switch o per reagire
alle interruzioni... :-)
A.D.

 nativamente (?) le OpenGL ha senso usare le QT?
Certo, QT è un toolkit grafico, OpenGL è un'insieme di funzioni di 
bassissimo livello per il 3D.
Con la QT disegni i bottoni, finestre, tab, textbox e via dicendo. Con 
OpenGL definisci vertici, texture e cose del genere. La QT è un layer 
sopra OpenGL e può usarlo per accelerare il ridisegno dei widgets.
Farsi un toolkit grafico come le QT richiede davvero anni di lavoro.
Non farti prendere dalla riscrivite, sembra tutto semplice all'inizio, 
ma nella migliore delle ipotesti, dopo qualche mese di lavoro, ti 
ritroveresti con un sistema molto limitato, bruttino e pieno di bug.


 librerie non mi sembra molto conveniente...
Anche qui, dipende. Nel caso specifico direi che conviene, non ha
senso reinventarsi la ruota.
Concludo con un'osservazione un po' filosofica: in genere chi proviene
da un background prettamente elettronico ha un po' paura degli RTOS e
OS in genere, in primo luogo perché non li conosce.
Io sono di formazione elettronica e ho fatto l'elettronico puro per un 
po' di tempo, prima di scoprire che mi piaceva di più l'embedded e il 
firmware in generale. Stare in questo settore è difficile perché 
essendo a metà tra due mondi viene snobbato sia dagli elettronici che 
dagli informatici puri.
Gli informatici in genere dicono che in ogni progetto c'è troppa
elettronica, che si poteva fare prima e meglio solo in software. Gli
elettronici che c'è troppo software e che si poteva fare prima e
meglio senza OS :-)
Io che sto nel mezzo vedo pregi e difetti di entrambi i mondi. Un
sistema operativo adeguato al livello dell'applicazione è sempre una
cosa positiva, non bisogna a prescindere usarlo sempre (e sempre lo
stesso) o non usarlo mai. Ne sono disponibili tanti e a vari livelli
(come ha indicato dalai), dai piccoli RTOS fino a Linux.
Sono convinto che anche nei tuoi casi d'uso specifici (parlo
direttamente a A.D.) un OS potrebbe essere proficuo.
Volevo solo chiederti: ne avete provato qualcuno e poi abbandonato e
non avete mai provato?


 alle interruzioni... :-)
Sì, ma se dovessi fare una cosa del genere, non conviene usare un approccio
PIC (che era nato come Peripheral Interface Controller per una CPU più
potente ma meno "interrompibile"), ovvero fare le cose a basso livello e
deterministiche con un processore e lasciare la gestione dell'interfaccia
utente e della post-elaborazione ad un altro?

 sopra OpenGL e può usarlo per accelerare il ridisegno dei widgets.
Solo concettualmente o usa proprio OpenGL?

 
parole sante

 OS in genere, in primo luogo perché non li conosce.
Concordo anche su questo. E' tipico "avere paura" di ciò che non si 
conosce. O comunque non si sa valutare se può essere una scelta 
azzeccata. Da questo punto di vista il dialogo con persone più esperte - 
anche dalle diverse opinioni - risulta estremamente formativo.



Lo usa proprio, se vuoi. Non è il default, ma è possibile creare i 
widget dicendogli di accelerarli in OpenGL.
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org/

 
è molto interessante! peccato non abbia ethernet a bordo

 è molto interessante! peccato non abbia ethernet a bordo
Già, questa è l'unica pecca grave :-(


 Già, questa è l'unica pecca grave :-(
E con il passare del tempo purtroppo non è che TI abbia imparato la
lezione. I DaVinci più grossi hanno sì il controller ethernet integrato, ma
è pesantemente buggato (almeno nelle silicon revision che ho dovuto usare)
mentre i DaVinci più piccoli e succosi come il DM355 non ce l'hanno
neppure. :(
Purtroppo OMAP e DaVinci di fascia bassa sono pensati per palmari e
smartphone, dove ethernet obiettivamente serve a poco.
-- 
emboliaschizoide.splinder.com

 dagli informatici puri.
Trovi? A me capita il contrario, tendono a essere in soggezione perché per
entrambe le categorie una parte del tuo lavoro rappresenta un qualche cosa
di mistico e misterioso. :)
E si possono fare considerazioni simili con chi scrive firmware per logiche
programmabili: trattati con deferenza sia dagli hardwaristi (che sanno che
con un dispositivo da pochi euro puoi eclissare le loro ridicole logiche
discrete), sia dai firmwaristi dei microprocessori (che sanno che le loro
patetiche decine di MIPS sono niente confronto al tuo massiccio
parallelistmo). ;-)
-- 
emboliaschizoide.splinder.com

 parallelistmo). ;-)
Quindi un programmatore di FPGA starà sempre sulle pa**e a tutti...
Ecco perchè non si trovano tutorial, perchè la gente ha paura a firmarsi per 
non rischiare di rimanere solo e senza famiglia.
;)
coals 

 parallelistmo). ;-)
Sarò masochista ma lavorare su logiche programmabili è il mio sogno, non 
vedo l'ora di aver l'occasione per farlo :-)
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org/

 ad un altro?
In generale si, se non hai vincoli sul consumo di
potenza, sull'ingombro, sulla resistenza meccanica,
e tante altre cose simpatiche del genere... :-)
A.D.

 e poi abbandonato e non avete mai provato?
Ne ho provati diversi, e non ho avuto problemi.
Quando ti puoi permettere il "lusso" di usarli
effettivamente semplificano molto certe cose.
A.D.

 
ecco, io da firmwarista penso esattamente questo dei fpgaisti :-)

 e tante altre cose simpatiche del genere... :-)
Le vie dei problemi sono infinite... :-)

 dove vado a finire...
Se usi una scheda embedded probabilmente ti conviene andare direttamente
su LVDS e saltare a pie' pari VGA.

 is not an indication of total quantity they have.
Confermo che DigiKey le ha disponibili anche se a catalogo non sembra. 
Mi hanno chiesto però per ben tre volte a cosa mi servono e chi è il 
cliente finale....
Marco / iw2nzm