Newsgroup: it.hobby.elettronica.digitale
Titolo: Pilotare un piccolo TFT

Ovvio che su un 15" non ci avrei pensato più di tanto: una bella scheda PC con 
uscita TTL o LVDS con un sistema operativo e vai.
Il problema è che vorrei utilizzare uno di quei piccoli TFT, non proprio così 
piccoli da cellulare, diciamo da palmare o navigatore GPS. Diciamo intorno ai 
4.7"-5.7" di diagonale e una risoluzione di 1/4 VGA.
Sicuramente la scheda PC con processore Intel compatibile e uscita TTL (forse 
l'LVDS non è così usata su quel taglio di TFT) va benone: ci metto un sistema 
operativo grafico e sono a posto. Ma ho la sensazione che sia una soluzione 
sovrabbondante.
Esiste qualche altra soluzione più low-cost per pilotare direttamente un TFT con 
interfaccia TTL di questo tipo? Non mi interessano i milioni di colori, mi 
andrebbero benissimo centinaia o migliaia (dovrebbe dipendere dalla risoluzione 
in bit di ogni pixel del TFT).
L'altra domanda riguarda la parte puramente grafica, la GUI. Scartando subito le 
interfacce a finestre, cosa potrei utilizzare? Io penso alle interfacce grafiche 
dei navigatori satellitari: grafica molto piacevole, touch-screen, tasti, barre 
di scorrimento, ecc.
Esiste qualche libreria grafica di questo tipo pronta all'uso (open-source 
sarebbe l'ideale)?

 (open-source sarebbe l'ideale)?
Mi sembra che tutto sommato la tua applicazione sia grossina, credo che 
tu faccia immensamente prima a usare un S.O. embedded che non a scrivere 
tutto da capo. Chiaramente ti consiglio Linux o uClinux.
Per la GUI prova a vedere la rinomata libreria Qt, che esiste anche in 
versione embedded. Quest'ultima non ha bisogno di un server X window ma 
disegna direttamente su un framebuffer.
Per maggiori info:
http://trolltech.com/products/qt/qt3/embedded/index
Ciao

 
http://trolltech.com/products/qt/qt3/embedded/index
Ok, proverò a guardare.
Per quanto riguarda l'hw, invece? Devo per forza buttarmi su una
scheda PC embedded?
Oppure esiste qualche altra scheda più a basso costo tutto embedded
(processore, RAM, Flash, Ethernet,
controller TFT, ecc.)?

 controller TFT, ecc.)?
PC embedded no, ci sono soluzioni migliori.
Per esempio le schede con processori ARM: hanno la potenza di un 
palmare ed hanno tutto integrato.
A seconda della potenza richiesta puoi scegliere o un ARM7 o un ARM9.
Alcuni link presi a caso solo per farti capire di che schede parlo:
http://www.kwikbyte.com/products.html
http://www.raisonance.com/arm/STR9/skSTR9.php
http://www.emtrion.de/hicoarm9st_linux_en.php
Ciao

 
http://www.emtrion.de/hicoarm9st_linux_en.php
Guardo e ti faccio sapere.

 
http://www.emtrion.de/hicoarm9st_linux_en.php
Le prime due non sembrano supportare TFT.
L'ultima sì (utilizza il controller della EPSON S1D13A04 che gestisce
fino,
ovviamente interfaccia TTL, a 64K di colori su TFT).
Il sito sembra scarno... hai avuto modo di utilizzare i loro prodotti?
Hai idea
dei costi?

 C'entra qualcosa la LGPL in questo discorso?
Hai centrato esattamente il punto. Sebbene il kernel debba per forza 
di cose essere rilasciato con i sorgenti in GPL, questo non è vero per 
le applicazioni che scriverai e che ci gireranno sopra. Puoi usare 
tutte le librerie di sistema che vuoi e rilasciare la tua applicazione 
closed source, proprio grazie alla LGPL. Tieni presente però che non 
potrai usare codice GPL all'interno del tuo applicativo, e questo 
potrebbe essere un problema.
Ciao

 dei costi?
In genere una scheda di sviluppo ARM costa da 100€ fino ad alcune 
centinaia, a seconda del processore, della memoria e delle periferiche 
installate. Dovresti cercare di definire per bene di cosa hai bisogno 
e poi vedere di conseguenza cosa offre il mercato.
Ciao

 oppure da un Linux "normale" per ridurlo piano piano?
