Read incomming message in an Interrupt handler

[Folknology]

Out of interest does mixing interrupts and events in this manner break the determinism of XC?

regards
Al

[neon]

Hey Richard,

thanks for your advice.

I will change this in my code

regards
Bernhard

[richard]

I would also assume like yourself that the XC compiler isn't bothered that GlobalTemp isn't constant or initialised/written too as long as the threads only ever read from it. I'm guessing the compiler only ever looks at global variable writes to detect disjointedness.

Yes, so long as a variable is only read from you can access it from any number of threads. Since the interrupt handler is written in assembly the disjointness checking won't know about the write to GlobalTemp and so it won't error.

There is a danger that updating variables in this way behind the compiler's back could cause optimisations to change the behavior of the code. For example consider:

Code: Select all

int global;
void f(port p) {
  while (1) {
    p <: global;
  }
}

The compiler is free to optimise this to:

Code: Select all

int global;
void f(port p) {
  int tmp = global;
  while (1) {
    p <: tmp;
  }
}

If the global variable is changed in an interrupt handler then in the optimised version the value on the port will never change. Instead of using the global directly in XC it would be safer to define an assembly function which reads and returns the value of the global. You would call this function from XC whenever you need to know its value of the global. This would prevent any optimisations that would be unsafe due to the value being updated behind the compiler's back. Alternatively if you are accessing the global from C you could mark it as volatile to indicate that the value could change at any time.

The code neon posted will work (at least with the current compiler) since there is a call to a function (printf) which, as far as the compiler is concerned, might change the value of the global. Because of this the compiler will reload the value of the global each time around the loop. In future this might change. For example the compiler might recognise printf as a standard library function and understand that it doesn't write to globals that are nothing to do with file I/O).

[richard]

Out of interest does mixing interrupts and events in this manner break the determinism of XC?

It certainly makes it harder to reason about the timing of the code you are interrupting. You must allow for the fact that an interrupt could happen at any time resulting in the current task being paused for the amount of time it takes to handle the interrupt. If you know how long it takes to handle the interrupt and the maximum rate at which the interrupt can fire you could still calculate the worse case timing. The XTA has no concept of interrupts so you would need to factor this information in yourself.