Forum: Mikrocontroller und Digitale Elektronik Bug in WinARM (LPC2103TDMI)


von Bernd (Gast)


Lesenswert?

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.

von Bernd (Gast)


Lesenswert?

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?

von A.K. (Gast)


Lesenswert?

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.

von A.K. (Gast)


Lesenswert?

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.

von manu (Gast)


Lesenswert?

Ich darf noch anmerken, dass
      FIO*  = Fast General Purpose Input/Output
      GPIO* = General Purpose Input/Output
bedeutet und nicht dasselbe ist (siehe LPC Handbuch)

von A.K. (Gast)


Lesenswert?

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".

von Martin Thomas (Gast)


Lesenswert?

>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
Noch kein Account? Hier anmelden.