Per questa scheda, che non ho mai usato, mettono a disposizione
l'immagine linux 2.6
http://www.olimex.com/dev/cs-e9315.html
Sul sito ci sono anche i prezzi.
http://www.olimex.com/dev/pricelist.html
Ciao
Paolo

 sovrabbondante.
Di solito quel tipo di LCD si pilotano in RGB (666 oppure 888), con livelli
logici LVTTL (3.3 V o meno). I due metodi più semplici per interfacciarlo
sono:
1) Usare una CPU (di solito grossina) che li supporti direttamente;
2) Usare una logica programmabile che generi i segnali RGB pescando da una
RAM sulla quale scrive anche la CPU (una sorta di frame buffer, anzi,
proprio quello :-)).
Tempo fa ho visto pure dei display del genere che avevano già il controller
grafico integrato, in pratica tu spedivi (probabilmente attraverso una
connessione seriale) dei comandi ad alto livello come "disegna cerchio" e
cose del genere, e lui si occupava di tutto. Ora purtroppo non trovo più i
link.
-- 
emboliaschizoide.splinder.com

 
http://www.emtrion.de/hicoarm9st_linux_en.php
Se ti interessano gli XScale già pronti con Linux, fatti un giro qui:
http://www.toradex.com/e/products.php
Vendono anche una schedina che converte TTL/LVDS, e nelle pics si legge  
nitidamente quale integrato adopera. :P
Saluti
-- 
Matricola
Mac Pro Dual Xeon 2,66GHz - 2Gb Ram - 250Gb HD - GeForce 7300GT 256Mb


Bellini davvero. Non li conoscevo. :)


 essere un problema.
Quindi, ricapitolando, se nella mia macchina "gira" il kernel di Linux, questo 
deve essere open-source (molto probabilmente già lo è perchè non ho intenzione 
di toccarlo ma solo di utilizzarne uno funzionante).
Se scrivo un'applicazione che gira sotto questo Linux linkando le librerie di 
base libc, posso creare tranquillamente una applicazione closed-source perchè le 
libc sono LGPL.
Se utilizzo, però, altre librerie (chessò, qualcosa che mi permette di 
visualizzare immagini JPG su display oppure librerie di compressione) devo stare 
attento alla licenza. Se sono rilasciate sotto LGPL allora posso continuare a 
creare la mia applicazione closed-source, altrimenti devo rilasciare la mia 
applicazione open-source.
A tal proposito, penso che esista una differenza se le librerie che utilizzo 
sono linkate dinamicamente o staticamente. Se sono linkate dinamicamente, è vero 
che le utilizzo nella mia applicazione, ma non sono "incorporate" all'interno. 
Devo anche in questo caso rilasciare la mia applicazione sotto GPL?
A parte le librerie, cosa succede per le applicazioni che utilizzerei così come 
sono? Per esempio, se volessi utilizzare nano-X (
www.microwindows.org
)? La 
licenza sembra che possa essere scelta tra GPL o MPL (quella di Mozilla). Se 
utilizzo nanoX così com'è (al massimo lo compilo per la mia piattaforma) e 
sviluppo un'applicazione per questo ambiente grafico? Cosa ne è della mia 
applicazione? GPL (quindi open-source con l'obbligo di rilasciare i sorgenti) 
oppure closed-source?
Se volessi utilizzare un web server, per esempio apache? Al massimo compilo il 
servizio per la mia piattaforma e poi lo configuro creando opportune pagine. 
Magari devo scrivere qualche script... Devo rilasciare qualcosa? Penso di no, il 
software apache non lo modifico, rimane tale e quale.
Infine un'altra cosa. Che obbligo c'è di pubblicizzare la tecnologia con cui è 
sviluppata la mia applicazione? In altre parole, quando vendo il mio prodotto in 
cui gira un Linux, devo forzatamente pubblicizzarlo? Devo dire che sta girando 
nano-X, oppure apache o altro? Penso proprio di no...
Scusate per le domande a raffica, ma penso che sia necessario chiarire bene 
questi punti prima di fare la scelta di utilizzare Linux nelle applicazioni 
commerciali per le quali non si vuole rilasciare il codice sorgente.
Esiste qualche sito o documento da studiare per chiarirsi meglio i concetti?

 
http://www.olimex.com/dev/cs-e9315.html
Però dice: "PRELIMINARY INFO, THIS DEVICE WILL BE AVAILABLE FOR SALE IN DECEMBER 
2006" e Dicembre 2006 è bello che passato.

 
http://www.toradex.com/e/products.php
Il modulo Colibri PXA270 312MHz costa 99€, la scheda Orchid (per usare la 
Colibri) costa 169€. Stiamo parlando di 268€, quasi quanto una scheda PC/104 che 
monta un processore Celeron dove non dovrei avere problemi di compatibilità con 
l'hw visto che è a tutti gli effetti un PC (vedi lo sbattimento di ricompilare 
applicativi per Xscale).
Cosa ne pensi?

  
ha scritto:

