Newsgroup: it.hobby.elettronica.digitale
Titolo: gestire un tfp401

ciao a tutti,
  in un nostro progetto utilizziamo l'integrato in oggetto
http://focus.ti.com/docs/prod/folders/print/tfp401.html
Questo integrato acquisisce un segnale video dvi e butta fuori un 
segnale parallelo con 8 bit per colore + hsync vsync e framesync.
Lo usiamo per acquisire, con una FPGA altera, alcune sottoparti della 
schermata del segnale video (1024x768 a 60Hz, per un pixel rate di 
47milioni e rotti di pixel al secondo), per la precisione dei rettangoli 
di cui definiamo coordinate iniziali e finali; i dati di ciascun 
rettangolo vengono spediti in uscita su delle linee seriali dalla FPGA 
stessa.
Tenendo conto che
- il programma FPGA è stato realizzato da un consulente esterno (quindi 
non abbiamo un completo controllo sul progetto)
- ora non ci bastano più i rettangoli  ma ci servono forme più 
complesse, tra le altre cose, e ci serve una maggiore flessibilità in 
fase di trasmissione
vorremmo valutare soluzioni alternative alla FPGA, ad esempio 
microprocessori [molto] veloci (il pixel rate è 47Mhz, come detto), o 
addirittura pc industriali ...
avete qualche dritta?
ciao
  BQ

 addirittura pc industriali ...
Un pc industriale è un pc come gli altri dal punto di vista della potenza
di calcolo. 
47 milioni di pixel/secondo, per 24 bit al pixel fanno un throughput
mostruoso! Altro che cpu...

 avete qualche dritta?
Questo mi sembra uno dei pochi casi in cui l'uso di una logica 
programmabile è praticamente d'obbligo.
Come ha fatto notare SilverLeo un flusso del genere è enorme.
Un PC (potente) con una scheda di acquisizione buona e un software ad 
hoc forse potrebbe riuscire (comprimendolo) a salvare il tutto su un 
disco, ma non so se è quello che dovete fare.
Ciao

 
Sono d'accordo con te, ma era l'unica soluzione che ci consentiva di 
rispettare i tempi richiesti. Ora abbiamo un po' di tempo per valutare 
eventuali evoluzioni e soluzioni sulle quali possiamo avere un controllo 
migliore.

Francesco Sacchi ha scritto:

ciò che abbiamo già realizzato (e di cui vogliamo valutare possibili 
evoluzioni) è in sostanza un controller che pilota pannelli a led (tipo 
schermo gigante per intenderci, ma con un pitch più alto, tipo 30-40mm, 
per effetti grafici; ultimamente li usano spesso in studi televisivi).
Finora abbiamo utilizzato la FPGA per prendere la gran mole di dati, 
selezionarne una piccola parte (poniamo 8k pixel per ogni FPGA, ma 
volendo utilizzare un micro anche meno, diciamo 1kpixel, e poi metto 8 
micro) un frame si e uno no, e buttarla fuori a 30fps su seriali a 
velocità 'umane', e i pannelli a led acquisiscono e visualizzano.
Il nodo sta nel selezionare in maniera efficiente le parti di schermo da 
acquisire; poi una volta che le si ha in un buffer, ritrasmetterle a 
velocità più basse non è un problema.
Ci sono dei micro sufficientemente veloci?
questo ad esempio devo guardarlo meglio,
http://focus.ti.com/docs/prod/folders/print/tms320dm642.html
ma può arrivare fino a 5760MIPS, in 5760/47=122 istruzioni per pixel 
dovrei più che cavarmela no?

 migliore.
La soluzione a FPGA mi sembra la migliore in assoluto, vista 
l'applicazione (e, soprattutto, viste le alternative). Non so che 
famiglia/parrocchia stiate usando (altera, xilinx, lattice, ecc...), ma 
alla fine il livello di complessità del progetto non è così elevato: 
acquisire lo stream video e piazzarlo in una ram dual port non è 
tremendo, poi una piccola cpu su fpga (il nios II viene via gratis :-) ) 
che programma il dma per leggere la dual port e scrivere sul/sui pannelli 
a led è pure abbastanza affrontabile.
Le soluzioni a cpu mi sembrano abbastanza un accrocchio, quantomeno dal 
punto di vista concettuale: il frame acquisito (si spera in tempo) dove 
viene salvato? Quanto tempo di cpu resta per leggere le varie regioni e 
spedirle ai display a led? 
Altra cosa: voglio conoscere chi si mette a scrivere il codice per la cpu 
in assembly (viste le velocità), e poi voglio rivederlo qualche mese dopo 
quando deve lavorare di debug zen perchè ogni tanto un puntatore se ne va 
per i campi :-P
Per me la soluzione fpga è la migliore: costi contenuti, semplicità di 
manutenzione, scalabilità e indipendenza dall'architettura. Una volta 
scritto tutto per bene (avete il vhdl/verilog sorgente della vostra 
fpga?) passare da una fpga all'altra è quasi (...) indolore. Delle 
cyclone III non costano tanto e hanno degli io configurabili che 
promettono di fare risparmiare molto sul routing del pcb. 

 
grazie per le tue riflessioni! non hai tutti i torti. E' che il mio pane 
  è l'assembly e il c, la fpga come ti dicevo sopra mi ha fatto perdere 
un paio di mesi senza ottenere risultati... però magari si può riprovare.
ciao
  bq

 un paio di mesi senza ottenere risultati... però magari si può riprovare.
Ci vuole tanta pazienza e una buona base di elettronica digitale alle spalle. Io
preferisco l'analogica ;-)