Out of interest does mixing interrupts and events in this manner break the determinism of XC?
regards
Al
Read incomming message in an Interrupt handler
-
- XCore Legend
- Posts: 1274
- Joined: Thu Dec 10, 2009 10:20 pm
-
- Junior Member
- Posts: 7
- Joined: Tue Nov 02, 2010 9:56 am
Hey Richard,
thanks for your advice.
I will change this in my code
regards
Bernhard
thanks for your advice.
I will change this in my code
regards
Bernhard
-
- Respected Member
- Posts: 318
- Joined: Tue Dec 15, 2009 12:46 am
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.Folknology wrote: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.
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;
}
}
Code: Select all
int global;
void f(port p) {
int tmp = global;
while (1) {
p <: tmp;
}
}
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).
-
- Respected Member
- Posts: 318
- Joined: Tue Dec 15, 2009 12:46 am
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.Folknology wrote:Out of interest does mixing interrupts and events in this manner break the determinism of XC?