We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I get strange behaviour with integer conversion; in the following example T4Frozen never reaches the value 790 because it turn back to 700 when it step over 767. This happen both on the target and on Dscope.
T4Frozen=700; while(TRUE){ PeriodoEncoder=(float)T4Frozen; PeriodoEncoder/=2.5; T4Frozen++; if(T4Frozen>790){ Dummy=700; } }
Integer to float conversion is correct (we have tested it); it was only our first hypothesis to address the problem. In order to clarify what I mean our problem is to make use of a float variable but unfortunately the variable is set by an ISR (max priority) and read (and used) by main loop procedure; the value read by main is sometime not correct (depending on the frequency of ISR). Is it possible that a 32 bit float is affected by ISR during main loop reading in the way that low 16 bit are "old" and the high 16 bit are "new"? If so, which treatments can I adopt to avoid this problem? Compiler version 4.11 Linker 4.10 IDE version 2.14 Thanks a lot for your answers
Have you declared it volatile? "Is it possible that a 32 bit float is affected by ISR during main loop reading in the way that low 16 bit are 'old' and the high 16 bit are 'new'?" Yes: of course that is entirely possible - due to the very nature of the way interrupts work! And, of course, it's even worse with floats because the processor has to do a lot of work to handle them - so even more chance for an interrupt to happen in the middle of it! "If so, which treatments can I adopt to avoid this problem?" Err - disable the interrupt...? BTW: do you really need to use floating point? Have you considered fixed-point? (wouldn't make any difference to this particular problem, though).
I would strongly recommend not using floats inside an ISR at all. Aside from the fact that any operation on a float is fairly time consuming it involves calls to library functions which I would guess are not reentrant. If this is the case your ISR could corrupt any floating point calculations anywhere in your program, not just ones involving the FP variable modified in the ISR. Whenever you need to share any multibyte variable between an ISR and the rest of your program you must declare it as volatile and also disable interrupts while accessing it outwith the ISR. I like to use a function similar to this: long ReadSharedLong(long *shared) { long temp; EA=0; temp=*shared; EA=1; return(temp); } Stefan
Or try:
#pragma DISABLE long ReadSharedLong(long *shared) { return(*shared); }
We use floats into main and 2 ISRs, and so I'm really worried about: Aside from the fact that any operation on a float ... involves calls to library functions which I would guess are not reentrant This is much more difficult to manage than data consistence. We can't disable interrupts (or at least one of them) so we are trying to use integers where it is possible, and could be hard work. Any other way could be dangerous. Thanks a lot
Alfredo, Please note that I do not know whether the FP library functions are reentrant or not. You need to check the manuals or check with Keil if the info isn't there. Stefan
We have posted a technical request directly to keil because the problem is still active and we are thinking that it is binded in some way to floating point library. Strained all the gnats but still swallowing the camel! Thanks again