Bitte um Hilfe bei der Programmierung von AVR8-Mikrocontrollern in C

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Falk B. schrieb:
> Ach so, du bist es ja!
>
Und du auch schon wieder !

Kannst du dir nicht wenigstens Punkt 5 der universellen Forumsregeln 
merken ?

Die fünf universellen Forumsregeln :

1. Threadüberschrift lesen
2. Evtl. Datum beachten
3. Posting verstehen
4. Falls nicht 3., dann nachfragen oder Klappe halten.
5. Auf die Fragen eingehen und / oder Alternativen bzw. Verbesserungen
   nennen.

Die Punkte kann man an einer Hand abzählen und deshalb evtl. gut merken,
wenn nicht dann nur Punkt 3 und Punkt 4 merken.





Der Fehler ist natürlich nicht weg, sondern taucht bei der Konstellation 
nicht auf. Wenn ich OCR3A z.B. mit 694 lade ist er wieder da.

Das ganze dient zum Erkennen, wann meine Schrittmotorkonstruktion 
anfängt Schritte zu verlieren. Es wird die FastPWM Mode 15-Kurve ohne 
Vorteilung  mit einem CPU-Takt von 16MHz druchlaufen.
Dazu lasse ich den SM einen bestimmten Kurvenbereich abfahren, dann 
sofort zurück und hiernach wird ca. 1,5 Sekunden gewartet bis es von 
neuem losgeht.
Aber sporadisch läuft die Sache dann schief. Dort im leider schlechtem 
Video kann man es sehen :

Beitrag "Schrittmotor : Programmfehler"

Ich würde mich freuen, falls mal jemand oben auf Punkt 5 eingeht.
Debuggen kann ich nur mit dieser Print-Krücke.


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Arduino F. schrieb:
> Die Print::print() werden sofort ausgeführt.
> Es wird ein char/uint8_t Ringbuffer mit den Ausgaben gefüllt.
> Die Probleme/Blockaden entstehen, wenn der Ringbuffer voll ist.
>
Seltsam, ich hatte doch 3 weitere Print-Befehle hinzugefügt, da hätte 
der Fehler demnach erst recht auftauchen müssen.

Arduino F. schrieb:
> Auch da sich Ausgaben des Hauptprogramms und Ausgaben in der ISR
> vermischen können/werden.
>
Das Hauptproblem ist halt, dass stepCount entweder nachgeladen oder mit 
einem falschen Wert geladen wird. Das kann ich halt nicht festellen.

Ich verstehe halt nicht wie dies sein kann.

