Him
Vincent Trouilliez schrieb:
Thank you very much Ian, your code is highly efficient, and does work
perfectly, unlike or . :o) I am in heaven :
temp = (address 16) 0xFF;
28bc: ca 01 movwr24, r20
28be: aa 27 eor r26, r26
Hi,
if i read:
The code fragment,
...
dtostrf(cos_rad,6,3,line4[14]);
line3[20] = ' ';
line4[20] = ' ';
TRACE_ON(TRACE4); // portb |= _bv(04)
atan_rad = atan2(cos_rad,sin_rad);
TRACE_OFF(TRACE4); // portb = ~_bv(04)
dtostrf(atan_rad,6,3,line4[26]);
portb it looks like
Hi,
Loveny Design schrieb:
I wouldn't have thought the compiler was allowed to re-order statements
*around* a volatile access. Perhaps someone can help my understanding, given
:-
1: Volatile Statementssp
2: Statementssp
3: Volatile Statementssp
where sp is a sequence point.
Line 3 has a
Hi,
That's way too much code... Its fairly obvious where the optimisations
should be, although I can see that some have been done already.
I can't see much possibility for improving the above code (except by
removing the push and zeroing of r1). You asked for status to be a
volatile
Hi,
There is every reason. The flags get updated in interrupt routines and
in non-interrupt code.
Try the following version of set_status:
void set_status(uint32_t flag, uint8_t set) {
if (set) *(uint32_t* status) |= flag;
else *(uint32_t* status) = ~flag;
asm( : : :
