www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Fehler beim Codevision-AVR


Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Eigentlich ist es kein Fehler, sondern eher ein Umstand, den man wissen
muss.
Ich möchte wissen wie ihr dazu steht. Vielleicht liest auch jemand
diese Nachricht, der mit dem GNU-Compiler zu tun hat, um zu sehen wie
dieses Problem dort umgangen wird.

Kurze Erklärung des Programmablaufes: Es handelte sich um eine reine
Testroutine.
Das Hauptprogramm bestand aus einer While-Schleife in welcher ständig
PORTB.1 invertiert wurde.
while (1)
      {
      // Place your code here
      portb1=~portb1;
      };

Zusätlich war der externe IRQ-0 eingeschaltet und der entsprechende Pin
(PD.2 2313) mit einem Frequenzgenerator verbunden.
Die IRQ-Routine hatte die Aufgabe den PIN PORTB.0 zu invertieren.
// External Interrupt 0 service routine
interrupt [EXT_INT0] void ext_int0_isr(void)
{
// Place your code here
portb0=~portb0;
}

Alle Ein- und Ausgangssignale wurden zusätzlich auf einem OSZI
angezeigt.
Das Lustige bei dem Ganzen war, dass es ab und zu passierte, dass
portb0 nicht nur in der IRQ-Routine invertiert wurden, sondern auch
nach dem verlassen dieser!?!

Ich sah mir den Assembler-Code mal. Dies ist der Assemblercode aus dem
Hauptprogramm:

99:             portb1=~portb1;
+00000067:   94E8        CLT                      Flag clear
+00000068:   9BC1        SBIS    0x18,1           Skip if bit in I/O
register set
+00000069:   9468        SET                      Flag set
+0000006A:   B3E8        IN      R30,0x18         In from I/O location
+0000006B:   F9E1        BLD     R30,1            Bit load from T to
register
+0000006C:   BBE8        OUT     0x18,R30         Out to I/O location
100:            };
+0000006D:   CFF9        RJMP    -0x0007          Relative jump

Der Fehler:
In Zeile +6a kann man erkennen, dass Portb (0x18) in das Register R30
kopiert wird, um später den PIN PORTB.1 verändern zu können.
Wird nach der Ausführung dieses Befehls ein IRQ ausgelöst, so werden
die Register erst mal ge push t. Danach wird PortB.0 in der IRQ-Routine
verändert. Jetzt werden alle Register wieder ge pop t.
Nach dem Rücksprung befindet sich der alte Wert, der sich vor dem
Einsprung in die Irq-Routine im Register 30 befunden hat noch immer im
R30, also vor der Änderung von Portb.0.
Nun fährt das Hauptprogramm fort und nach Kurzem wird, man sieht es in
Zeile +6C (out 0x18,R30), R30 wieder auf 0x18 (PORTB)
zurückgeschrieben.
Die Veränderung, die in der IRQ-Routine vollzogen wurde ist nun
futsch.

Ich habe eine Fehlerbeschreibung an HPINFOTECH gesendet mit folgender
Antwort:
Dear Sir,
The problem you are describing is not the fault of the compiler.
If you want that it will not occur write:

while (1)
{
// Place your code here
#asm("cli") // disable interrupts
portb1= ~ portb1;
#asm("sei") // re-enable interrupts
}

Also ich finde das einwenig schwach, dass man den IRQ ausschalten muss,
wenn man mal einen Portpin in einem Hauptprogramm verändern möchte. Was
ist, wenn ich mal einen ganzen PORT verändern möchte, tritt dann das
Problem auch auf?

Hierbei handelt es sich wieder mal um einen Fehler, wo man wochenlang
sucht und sich bestimmte Fehlschaltungen nicht erklären kann.

Wie ist das beim GNU-Compiler gelöst? Das wäre interessant.

Ich freue mich auf eure Komentare, Anregungen und Erklärungen...

Tschüss.

Martin