Che della scheda Orchid sono disponibili anche gli schematics, con tanto  
di bom.
Quindi il lavoro di adattamento è praticamente già svolto. Basta  
implementare solo le parti che ti interessano e lasciare fuori la  
moltitudine di features/periferiche che non sono necessarie alla tua  
applicazione.
Il connettore SoDimm per montare il modulo sulla tua mobo è disponibile su  
Digikey.
Il modulo è compatibile WinCE; significa che acquistandolo non solo hai  
automaticamente la licenza, ma puoi sviluppare qualsiasi software e  
relativa interfaccia utente con il tool più facile del mondo: Embedded  
Visual Basic, scaricabile gratis (come la controparte Visual C). ;)
Se cerchi sul sito ci sono dei video su come fare lo startup del demo kit  
con WinCE.
E' molto ben fatto.
Saluti.


 concetti?
Of course:
http://www.gnu.org/licenses/gpl-faq.it.html
Ricorda comunque che quella che vale legalmente è la versione inglese.
Ciao

 aggiuntivo.
Aggiungo una cosa: non è sufficiente fornire un link da cui scaricare i 
sorgenti, perchè il link tra un mese potrebbe cambiare. Devi impegnarti 
a fornire un metodo per dare i sorgenti all'utente, senza costi 
aggiuntivi, finchè il copyright sarà valido. L'unico costo che puoi 
aggiungere è solo quello di distribuzione.
Se per esempio scegli di fornire i sorgenti su CD a chi lo chiederà, 
puoi farti pagare il costo del CD e delle spese postali, ma i sorgenti 
in se non possono essere fatti pagare.
Per questo molti distribuiscono subito, insieme ai binari, anche i sorgenti.
Ciao

 nella tua applicazione.
Però leggiamo qui (dalle faq della GNU GPL):
---
    Does the GPL require that source code of modified versions be
posted to the public?
The GPL does not require you to release your modified version. You are
free to make modifications and use them privately, without ever
releasing them. This applies to organizations (including companies),
too; an organization can make a modified version and use it internally
without ever releasing it outside the organization.
But if you release the modified version to the public in some way, the
GPL requires you to make the modified source code available to the
program's users, under the GPL.
Thus, the GPL gives permission to release the modified program in
certain ways, and not in other ways; but the decision of whether to
release it is up to you.
---
Mi sembra anche giusto: scarico un sorgente di un programma GPL e lo
modifico come mi piace
a casa o anche in azienda per utilizzarlo internamente e non per
pubblicarlo.
Però quando vendo un apparato hw, a rigore, non sto vendendo o
distribuendo software, ma appunto l'hw.
Possiamo dire che il software mi serve "internamente" per far
funzionare la macchina. L'utente vede solo
delle porte a cui collegarsi, magari un display con tasti, ma non si
mette a installare software.
Forse, in questo caso, non sono obbligato a distribuire le eventuali
modifiche che dovessi fare al software GPL.
Certo che, alla fine, si diventa avvocati a studiare 'ste cose e il
fascino di Linux nel mondo embedded
commerciale cala notevolmente.

 commerciale cala notevolmente.
Dipende dai punti di vista: se cerchi cavilli legali per eludere la 
GPL sì, devi darti molto da fare. Io però non credo che sia il modo 
giusto di procedere.
Ho abbracciato la filosofia open source da un po' e ti posso dire che 
fin'ora mi ha portato solo benefici.
Molti credono che la GPL obblighi a distribuire gratis il proprio 
lavoro o che tutti possano copiare il tuo codice.
Questo non è assolutamente vero: puoi farti pagare per il tuo lavoro, 
e rimarrai sempre il detentore del copyright.
La GPL aiuta ad accorciare enormemente i tempi di sviluppo, perchè non 
è necessario ogni volta reinventare la ruota.
E se hai paura che un concorrente possa copiare il tuo prodotto, tieni 
presente che anche tu potrai fare lo stesso: quello che ottieni è di 
poter sviluppare molto più velocemente, avendo accesso al lavoro fatto 
da altri prima e dopo di te.
Se non ti convince puoi sempre sviluppare la tua applicazione 
closed-source e fornire i sorgenti del solo S.O., come abbiamo visto è 
perfettamente legale.
Ma se vuoi che tutto sia closed-source non ci sono alternative: non 
puoi usare nulla di GPL.
Ciao

 perfettamente legale.
