die Fehlermeldung Error: syntax error ist ja sehr aussagekräftig... ich arbeite an einem Programm zur Ansteuerung eines VS1011. Folgende Variablen wurden u.A. definiert: #define VS_xcs = LATCbits.LATB4 #define VS_xdcs = LATCbits.LATB3 bei jedem Aufruf von z.B. VS_xcs=1; kommt die obgenannte Fehlermeldung. Jemand Ahnung warum? SK
Nach dem Präprozessor-Lauf steht da
1 | = LATCbits.LATB4=1; |
Und das ist ja wohl kaum ein sinnvolles Statement in C. Warum bei deinem Compiler die Fehlermeldung nicht aussagekräftiger ist? Keine Ahnung.
Richtigen Compiler zum Source-Code suchen und verwenden. Oder diesen entfernt an C angelehnten Source-Code nach C portieren. Ob ein Compiler in der Lage ist, bei einem Syntax Error weiter gehende Information zu liefern, hängt davon ab wie dessen Parser implementiert ist. Der von GCC ist mittlerweise handgestrickt und entsprechend auskunftsfreudig. Andere nehmen Parser-Generatoren, wie GCC früher auch. Die sind oft weniger geschwätzig.
PS: Das zum "richtigen Compiler" war Käse, hab's mit irgendwelchem #bit Kram verwechselt, der hier letzthin rumgeisterte.
habs geändert aber immern noch das selbe: #define VS_xdcs = LATBbits.LATB3 #define VS_xcs = LATBbits.LATB4 Port wird initialisiert mit: TRISB=0b00000100; ich glaub ich steh im Wald...
ok ohne "=" hats geklappt. Dankedanke... warum ist das aber so? habe doch einige deinitionen mit = stehen, ohne Beanstandung...
Ein C Handbuch könnte dabei helfen, die Rolle des Präprozessors zu verstehen. Ein #define ist keine schwarze Magie, sondern hat eine ganze bestimmte Bedeutung und Syntax. Wär mal interessant, diejenigen zu sehen wo es mit "=" funktioniert.
Du definierst die variable "VS_xcs" als LATCbit.LATB4 (wobei das ja auch wiederum ein define ist) >#define VS_xcs = LATCbits.LATB4 >#define VS_xdcs = LATCbits.LATB3 dann schreibst du >VS_xcs=1; und versuchst die bereits definierte Variable wieder zu ändern, das geht nicht! das define definiert ja, dass VS_xcs einen festen wert hat, da kannst du nicht einfach VS_xcs = 1 machen.
gast schrieb: > Du definierst die variable "VS_xcs" als LATCbit.LATB4 (wobei das ja auch > wiederum ein define ist) Mit dem "#define" wird keine Variable definiert, sondern ein Präprozessor-Makro. Und LATCbit.LATB4 ist kein #define, sondern eine member einer struct, also tatsächlich eine Variable. > das define definiert ja, dass VS_xcs einen festen wert hat, da kannst du > nicht einfach VS_xcs = 1 machen. Sorry, aber das ist nun wirklich Quark. Bis auf das Missverständnis über die Syntax eines #define Statements war bei ihm alles in Ordnung.
machts es doch nicht so schwer #define SEARCH REPLACE suche SEARCH, wenn gefunden, ersetze mit REPLACE zb.: #define BUZZER LATBbits.LATB2 BUZZER = 1; // im original LATBbits.LATB2 = 1; // nach dem präprozesor entsprechend erkennt man doch gut das hier ein "= 1" nichts zu suchen hat ;)
ok, danke für die Aufklärung einige #define sind aber im Programm tatsächlich (noch) mit = angegeben. Dass dort keine Meldung kommt beim Compilieren, ist wahrscheinlich weil sich im Programm noch nicht implementiert wurden...
jetzt hab ich eine weitere (eigentlich etwa 10 identische) Fehlermeldung mit der ich nicht viel anfangen kann: Message [3002] comparison of a signed integer to an unsigned integer detected bei einer normalen if Abfrage if (i==0)
Serial Killer schrieb: > Message [3002] comparison of a signed integer to an unsigned integer > detected > > bei einer normalen if Abfrage if (i==0) Die Meldung ergibt in diesem Zusammenhang keinen Sinn. War allerdings auch die erste Fehlermeldung, die ich dem C18 abgewöhnt habe, ohne gross zu kontrollieren sie ob im jeweiligen Zusammenhang sinnvoll war.
so das Programm hätte ich mittlerweile "ausgekäfert" :) beim compilieren kommt aber noch die MEldung: Error - section '.idata_MP3Player.o' can not fit the section. Section '.idata_MP3Player.o' length=0x00000102 Errors : 1 ich hatte einen Fehler bezüglich udata mal, den konnte ich mich #pragma udata block1 #pragma udata block2 umgehen. Bei idata funktioniert das aber nicht. Welche Möglichkeiten habe ich?
>Bei idata funktioniert das aber nicht. Welche Möglichkeiten habe ich?
Die benutzten Variablen auf ein Minimum reduzieren.
Oder das Linkerscript anpassen. Warum die Standard-Linkerscripts
das RAM in 256 Byte Stückchen aufteilen habe ich bis heute nicht
verstanden.
ich hab nun versucht, Variablen zu streichen, Feldvariablen zu schrumpfen und Funktionen zu entfernen. Die Fehlermeldung ist aber immer die selbe... idata_MP3Player.o' can not fit the section. Section '.idata_MP3Player1.o' length=0x00000102 die 0x102 hat sich nicht geändert...
ok, es handelt sich nur um dieses Array: unsigned char RNDL [256]= {208,75,137,110,218,247,165,23,248,216,204,59,118,35,193,29,83,158,93,57 ,224,194,3,207,205,149,203,22,129,171,10, 142,251,99,249,244,144,16,17,238,37,197,111,151,4,192,104,7,95,150,67,10 1,69,15,132,186,87,156,206,27,166,20,182, 163,92,198,119,213,180,61,152,39,185,19,58,45,33,64,24,160,40,222,172,13 1,227,221,105,108,177,183,73,43,157,12,199, 113,9,245,126,130,106,120,210,215,31,167,246,76,139,195,239,50,229,169,5 5,122,212,30,112,6,85,141,82,236,21,32,89, 219,173,188,127,74,214,187,190,176,62,123,189,121,184,148,225,34,1,196,2 8,49,46,79,77,54,117,240,175,242,140,231, 13,128,25,97,146,228,179,116,70,53,178,18,254,78,109,155,241,233,81,255, 159,202,102,2,174,14,147,234,60,8,84,52,98, 100,230,145,211,125,11,181,164,26,90,134,161,36,71,223,143,232,136,63,68 ,51,96,243,66,65,235,47,154,237,252,72,209, 114,138,115,86,250,5,94,133,42,44,88,226,103,253,124,168,91,48,217,56,80 ,135,220,107,191,201,162,153,38,170,41,200,0}; wenn ich es um 2 byte kürze und die letzten 2 Zahlen lösche, wird das Programm einwandfrei compiliert...
unsigned char RNDL [256]= Muss das im RAM liegen? Versuchs mal mit: const rom unsigned char RNDL [256]=
super, hat nun geklappt, danke. Der Fehler wundert mich aber trotzdem. Zumal ich auch noch ein anderes (leeres) Array mit 256b angegeben hab, das aber keine Zikken machte...
Ich hatte mit einem großen Array (512 Byte) ein ähnliches Problem. Musste das Linker-Script anpassen. Gehört zwar nicht direkt zum Thema aber hier ist das ganz gut beschrieben: http://www.microchip.com/forums/tm.aspx?m=39357 mfg, christian
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.