Hallo, ich bin noch recht grün, in der C Programmierung. Ich möchte über die Serielle Schnittstelle ein Telegramm senden. Hierzu will ich in einem array einzelne Bits setzen. Wenn ich nun folgenden Befehl schreibe funktioniert das Ganze. Telegramm[3] = (1<<2); und dritte Element im array Telegramm wird beeinflußt. Da ich aber nur ein Bit setzen will schreibe ich jedoch: Telegramm[3] |= (1<<2); Nun wird allerdings das Element 0 geändert. Mache ich da etwas falsch? Danke Mario
>Telegramm[3] = (1<<2); >und dritte Element im array Telegramm wird beeinflußt. Es wird das vierte Element geändert. In C beginnen Arrays mit dem Element 0. >Telegramm[3] |= (1<<2); >Nun wird allerdings das Element 0 geändert. Wie stellst du das fest? Zeig mal deinen kompletten Code, nicht nur Mikrobruchstücke davon. Vermutlich machst du an anderen Stellen einen Fehler. Es wird übrigens nicht gern gesehen, wenn du die selbe Frage in zwei verschiedenen Foren postest. Entscheide dich für das Forum, in das deine Frage am besten hineinpasst und poste nur einmal.
Danke für die Antwort.
Also das Programm ist natürlich länger. Festgestellt habe ich es, da das
Element 0 in meinem Array das Startbyte ist. Es wurde überschrieben und
der Empfänger antwortete nicht.
Darauf hin habe ich mir die Sache mal im Simulator angeschaut und es
wurde tatsächlich Element 0 überschrieben.
Mein nächster Schritt war dann folgendes Miniprogramm:
C - Code
char Array[20];
void main() {
Array[1] = 1;
Array[5] |= (1<<2);
}
Der Compiler übersetzt es in das folgende Listing:
ASM - Listing
Arraytest.c,4 :: void main() {
;Arraytest.c,6 :: Array[1] = 1;
0x005C 0xE0B1 LDI R27, 1
0x005E 0x006193B0 STS _Array+1, R27
;Arraytest.c,7 :: Array[5] |= (1<<2);
0x0062 0x006091B0 LDS R27, _Array+0
0x0066 0x60B4 SBR R27, 4
0x0068 0x006093B0 STS _Array+0, R27
;Arraytest.c,8 :: }
L_endmain:
0x006C 0xCFFF RJMP L_endmain
Man sieht also schon in der Übersetzung, dass das nullte Element
manipuliert wird.
Ich habe den MikroC pro Compiler.
Ist da jetzt ein Fehler im meiner Quelle oder baut der Compiler Mist?
Mario wrote:
> Ich habe den MikroC pro Compiler.
Tja, dann hat wohl dein Compiler einen Bug.
Aber da du dich ja ins GCC-Forum damit verirrt hast, kennst du nun
zumindest einen Compiler, der diesen Bug nicht hat. ;-)
1 | main: |
2 | ldi r24,lo8(1) |
3 | sts Array+1,r24 |
4 | lds r24,Array+5 |
5 | ori r24,lo8(4) |
6 | sts Array+5,r24 |
Danke. Nur sehr ärgerlich, dass ich dafür Geld bezahlt habe. Und der Support dieses Problem einfach übergangen hat. :-(
warum tust du das auch? also geld für nen C compiler zahlen oder hast du irgendwas exotisches für das es noch keinen gcc port gibt? und ohne den compiler jetzt zu kennen... benutz den am besten garnicht mehr wenn der schon bei so grundlegenden dingen wie einem eindimensionalen array und bitmanipulation probleme macht dann will ich nicht wissen was der macht wenn die wirklich interessanten dinge kommen und man macht immerhin schon genug eigene fehler ;) gruß sven
Hast du enn mal:
1 | Telegramm[3] = Telegramm[3] | (1<<2); |
probiert? ggf interpretiert dein Compiler den Operator anders (Handbuch!) ist nämlich alles ne Frage inwieweit sich der Compiler an den und welchen C Standard hält.
Bei diesem Trivialcode gibt es keine verschiedenen Standards, da gibt es nichts zu interpretieren. Jedenfalls nicht wenn das wirklich auch nur entfernt etwas mit C oder gar einem offiziellen Standard zu tun haben soll. Wäre allerdings ein komischer Fehler. Suggeriert, dass man für die Benutzung dieses Compilers Geld kriegen sollte statt dafür zu zahlen.
http://www.avrfreaks.net/modules.php?op=modload&name=News&file=article&sid=712&mode=thread&order=0&thold=0 Es sit eine BETA Version wie es scheint, und da KÖNNTE es ja sein das es nicht ALLE vorgaben des neuesten C-Standards vorsieht/korrekt implementiert. Und ich denke man könnte ohne probleme mal die langschreibweise ausprobieren, ggf wird hier ein operator verkehrt herum ausgewertet oder oder. Da steht aber auch nix von wegen das der was kostet...
Läubi Mail@laeubi.de wrote: > Es sit eine BETA Version wie es scheint, und da KÖNNTE es ja sein das es > nicht ALLE vorgaben des neuesten C-Standards vorsieht/korrekt > implementiert. Das hat überhaupt nichts mit ,,neuestem C-Standard'' oder sowas zu tun. Wenn es ein Compiler nicht schafft, die Anweisungen a = a | b und a |= b als äquivalent zu betrachten, dann brauch ich seiner Codegenerierung schlicht und ergreifend nicht übern Weg trauen.
Ausserdem ist es ja nicht die OR-Operation, die hier in die Binsen geht, sondern ausschliesslich die Adressgenerierung. Und die hat mit dem Operator rein garnichts zu tun.
Hallo, danke für die zahlreichen Antworten. Also, der Support hat sich mittlerweile gemeldet (über eine Woche) und den Bug bestätigt. Ich habe halt bei der Anschaffung, des Compiler gedacht, dass komerzielle Produkte funktionieren und auch der Support stimmt. Leider erwies sich beides als Trugschluß. Der Compiler ist auch nicht mehr in der Beta Phase. Mal gespannt wie es weiter geht. Gruß Mario
> Der Compiler ist auch nicht mehr in der Beta Phase.
Welch' Schweinderl ist's denn? Nicht, daß hier noch jemand anderes in
die selbe Falle tappt ...
Im Changelog zur letzten Version findet sich dort beispielsweise: - Fixed: Getting address of an extern variable with fixed address - Fixed: Getting address of subaggregate (structure, array or union Mit Adressgenerierung haben die es scheint's nicht so.
A. K. wrote: > Im Changelog zur letzten Version findet sich dort beispielsweise: > - Fixed: Getting address of an extern variable with fixed address > - Fixed: Getting address of subaggregate (structure, array or union > Mit Adressgenerierung haben die es scheint's nicht so. Mario wrote: > Der Compiler ist auch nicht mehr in der Beta Phase. Da würden bei mir jetzt allerdings alle Glocken zu läuten anfangen. Das in einem Compiler mal ein Fehler drinnen ist ... ok, kommt vor Das es sich um einen fischigen Fehler handelt ... ok, auch das kommt vor Das sich solche fischigen Fehler aus dem Alpha-Stadium in die Beta Phase durchmogeln ... sollte zwar nicht sein, kommt aber vor Das sich aber ein Fehler wie dieser, aus der Beta Phase in ein kommerzielles Produkt einschleicht, wirft ein gewisses Licht auf die Qualitätssicherung im Haus. Denn eines muss klar sein: Wie A.K. weiter oben schon gesagt hat: Der Fehler ist in der Adressgenerierung. Auf Anhieb fällt mir überhaupt keine Möglichkeit ein, wie man bei einem normal aufgebauten Compiler so einen Fehler einbauen kann, ohne dass es dem Entwickler bei den ersten 10 Programmen die er durch den Compiler jagt, in der Alpha Phase auffällt. Wer einen Compiler baut hat normalerweise eine Testsuite, die aus meherern zig Test-Programmen besteht, die automatisiert durch den Compiler gejagt werden und wo sich ein Programm den generierten Maschinencode mit dem vorgegebenen Maschinencode vergleicht und sofort Alarm schreit, wenn das nicht übereinstimmt. Sowas ist gängige Praxis bei allen Compilerherstellern und man verhindert damit wirkungsvoll, dass man sich unbemerkt blöde Fehler einbaut. Edit: Nachdem ich diese Changelog Einträge gesehen habe, gebe ich den Text doch noch frei den ich im Nachhinein wieder gelöscht habe. Ursprünglich dachte ich: Beschuldige niemanden einer Nachlässigkeit die du nicht beweisen kannst. Aber diese Changelog Einträge werfen dann schon ein bezeichnendes Licht auf die Sache.
Mario wrote: > Ich habe halt bei der Anschaffung, des Compiler gedacht, dass > komerzielle Produkte funktionieren und auch der Support stimmt. Der war gut :D Ich kann mich im Prinzip nur beipflichten. Nimm den GCC falls er fuer die Zielplattform existiert.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.