Worin liegen Unterschiede zwischen GCC und IAR C Compiler für AVR? - Sind die erzeugten HEX-Files vom IAR besser als die vom GCC? - Ist der C Syntax anders? - Sind die Header Files gleich?
Hi >- Sind die erzeugten HEX-Files vom IAR besser als die vom GCC? Anderst: Ja. Besser? Kommt auf die Betrachtungsweise an. IAR erzeugt wohl besseren (schneller, kleiner) Code als der GCC. Das Verhältnis Preis/Qualität ist aber beim GCC deutlich besser. >- Ist der C Syntax anders? Ja, insbesonder beim Handling von Konstanten im Flash und bei der ISR-Handhabung. >- Sind die Header Files gleich? Die C-Standard-Header sollten es (zumidest in größeren Teilen) sein. Alles was mit IO und Hardware zu tun hat wird anderst sein. Matthias
> Alles was mit IO und Hardware zu tun hat wird anderst sein. Nö, nicht so schlimm. Nachdem vor ca. 5 Jahren GCC nachgezogen hat und die inp()- und outp()-Notwendigkeit entfallen ist, benutzen praktisch alle AVR-C-Compiler die von Atmel in den Datenblättern und Beispielen angwandte Form der direkten Portzuweisung (PORTB = 42; i = PIND; ...). Neben den schon genannten Dingen bezüglich memory spaces (RAM vs. Flash-ROM vs. EEPROM) und Interrupts sind es vor allem Kleinigkeiten. So werden beim IAR Interrupts mit __enable_interrupt() ein- und mit __disable_interrupt() wieder ausgeschaltet, bei avr-libc nimmt man sei() und cli(). Der IAR erzeugt im Durchschnitt vielleicht 10...15 % kompakteren Code, wobei ich letztens bei einer zeitkritischen Anwendung feststellen musste, dass ein GCC mit -O3 zwar nochmal weitere 10 % auf die Codegröße drauflegt, aber dafür auch ca. 10 % schneller war als der IAR in seiner schnellsten Optimierung. Das ist natürlich jetzt alles andere als repräsentativ, aber vielleicht ein Anhaltspunkt. Zum IAR wird eine kommerzielle libc von P. J. Plauger (eine der ,,Urgrößen'' von C) mitgeliefert, die wirklich alles abdeckt, was der Standard bietet -- bis hin zu einer kompletten Implementierung von wide chars und einem kompletten EC++ (embedded C++). Dann gibt es wieder andere Dinge, in denen ein GCC oder eine avr-libc eindeutig die Nase vorn haben. Die inline-assembler-Funktionalität von GCC lässt vermutlich jeden anderen Compiler komplett links liegen, so kryptisch sie auch zu benutzen sein mag. Beim IAR kann man dem asm-Statement keinerlei Parameter (Variablen aus dem C-Programm etc.) zuweisen, für alles, was über ein einfaches »asm("nop");« hinausgeht, begiebt man sich also auf ein ziemliches Glatteis, dass die nächste Compilerversion intern irgendwas anders tun könnte als die jetzige. (GCC inline asm ist wahrscheinlich am interessantesten für die Implementeure der Bibliothek selbst, gar nicht mal so sehr für den Endanwender.) Die umfassende generische C-Bibliothek hat auch ihre Schattenseiten: alles, was AVR-spezifisch wird, kommt eher knapp weg. So haben die stdio-Funktionen keine vollständigen Satz von Parallelfunktionen mit angehängtem _P (Formatstring liegt im program space), besonders die wichtige Funktion vfprintf_P() fehlt. Andere der Annehmlichkeiten der avr-libc wie verallgemeinerte Behandlung von sleep_mode und watchdog fehlen ebenfalls.
"begibt" schreibt sich natürlich ohne "ie". ;-)
Gast
#363757
Ein Punkt wäre vielleicht noch erwähnenswert. Beim IAR kann man recht einfach auf double umschalten. Es wird dann eine andere Lib verwendet, die dann mit 64-Bit für float/double rechnet. Ist recht schnell.