ElectroYou

Tra i vari progetti nel cassetto, dei quali non faccio mai nulla di concreto, c'è un firmware ormai sviluppato, che elabora un OP code di mia ideazione. Lo avevo studiato e scritto per una pazza idea chee è rimasta sepolta tra la moltitudine di altre idee. Ora è tornata alla ribalta... Se non ne farò nulla di pratico, almeno ne farò un altro articolo per il blog.

Per intanto il problema che ho, o meglio, l'idea che mi manca è come scrivere un debug. Mi spiego.
Il firmwarer scritto è per dei PIC ed implementa già una buona libreria di comunicazione che sarà l'interfaccia tra il PIC ed il resto del mondo. Tramite questa interfaccia, dialogo col codice ideato e posso leggere e modificare il programma: non il firmware del PIC, ma la parte compilata dalla mia utility. Ora vorrei fare il debug real time del mio codice, in modo che sul PC di programmazione possa mettere in animazione il risultato delle elaborazioni interne al PIC, (che per il vero potrebbe essere qualunque processore). Non mi viene in mente una idea brillante, semplice.
Le strade che ho in mente sono:
1) con un buffer ed una struttura dati predisposta, per ogni riga del mio OP code, memorizzo il risultato, oltre che nelle variabili di destinazione, anche nelle variabili del buffer di debug per la riga corrispondente e, successivamente, tutto il buffer viene inviato al PC per l'animazione.
2) dopo l'elaborazione di ogni riga, invio al PC il risultato dell'elaborazione.

La soluzione 1) prevede l'uso di parecchia memoria che può essere limitata facendo l'animazione per solo alcune righe di codice consecutive.
La soluzione 2) invece impiaga molte risorse di comunicazione, che tipicamente sono lente, e, quindi, rallenterebbero moltissimo l'elaborazione del programma. Non mi sembra affatto una bella idea.

Spero in qualche idea illuminante, semplificativa.

Quando scrivevo ad oggetti, era buon uso su nuovi progetti beta, creare dei log.
Devi sempre essere sicuro che la funzione stia facendo quello che deve fare, altrimenti #warning.
Ovviamente software per PC, significa avere i messaggi in real time.
Per il PIC potresti realizzare una funzione che ti stampa su display. Oppure molto meno complicato ma sempre simile alla scrittura ad oggetti, poi usare 4 porte, classificare i warning per codice, cioè #warning 1 = la funzione IC2 non ha trasmesso il dato, e fai accendere l'ultimo led dei 4.

Non so se ti possono essere di aiuto. comunque se vuoi fare un debug in live il modo migliore è comprare il PicKit 3 e con Mplab eseguire passo passo.

Ma cosa intendi per: "dialogo col codice ideato e posso leggere e modificare il programma" e "la parte compilata dalla mia utility" ? se non è il firmware del PIC cosa sarebbe? ti colleghi ad un PC? e hai un software con cui comunicare?

No, non mi interessa fare il debug al firmware che, tra l'altro, so abbastanza bene come farlo.
No, quello che mi interessa, è trovare il modo di animare l'elaborazione del mio interprete, che elabora un codice macchina di mia ideazione, simile a, anzi, questo:


Nel firmware del PIC ho scritto un interprete di codice, di cui, come scrivevo, posso fare download ed upload, ovviamente, altrimenti sarebbe inutile scrivere un interprete di codice macchina. Non mi interessa farne il debug, mi interessa trovare la formula migliore per offrirne l'animazione al tool di sviluppo che sto portando avanti.

Credo che, quando arriverò a quel punto, adotterò la soluzione del mio precedente punto 1). Ormai i PIC sono performanti anche in termini di RAM interna e, scegliendo quello giusto, troverò lo spazio anche per creare un buffer di cattura e, quindi, animazione del codice.

Quello che mi preoccupa di più è la formula, (ma si tratta di scrivere del software), per far si che l'animazione risultate sia fedele alla riga elaborata. In molti tool di sviluppo che mi trovo anche a dover usare, sovente l'animazione si riferisce allo stato della variabile come risultante a fine del loop interno, (per ragioni di sincronismo con la lettura/scrittura degli I/O), che però non è fedele alla riga analizzata, cosa che voglio evitare.
Quindi, appunto, alla fine se implementerò anche l'animatore dell'interprete, adottero una soluzione simile a quella discussa in 1).