Hi @all,
ich habe ein Problem mit inline Funktionen da diese nicht "echt"
inline sind ... z.B.
inline void HAL_USART_INIT(unsigned int wUBRR){
UBRR0H = (unsigned char)(wUBRR>>8);
UBRR0L = (unsigned char)wUBRR;
UCSR0B = (1<<RXEN0)|(1<<TXEN0);
UCSR0C = (1<<USBS0)|(3<<UCSZ00);
}
=> Dissassembly
10: HAL_INIT();
+00000042: D01B RCALL PC+0x001C Relative call subroutine
genau das wollte ich aber eigentlich verhindern?? Was besser
funktionierte (zumindest bzgl. Codegröße) war:
#define HAL_USART_INIT(ubrr) \
UBRR0H = (ubrr>>8); \
UBRR0L = ubrr; \
UCSR0B = (1<<RXEN0)|(1<<TXEN0); \
UCSR0C = (1<<USBS0)|(3<<UCSZ00);
allerdings hab ich hier keinerlei Typsicherheit und IMHO ist es auch
kein guter Stil (oder??). Ich hätte auch gedacht ich könnte inline Fkt.
direkt in der Header-File definieren allerdings bekomm ich dann immer
den Fehler:
gcc plug-in: Error: Object file not found on expected location [..]
Bin für jeden Tipp dankbar!
so long ... Lif
Gast
#285659
Prüfe mal den Optimierungslevel. Also bei mir wird bei O2 inline auch zu inline.
So kenn ich das gar nicht. Bei mir tut das:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
Allerdings ist bei mir -O2 eingeschaltet.
__attribute__((always_inline)) sollte man mit inline kombinieren. Den Fehler hatte ich kürzlich auch in der avr-libc begangen, das inline dabei wegzulassen... Normalerweise benutzt der Compiler halt eine Heuristik, ab der er denkt, dass es lohnt, die Funktion wirklich inline zu erweitern, andernfalls wird sie wie eine normale Funktion behandelt.