Interfacciare Pic16f877a a RAM 6264

[stex90]

Purtroppo non ho un oscilloscopio. Però potremmo considerare la velocità massima a cui può lavorare la ram in base al datasheet (100ns per la mia HY6264-10) e calcolare se ci sto dentro con un 18f a 40 MHz.

[Robert8]

Il PIC 18 a 40 MHz riesce ad eseguire una singola istruzione assembler in 100 ns.
Se vuoi calcolare la velocità massima di scrittura sulla RAM compatibile con la lettura dal PIC dovrai contare quante istruzioni assembler ti servono sul PIC per eseguire il test e quante per, eventualmente, leggere il dato e fare tutto ciò che ti serve, quindi, moltiplicare tale valore per 100 ns.
Supponiamo che tu abbia 20 istruzioni assembler per 100 ns ottieni 2 us: questo è il tempo minimo di scrittura che dovrai impostare sul 6808.

Comunque per sincronizzare il tutto ti servirà o l'oscilloscopio o un analizzatore digitale.
Ce ne sono anche da 100 euro tipo quello descritto in questo articolo

[stex90]

Bene. Studiando un po il datasheet del processore (6802) e non (6808) come avevo scritto in precedenza, (una svista) mi sono accorto che coma diceva c1b8 un ciclo di utilizzo bus dati impiega da un minimo di 1us a un massimo di 10 us. Quindi i tempi si fanno un po' più larghi. Ora devo capire se potrò usare il picbasic o dovrò cominciare a studiarmi l' assembler

Quando faccio la compilazione del programma che scrivo in PIC basic mi vengono generati diversi file. Un .asm un .hex un .lst e un .mac. Contando le righe nel file .asm riesco a capire quante operazioni assembler occupa il mio programma?

[posta10100]

Contando le righe nel file .asm riesco a capire quante operazioni assembler occupa il mio programma?

Non basta contare le righe, ci sono istruzioni che vengono eseguite in un solo ciclo macchina (4 cicli di clock) e altre che ne richiedono 2 (non ricordo se ce ne sono di più lunghe).
Se guardi sul datasheet del PIC trovi per ciascuna istruzione la spiegazione di cosa fa e quanti cicli richiede.
Con tutte queste informazioni puoi calcolare il tempo di esecuzione.

[AlbertoBianchi]

Ciao, come ti suggeriva Robert8, lo strumento più idoneo per fare un acquisizione di questo tipo e senza dubbio l'analizzatore di stati logici; anch'io te lo consiglio vivamente. Girando intorno al PIC rischi di perdere ancora un sacco di tempo senza arrivare a nulla di concreto. E' un piccolo investimento che fa risparmiare un sacco di grane e di tempo, che potrai sfruttare in un sacco di altre occasioni. Io ho uno Zeroplus LAP-C 16032 che va benissimo, e quando l'acquistai, mi regalarono anche un sacco di moduli per l'analisi dei protocolli di comunicazione più diffusi.
A.

[Robert8]

Quindi i tempi si fanno un po' più larghi. Ora devo capire se potrò usare il picbasic o dovrò cominciare a studiarmi l' assembler

Studiare l'assembler non fa certo male ma, visto che i tempi non sono tanto stretti, con l'analizzatore logico te la cavi con poco:
1 - visualizzi i tempi di scrittura sulla RAM
2 - visualizzi i tempi di lettura del PIC
3 - adegui i tempi del PIC col PICbasic e ricicli le fasi 2 e 3 fino alla perfetta sincronizzazione.

[WALTERmwp]

o dovrò cominciare a studiarmi l' assembler

... in tal caso il controllo dell'output del listato assembler è un buon esercizio.
Ma se vuoi provare anche questa strada considera che, oltre alla corrispondenza dei tempi delle istruzioni, devi "leggere" il flusso del programma per determinare i periodi quindi, se ci sono, i loop(s), i salti e le call(s).

Saluti

[stex90]

molte volte ho sentito l' esigenza di uno strumento che mi aiutasse nell' analisi dei segnali logici ma non mi sono mai interessato più di tanto, e sopratutto non immaginavo fosse alla portata di tutte le tasche. Penso proprio che seguirò i vostri consigli e per natale mi regalerò un analizzatore logico!

Nell' attesa di averlo sottomano comincerò a fare qualche prova anche con un PIC serie 18.

Studiare l'assembler non fa certo male ma, visto che i tempi non sono tanto stretti, con l'analizzatore logico te la cavi con poco:
1 - visualizzi i tempi di scrittura sulla RAM
2 - visualizzi i tempi di lettura del PIC
3 - adegui i tempi del PIC col PICbasic e ricicli le fasi 2 e 3 fino alla perfetta sincronizzazione.

Robert8 parli di sincronizzazione tra il PIC e la ram. Ma utilizzando un PIC adeguatamente veloce, in teoria, se vado a leggere "nell' istante" in cui il write va basso, dovrei trovarmi l' indirizzo e i dati corretti senza dover aggiungere pause, e tanto meno sincronizzare le letture del PIC con le scritture della ram. Anche perché molto probabilmente non sono continue e precise nel tempo. E' corretto il mio punto di vista?

Vi ringrazio per le risposte. E continuerò a tenere aggiornata la discussione con gli sviluppi

[posta10100]

se vado a leggere "nell' istante" in cui il write va basso, dovrei trovarmi l' indirizzo e i dati corretti senza dover aggiungere pause, e tanto meno sincronizzare le letture del PIC con le scritture della ram.

Quello che dovresti fare è far generare un "interrupt on change" quando il pin di write cambia stato, nella routine di interrupt dovresti:
a - verificare che il nuovo stato sia basso (l'interrupt viene attivato anche per la transizione basso alto)
b- leggere l'indirizzo e il dato scritto
c- se l'indirizzo è tra quelli di interesse, salvare il dato da qualche parte


Se riesci a completare i passi a. b. entro il tempo in cui il pin write sta basso ed il passo c. mentre il pin è alto allora non dovresti avere problemi. Con un clock a 48MHz e con un software scritto bene ce la dovresti fare.

[Robert8]

Ma utilizzando un PIC adeguatamente veloce, in teoria, se vado a leggere "nell' istante" in cui il write va basso, dovrei trovarmi l' indirizzo e i dati corretti senza dover aggiungere pause

Non avendo la pallida idea sui valori di tWC, tPWE, etc, direi: in "teoria" non proprio e "nell'istante" nemmeno!
Perché l'istante del PIC potrebbe arrivare troppo tardi rispetto all'istante del WE:

Forse in pratica ti può andare bene: prova!

Non possedendo un analizzatore cercherei, prima di leggere indirizzo e dato, di valutare il tPWE con gli interrupt come suggerito da posta10100 e col minor numero possibile di istruzioni.
Ma anche così c'è il rischio di sotto campionare il WE valutandolo il doppio, il triplo o più, nel caso che il tPWE sia più breve del tempo di esecuzione di un interrupt.

Ma devi proprio leggere durante la scrittura