Newsgroup: it.hobby.elettronica.digitale
Titolo: video e ram

Salve a tutti,
Sto lavorando su un'interfaccia grafica che visualizza su uno schermo
il contenuto di una RAM statica da 512Kbyte.
Per quanto riguarda la visualizzazione tutto ok.
Il problema e' relativo all'aggiornamento del contenuto della ram.
Adesso aggiorno la ram nelle linee video non utilizzate dall'immagine
e negli intervalli di back e front porch orizzontale, ma il sistema
e' estremamente lento; per scrivere tutti e 512 i Kbyte di memoria
(per un comando CLEAR SCREEN) impiego almeno un secondo.
Non posso usare le ram dual port perche' di quelle dimensioni costano
uno sproposito.
Qualcuno conosce qualche barbatrucco o puo' darmi qualche dritta per
velocizzare la scrittura della ram per impieghi video?
Se scrivo durante le sole linee pari o dispari e durante la
visualizzazione salta all'occhio qualcosa a chi osserva il monitor????
Grazie 2^10 anticipatamente
Ciao

 velocizzare la scrittura della ram per impieghi video?
Puoi pensare al double buffer...
In pratica due ram affiancate mentre una viene scritta l'altra viene 
letta ed ad ogni quadro si inverte il ciclo.
-- 
Use free-form input where possible.
News 2002 [v 2.4] - [ StopDialers/PopDuster/SMTP Proxy - 
http://www.socket2000.com
 ]

 ha scritto:

Non � molto chiaro, usi un controller o cosa ?
La gestione del bus A0...An D0...Dn  come � fatta?
--
ciao
  Stefano

 
Salta all'occhio che l'immagine cambia.
Per� da questa domanda mi sorge il dubbio che forse non ho capito bene i 
limiti dell'architettura del tuo bus.
Ciao

 La gestione del bus A0...An D0...Dn  come è fatta?
Nel modo piu' semplice immaginabile.
I dati del bus a 8 bit formano un pixel con possibilita' di 256
combinazioni diverse di colore.
Stavo pensando se non fosse conveniente(almeno al momento) lavorare
con 16 colori in modo da dimezzare la frequenza di "pescaggio" dalla
ram.
Oppure potrei affiancare 2 ram con bus da 8 bit per farne uno da 16 ed
ottenere lo stesso effetto.
La ram che uso ha un tempo di accesso di 10ns e per scansionarla tutta
sono tengo sempre il pin OE basso e cambio l'indirizzo su A0.. An al
volo; sembra strano, ma il risultato e' ottimo e tra pixel e pixel non
si nota nulla di strano(mi riferisco alla concorrenzialita' dei
segnali sui bus dati e indirizzi).
Da come avete capito uso dei sistemi un po' rudimentali e barbari, ma
sto ancora esplorando il mondo delle cpld e non posso al momento
tentare soluzioni piu' raffinate.

 letta ed ad ogni quadro si inverte il ciclo.
Mi e' venuta in mente ieri notte questa soluzione, ma non mi e' chiaro
come fare per condividere le informazioni tra un quadro e l'altro.
Scusami, ma ho bisogno di qualche informazione in piu'.
Col doppio buffer non mi trovo sempre nella condizione di dover
scrivere dalla ram A alla B e dalla B alla A?

 limiti dell'architettura del tuo bus.
mah...veramente i limiti sono nella mia testa, perche' sto
sperimentando una cosa nuova e non so se riusciro' a portarla a
termine :)

 scrivere dalla ram A alla B e dalla B alla A?
Vediamo se questa e' fattibile.....
usando per es. la ram A per qualche frame, ho una finestra temporale
utile per aggiornare la RAM B....dopodiche' c'e' un frame o 2 in cui
"travaso" (ma intanto continuo a leggere) tutte le informazioni dalla
B alla A.... e poi il ciclo si ripete all'infinito nelle due
direzioni.
E' questo che intendevi?
in questo caso dovrei creare un segnale di BUSY per informare
l'utilizzatore dell'interfaccia di non scrivere sulla ram durante il
trasferimento A->B e B<-A.

 disponibile.....
