Hi,
last night I decided to bite the bullet and coded all of my interrupt in
assembly
which allowed me to rise the interrupt frequency from 60 kHz up to 170 kHz after
which it it leaves so few cycles for the anything else that the USB stack stops
working. This is fine, as at my target freq of 120
>I can currently not verify this, but anyways: I think that union's were
>and possibly are implicitly
>treated as volatile by SDCC and/or the PIC backend(s) due to problems in
>maintaining correct
>potential alias sets. This might explain the bad code that is generated
>for the a+=b operation
>
Hi,
I can currently not verify this, but anyways: I think that union's were and
possibly are implicitly treated as volatile by SDCC and/or the PIC
backend(s) due to problems in maintaining correct potential alias sets.
This might explain the bad code that is generated for the a+=b operation
you se
Right,
sorry about that.
I'm working on PIC18F4550.
Compilable function ... well I can give you the defs and a code
snippet:
typedef struct {
union {
uint16_t nco;
struct {
unsigned nco_low_bits :15;
unsigned nco_hi_bit :1;
};
};
struct {
unsigned has_next :1;
unsigned reserv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I think it would be helpful to readers of your post, if you'd
* State which target this is about
* State which data types the variables are (or even better: give a
compileable function)
While these could be inferred from the assembly code you posted,
Hi,
its me again ;)
Any idea how difficult it would be to add optimisation operators like
'+=' and company?
Here is a piece of compiled C from my project:
; .line 150; stepperirq.c MOTOR.nco += MOTOR.speed;
MOVF (_g + 10), W, B
ADDWF (_g + 4), W, B
MOVWF r0x00
MOVF (_g + 11), W, B
ADDWFC
