Sì.Praticamente tutto in un MCU può essere interrotto da una richiesta di interruzione.Quando il gestore degli interrupt completa, il codice precedente continuerà semplicemente, quindi di solito non è un problema.

In un caso speciale, i gestori di interrupt possono essere interrotti da soli interrupt di priorità più alta (interrupt annidati).

Se una serie di istruzioni non deve essere interrotta, è necessario implementare una sezione critica (fondamentalmente disabilitare globalmente gli interrupt, fare il lavoro, abilitare di nuovo).

Ricorda che, a seconda dell'architettura della CPU di destinazione, una singola riga di C può essere compilata per molte istruzioni di assemblaggio.Un semplice i ++ su un AVR viene compilato in più istruzioni se i è ad esempio uint32_t .

Qualsiasi operazione che non sia atomica può essere disturbata da un interrupt.Questo tipo di programmazione è spesso molto diverso dalla maggior parte degli altri programmi e può creare confusione per le persone che non hanno studiato la progettazione del processore o l'architettura del computer.

Potresti pensare a te stesso "Questo non accadrà mai, quanto tempo ci vuole per copiare questo codice e quanto è probabile che si verifichi un'interruzione?"Ma con la maggior parte delle applicazioni incorporate di produzione accadrà perché il prodotto è attivo per anni senza aggiornamenti.

L'altro problema con le copie di struct come questa è che quando si verificano sono straordinariamente difficili da eseguire il debug perché si verificano solo quando l'interrupt si verifica al momento giusto (che può durare anche un solo ciclo).

Il punto centrale delle interruzioni è che possono (e accadono) tutto il tempo e sono progettate per avere un impatto zero su qualsiasi codice che sia in esecuzione quando si verificano. Tutti i registri vengono salvati e, a seconda dell'architettura della CPU, può essere scambiato un set di registri completamente diverso, l'interrupt fa la sua cosa, quindi i registri originali vengono ripristinati e il codice continua a funzionare normalmente.

Possono verificarsi problemi quando la stessa routine del servizio di interruzione tenta di accedere alla memoria a cui accede il codice interrotto in esecuzione. Errori ancora più sottili possono verificarsi quando un processo di I / O critico in termini di tempo viene interrotto. Questi problemi sono comuni con architetture più vecchie, più semplici e meno sicure in cui può esserci poca separazione tra il codice in modalità "utente" e "supervisore / kernel".

Questo tipo di problema può essere difficile da identificare e spesso difficile da riprodurre, ma una volta identificato è spesso abbastanza banale da risolvere utilizzando la programmazione difensiva, mutex / semafori o semplicemente disabilitando gli interrupt nelle sezioni critiche del codice.

La classe generale di problemi è stata ampiamente studiata e le moderne CPU multi-core e persino i sistemi operativi multi-tasking non sarebbero possibili se non fossero già state provate e testate più soluzioni.

Vado avanti e presumo che tu l'abbia chiesto per un'ottima ragione.

  * Data_external = Data_internal;
 

Può essere diviso (salvo alcuni casi limite che è improbabile che siano in gioco qui).

Non conosco la tua CPU ma non ho ancora visto una CPU che non possa fare l'equivalente morale di:

  cli ();/ * maschera tutti gli interrupt * /
* Data_external = Data_internal;
sti ();/ * ripristina la maschera di interruzione * /
 

Ora non può essere diviso su nessuna CPU single core perché nulla può interrompere mentre gli interrupt sono disattivati.Che questa sia o meno una buona idea dipende da molte cose che semplicemente non sono qualificato per valutare.

Se sei multi-core (e finalmente mi sono ricordato che sul mercato esiste una CPU embedded multi-core) non farlo.Non ha valore.Avresti bisogno di sviluppare un lock appropriato.

Il codice così come lo hai presentato può essere effettivamente interrotto.Tuttavia, prima di iniziare a creare sezioni critiche ovunque, dovresti controllare alcune cose:

• Dici che questa funzione è "all'interno di un driver".Gli interrupt sono già disabilitati quando viene chiamata questa funzione?O è chiamato all'interno di un gestore di interrupt che impedisce l'attivazione di altri interrupt?In caso affermativo, l'operazione non può infatti essere interrotta.

• È mai stato effettuato l'accesso a Data_internal all'interno di un gestore di interrupt?In caso contrario, non ci sono danni anche se l'operazione può essere interrotta.

[Rappresentante insufficiente per commentare]

Un altro trucco con quel tipo di copia della struttura è che è una copia superficiale.Potrebbe essere necessaria una copia completa.

Una copia superficiale potrebbe forse, ma non probabilmente, essere atomica, a seconda dell'architettura della macchina.Una copia profonda quasi certamente non è atomica su nessuna architettura.

Un'implementazione di qualità adatta all'uso in sistemi embedded documenterà come le letture o le scritture volatili qualificate di vario tipo verranno eseguite in modo sufficientemente dettagliato per indicare se e come possono essere "divise" da interruzioni e anche se le letture e le scritture volatili sono sequenziate rispetto a letture e scritture non qualificate. Sebbene alcune implementazioni possano comportarsi come se tutte le letture e le scritture fossero volatili qualificate, ci si aspetta generalmente che le implementazioni siano libere di elaborare sequenze di letture e scritture non qualificate in qualunque modo sarebbe più efficiente quando ci sono nessun accesso volatile intermedio.

Su un tipico microcontrollore a 32 bit, legge e scrive di tipi interi qualificati volatile di 32 bit e inferiori; un compito consisterà in una lettura atomica seguita da una scrittura atomica. Se vuoi assicurarti che una struttura a 32 bit venga copiata atomicamente, inseriscila in un'unione con un uint32_t e leggi o scrivi quel membro per leggere o scrivere la struttura nel suo insieme. Le implementazioni di qualità che sono configurate per essere adatte all'uso di sistemi embedded consentiranno ai sindacati di essere impiegati in tale modo senza considerare se lo Standard richiederebbe implementazioni che non sono destinate a tale uso per fare altrettanto. Nota che gcc e clang non si comporteranno in modo affidabile come implementazioni di qualità adatte all'uso da parte di sistemi embedded a meno che non siano disabilitate varie ottimizzazioni.