Autor: Armin Kniesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie hast Du denn "portb1" deklariert?

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gegenfrage: wie würdest du es in Assembler lösen, OHNE den Interrupt zu
sperren? Und wärest du zufrieden, wenn automatisch bei allen
Portzugriffen dieser Art die Ints gesperrt würden?
Ein Compiler ist kein Freifahrtsschein, die Besonderheiten des
Prozessors zu beachten, liegen in Hand des Programmierers.
Ein umfassender Softwaretest ist deshalb schwierig, weil eben auch
solche Besonderheiten berücksichtigt werden müssen, bzw. ergibt sich
daraus die ernüchternde Erkenntnis, dass es kaum bis gar nicht möglich
ist, ein Programm unter allen möglichen Betriebszuständen zu testen.
Und gerade Interrupts sind immer besonders zu beachten. Letzten Endes
können selbst unscheinbare Änderungen am Programm zu einem kompletten
Neutest führen. Wenn dein Fehler vielleicht nur einmal im Monat
aufträte - wer denkt da erstmal an einen Softwarefehler?
Gibt genug solcher Beispiele, wo nach jahrelangem fehlerfreien Betrieb
plötzlich ein Softwarefehler mit z.T. fatalen Folgen auftritt.
Berühmt-berüchtigt ist ein Fehler einer Bestrahlungskanone, wurde eine
bestimmter Dosis (falsche Eingabe) durch eine bestimmte andere Dosis
ersetzt, drehte das Maschinchen durch und verbrutzelte einen Patienten,
inzwischen leider verstorben. Hat lange gedauert, bis die Ursache
geklärt war.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Armin
Das habe ich so gemacht:
#define portb1 PORTB.1
#define portb0 PORTB.0

@crazy horse
Natürlich hast du recht mit deiner Meinung und ich bin froh, dass ich
bei einem einfachen Softwaretest draufgekommen bin und nicht etwa bei
einem komplizierten Projekt.
Aber meiner Meinung nach sollte eine Hochsprache solche
architektonischen Nachteile ausgleichen. Darum gibt es die Hochsprachen
ja als Werkzeug, damit man in die Prozessorarchitektur nur soweit als
notwendig einsteigen muss.
Ich beschäftige mich mit drei Verschiedenen Prozessorfamilien. Und wenn
ich bei jeder Familie den Assemblerdialekt auf das Genaueste lernen
hätte müssen, wäre ich heute noch nicht besonders weit. Außerdem stehen
leider nie architektonische Nachteile im Datenblatt.
Bei C hat man den weiteren Vorteil, dass man den Code auf andere
Familien viel leichter übertragen kann.
Meiner Meinung nach könnte der Compiler schauen, ob in der IRQ-Routine
ein Bit desselben Ports gesetzt wird, um erst dann im Hauptprogramm den
IRQ kurzzeitig zu sperren. Wäre eine Möglichkeit, da ich finde, dass
der Programmierer schon genung mit Programmablauf und Initialisierungen
beschäftigt ist.

Aber zumindest ein Hinweis des C-Compiler-Herstellers auf diese
Schachstelle wäre von Vorteil.

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich glaube nicht, dass man das Problem durch Änderungen am Compiler
lösen kann, und dein Problem tritt nicht nur bei den Ports auf, sondern
bei allen read/modify/write_back-Operationen auf. Wenn das
Hauptprogramm eine Speicherzelle manipuliert, also i.a. erstmal in ein
Register/Akku lädt, dabei unterbrochen wird, ein anderer Programmteil
die Ausgangsdaten manipuliert und anschliessend die ursprüngliche
Operation zu Ende geführt wird, muss das Ergebnis fehlerhaft werden.
Das ist kein Problem des AVR, sondern ein generelles, welches bei allen
Prozessoren auftaucht.
Es hilft nur eines: gerade bei Interrupts aufpassen wie ein Luchs.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grundsätzlich muß man immer davon ausgehen, daß C-Instruktionen nicht
atomar sind, d.h. sie bestehen fast immer aus mehreren
Assemblerinstruktionen.

Der Compiler kann nichts dafür und kann deshalb auch nichts dagegen
tun.
Allein Du kannst und must das prüfen und entsprechende Gegenmaßnahmen
treffen.

Besonders, wenn man Code von einer anderen Maschine portiert muß trotz
einwandfreier Compilierung der Code noch lange nicht laufen.

Z.B. ist dieselbe Instruktion auf einem 8051 völlig gefahrlos, da der
mit einem einzigen Assemblerbefehl Portpins invertieren kann. D.h. dort
ist diese Instruktion rein zufällig atomar.


Peter

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
alles richtig, aber noch nicht umfassend.
Das Problem hat mit C oder Compiler gar nichts zu tun, es ist in
Assembler genauso vorhanden und auch da nur durch programmiertechnische
Lösungen zu umgehen.

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.