Tips & Tricks - PIC

 

 


Un Template "alla nostra maniera" 


Vediamo nei dettagli come è strutturato un template "alla nostra maniera".

Va da sè che:

  • usare questo o quell' altro template non è un obbligo, ma una facilitazione
  • il template non nega la creatività di ognuno, come non la nega la carta millimetrata. Quindi è ben possibile, una volta afferrato il concetto, modificare un template, aggiungendo, togliendo o variando parti e sequenze, adattandole insomma, alla propria "mano".
  • e, nello steso senso, è ben possibile modificare, tagliare, sopprimere, ampliare parti del template-modello dove l' applicazione non lo richieda. E aggiungerne altre nuove dove sia richiesto.

Quindi, quello proposto è solo una linea guida che potrà essere variato come meglio si desidera, sempre nel senso fino ad ora indicato.

In particolare:

  •  l' uso di righe composto praticamente di soli segni del genere *** o ### o === o ---- è utile per evidenziare le varie sezioni del sorgente, ma ognuno le potrà adattare al proprio gusto.
  • così come le spaziature e la formattazione generale del testo.

Un particolare vantaggio sarà dato dall' uso di un editor specifico per la programmazione, con la funzione di colorare le parti del testo a seconda del loro scopo nel sorgente stesso. Anche se i colori sono spesso programmabili dall' utente, solitamente si avrà:

  • in verde quegli elementi del testo che saranno considerati come commenti dall' assembler.
  • in blu gli opcodes
  • in viola le direttive
  • In nero le linee che faranno parte della compilazione.

Usualmente Il testo è scritto utilizzando un carattere monospace, tipo Courier, per avere allineamenti che aiutano nella lettura del testo. Classica la buona abitudine di sistemare in colonne successive rientranti gli statements di #if, per allinearli con i relativi #else o #endif allo scopo di tenerne sotto controllo visivo la struttura ed evitare la mancata chiusura

Occorre anche ricordare che, in generale, i compilatori sono case sensitive, ovvero distinguono maiuscole e minuscole. Anche se può essere possibile escludere questa opzione, è molto più pratico mantenerla attiva, dato che consente un maggior numero di label possibili e, sopratutto, una via per differenziare "a vista" elementi del programma. Caso speciale, solitamente, è costituito da statements, opcodes e, in generale, tutte parole riservate che potranno essere scritte sia con maiuscole o minuscole.
In questo campo non esistono leggi specifiche, ma solo convenzioni di stile, per cui, ad esempio, in un testo si useranno le parole riservate tutte in maiuscolo o tutte in minuscolo, senza mescolare le due forme.
Per curiosità, dal punto di vista psicologico, i caratteri maiuscoli sono meno facilmente leggibili dei minuscoli, ma sono molto evidenti parole in maiuscolo in un insieme di parole in minuscolo.
E' uso comune anche scrivere le label delle macro in maiuscolo, così pure come le costanti, mentre le variabili useranno minuscole.

In ogni caso, è facile notare che la forma in cui il testo è scritto può facilitare la rilettura, se ben formattato, ma anche complicarla se mal disposto (e questo solamente in relazione al layout grafico e non alla struttura logica).

Naturalmente, nonostante tutte le possibili migliorie, un programma in linguaggio Assembly o in C è quasi illeggibile per chi non conosce sufficientemente il linguaggio. Ma una buona impostazione è sicuramente di aiuto per una lettura e comprensione del sorgente non solo per altri, ma anche per l' autore stesso.

Un buon template segue la logica base di un programma, che comprende:

  • una introduzione, che non fa parte delle istruzioni, ma è fondamentale per capire cosa si va a  fare.
    Questo serve sia come documentazione, per se e per gli altri, sia per chiarirsi le idee prima di buttare giù righe di istruzioni
  • una parte iniziale di descrizione dell' ambiente di lavoro, sempre sia a scopo documentale, sia per la chiarezza delle idee

Quindi trova posto il sorgente vero e proprio, inserendo nell' ordine, le parti obbligatorie:

  • la definizione del processore, dalla sua configurazione, ecc
  • l' area delle risorse incluse (librerie, macro, ecc)
  • la definizione dell' uso della memoria RAM e EEPROM
  • la definizione dell' uso dei port

Tutte queste parti sono comuni ad un certo processore o famiglia di processori e potranno essere spesso riportate a copia-e-incolla oppure modificandone piccole parti per adattarle all' applicazione.

Va compreso che la parte "introduttiva" ha altrettanta importanza della sequenza delle istruzioni vere e proprie: la definizione dell' uso della memoria, la configurazione, la definizione dell' uso dei port, scritte in modo logico e chiaro, non solo rendono leggibile il sorgente, ma costituiscono un elemento chiave per l' uso di quel determinato processore in quella determinata applicazione. 

Ora possiamo iniziare le istruzioni vere e proprie:

  • il vettore del reset
  • il vettore dell' interrupt
  • il programma principale

Nella coda del testo inseriremo: 

  • driver, librerie, tabelle, e quant' altro di predisposto e che non ha bisogno di rientare nell' area di lettura principale, perchè già provato funzionante
  • l' obbligatorio END che chiude il sorgente

Vediamo un esempio.

Nota: non formalizzatevi sul contenuto: a puro scopo esemplificativo sono state inserite linee ed elementi presi a caso da vari programmi,che, in questo ambito non hanno alcun senso compiuto se non quello di fornire un campione di come può essere compilata la sezione. Quello che importa è afferrare il senso del template.


  1. Il Titolo

  2. Definizione del processore

  3. Definizione degli I/O

  4. Condizioni di compilazione

  5. Configurazione del processore

  6. Fare lavorare MPASM

  7. Definire la memoria

  8. Le MACRO

  9. START: il Vettore del Reset

  10. Interrupt

  11. MACRO-Sub e tabelle

  12. Inizializzazione delle periferiche

  13. Programma principale

  14. Moduli, driver, librerie

  15. La coda


Copyright © afg . Tutti i diritti riservati.
Aggiornato il 23/05/12 .