PIC a 8 bit e funzioni "atomiche"

[ivanpascolo]

Ho scoperto da poco il significato delle funzioni atomiche e cosa può succedere se modifico una variabile a 16/32bit durante l'interrupt (e la leggo nel main).
Da allora cerco di starci attento, ma la domanda a questo punto è: se faccio un "if (x== numero)" dove entrambi le variabili sono a 8 bit e la variabile "x" viene incrementata in interrupt rischio ugualmente il problema?
L'istruzione "if..." in assembler viene tradotta come segue

0x20: MOVF x, W
0x21: XORWF numero, W
0x22: BTFSC STATUS, 0x2

Se alla righe 0x21 arriva l'interrupt cosa succede? Se sotto interrupt modifico solo variabili a 8 bit posso stare tranquillo?

Grazie
Ivan

[luxinterior]

Se l'interrupt scrive il valore a 8bit e il main lo utilizza o vceversa non succede nulla
Il tuo if viene tradotto in tre istruzioni se lì'interrupt capita prima del MOVF l'if userà il valore aggiornato dall'interrupt altrimenti il test viene fatto con il valore attuale. L'interrupt potrà aggiornare il valore attuale di x nel mezzo delle tre istruzioni assembler che compongono l'if ma il main se ne accorgera al "prossimo giro" quando ripeterà la sequenza delle tre istruzioni.
Se vuoi essere certo che x venga utilizzato solo dopo che l'interrupt lo ha aggiornato potresti usare uan variabile di stato o un semplice flag ceh l'interrupt mette a 1 e il main controlla e azzera nell'esecuzione dle codice condizionato

[WALTERmwp]

Ciao @ivanpascolo

(...) Se sotto interrupt modifico solo variabili a 8 bit posso stare tranquillo?

non so se fai riferimento a una casistica definita ma io suggerirei di lavorare su variabili differenti recuperando poi, nel main (o sua funzione), l'informazione del transito nella irq.
Infatti, il codice scritto ad alto livello potrebbe riservarti altre sorprese, le combinazioni sono più d'una.

Saluti

[TardoFreak]

Classico problema della sezione critica (se ci sono dati condivisi).

[ivanpascolo]

Diciamo che non mi interessa se l'istruzione "if" viene eseguita con il valore precedente, quindi è OK.
Se utilizzo un flag credo ci sia ancora margine di errore, ad esempio se l'interrupt arriva appena letto lo stato del flag o sbaglio?
L'unica soluzione sicura è disabilitare l'interrupt per fare un passaggio di variabile (o eseguire l'intera istruzione), soluzione che non mi piace per niente.

[WALTERmwp]

Se utilizzo un flag credo ci sia ancora margine di errore, ad esempio se l'interrupt arriva appena letto lo stato del flag o sbaglio?

non so, dipende sempre da come fai quello che fai.
E' solo una questione di gestione di risorse definite, come per esempio per le variabili globali.
Andare a disabilitare il controllo generale degli interrupts solo per agire in via cautelativa mi pare veramente eccessivo.

Saluti

[Brianz]

Mi sembra che un problema si ponga solo se stai utilizzando una struttura logica non corretta rispetto al processo.
Se una variabile (che sia a 8 o 128 bit) viene modificata in interrupt e la analizzi al di fuori dell’interrupt è evidente che devi completare l’analisi PRIMA di un nuovo evento di interrupt, altrimenti non potrai mai avere un risultato corretto.

[TardoFreak]

Nel caso evidenziato da Brianz è sufficiente sincronizzare il programma principale con la interrupt. Basta un flag per sapere se la interrupt h già svolto il suo lavoro.
Nel main

Codice: Seleziona tutto

// Variabile globale di sincronizzazione 
uint8_t flag = 0;
{
  ...
  // Aspetta la sincronizzazione
  flag = 0;
  while(!flag);
  // Sezione critica
  ...
}

Nella interrupt

Codice: Seleziona tutto

{
  // Esegue la funzione di servizio
  ...
  flag = 1;
}

[ivanpascolo]

Adesso è tutto più' chiaro, grazie mille per i vostri consigli.