Inside the driver I have got a function to copy the data from the internal struct into a struct from the application.
Can this process be interrupted by a microcontroller interrupt trigger?
uint16_t getRawData(struct Data *Data_external) { if(Data_external == NULL) { return ERR_PARA; } else { *Data_external = Data_internal; // the copy process. Could this be interrupted? } return ERR_NONE; } Yes. Pretty much everything in an MCU can be interrupted by an interrupt request. When the interrupt handler completes the previous code will just continue so it is usually not a problem.
In a special case the interrupt handlers can be interrupted themselves by interrupts of higher priorities (nested interrupts).
If a series of instructions must not be interrupted then you need to implement a critical section (basically globally disable interrupts, do the job, enable again).
Remember that depending on architecture of the target CPU a single line of C can be compiled to many assembly instructions. A simple i++ on an AVR is compiled to multiple instructions if i is for example uint32_t.
Any operation that is not atomic can be interfered with by an interrupt. This kind of programming is often very different than most other programming and can be confusing to people who haven't studied processor design or computer architecture.
You may think to yourself "This will never actually happen, how long does this code take to copy and how likely is an interrupt?" But with most production embedded applications it will happen because the product is on for years without updates.
The other issue with struct copies like this is when they do happen they are extraordinarily difficult to debug because they only happen when the interrupt occurs at just the right time (which can be as little as one cycle).
The whole point of interrupts is that they can (and do) happen all the time, and are designed to have zero impact on any code that happens to be running when they occur. All the registers are saved, and depending on the CPU architecture, a completely different register set may be swapped in, the interrupt does its thing, and then the original registers are restored and the code continues to run as normal.
Problems can occur when the interrupt service routine itself tries to access memory that is being accessed by the running, interrupted code. Even more subtle errors can occur when a time-critical I/O process is interrupted. These problems are commonplace with older, simpler, less secure architectures where there may be little separation between "user" and "supervisor/kernel" mode code.
This kind of problem can be hard to identify, and often difficult to reproduce, but once identified they're often fairly trivial to fix using defensive programming, mutexes/semaphores or simply by disabling interrupts in critical sections of code.
The general class of problems has been studied extensively, and modern multi-core CPUs and even multi-tasking operating systems would not be possible if multiple solutions were not already tried and tested.
I'm just going to go ahead and assume you asked this for a very good reason.
*Data_external = Data_internal; Can be split (barring some edge cases that are unlikely to be in play here).
I don't know your CPU but I haven't seen a CPU yet that can't do the moral equivalent of:
cli(); /* mask all interrupts */ *Data_external = Data_internal; sti(); /* restore interrupt mask */ Now it can't be split on any single core CPU because nothing can interrupt while interrupts are off. Whether or not this is a good idea depends on a lot of things that I'm simply not qualified to evaluate.
If you are multi-core (and I finally remembered there is a multi-core embedded CPU on the market) don't do this. It is worthless. You would need to develop proper locking.
The code as you presented it indeed can be interrupted. However, before you start making critical sections all over the place, you should check a few things:
You say this function is "inside a driver". Are interrupts already disabled when this function is called? Or is it called inside an interrupt handler which prevents other interrupts from triggering? If yes, the operation cannot in fact be interrupted.
Is Data_internal ever accessed inside an interrupt handler? If not, there is no harm even if the operation can be interrupted.
[Not enough rep to comment]
Another gotchya with that kind of struct copy is that it is a shallow copy. You may need a deep copy instead.
A shallow copy could possibly but not likely be atomic, depending on machine architecture. A deep copy is almost certainly not atomic on any architecture.
A quality implementation suitable for embedded-systems use will document how volatile-qualified reads or writes of various types will be performed in sufficient detail to indicate whether and how they may be "split" by interrupts, and also whether or not volatile reads and writes are sequenced with regard to non-qualified reads and writes. While some implementations may behave as though all reads and writes are volatile-qualified, implementations are generally expected to be free to process sequences of non-qualified reads and writes in whatever fashion would be most efficient when there are no intervening volatile accesses.
On a typical 32-bit microcontroller, reads and writes of volatile-qualified integer types that are 32 bits and smaller; an assignment will consist of an atomic read followed by an atomic write. If you want to ensure that a 32-bit structure is copied atomically, place it in a union with a uint32_t, and read or write that member to read or write the structure as a whole. Quality implementations that are configured to be suitable for embedded systems use will allow unions to be employed in such fashion without regard for whether the Standard would require implementations that aren't intended for such use to do likewise. Note that gcc and clang will not reliably behave as quality implementations suitable for embedded systems use unless various optimizations are disabled.