Infatti penso che sia, attualmente, il modello di business migliore
per
utilizzare Linux embedded. Anche TomTom fa così. Hanno modificato
molti
pacchetti software GPL (tra cui il kernel e altri tools e
applicazioni) e rilasciano,
ovviamente, tutti i sorgenti ed eseguibili.
La applicazione principale (il navigatore), invece, è closed-source.
Vorrei vedere
la TomTom a fornire i sorgenti del software di navigazione!!! Non lo
farebbe mai.
L'unica cosa è stare molto attenti ad utilizzare, nella applicazione
closed-source,
solo pezzi LGPL o comunque GPL più "rilassate".
Da quello che ho capito, per la gestione del display TFT utilizzano
direttamente
il framebuffer. Questo vuol dire che tutti gli elementi grafici che
disegnano (tasti,
testi, finestre, ecc.) sono disegnate tutte "da zero", senza sfruttare
altre librerie
già fatte (X, GTK, nano-X). Chissà se questa è stata una scelta dovuta
proprio
a problemi di licenza GPL...

 a problemi di licenza GPL...
Penso che più che altro sia dovuto alla scarsezza di risorse. Inoltre 
a cosa serve un server X se il tuo oggetto è monoapplicazione e 
monofinestra, come la maggior parte delle applicazioni embedded?
Per questo a inizio thread ti avevo suggerito di usare Qt Embedded, 
che non è altro che una serie di widget disegnati direttamente su un 
framebuffer. Adesso il progetto ha cambiato nome, si chiama QTopia.
Non vorrei sbagliarmi, ma dall'interfaccia direi che anche TomTom la usa.
Ciao

 controller TFT, ecc.)?
Esistono microprocessori con un controller grafico integrato. 
In moltissimi telefoni e navigatori di ultima generazione ci sono 
processori ARM di diversi produttori (Intel, Freescale, Samsung, 
NGX/Philips, Atmel, Sharp, Cirrus etc.).
Su architetture ARM7 (senza MMU) puoi usare linux, FreeRTOS a altri 
OS. Su ARM9 (o 11) anche Windows CE, VxWorks etc.
Il costo dei componenti hardware è sicuramente inferiore a quello di 
un PC.
Il costo del prodotto finito è più basso solo se si parla di molti 
pezzi. 
Per produzioni limitate una scheda ARM "già pronta" generalmente costa 
come o addirittura più di un PC embedded perchè le produzioni sono più 
limitate e quindi chi produce e vende quelle schede non potrà 
"spalmare" i costi di progetto sugli stessi numeri che fanno VIA, 
Advantech o altri produttori di PC embedded. 
Nel caso di una tua scheda custom puoi sicuramente avere costi bassi 
per l'hardware (ritagliando solo quello che ti serve), ma devi mettere 
in conto costi per la progettazione e la produzione (visto che 
difficilmente si tratta di oggetti assemblabili con strumentazione 
hobbystica) che dovrai dividere per il numero di oggetti che pensi di 
produrre.
Molti produttori di chip hanno schede di evaluation per i loro micro. 
Anche qui i costi variano dalle migliaia di euro a qualche centinaio.
Per Windows CE (il sistema che conosco meglio e su cui lavoro più 
spesso), alcuni produttori (Intel, Freescale, Samsung) rilasciano i 
driver e tutto quello che serve per far girare il sistema operativo 
direttamente in formato sorgente (la qualità purtroppo varia...), 
altri lo rilasciano in formato binario o richiedono l'acquisto (a 
volte per un prezzo non proprio simbolico) di quella parte di 
software.
Considera però che avere un sistema operativo già pronto e i relativi 
strumenti di sviluppo e debug ti fa poi risparmiare parecchio tempo in 
fase di sviluppo, garantendoti un insieme di funzionalità già pronte e 
stabili per la tua applicazione.
Le grandi aziende possono permettersi di realizzarsi un sistema in 
casa (Nokia per diverse serie dei suoi telefoni, ad esempio), ma solo 
investendo anni di lavoro con la prospettiva di mantenerlo ed 
utilizzarlo per parecchi prodotti. Nel caso di una piccola azienda o 
di un obbysta, scriversi tutto da zero è IMVHO, se non per scopi 
didattici, un'impresa folle.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)