Ich habe in meinem Programmcode die Zeile int value = 0xAE+a[6]; stehen, was dem Compiler aber nicht gefällt. Er meckert immer: "ledswitch.c:88:15: error: invalid suffix "+a" on integer constant" Tasche ich 0xAE und a[6], dann ist alles OK. int value = a[6]+0xAE; Das kann doch irgendwie nicht richtig sein. Die Demoversion von Keils µVision macht da keine Schwirigkeiten. Auch fällt auf, dass jeder Compiler die MCU SFRs anders bennent. Mal heißen die Register GPIO_IOSET, mal nur IOSET oder FIO0SET und FIOSET. Gibt's da nicht sowas wie einen Standard? Das ist doch der Sinn von C, dass man seinen Code leichter portieren können soll.
Habe garade noch herausgefunden, dass wenn man ein Leerzeichen anhängt int value = 0xAE +a[6]; sich der Code compilieren lässt. Enthält die erst Hexzahl nicht nur Buchstaben, also z.B. 0x5+a[6], geht es auch ohne Leerzeichen. Irgendwie komisch?
Für C gibt es einen Standard. Aber für maschinenspzifische Dinge nicht. Mancher hält sich an Herstellernamen, andere nicht. Das Zahlenproblem hängt wohl irgendwie mit Fliesskommakonstanten zusammen, 15e+1. Muss mal sehen ob GCC da eigene Brötchen backt, denn im C Standard stellt das kein Problem dar.
Yep, C99 kennt Fliesskommakonstanten zur Basis 16. GCC erlaubt das auch bei C89. Die sehen zwar hinten anders aus, aber offenbar ist der betreffende Code im GCC nicht ganz wasserdicht.
Ich darf noch anmerken, dass FIO* = Fast General Purpose Input/Output GPIO* = General Purpose Input/Output bedeutet und nicht dasselbe ist (siehe LPC Handbuch)
GCC hat wie üblich recht: "0xAE+a" ein einziges Token, wenngleich ein ungültiges. Siehe http://www.math.uni-wuppertal.de/~axel/skripte/oop/oopA2.html Stichwort "pp-number".
>Auch fällt auf, dass jeder Compiler die MCU SFRs anders bennent. >Mal heißen die Register GPIO_IOSET, mal nur IOSET oder FIO0SET und >FIOSET. Gibt's da nicht sowas wie einen Standard? Das ist doch der >Sinn von C, dass man seinen Code leichter portieren können soll. Nicht der Compiler benennt, es werden lediglich von den Compilerherstellern oder bei GNU den "Toolchain-Zusammenpackern" (im Fall von WinARM bin das ich) Definitionsdateien mitgeliefert, in denen die SFR-Addressen manchmal etwas "individuell" bezeichnet werden. Das hat nichts mit der Programmiersprache zu tun. Ansich ist es Sache der Hersteller, entsprechende Definitionsdateien auf Grundlage der Bezeichnungen des Datenblatts herauszugeben und damit einen de-facto Standard zu schaffen, es ist ja nicht wirklich im Interesse der "Kommerziellen". Dies wird auch von vielen Herstellern so gemacht (z.B. f. STR7, AT91, ADuC7000), aber es haellt sich dennoch nicht jeder daran (wie bereits von A.K. angemerkt). Bei Philips ist in diesem Bereich noch ein wenig Nachholbedarf. Im Moment gibt es meines Wissens nur "offizielle" Definitionen fuer LPC214x im "Sample Code Bundle" (Addressen sind aber bei andere LPC2000 meist identisch so die Funktion im Controller vorhanden). Oft werden fuer Philips ARM die Definitionen von Keil genutzt (www.keil.com->Device-Database->Header Files). Es gibt allerdings wie erkannt auch andere (newlib-lpc, GNUARM...). Man kann aber beim Portieren allermeistens die Definitionsdatei fuer den urspruenglichen Code nutzen und erspart sich damit Anpassungsarbeit. Martin Thomas
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.