Hi,
When developing an OS for the smallest Atmels (ATtiny861/461/21)
i observed a strange effect. Sometimes, depending on the optimization
choosen by gcc, the compiler generates code which cannot be correct
(in my view). Most of the time the code is not functional too.
The problem is that use
So this begs the question... What *isn't* re-entrant?
The avr-libc docs mention:
strtok()re-entrant version: strtok_r()
rand() re-entrant version: rand_r()
random()re-entrant version: random_r()
eeprom_*() uses IO registers
strtod()uses errno
strtol()uses
Not a bug
According to the sources you posted,
privQueuRequestBody
void privQueuRequestBody(uint8_t uiSlot, int8_t siFreeFilling, uint16_t
uiTicksToWait) __attribute__ ( ( naked ) );
The relevant part being naked
That means gcc will omit prolog - which is where stack and frame pointer are
Ok you should not be using naked.
If function never returns (I mean never!) then it should be something
like this :
void main(void) __attribute__((noreturn));
-fomit-frame-pointer will work if gcc can really omit it.
Frame pointer will be used to store local variables that are to big to
Hi All,
Just a note to mention that Atmel has temporarily removed support for
the ATmega32HVB device. The latest release of WinAVR will no longer
support this device.
Anatoly, Joerg, I'll take care of submitting the patches to remove
support from binutils, gcc, and avr-libc. Anatoly, I will need