Nur bei stepCount == 0, wird ja die entscheidene Loop-Routine 
durchlaufen und nur wenn dann auch die Richtung stimmt, wird stepCount 
neu geladen.
Da wird wohl irgend ein Interrupt dazwischenfunken, aber dass dürfte 
doch egal sein, wenn dieser IRQ nicht die selbe Varialbe ( stepCount ) 
nutzt oder ?


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Dachte nun wenn ich IRQ`s generell unterbinde, aber seht euch den Anhang 
an.

        cli();
        stepCount = SM_SCHRITTANZAHL;  // Variable wird in ISR runtergezaehlt
        // Sofortigen Interrupt verhindern
        TCNT3   =  0;             // Timer ruecksetzen
        TIFR3   =  1<< OCF3A;     // Output Compare Interrupt Flag loeschen
        TIMSK3 |=  1<< OCIE3A;    // Output Compare Interrupt freigeben  
        sei();

Bernd_Stein

[Monk (Gast)]

if( stepCount == 0 ) {
   ... 
   Serial.print  ( "stepCount" );
   Serial.print  (  stepCount  );
   Serial.println( ); 
   ...
}

Da muss auch eine Interruptsperre drumherum. Denn sonst kann die 
Variable beim Lesen verändert werden.

Angenommen, StepCount hat vor dem if-Befehl gerade den Wert 256 (hex: 00 
00 01 00). Nun werden die vier Bytes nacheinander von rechts nach links 
gelesen:

Viertes Byte: 00
Jetzt kommt ein Interrupt, welcher den Wert auf 255 ändert (hex: 00 00 
00 FF)
Drittes Byte: 00
Zweites Byte: 00
Erstes Bytes: 00

Alle vier haben "scheinbar" den Wert 0, die if-Bedingung ist erfüllt. 
Dann kommt die korrekte Ausgabe der Variable.

Anmerkung:
Wenn die Intervalle zwischen den Interrupts kürzer wären, könnte auch 
die Ausgabe mittels Serial.print(steCount) gestört werden.

Korrekturvorschlag:

void loop()
{
   int32_t tmp;
   
   cli();
   tmp=stepCount;
   sei();
   
  if( tmp == 0 ) {
    TIMSK3 &=  ~1<< OCIE3A;     // Output Compare Interrupt sperren    
    
    // Nur jedes 2te mal eine Pause einlegen 
    if( !( SM_RICHTUNG_PORT & SM_RICHTUNG ))  {
          
                   
Serial.print  ( errorZaehler );
Serial.print  ( " PAUSE" );  
Serial.print  ( "\t" );         // Neu  
Serial.print  ( "stepCount" );  // Neu
Serial.print  (  tmp  );  // Neu  
Serial.println( ); 
  
        errorZaehler ++;
        
        delay( SM_PAUSE );
    }
        
        cli();
        stepCount = SM_SCHRITTANZAHL;  // Variable wird in ISR runtergezaehlt
        // Sofortigen Interrupt verhindern
        TCNT3   =  0;             // Timer ruecksetzen
        TIFR3   =  1<< OCF3A;     // Output Compare Interrupt Flag loeschen
        TIMSK3 |=  1<< OCIE3A;    // Output Compare Interrupt freigeben    
        sei();
  }
} // Ende void loop()

Gewöhne dir an:

1) Variablen die sowohl innerhalb als auch außerhalb einer ISR benutzt 
werden, müssen volatile sein.

2) Wenn diese Variable größer als 8 Bit ist, dann muss der Zugriff durch 
eine Interruptsperre geschützt werden.

Es gibt sehr spezielle Ausnahmen, wo das nicht nötig ist, aber das ist 
eher ein Thema für fortgeschrittene Programmierer.

[Arduino F. (Firma: Gast) (arduinof)]

Steve van de Grens schrieb:
> 1) Variablen die sowohl innerhalb als auch außerhalb einer ISR benutzt
> werden, müssen volatile sein.
>
> 2) Wenn diese Variable größer als 8 Bit ist, dann muss der Zugriff durch
> eine Interruptsperre geschützt werden.
Punkt 1 stimme ich nicht zu
Punkt 2 durchaus ja.

Hier würde ich zu den Atomic Block Makros raten.
Die sind recht einfach zu handhaben und tun was sie sollen.

[Wilhelm M. (wimalopaan)]

Steve van de Grens schrieb:
> 1) Variablen die sowohl innerhalb als auch außerhalb einer ISR benutzt
> werden, müssen volatile sein.

Zwar bekommt man mit dieser Holzhammerregel keine Probleme mit dem 
Optimizer, jedoch ist diese Aussage in Gänze falsch.

[Monk (Gast)]

Arduino F. schrieb:
> Punkt 1 stimme ich nicht zu

Wilhelm M. schrieb:
> Zwar bekommt man mit dieser Holzhammerregel keine Probleme mit dem
> Optimizer, jedoch ist diese Aussage in Gänze falsch.

Vielleicht einfach mal vollständig lesen und zitieren:

Steve van de Grens schrieb:
> Es gibt sehr spezielle Ausnahmen, wo das nicht nötig ist, aber das ist
> eher ein Thema für fortgeschrittene Programmierer.

Ihr könnte das ja gerne in einem weiter führenden Thread ausdiskutieren. 
Das letzte mal ist immerhin länger als ein Monat her. Aber seid dem 
Bernd bitte nicht böse, wenn er an diesem Detail (gerade) kein Interesse 
hat.

[Arduino F. (Firma: Gast) (arduinof)]

Steve van de Grens schrieb:
> Aber seid dem
> Bernd bitte nicht böse, wenn er an diesem Detail (gerade) kein Interesse
> hat.

Ich glaube nicht, dass es deine Entscheidung ist, was ihm schmeckt, oder 
auch nicht.

Weiterhin:
Es gibt diese schönen Makros.
Also kann man sie auch verwenden.
Ist nicht so dolle eigenbrötlerisch denn es nutzt einen dokumentierten 
und ausgetretenen Pfad.
Dann brauchts auch kein volatile.

Man/Bernd muss noch nicht mal verstehen, was die Makros "wirklich" tun.

Disclaimer: Dieses ist ein Rat. Ein kostenloser Rat.

PS:
Dass ihm da schlampig vorgegangen ist, sollte ihm auch mittlerweile klar 
geworden sein.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Steve van de Grens schrieb:
> Angenommen, StepCount hat vor dem if-Befehl gerade den Wert 256 (hex: 00
> 00 01 00). Nun werden die vier Bytes nacheinander von rechts nach links
> gelesen:
>
> Viertes Byte: 00
> Jetzt kommt ein Interrupt, welcher den Wert auf 255 ändert (hex: 00 00
> 00 FF)
> Drittes Byte: 00
> Zweites Byte: 00
> Erstes Bytes: 00
>
> Alle vier haben "scheinbar" den Wert 0, die if-Bedingung ist erfüllt.
> Dann kommt die korrekte Ausgabe der Variable.
>
Vielen dank für diese verständliche Erklärung.
Habe dies umgesetzt und es scheint die Ursache gewesen zu sein.
Bisher 140 Errorzählungen ohne Fehler auch beim Verfahren des SM.

   int32_t tmp;

   cli();
   tmp = stepCount;  // Ein verfaelschen durch ISR verhindern
   sei();

   if( tmp == 0 ) {

Ach, in diesem Zusammenhang fällt mir ein:
Ist der Zugriff in C auf 16-Bit Register bzw. Variablen schon von Haus 
aus geschützt oder müsste ich dies auch per Interruptsperre schützen?

  TCNT3   =  0;             // Timer ruecksetzen

  uint16_t  spanne = 0;

Bernd_Stein

[Monk (Gast)]

Bernd S. schrieb:
> Ist der Zugriff in C auf 16-Bit Register bzw. Variablen schon von Haus
> aus geschützt

Ist er nicht. Nur Variablen, die deine CPU atomar (mit einem 
Assembler-Befehl) laden/speichern kann, haben das "Problem" nicht.

Zu TCNT3 lies mal 
https://ww1.microchip.com/downloads/en/Appnotes/doc1493.pdf

Wo du die "spanne" jetzt her geholt hast, ist mir schleierhaft. 
Diskutieren wir nicht mehr über 
https://www.mikrocontroller.net/attachment/highlight/613919 ?

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Steve van de Grens schrieb:
> Bernd S. schrieb:
>> Ist der Zugriff in C auf 16-Bit Register bzw. Variablen schon von Haus
>> aus geschützt
>
> Ist er nicht. Nur Variablen, die deine CPU atomar (mit einem
> Assembler-Befehl) laden/speichern kann, haben das "Problem" nicht.
>
Jo, habe da auch was gefunden. Ich kann zwar

TCNT3 = 65535;

schreiben, anstelle von

TCNT3H = 0xFF; 
TCNT3L = 0xFF;

aber trotzdem werden zwei Schreibzugriffe erzeugt.

https://www.mikrocontroller.net/articles/AVR_16-Bit-Register#Zugriffe_in_C


Steve van de Grens schrieb:
> Wo du die "spanne" jetzt her geholt hast, ist mir schleierhaft.
> Diskutieren wir nicht mehr über
> https://www.mikrocontroller.net/attachment/highlight/613919 ?
>
Das war nur ein Beispiel. Und nein, darüber brauchen wir nicht mehr 
diskutieren dass Problem hast du ja bereits erkannt und eine Lösung 
dargebracht.


Bernd_Stein

[Spess53 .. (hardygroeger)]

Hi

>aber trotzdem werden zwei Schreibzugriffe erzeugt.

Weil es zwei 8-Bit Register sind und kein 16 Bit Register.

MfG Spess

[Peter H. (hp-soft)]

Leute:
Also Echt.

Der Autor stellt eine simple Frage. Was folgt:

Ein Kindergarten von Animositäten wird in über 200 Post´s aktiv.
Ich hoffe, dass ich in diesem Forum niemals über ein Problem berichten 
muss.