Tanto per curiosità....che CPLD stai usando? (giusto perchè la
settimana prossima devrò farlo anch'io)

 settimana prossima devrò farlo anch'io)
Ciao,
sto usando una EPM240T100C5N
la piu' piccola della sua famiglia , ma mi ci sto divertendo
parecchio.
Qualche tempo fa mi sono fatto arrivare tramite digi-key una delle
sorelle maggiori(una EPM1270)
che ha un package ancora saldabile a mano e a.... occhio.
Devo dire pero' che per me che non so ottimizzare la descrizione in
vhdl sono un po' piccole, ma credo che uno esperto possa sfruttarle
bene e ottenere frequenze di funzionamento elevate.
Anche il costo e' buono.

 E' questo che intendevi?
No. Mentre scrivi una delle due ram l'altra la leggi. Finito il frame
(oppure quando necessita il refresh dello schermo perch� hai scritto 
qualche cosa) inverti il senso (sulla ram dove scrivevi prima ora 
leggi e viceversa) Questo sistema, per�, funziona solo se tutto il 
processo scrive quadri completi nella RAM. Dipende cosa hai 
implementato.
-- 
Sure it's user-friendly...if you know what you're doing.


 parecchio.
Ottimo, è la stessa che mi sta arrivando; personalmente avevo
"improntato" il codice in verilog tanto per vedere se ci stavo sul
chip per la gestione completa di un tft 320x240 a colori, ma non avrei
pensato si potesse usare molto dello spazio disponibile; con  quale
risoluzione e profondità di colore stai lavorando?.
Io ho a disposizione delle ram statiche da 16Mb che costano 1.5$, e
purtroppo non sono dual port.
Ad ogni modo per ovviare al tuo problema avevo pensato che fare almeno
2 buffer interni (uno per l'uscita verso il tft e l'altro  per la
ricezione dei dati dall'ingresso) potesse essere la soluzione ai
problemi in cui sei incappato, dato che una volta bufferizzati i dati
posso fare sulla ram più cicli di scrittura per ogni lettura.....ma
magari da qualche parte c'è un inghippo che non ho considerato e  mi
ritrovo con i tuoi stessi problemi.

 ritrovo con i tuoi stessi problemi.
Io non mi farei troppi problemi. Le difficolta' che sto incontrando io
sono dovute solo alla mia inesperienza. Sicuramente perdendoci un po'
di tempo e arrivando a qualche compromesso, si riuscira' ad avere un
risultato soddisfacente.
Saluti
MAssimo IW0HKG

tentare soluzioni piu' raffinate.
Devi vedere se c'� la possibilt� di avere le temporizzazioni giuste, poi
alternare in modo furbo letture e scitture, fino ai limiti dell' hardware.
--
ciao
  Stefano

 alternare in modo furbo letture e scitture, fino ai limiti dell' hardware.
L'unica strada che mi viene in mente per non abbassare la risoluzione
e i colori e' quella di usare un bus dati molto largo.
Cosi' la PLD impiega meno tempo a pescare i dati dalla ram(la occupa
per un tempo inferiore) e mi lascia lo spazio per scriverci sopra.
Ma la cosa che piu' mi preoccupa e' che non voglio un utilizzatore
costretto a viaggiare alla stessa velocita' della CPLD, non avrebbe
senso.
Avevo immaginato un sistema che permettesse di disegnare un pixel
azionando addirittura dei pulsanti a mano........
Saluti
MAssimo

 risoluzioni.
Effettivamente x il pll concordo pienamente; non capisco per quale
motivo non debbano mettere un pll interno alla cpld: costa troppo?
per il buffer di memoria di cui parlavo qui trovi un esempio:
http://www.edaboard.com/ftopic160169.html


Potresti scrivere i dati dal micro verso un buffer composto da alcune
RAM veloci in modo da memorizzare sia dati che indirizzi.
Negli istanti di non refresh video tali RAM verrebbero lette molto
velocemente e garantirebbero la scrittura della RAM video.
Una funzione simile potrebbe essere gestita da un DMA che normalmente
dispone delle logiche di arbitraggio del bus, ma bisognerebbe rivedere
e complicare la generazione degli indirizzi.
Comunque, il primo parametro per l'architettura è stabilire quanti
pixel per frame il micro è in grado di aggiornare.
Mi spiego meglio: se il micro può scrivere (dato che li dovrà
calcolare/gestire) solo 2k di pixel per ogni generazione di frame
(cioè ogni 1/60 di secondo, ad es), il buffer di scrittura può
limitarsi a qualche k senza bisogno di sconfinare in una RAM gemella.
Diverso è il caso se bisogna inseguire un refresh simile a quello
dello schermo.
Non so se mi sono capito... :(
Piccio.