www.mikrocontroller.net

Forum: Compiler & IDEs Telegramm[3] |= (1<<2) legal?


Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)
main:
        ldi r24,lo8(1)
        sts Array+1,r24
        lds r24,Array+5
        ori r24,lo8(4)
        sts Array+5,r24

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke.
Nur sehr ärgerlich, dass ich dafür Geld bezahlt habe.
Und der Support dieses Problem einfach übergangen hat. :-(

Autor: sebba (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du enn mal:
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.avrfreaks.net/modules.php?op=modload&na...

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steht doch oben: "MikroC pro".

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.