ISR Code schneller machen?

[Veit D. (devil-elec)]

Hallo,

die ISR benötigt minimum 22,8µs, der ATtiny taktet mit 8MHz.
Damit kann ich die Servos nur in Schritten größer 2° einstellen.

Ist es irgendwie möglich den Code schneller zu machen?

ISR(TIMER1_COMPA_vect)    
{
  static uint16_t count = 0;
  
    if (count == servo[0].pulscount) {    // Impulsdauer Servo 1
      K6_1_OFF;
    }
  if (count == servo[1].pulscount) {    // Impulsdauer Servo 2
    K6_2_OFF;
  }
  if (count == servo[2].pulscount) {    // Impulsdauer Servo 3
    K6_3_OFF;
  }
  if (count == servo[3].pulscount) {    // Impulsdauer Servo 4
    K6_4_OFF;
  }
  if (count == servo[4].pulscount) {    // Impulsdauer Servo 5
    K7_5_OFF;
  }
  if (count == servo[5].pulscount) {    // Impulsdauer Servo 6
    K7_6_OFF;
  }
  if (count == servo[6].pulscount) {    // Impulsdauer Servo 7
    K7_7_OFF;
  }
  
  if (count == MaxPulscount) {    // nach aktuell längster Pulsdauer Timer stoppen
    stop_Timer1();
    count = 0;
    state_running_Timer1 = false;
  }
  
  count++;
}

[MaWin O. (Gast)]

Veit D. schrieb:
> Ist es irgendwie möglich den Code schneller zu machen?

Ohne den restlichen Code zu kennen nicht.

[Stefan F. (Gast)]

> Damit kann ich die Servos nur in Schritten größer 2° einstellen.

Genauer lassen sich die üblichen Modellbau Servos ohnehin nicht 
einstellen, egal welche Klimmzüge  du mit der Ansteuerung anstellst.

[S. Landolt (Gast)]

182 Takte, erscheint mir etwas viel für das bisschen Programm - was 
verbirgt sich hinter Kn_m_OFF?
Lässt sich vielleicht der ATtiny schneller machen?

[Dieter F. (Gast)]

Veit D. schrieb:
> die ISR benötigt minimum 22,8µs, der ATtiny taktet mit 8MHz.
> Damit kann ich die Servos nur in Schritten größer 2° einstellen.

Schön - was willst Du denn genau? So beschrieben, dass alle es verstehen 
:-)

[Veit D. (devil-elec)]

Hallo,

der restliche Code ist sehr umfangreich, liest sich bestimmt niemand 
durch.

Die Vergleiche benötigen die meiste Zeit. Darum gehts.

Die K6...ON  K7...OFF  Anweisungen sind define mit sbi und cbi.

Die count Vergleiche habe ich nun von 16Bit auf 8Bit geändert. Der 
Wertebereich bis 255 reicht aus. Sind nur Ganzzahlvergleiche. Macht 4µs 
weniger. Damit kann ich schon einmal sicher auf 2° einstellen. Weil die 
ISR unter 22µs bleibt. Sonst gibts unnötige Abweichungen wenn die ISR 
länger benötigt wie berechnet.

Stefan du meinst weniger wie 2° macht keinen Sinn? Habe das Gefühl das 
die sich schon in 1° Schritten einstellen lassen.

[Veit D. (devil-elec)]

Hallo,

der ATtiny taktet mit seinen internen 8MHz. Schneller geht nicht, alle 
Pins sind belegt. Das Design ist leider fertig.

Die K6...OFF  K7...OFF  Anweisungen sind define mit sbi und cbi. 
Schneller gehts glaube ich nicht.

Alle Ganzzahlvergleiche sind auf 8Bit Datentyp geändert.

ISR(TIMER1_COMPA_vect)    
{
  static uint8_t count = 0;
  
    if (count == servo[0].pulscount) {    // Impulsdauer Servo 1
      K6_1_OFF;
    }
  if (count == servo[1].pulscount) {    // Impulsdauer Servo 2
    K6_2_OFF;
  }
  if (count == servo[2].pulscount) {    // Impulsdauer Servo 3
    K6_3_OFF;
  }
  if (count == servo[3].pulscount) {    // Impulsdauer Servo 4
    K6_4_OFF;
  }
  if (count == servo[4].pulscount) {    // Impulsdauer Servo 5
    K7_5_OFF;
  }
  if (count == servo[5].pulscount) {    // Impulsdauer Servo 6
    K7_6_OFF;
  }
  if (count == servo[6].pulscount) {    // Impulsdauer Servo 7
    K7_7_OFF;
  }
  
  if (count == MaxPulscount) {    // nach aktuell längster Pulsdauer Timer stoppen
    stop_Timer1();
    count = 0;
    state_running_Timer1 = false;
  }
  
  count++;
}

[Stefan F. (Gast)]

> Stefan du meinst weniger wie 2° macht keinen Sinn?

Ja. Aber vielleicht hast du ja ganz besondere Servos vorliegen.

[Einer K. (Gast)]

Veit D. schrieb:
> der ATtiny taktet mit 8MHz.

Welcher?
Einer Mit PLL?
Dann kannste den Takt verdoppeln.

[S. Landolt (Gast)]

> der ATtiny taktet mit seinen internen 8MHz
Um welchen geht es denn, wenn ich fragen darf?

[jz23 (Gast)]

Veit D. schrieb:
> Die count Vergleiche habe ich nun von 16Bit auf 8Bit geändert.

Wäre jetzt auch meine Empfehlung gewesen.


Hast du denn im Compiler mal Optimierung eingeschaltet? (Also das 
Projekt als "Release" kompilieren und in den Projekteinstellungen den 
Compiler auf Geschwindigkeit trimmen)

[Johannes S. (Gast)]

Es gibt unterschiedliche Servos, unterschiedliche Hysteres. Einige sind 
nervöser, andere ruhiger, die 1° sind nicht unrealistisch. Ob das so ist 
lässt sich ja einfach testen indem die ISR auf ein Servo reduziert wird.
Hast du schon mit verschiedenen Optimierungen kompiliert?

[Veit D. (devil-elec)]

Hallo,

es ist ein ATtiny841.

vermessen tue ich die ISR mit dem eigentlich 8. Servopin.
Diesen Pin schalte ich am Anfang der ISR ein und am Ende wieder aus.
Gemessen wird mit Oszi und Datalogger.

sbi und cbi sind die üblichen defines.

#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))   // setzt das angegebene Bit auf 1
#endif
#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))  // setzt (löscht) das angegebene Bit auf 0
#endif

Okay, auch wenn vielleicht unter 2° keinen echten Sinn machen, wäre ich 
wenn möglich dennoch interessiert ob die ISR noch schneller gemacht 
werden kann.

[Löser (Gast)]

Wenn die servos nach ihrer pulsecount Variable aufsteigend in dem Array 
stehen, kannst du den längsten Pfad auch halbieren.

[Veit D. (devil-elec)]

Hallo,

Compileroptimierung habe ich noch nicht probiert, möchte vorher den Code 
optimal wissen. Wenn der Code schon das optimale wäre, kann ich mit dem 
Compiler rumspielen. Ja, wäre eine Idee.

Die einzelnen Pulscounts können alle unterschiedlich sein.

[Dieter F. (Gast)]

Dieter F. schrieb:
> Schön - was willst Du denn genau? So beschrieben, dass alle es verstehen
> :-)

Nochmal ...

[MaWin O. (Gast)]

Veit D. schrieb:
> if (count == MaxPulscount) {    // nach aktuell längster Pulsdauer
> Timer stoppen
>     stop_Timer1();
>     count = 0;
>     state_running_Timer1 = false;
>   }
>
>   count++;

Ist es gewollt, dass count mit 1 statt 0 stoppt?

[H.Joachim S. (crazyhorse)]

Die beste Variante ist, wenn du einem nach dem anderen bedienst. Also 
so, wie es im Fernsteuerprotokoll eigentlich vorgesehen war.

[Mitlesa (Gast)]

Veit D. schrieb:
> Ist es irgendwie möglich den Code schneller zu machen?

Den Code-Inhalt der Funktion

stop_Timer1();

in die ISR aufnehmen. Spart mindestens Call und Return,
vielleicht auch noch Stack-Sicherung und Stack-Restore.

[S. Landolt (Gast)]

> Compileroptimierung habe ich noch nicht probiert
Liegt es daran?

In Assembler sollte der Kern doch etwa so aussehen:

  lds  r16,count
  .
  .
  lds  r17,servo_n.pulscount
  cp   r16,17
  brne 
   cbi
  .
  .

Das sind also 8* 6 Takte, ganz grob gerechnet, plus Overhead von 
vielleicht 40, ergeben rund 90 Takte = 11 us.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Dieter F. schrieb:
> Dieter F. schrieb:
>> Schön - was willst Du denn genau? So beschrieben, dass alle es verstehen
>> :-)
>
> Nochmal ...

Das ist eine normale Soft-PWM.

[Veit D. (devil-elec)]

Hallo,

Jungs, habe Mist gemacht, hatte die falsche Oszi Messeinstellung. Ich 
muss ja um den ISR zu vermessen die High Pulslänge messen und nicht die 
Periodendauer. Dann schwirrten mir noch die Werte mit anderen 
Timerberechnungen im Kopf rum sodass ich nicht drauf kam das etwas nicht 
stimmt.

Also aktuell benötigt die ISR 8µs.

Großes Entschuldigung.

@ Mawin:

wenn ich zu ISR Beginn count++ mache, dann würde er doch um eins zu kurz 
zählen, sprich die Pulsslängen wäre um eine Timerpulslänge zu kurz?

Wenn der Timer selbst einen Umlauf später stoppt ist das nicht schlimm. 
Er soll nur nicht ständig laufen.

@Joachim:

wie meinst du das? Momentan weiß ich nicht wie du das meinst. Um die 
Timeraktivität so kurz wie möglich zu halten, starten alle zeitgleich. 
Damit läuft der Timer max. 2ms und hat 20ms Pause.

[Veit D. (devil-elec)]

Hallo,

mit

//stop_Timer1();
TCCR1B &= ~( (1<<CS12)|(1<<CS11)|(1<<CS10) );

sind es nun 7,8 statt 8µs. Danke für den Hinweis.

Edit:
Muss mich revidieren, macht keinen Unterschied. Hängt von der Oszi 
Auflösung Einstellung ab. Beide Varianten 7,8µs. Scheinbar greift hier 
schon der Compiler ein.

[H.Joachim S. (crazyhorse)]

Veit D. schrieb:
> Damit läuft der Timer max. 2ms und hat 20ms Pause.

Brauchst du das für irgendwas anderes? Wenn nicht:
Jeder ISR-Aufruf erzeugt genau einen Impuls für einen Servo.

-alle Ausgänge löschen
-den, der dran ist, setzen
-OCR mit aktuellem+gewünschter Impulslänge laden, Überlauf der Addition 
stört nicht, wenn der Timer durchläuft

Den meisten Servos ist die Impulspause völlig egal, kann man dann auch 
komplett weglassen. Oder aber einen neunten Zyklus einführen.

[Veit D. (devil-elec)]

Hallo,

aha, verstehe wie du das meinst. Dann würde der Timer maximal 8x 2ms 
hintereinander laufen. satte 16ms. Kann ich mir leider nicht erlauben. 
Genau das würde das restliche Programm stören, vorallendingen meine 
schnelle uart Kommunikation mit 250kBaud. Das ist der Nachteil schneller 
Kommunikation.

[MaWin O. (Gast)]

Veit D. schrieb:
> wenn ich zu ISR Beginn count++ mache, dann würde er doch um eins zu kurz
> zählen, sprich die Pulsslängen wäre um eine Timerpulslänge zu kurz?
>
> Wenn der Timer selbst einen Umlauf später stoppt ist das nicht schlimm.
> Er soll nur nicht ständig laufen.

Der Timerlauf fängt aber bereits mit 1 an, weil der letzte Timerlauf mit 
1 aufhört (weil count=0; count++)

[Veit D. (devil-elec)]

Hallo Mawin,

stimmt, erzeugt eine kleine ungewollte Abweichung. Danke.

[H.Joachim S. (crazyhorse)]

?
Das tut doch nicht weh, wenn der läuft :-).
Alle rund 1,5ms kommt ein int mit ein paar wenigen Takten, das ist doch 
kein Problem für die Kommunikation.
Nach deinem Verfahren hast du eine viel höhere zeitliche Belastung. Die 
ISR selbst dauert viel länger, und du musst sie für vernünftige 
Servoauflösung sehr oft aufrufen.

[Veit D. (devil-elec)]

Hallo,

das muss ich mir nochmal durch den Kopf gehen lassen. Im groben kann ich 
mir schon vorstellen wie das ablaufen könnte bzw. wie du das im Detail 
meinst. Damit wäre die Interruptlast drastisch reduziert, wenn eine ISR 
noch nur aller 1 bis 2ms dazwischen funkt. Nur wie ich die 8 Servos 
nacheinander dann einzeln steuere ist mir noch nicht so richtig bewusst.

@ Mawin:
habe nochmal nachgedacht. Weil wo ich den Code geschrieben habe ist 
schon eine Weile her. Mal angenommen ich möchte eine Pulslänge von einem 
count erzeugen, sprich einer Timerlänge von 22µs.

Ich starte in einer anderen Funktion den Timer mittels Prescaler setzen.
Der Timer läuft los und springt in die ISR wenn der Compare Vergleich 
gültig ist. Nach 22µs. Dann wird 1 == 1 verglichen, Pulslänge fertig.
Demzufolge haut das hin.

[MaWin O. (Gast)]

Veit D. schrieb:
> Demzufolge haut das hin.

Dann stimmt aber die statische Initialisierung mit 0 nicht. Denn dann 
ist der erste Durchlauf falsch.

[Veit D. (devil-elec)]

Hallo,

okay, stimmt, jetzt sollte daran alles korrekt sein.   :-)

[H.Joachim S. (crazyhorse)]

Veit D. schrieb:
> Damit wäre die Interruptlast drastisch reduziert

Genau.

[Veit D. (devil-elec)]

Hallo,

deine obigen Stichpunkte nochmal anders formuliert.
Würde für mich bedeuten, ich setze in einer Funktion, nicht in ISR, den 
gewünschten Servopin auf 1. Der Puls beginnt damit. Gleichzeitig, also 
sofort danach, lade ich den OCRnx auf den gewünschten Wert für die 
geforderte Pulslänge, aktueller Zähler + "Längencount" und die ISR 
selbst macht nichts anderes als pauschal alle Servopins wieder auf 0 zu 
setzen. Hier muss ich nicht nochmal den aktiven Pin rausfischen.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>Würde für mich bedeuten, ich setze in einer Funktion, nicht in ISR, den
>gewünschten Servopin auf 1. Der Puls beginnt damit. Gleichzeitig, also
>sofort danach, lade ich den OCRnx auf den gewünschten Wert für die
>geforderte Pulslänge, aktueller Zähler + "Längencount" und die ISR
>selbst macht nichts anderes als pauschal alle Servopins wieder auf 0 zu
>setzen. Hier muss ich nicht nochmal den aktiven Pin rausfischen.

Nicht ganz. Sinnvollerweise packt man die gesamte Servofunktionalität in 
die ISR. Mit der seriellen Servopulserzeugung kann man theoretisch mit 
einer Auflösung von 1 CPU-Takt die Servosignale erzeugen, weil dann nur 
noch der Jitter der ISR reinspuckt aber nicht mehr die minimale 
ISR-Laufzeit.

>meinst. Damit wäre die Interruptlast drastisch reduziert, wenn eine ISR
>noch nur aller 1 bis 2ms dazwischen funkt.

Die ISR funkt gar nicht dazwischen, sie macht einfach ihren Job.

> Nur wie ich die 8 Servos
>nacheinander dann einzeln steuere ist mir noch nicht so richtig bewusst.

Das ist einfach. Die Servosignale werden zwar zeitlich versetzt 
generiert, in der Praxis ist es aus Sicht der übergeordneten Steuerung 
aber vollkommen egal! Dein Programm übergibt per Funktion/globale 
Variablen die Servo-Pulsbeite an die ISR und fertig. Die Servos 
reagieren aber praktisch genau so, wie wenn die Pulse nicht zeitversetzt 
wären. Schließlich sind es nur ein paar ms.

---****---
-------****---
-----------****---

Ungefähr so. Bei 8 MHz wird man wohl auf den Prescaler /8 gehen müssen, 
das ist aber immer noch mehr als ausreichend.

#define SERVO_CNT 7  // 6 echte + 1 virtueller Servo
#define SERVO_FRQ 50  // Servo Widerholfrequenz /Hz
#define SERVO_PERIOD (F_CPU / (8* SERVO_FRQ)) // Periodendauer der Servosignale in Timer-Takten 

volatile uint16_t pulsbreite[SERVO_CNT];

ISR(TIMER1_COMPA_vect) {
  static uint8_t servo;
  
  switch(servo) {
    0: K6_1_OFF; K6_2_ON; break;
    1: K6_2_OFF; K6_3_ON; break;
    2: K6_3_OFF; K6_4_ON; break;
    3: K6_4_OFF; K6_5_ON; break;
    4: K6_5_OFF; K6_6_ON; break;
    5: K6_6_OFF;          break;
    6:           K6_1_ON; break;  // virtueller Servo
  }

  servo++;
  if (servo => SERVO_CNT) servo = 0;
  OCR1A += pulsbreite[servo];
}

Wenn man dann noch einen zusätzlichen, virtuellen Servokanal einfügt, 
welcher als Pulsbreite die Differenz der echten Kanäle zur minimalen 
Periodendauer kompensiert, ist es perfekt.

calc_vservo(void){
  uint16_t i, j;

  for (i=0, j=0; i<SERVO_CNT-1; i++) {
    j += pulsbreite[i];
  }
  pulsbreite[SERVO_CNT-1] = SERVO_PERIOD - j;
}

[Peter D. (peda)]

Veit D. schrieb:
> Genau das würde das restliche Programm stören, vorallendingen meine
> schnelle uart Kommunikation mit 250kBaud.

Das ist Unsinn. Die UART kann 2 Byte puffern, ehe ihr Interrupt 
behandelt werden muß. Das ergibt satte 640 Zyklen Zeit bei 8MHz, um die 
andere Interrupts verzögern dürfen.

Mit einem zusätzlichen 74HC164 könnte man 8 Servos sogar auf 125ns genau 
ansteuern, indem der 74HC164 seinen CLK von einem Compare-Output 
bekommt. Und zwischen den Takten sind >1ms (8000 Zyklen) Zeit, um das 
nächste Compare vorzubereiten.

[Veit D. (devil-elec)]

Hallo Falk,

mit dazwischen funken meinte ich, dass die ISR Zeit meine serielle 
Kommunikation dahingehend stört, dass ich das Byte vom Ringbuffer zu 
spät abhole, weil die ISR zu oft und zu lange benötigt. So wie ich den 
Timer bzw. ISR derzeit verwende. Das kann ich zwar mit gewissen "Tricks" 
umgehen, ist aber ziemlich unschön. Der Code wird auch nicht gerade 
lesbarer.

Die Servos müssen und sollen bei mir nicht permanent laufen. 1s reicht 
aus. Nur solange das sie sicher ihre Position erreichen. Ihre eigene 
Getriebesperrung ist hier ausreichend. Deshalb das einschalten der 
Servos in einer anderen Funktion als die ISR. Hat aber den Nachteil, wie 
von dir aufgezeigt, gewisse Timingdifferenzen, wenn man nicht alles in 
der ISR erledigt.

Ich überlege mir aktuell etwas, wo ich noch eine Art Flag mitgebe ob das 
spezielle Servo was jetzt dran wäre überhaupt eingeschaltet werden soll 
oder nicht.

Vielen Dank erstmal.

Tschau
Veit

[Falk B. (falk)]

Naja, wenn noch ein UART mit 250kBAud (DMX512?) nebenher läuft, muss man 
ein wenig tricksen. D.h. man schalter kurz vor dem eigentlichen 
Interrupt den UART-Interrupt ab und nach dem COMPA Interrupt wieder an. 
Doch wie macht man das praktisch? Mit dem COMPB Interrupt!

#define TIMING_WINDOW 75   // Timer Cycles

ISR(TIMER1_COMPA_vect) {
  static uint8_t servo;
  
  switch(servo) {
    0: K6_1_OFF; K6_2_ON; break;
    1: K6_2_OFF; K6_3_ON; break;
    2: K6_3_OFF; K6_4_ON; break;
    3: K6_4_OFF; K6_5_ON; break;
    4: K6_5_OFF; K6_6_ON; break;
    5: K6_6_OFF;          break;
    6:           K6_1_ON; break;  // virtueller Servo
  }

  servo++;
  if (servo => SERVO_CNT) servo = 0;
  OCR1A += pulsbreite[servo];
  OCR1B  = OCR1A - TIMING_WINDOW;
  USCR0B |= (1<<RXCIE0);  // USART0 RXC ISR ON
}

ISR(TIMER1_COMPB_vect) {
  USCR0B &= ~(1<<RXCIE0);  // USART0 RXC ISR OFF
}

TIMING_WINDOW muss per #define so groß gewählt sein, daß die UART RX ISR 
definitv WENIGER Timer-Takte braucht, gleichzeitig aber innerhalb dieser 
Zeit nicht mehr als 2 Datenbytes ankommen können.

[Veit D. (devil-elec)]

Hallo,

aber Peter, die uart kann meinetwegen 2000 Bytes puffern. Wenn die 
Hauptschleife keine Zeit hat diese abzuholen gehen auch hier irgendwann 
Bytes verloren. Ich kann ja nur vom aktuellen Zustand reden. Und da wird 
die ISR aller 22µs aufgerufen und benötigt selbst derzeit 8µs, es 
verbleiben für das Hauptprogramm demzufolge nur 14µs für alles, unter 
anderem ein Byte vom Ringerbuffer zu holen.
Wie gesagt, ich rede vom aktuellen Programmzustand.
Wenn ich das ändere wie hier gesagt, sieht das alles anders aus.
Das darf man jetzt nicht alles zusammenwürfeln, dann kommen falsche 
Meinungen bei raus.

Ich tüftel mal weiter ...   :-)

Tschau
Veit

[H.Joachim S. (crazyhorse)]

Falk B. schrieb:
> Naja, wenn noch ein UART mit 250kBAud (DMX512?) nebenher läuft, muss man
> ein wenig tricksen.

Da braucht man gar nicht tricksen. Bei 250kBaud dauert ein Zeichen schon 
mal 40µs, also 320 Takte. Das braucht dein obiges Programm bei weitem 
nicht, ich schätze mal um die 100, wenn überhaupt. Also selbst bei 
gleichzeitigem OCR- und UART-Int gibts keine Probleme.

[Veit D. (devil-elec)]

Hallo,

upps Falk hat schon wieder geantwortet.

Wenn die ISR kurz genug ist, sollte das die uart Kommunikation nicht 
stören, wenn das aller 1 bis 2ms auftritt. Wenn alle Stränge reißen, 
kann ich notfalls die Baudrate halbieren, möchte ich aber erstmal 
vermeiden.

Kein DMX, normale serielle zwischen mehreren Controllern.
Das wird am Ende eine Modelleisenbahnsteuerung.
Im Grunde ist es eine Eigenbau SPS wenn man das nüchtern betrachtet.

Jetzt hat Joachim zwischenzeitlich noch geantwortet.

Geht alles in die richtige Richtung.

Danke euch erstmal.

[Falk B. (falk)]

@ H.Joachim Seifert (crazyhorse)

>> Naja, wenn noch ein UART mit 250kBAud (DMX512?) nebenher läuft, muss man
>> ein wenig tricksen.

>Da braucht man gar nicht tricksen.

Doch, muss man!

> Bei 250kBaud dauert ein Zeichen schon
>mal 40µs, also 320 Takte. Das braucht dein obiges Programm bei weitem
>nicht, ich schätze mal um die 100, wenn überhaupt. Also selbst bei
>gleichzeitigem OCR- und UART-Int gibts keine Probleme.

Falsch!

Das Problem ist der JITTER! Wenn nämlich ein handvoll Takte VOR dem 
COMPA-Interrupt der UART-RXC Interrupt aktiv wird, wird dieser 
ausgeführt und verzögert damit die Ausführung des COMPA-Interrupts. Das 
ist natürlich zufällig -> Jitter im Servosignal!

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>Wenn die ISR kurz genug ist, sollte das die uart Kommunikation nicht
>stören, wenn das aller 1 bis 2ms auftritt.

Schon mal das Ganze anders herum betrachtet? Daß der UART die 
Servosignale stört?

>Kein DMX, normale serielle zwischen mehreren Controllern.
>Das wird am Ende eine Modelleisenbahnsteuerung.

Mit 250kBaud? Wieviel Millionen Weichen und Licher willst du damit 
steuern?

[Veit D. (devil-elec)]

Hallo,

anders betrachtet auch wieder wahr. Anderer Blickwinkel.

Das wird keine einfache Steuerung die nur auf Benutzereingaben wartet. 
Die soll in bestimmten Grenzen selbst Intelligenz zeigen. Kommt eine Lok 
woher angefahren, muss sowohl dessen Position als auch Richtung erkannt 
und abgefragt werden, danach werden entsprechend Weichen gesteuert. Das 
muss alles bissel ratz fatz gehen. An zu steuernden Teilen und 
vorallendingen Eingangssignalen (Sensoren) kommt schon einiges zusammen. 
Auch wenn die Anlage nicht groß wird.

[Peter D. (peda)]

Veit D. schrieb:
> Ich kann ja nur vom aktuellen Zustand reden. Und da wird
> die ISR aller 22µs aufgerufen und benötigt selbst derzeit 8µs, es
> verbleiben für das Hauptprogramm demzufolge nur 14µs für alles, unter
> anderem ein Byte vom Ringerbuffer zu holen.

Den Zustand kannst Du leicht ändern. Beim nacheinander Erzeugen der 
Servosignale hast Du nur alle 1..2ms einen Timerinterrupt und schon ist 
die CPU-Last kaum merkbar.
Und den Jitter durch die UART kannst Du gering halten, indem der 
UART-Interrupt sich selbst disabled und global die Interrupts freigibt 
(am Ende umgekehrt).
Völlig jitterfrei wäre die 74HC164 Variante.

[Veit D. (devil-elec)]

Hallo,

Peter, darüber reden wir doch schon die ganze Zeit, genau darüber ...
Aber schön das du der gleichen Meinung/Ansicht bist.

Die Falk Variante klingt vielversprechend. Ich versuche mich erstmal 
daran.
Habe das Rechtecksignal im Normal- und CTC Mode schon hinbekommen mit 
switch-case. Werde wohl bei CTC bleiben.

Wünsche allen schon einmal einen guten Rutsch ...
& vielen Dank
Veit

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>Die Falk Variante klingt vielversprechend. Ich versuche mich erstmal
>daran.

Gut.

>Habe das Rechtecksignal im Normal- und CTC Mode schon hinbekommen mit
>switch-case. Werde wohl bei CTC bleiben.

Nein! Diese Methode benötigt den Normalmodus des Timers! Der muss von 
0-0xFFFF durchlaufen!

[Veit D. (devil-elec)]

Hallo,

warum unbedingt Normal-Mode?
Worin macht sich das bemerkbar?

Im Normal-Mode addieren
OCR1A += pulsweite;

Im CTC Mode zuweisen
OCR1A = pulsweite;

Ich sehe es auf dem Oszi das es erstmal passt.
Alle 3 haben 2ms Puls und 18ms Pause.

ISR(TIMER1_COMPA_vect)    
{
  P_ON;                   // Sichtbarkeit des Timers zum vermessen
    
  static uint8_t servo = 0;
  const uint8_t SERVO_CNT = 9;        // Anzahl Servos

  switch(servo) {
    case 0: Servo0_OFF; Servo1_ON;  break;
    case 1: Servo1_OFF; Servo2_ON;  break;
    case 2: Servo2_OFF;             break;    
    case 3:                         break;    // virtueller Servo
    case 4:                         break;    // virtueller Servo
    case 5:                         break;    // virtueller Servo
    case 6:                         break;    // virtueller Servo
    case 7:                         break;    // virtueller Servo
    case 8:                         break;    // virtueller Servo
    case 9:             Servo0_ON;  break;    
  }

  servo++;
  
  if (servo > SERVO_CNT)  servo = 0;
  
  OCR1A = 15999;
  
  P_OFF;
}

CTC, Prescaler 1.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>Im Normal-Mode addieren
>OCR1A += pulsweite;

>Im CTC Mode zuweisen
>OCR1A = pulsweite;

Ok, so geht es auch.

>Ich sehe es auf dem Oszi das es erstmal passt.
>Alle 3 haben 2ms Puls und 18ms Pause.

In deinem Test ist ja auch alles statisch und gleich.

>CTC, Prescaler 1.

Tja, hier liegt das Problem. Bei 8 MHz und 50 Hz (20ms) Wiederholrate 
hat man 160.000 Timer-Takte / Servo-Periode. Ein 16 Bit Timer kann aber 
nur bis 65535 zählen bzw. 65536 Zyklen/Umlauf. Also müßte man die 
160.000 Takte durch MINDESTENS drei virtuelle Servos auf mindestens 3 
ISR-Durchläufe strecken, damit der OCR1A Wert immer <=65535 ist. Kann 
man machen, ist aber irgendwo albern. Mit Prescaler /8 und 1us 
Zeitauflösung hat man bei 2ms Pulsbreite schon 2000 Schritte/11 
Bit/0,18° Auflösung. Das sollte reichen.

[Veit D. (devil-elec)]

Hallo,

korrigiere mich wenn ich falsch liege.

Meine Meinung zum OCR1A Wert, Überlauf usw.

Der Timer muss nur bis 2ms laufen. Die Pulspause erzeugen wir doch mit 
den virtuellen Servos. Womit wir die restliche Zeit strecken um auf 18ms 
Pause zu kommen. Das ist doch dein Trick, den ich so verstanden hatte 
bzw. auch der von Joachim.

Wenn die ISR aller 20ms aufgerufen wird könnte ich doch nie nach 2ms 
abschalten.

Oder wir reden aneinander vorbei und du möchtest nur ein einziges 
virtuelles Servo verwenden was die restliche Pause erzeugt, dann müßte 
ich deinen Einwand beachten, weil dann der Timerwert entsprechend groß 
wird.

ISR(TIMER1_COMPA_vect)    
{
  P_ON;                   // Sichtbarkeit des Timers zum vermessen
    
  static uint8_t servo = 0;
  const uint8_t SERVO_CNT = 9;        // Anzahl Servos
  uint16_t temp;
  
  switch(servo) {
    case 0: Servo0_OFF; Servo1_ON; temp =  9999; break;
    case 1: Servo1_OFF; Servo2_ON; temp = 11999; break;
    case 2: Servo2_OFF;            temp = 15999; break;    
    case 3:                        temp = 15999; break;    // virtuel
    case 4:                        temp = 15999; break;    // virtuel
    case 5:                        temp = 15999; break;    // virtuel
    case 6:                        temp = 15999; break;    // virtuel
    case 7:                        temp = 15999; break;    // virtuel
    case 8:                        temp = 15999; break;    // virtuel
    case 9:             Servo0_ON; temp =  7999; break;    
  }

  servo++;
  
  if (servo > SERVO_CNT)  servo = 0;
  
  OCR1A = temp;
  
  P_OFF;
}

Passt immer noch, egal ob CTC oder Normal.
Bis ich die Pulsweitenberechnungen angepasst habe dauert noch, derweile 
behelfe ich mir so zum testen und rantasten wie das funktioniert.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>Meine Meinung zum OCR1A Wert, Überlauf usw.

>Der Timer muss nur bis 2ms laufen. Die Pulspause erzeugen wir doch mit
>den virtuellen Servos. Womit wir die restliche Zeit strecken um auf 18ms
>Pause zu kommen. Das ist doch dein Trick, den ich so verstanden hatte
>bzw. auch der von Joachim.

Ja.

>Wenn die ISR aller 20ms aufgerufen wird könnte ich doch nie nach 2ms
>abschalten.

Davon war doch auch nie die Rede.

>Oder wir reden aneinander vorbei

Wahrscheinlich.

>und du möchtest nur ein einziges
>virtuelles Servo verwenden was die restliche Pause erzeugt,

So der Ansatz.

> dann müßte
>ich deinen Einwand beachten, weil dann der Timerwert entsprechend groß
>wird.

Das meinte ich.

>Passt immer noch, egal ob CTC oder Normal.

Sicher.

Ob Normalmodus oder CTC ist fast egal. Das Problem des zu schnellen 
Taktes bei 8 MHz ist davon unabhängig.

[Veit D. (devil-elec)]

Hallo,

okay, mit nur einen einzigen virtuellen Servo zum Pause strecken sollte 
die ISR auch zeitlich kürzer dauern, mit weniger cases.

Gut, Danke für den Einwand.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>okay, mit nur einen einzigen virtuellen Servo zum Pause strecken sollte
>die ISR auch zeitlich kürzer dauern, mit weniger cases.

Nein, das tut sie nicht, denn der Compiler ist im Normalfall schlau 
genug, die Auswertung eines switch() Konstrukts recht schnell und nahezu 
unabhängig von der Anzahl der case Einträge zu machen. Er macht das 
NICHT wie du mit einer riesigen Kette von if() Vergleichen! Und selbst 
wenn sie geringfügig länger dauern sollte, spielt das keinerlei Rolle, 
denn diese ISR wird nur N+1 mal pro Periode für N echte Servos 
aufgerufen. Ob das nun 7 oder 10 sind ist praktisch egal.

[H.Joachim S. (crazyhorse)]

Falk B. schrieb:
> Falsch!
>
> Das Problem ist der JITTER! Wenn nämlich ein handvoll Takte VOR dem
> COMPA-Interrupt der UART-RXC Interrupt aktiv wird, wird dieser
> ausgeführt und verzögert damit die Ausführung des COMPA-Interrupts. Das
> ist natürlich zufällig -> Jitter im Servosignal!

So herum gesehen ist das ein Problemchen, aber auch nur ein 
theoretisches.
Wie lange dauert ein Rx-Int incl. wegschreiben in einen Ringbuffer? 30 
Takte? Vielleicht 50, schau ich mir jetzt nicht genau an. Wir reden bei 
50 Takten von max. 6µs jitter, eher weniger. Und das nur sporadisch am 
selben Servo. Vielleicht kann man es an der Stromaufnahme erkennen, 
bewegen wird es sich nicht. Wichtig ist nur, dass keine bytes der 
Kommunikation verloren gehen. Und das ist sichergestellt.

[Falk B. (falk)]

@ H.Joachim Seifert (crazyhorse)

>> Das Problem ist der JITTER! Wenn nämlich ein handvoll Takte VOR dem
>> COMPA-Interrupt der UART-RXC Interrupt aktiv wird, wird dieser
>> ausgeführt und verzögert damit die Ausführung des COMPA-Interrupts. Das
>> ist natürlich zufällig -> Jitter im Servosignal!

>So herum gesehen ist das ein Problemchen, aber auch nur ein
>theoretisches.

NEIN! Weder ein Problemchen noch theoretisch!

>Wie lange dauert ein Rx-Int incl. wegschreiben in einen Ringbuffer? 30
>Takte? Vielleicht 50, schau ich mir jetzt nicht genau an. Wir reden bei
>50 Takten von max. 6µs jitter, eher weniger.

Richtig! Und ohne diesen Jitter hätte das Signal nur 1-2 CPU Takte, 
sprich 125-250ns Jitter, dazwischen liegt der Faktor 24-48!

> Und das nur sporadisch am
>selben Servo. Vielleicht kann man es an der Stromaufnahme erkennen,
>bewegen wird es sich nicht.

Das weißt du gar nicht. Besonders digitale Servos gelten als sehr agil!

> Wichtig ist nur, dass keine bytes der
>>Kommunikation verloren gehen. Und das ist sichergestellt

Du bist und bleibst ein Schwätzer ohne Rückgrat. Ein Mensch mit diesem 
hätte einen Irrtum eingestanden und gut. Du aber versuchst mit billgen 
Ausreden Recht zu behalten. Es wird dir nicht gelingen!

[Veit D. (devil-elec)]

Hallo Nachtschwärmer,

bitte nicht in dem schönen Thread streiten. Das läuft gerade so schön 
interessant mit euch.

Ob der Jitter praktisch stört oder nicht darüber kann man reden.
Wenn man das Problem kennt, kann man es berücksichtigen.
Ich werde auf jeden Fall beide Varianten testen.
Danke an beide.

Was ich eigentlich noch berichten wollte, dass die kürzere 3 cases 
Version mit 3,4µs minimal schneller ist wie die 9 cases Version mit 
3,7µs.

Die 3 cases Version hat noch einen Vorteil, die ISR hat auch mal eine 
längere Pause, nämlich der restlichen Pausenzeit der fehlenden Servos. 
Die Pausenfüllzeit. Vorrausgesetzt man nutzt nicht alle die möglich 
sind.
Sieht man am unteren 4. Kanal, der Abstand der Spitzen, was dem ISR 
Aufruf bedeutet.

Jetzt ist erstmal die Matraze am Zug ...

ISR(TIMER1_COMPA_vect)    // wird aller >1ms aufgerufen (Prescaler 8)
{
  Servo8_ON;
  
  static uint8_t servo = 0;
    const uint8_t SERVO_CNT = 9;        // Anzahl Servos
    uint16_t temp = 0;
    /*
    switch(servo) {    // ISR Zeit 3,4µs
      case 0: Servo5_OFF;  Servo6_ON;  temp =  1499; break;
      case 1: Servo6_OFF;  Servo7_ON;  temp =  1999; break;
      case 2: Servo7_OFF;              temp = 16999; break;  // virtuelle
      case 3:              Servo5_ON;  temp =   999; break;
    }
    */
  switch(servo) {    // ISR Zeit 3,7µs
    case 0: Servo5_OFF; Servo6_ON;  temp =  1499; break;
    case 1: Servo6_OFF; Servo7_ON;  temp =  1999; break;
    case 2: Servo7_OFF;             temp =  1999; break;  // virtuelle
    case 3:                         temp =  1999; break;
    case 4:                         temp =  1999; break;
    case 5:                         temp =  1999; break;
    case 6:                         temp =  1999; break;
    case 7:                         temp =  1999; break;
    case 8:                         temp =  1999; break;
    case 9:             Servo5_ON;  temp =   999; break;
  }  
  
    servo++;
    
    if (servo > SERVO_CNT)  servo = 0;
    
    OCR1A = temp;
  
  // Count   999 =  1ms
  // Count  1999 =  2ms
  // Count 19999 = 20ms
  
  Servo8_OFF;
}

[H.Joachim S. (crazyhorse)]

Das ist doch kein Streit :-)
Ich hatte doch geschrieben, dass Falk prinzipiell Recht hat - damit habe 
ich überhaupt kein Problem.
Die Frage ist einfach: stört das ab und zu auftretende Fehlerchen oder 
nicht? Servos haben auch einen Totbereich in der Grössenordnung.
Und natürlich kann man es auch von vornherein so exakt wie möglich 
machen.

[Veit D. (devil-elec)]

Hallo,

schön, dann bin ich beruhigt.   :-)

Zur Zeit teste ich mit permanenter Kommunikation ohne Pause. Die 
serielle hat demzufolge keine Pause. Bis jetzt noch kein Fehler, kein 
Antwort-Timeout oder sonstige Verschlucker. Sehr schön.

Habe noch den usart receive Interrupt vermessen, diese ISR benötigt 
genau 4,24µs, sagen wir 4,3µs.

Damit muss das abzügliche Timing Windows gegen den Jitter mindestens:
4300ns/125ns = 35 Takte/Counts betragen.

Dazu kommt bestimmt noch ein Overhead den ich nicht messen kann, rein- 
und rausspringen in die ISR dazu. Also ich schätzte unter 50 darf es 
nicht sein. Oder sind die oben besagten 75 Takte schon anderweitig 
berechnet wurden?

[Falk B. (falk)]

@Veit Devil (devil-elec)

>Habe noch den usart receive Interrupt vermessen, diese ISR benötigt
>genau 4,24µs, sagen wir 4,3µs.

Vorsicht. Die Zeit vor und nach dem Setzen deines IOs kannst du nicht 
messen, die sieht man nur im Assemblercode! Das können mal fix 50 Takte 
sein, macht bei 8 MHz ca. 6us!

Beitrag "Re: Frage zu IR-Remote+LED-Strips an AVR"

>Damit muss das abzügliche Timing Windows gegen den Jitter mindestens:
>4300ns/125ns = 35 Takte/Counts betragen.

Vorsicht, in meinem Beispiel muss man das in Timer-Takte umrechnen, also 
nochmal /8., also eher 5-6.

[Veit D. (devil-elec)]

Hallo,

mit aktiver Jitter Korrektur habe ich immer mal wieder 
Kommunikationsaussetzer, sprich der Slave antwortet nicht, weil er das 
Datenpaket nicht komplett lesen konnte.

Das Timing-Window kann ich niedriger und höher setzen, ändert leider 
nichts.

Konfiguriere ich den Timer auf Normalmode, addiere ich OCR1x oder weise 
ich zu, ändert auch nichts an den Aussetzern.
Im CTC Mode sind die Aussetzer sporadisch.
Im Normalmode ist eine Weile Ruhe um dann wieder massiv zu sein und dann 
wieder Ruhe, als wenn sich ein Fehler aufaddiert und verschiebt.
Habe eigentlich schon alle Varianten probiert. Normal, CTC, OCR1x 
addieren, zuweisen ...

Laut meiner Meinung kann OCR1B Werte zwischen 0 und 65535 annehmen, 
demzufolge stört es die uart mit kleinen Werten und mit großen Werten 
eher nicht. ???

ATtiny841

void set_Timer1 ()    
{
  cli();      // Interrupts ausschalten
  TCCR1A = 0;    // Reset TCCR1A Register
  TCCR1B = 0;    // Reset TCCR1B Register
  TIMSK1 = 0;    // Reset TIMSK1 Register (disable Timer Compare Interrupts)
  TCNT1 = 0;    // Start 0
  OCR1A = 19999;  // TOP Wert & Prescaler 8 = 20ms 
  TIMSK1  = (1<<OCIE1A);  // enable Compare Match A ISR
  TIMSK1 |= (1<<OCIE1B);  // enable Compare Match B ISR
  //TCCR1B = (1<<WGM12);  // CTC
  TCCR1B |= (1 << CS11);  // Prescaler 8, Timer starten
  sei();          // Interrupts einschalten
}

ISR(TIMER1_COMPA_vect)    // wird aller >1ms aufgerufen (Prescaler 8)
{
  Servo8_OFF;
  
  static uint8_t servo = 0;
  const uint8_t SERVO_CNT = 3;        // Anzahl Servos
  const uint8_t TIMING_WINDOW = 7;    // 6µs / 125ns / Prescaler 8 = 6,25 Timertakte
  uint16_t temp = 0;
    
  switch(servo) {    // ISR Zeit 4,75µs
    case 0: Servo5_OFF;  Servo6_ON;  temp =  1499; break;
    case 1: Servo6_OFF;  Servo7_ON;  temp =  1999; break;
    case 2: Servo7_OFF;              temp = 16999; break;  // virtuelle
    case 3:              Servo5_ON;  temp =   999; break;
  }
    
  servo++;
    
  if (servo > SERVO_CNT)  servo = 0;
    
  OCR1A += temp;
  OCR1B = OCR1A-TIMING_WINDOW;
  UCSR0B |= (1<<RXCIE0);    // enable USART0 RX Complete Interrupt
  
  // Count   999 =  1ms
  // Count  1999 =  2ms
  // Count 19999 = 20ms
  
  Servo8_ON;
}

ISR(TIMER1_COMPB_vect)      // dauert 1,13µs
{  
  UCSR0B &= ~(1<<RXCIE0);    // disable USART0 RX Complete Interrupt
}

[Veit D. (devil-elec)]

Hallo,

Ergänzung:
1 Datenbyte dauert 40µs.
Das komplette Protokoll aus 11 Bytes demzufolge 440µs.

Eigentlich antwortet der Slave nach 120µs.
Mein Antwort Timeoutfenster ist auf 5ms festgelegt.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>mit aktiver Jitter Korrektur habe ich immer mal wieder
>Kommunikationsaussetzer, sprich der Slave antwortet nicht, weil er das
>Datenpaket nicht komplett lesen konnte.

Schlecht.

>Das Timing-Window kann ich niedriger und höher setzen, ändert leider
>nichts.

Dann liegt der Fehler woanders.

>Im CTC Mode sind die Aussetzer sporadisch.

Das kann eher Zufall sein.

>{
>  cli();      // Interrupts ausschalten
>  TCCR1A = 0;    // Reset TCCR1A Register
>  TCCR1B = 0;    // Reset TCCR1B Register
>  TIMSK1 = 0;    // Reset TIMSK1 Register (disable Timer Compare Interrupts)

Das ist alles Unsinn, die Register haben definierte Reset-Werte.

>  TCNT1 = 0;    // Start 0

Dito.

>  TIMSK1  = (1<<OCIE1A);  // enable Compare Match A ISR
>  TIMSK1 |= (1<<OCIE1B);  // enable Compare Match B ISR

Das kann man in eine Zeile schreiben.

>ISR(TIMER1_COMPA_vect)    // wird aller >1ms aufgerufen (Prescaler 8)
>{
>  Servo8_OFF;

>  static uint8_t servo = 0;
>  const uint8_t SERVO_CNT = 3;        // Anzahl Servos
>  const uint8_t TIMING_WINDOW = 7;    // 6µs  125ns  Prescaler 8 = 6,25 
Timertakte

Warum änderst du die #defines in echte Variablen? Das ist zwar nicht 
schlimm bringt aber auch keine Vorteile.

Der Fehler entsteht im Gesamtzusammenhang. Wir kennen aber weder deinen 
vollständigen Quelltext noch deine Testumgebung.

Hmm, ich hab noch ne Vermutung. Wenn dein TIMING_WINDOW zu klein ist, 
kann es passieren, daß gerade bei UART RXC Interrupt der COMPB und kurz 
danach der COMPA Interrupt aktiv werden. Wird der UART RX Interrupt nun 
beendet, wird ZUERST der COMPA Interrupt ausgeführt und DANACH erst 
COMPB, denn der hat eine niedrigere Priotität, weil er weiter unten in 
der Interruptvektortabell steht, siehe Datenblatt! Und damit wird der 
UART für LANGE Zeit ausgeschaltet!! AUTSCH.

Lösung. Setz mal TIMING_WINDOW = 20 oder gar 30.

[Veit D. (devil-elec)]

Hallo,

#defines:
habe gelesen das man wenn möglich const statt #defines verwenden soll, 
wegen Datentypprüfung und der Compiler kann damit besser umgehen.

einzelne Zeilen zur Registerkonfig:
damit kann ich beim testen Dinge besser auskommentieren

Register vorher nullen:
alte Angewohnheit, programmiere parallel noch einen Arduino in der 
Arduino IDE, da muss man das machen, bei eigener Timerkonfig

Sind jedoch alles Dinge die keine Rolle spielen, jeder schreibt seinen 
Syntax etwas anders.  :-)

Window 20-30 zeigt leider keine Besserung, würde meiner Logik 
widersprechen, je größer der Wert umso länger ist die uart tot gelegt. 
Dagegen bringt eine 1 auch keine Besserung. Verhext.

Nochmal zum Verständnis. Der "uart rx ISR" muss nur um die Zeit eher 
abgeschaltet werden wie wie der "uart rx ISR" selbst benötigt?

Wenn ich auf den COMPB trigger am Oszi, dann zappelt COMPA zeitlich hin 
und her. Das sollte doch eigentlich immer im gleichen Abstand sein?

[Veit D. (devil-elec)]

Hallo,

meine aktuelle These.

OCR1B wird ja im COMPA ISR geändert. Bedeutet doch eigentlich, dass 
beide nicht syncron laufen können, weil COMPB immer erst auf den compare 
wartet bevor der neue Wert übernommen wird.

Dagegen wird OCR1A sofort übernommen, weil es in der eigenen COMPA 
geändert wird.

Ich denke hier müssen wir neu ansetzen?

[Joachim B. (jar)]

ich blick zwar grad nicht mehr durch, aber der Thread und die Diskusion 
gefällt mir.
Hier kann man entgegen vieler Kritiker auch mal Perlen fischen und was 
lernen.

[Veit D. (devil-elec)]

Hallo,

genau meine Meinung. Mir gefällt es auch. Fühl mich wohl.
Habe auch bis jetzt viel gelernt wie man die Servosteuerung besser 
machen kann mit weniger CPU Last. Meine alte Variante war zu sehr CPU 
lastig am absoluten Rande des machbaren.

Die nackte neue Servosteuerrung funktioniert.
Nur sobald ich einen zweiten Compare Match B dazu nehme, der paar Takte 
vor Compare_A den uart receive abschalten soll, kommt die Kommunikation 
außer Tritt. Obwohl genügend Zeit wäre.

Ein Byte dauert 40µs. Bedeutet es muss nach 40µs vom Ringbuffer geholt 
werden sonst ist es verloren und damit ein Kommunikationsaussetzer.

Oder wir unterschätzen vielleicht das Compare A und Compare B ISR 
zusammen 40µs benötigen. ???

Habe auch schon CompA mit CompB vertauscht, aber da funktionierte nichts 
mehr. Habe momentan keine Idee mehr.

[S. Landolt (Gast)]

> Bedeutet es muss nach 40µs vom Ringbuffer geholt
> werden sonst ist es verloren und damit ein Kommunikationsaussetzer.


Trotz "The receive buffer consists of a two level FIFO"?

[Veit D. (devil-elec)]

Hallo,

habe meine Kommunikation mal dahin gehend geändert das ich einigermaßen 
debuggen bzw. mitloggen kann. Ich frage also den Slave permanent reihum 
immer auf TCNT1, OCR1A und OCR1B ab und lasse das im Terminal ausgeben.

Immer wenn die Ausschrift "countErrors" erscheint kam vom Slave keine 
Antwort zurück.

Zwischen den Ausschriften "countErrors" habe ich immer paar Zeilen 
gelöscht, sonst wird das Ellenlang.

Ich erkenne jedoch das OCR1B manchmal größer OCR1A ist. Was nicht sein 
dürfte. Und zwar immer dann, wenn OCR1A einen Wert für einen Puls hat. 
Nicht wenn er die Pausenlücke füllt.

Zwischen den Anfragen liegen 1,36ms. Schneller geht mit Ausgabe nicht.
Kann auch daran liegen, weil die Pulse kürzer sind wie das 
Abfrageintervall und sich überschneidet.

T 14039  A 16999  B 16990  
T 38     A 1499   B 1990  
T 243    A 16999  B 16990  
T 4123   A 16999  B 16990  
T 11960  A 16999  B 16990  
T 15932  A 999    B 
countErrors 61

16990  
T 3247  A 16999  B 16990  
T 7178  A 16999  B 16990  
T 11109  A 16999  B 16990  
T 15094  A 16999  B 990  
T 7788   A 16999  B 16990  
T 11732  A 16999  B 16990  
T 15717  A 999    B 
countErrors 62

16990  
T 3085   A 16999  B 16990  
T 10942  A 16999  B 16990  
T 14927  A 16999  B 990  
T 820    A 1999   B 1990  
T 1088   A 16999  B 16990  
T 14937  A 16999  B 990  
T 817    A 1999   B 1990  
T 1073   A 16999  B 16990  
T 16816  A 1499   B 1490  
T 
countErrors 63

3950     A 16999  B 16990  
T 11815  A 16999  B 16990  
T 15788  A 999    B 1490  
T 87     A 1999   B 16990  
T 606    A 1499   B 1990  
T 1851   A 16999  B 16990  
T 11660  A 16999  B 16990  
T 15631  A 16999  B 
countErrors 64

16990  
T 3613   A 16999  B 16990  
T 15435  A 16999  B 1490  
T 1380   A 1999   B 16990  
T 13730  A 16999  B 16990  
T 693    A 1499   B 1990  
T 1963   A 16999  B 16990  
T 11762  A 16999  B 16990  
T 15747  A 999   B 
countErrors 65

16990  
T 3064   A 16999  B 16990  
T 6981   A 16999  B 16990  
T 10912  A 16999  B 16990  
T 14897  A 16999  B 990  
T 777    A 1999   B 1990

[Some Kind of Schniedelwutz (Gast)]

S. Landolt schrieb:
> Trotz "The receive buffer consists of a two level FIFO"?

Trotz. Das hat er ja geschrieben und er hat das Programm in der Realität 
laufen...

[S. Landolt (Gast)]

> Das hat er ja geschrieben
In der Tat. Verstanden habe ich es trotzdem nicht.

Aber eine Frage, ich habe keine konkrete Vorstellung:
> Kommt eine Lok woher angefahren...
Wie schnell fährt eigentlich so ein Modellbahnzug?

[Joachim B. (jar)]

S. Landolt schrieb:
> Wie schnell fährt eigentlich so ein Modellbahnzug?

gefühlt unrealistisch schnell wenn ich so 50 Jahre zurück denke, die 
Teile waren schneller als es dem Maßstab entsprechen dürfte.

Ich weiss ja nicht wie das heute bei Modellbauer gesehen wird, schnell 
damit was auf der Anlage passiert und sich Zusände ändern gegen die 
Langeweile, oder eher gemütlich um möglichst realitätsnah zu werden?

[Veit D. (devil-elec)]

Hallo,

ich nutze die uart Lib von Peter Fleury, bis jetzt bestens.

Laut meinem Verständnis holt uart0_getc() immer nur ein Byte ab.
Danach muss erneut die Hauptprogrammschleife while(1) durchlaufen 
werden.
Das wird scheinbar zu sehr gestört.
Warum und weshalb weiß ich auch nicht.

Ausschnitt:

/*************************************************************************
Function: uart0_getc()
Purpose:  return byte from ringbuffer  
Returns:  lower byte:  received byte from ringbuffer
          higher byte: last receive error
**************************************************************************/
unsigned int uart0_getc(void)
{    
    unsigned char tmptail;
    unsigned char data;
    unsigned char lastRxError;


    if ( UART0_RxHead == UART0_RxTail ) {
        return UART_NO_DATA;   /* no data available */
    }
    
    /* calculate buffer index */
    tmptail = (UART0_RxTail + 1) & UART_RX_BUFFER_MASK;
    
    /* get data from receive buffer */
    data = UART0_RxBuf[tmptail];
    lastRxError = UART0_LastRxError;
    
    /* store buffer index */
    UART0_RxTail = tmptail; 
    
    UART0_LastRxError = 0;
    return (lastRxError << 8) + data;

}/* uart_getc */

ISR (UART0_RECEIVE_INTERRUPT)    // dauert 4,24µs @ 8MHz
/*************************************************************************
Function: UART Receive Complete interrupt
Purpose:  called when the UART has received a character
**************************************************************************/
{     
    unsigned char tmphead;
    unsigned char data;
    unsigned char usr;
    unsigned char lastRxError;
 
 
    /* read UART status register and UART data register */
    usr  = UART0_STATUS;
    data = UART0_DATA;
    
    /* get FEn (Frame Error) DORn (Data OverRun) UPEn (USART Parity Error) bits */
  #if defined(FE) && defined(DOR) && defined(UPE)
    lastRxError = usr & (_BV(FE)|_BV(DOR)|_BV(UPE) );
  #elif defined(FE0) && defined(DOR0) && defined(UPE0)
    lastRxError = usr & (_BV(FE0)|_BV(DOR0)|_BV(UPE0) );
  #elif defined(FE1) && defined(DOR1) && defined(UPE1)
    lastRxError = usr & (_BV(FE1)|_BV(DOR1)|_BV(UPE1) );
  #elif defined(FE) && defined(DOR)
    lastRxError = usr & (_BV(FE)|_BV(DOR) );
  #endif

    /* calculate buffer index */ 
    tmphead = ( UART0_RxHead + 1) & UART_RX_BUFFER_MASK;
    
    if ( tmphead == UART0_RxTail ) {
        /* error: receive buffer overflow */
        lastRxError = UART_BUFFER_OVERFLOW >> 8;
    } else {
        /* store new index */
        UART0_RxHead = tmphead;
        /* store received data in buffer */
        UART0_RxBuf[tmphead] = data;
    }
    UART0_LastRxError |= lastRxError;   
}

Mein Hauptprogramm macht nichts weiter wie Serielle bedienen.

while (1)  // Hauptprogramm
{             
      handle_Serial_0_to_Serial_0();
}

bool read_Ringbuffer_0()
{   
  //  mit Fehlerbehandlung und nichts tun, no data, wird die Funktion nach  0,5 µs verlassen 
  // ohne Fehlerbehandlung und nichts tun, wird die Funktion nach 10,46 µs verlassen 
  
  static uint8_t index = 0;
  static bool state_Read = false;
  static bool state_Complete = false;
  static bool state_Bypass = false;
  uint8_t length = sizeof(Nachricht);
  
  uint16_t c = uart0_getc();        // nächstes Zeichen vom Ringbuffer holen
  
  // UART Lib Fehlercodes  (dezimal)
  //      4096        2048          1024         512                   256
  // UART_FRAME_ERROR, UART_OVERRUN_ERROR, UART_PARITY_ERROR, UART_BUFFER_OVERFLOW, UART_NO_DATA
  
  if ( c & UART_NO_DATA) {  
    return false;            // Abbruch nach 500ns, es gibt nichts zum lesen
  }
  
  if ( c > UART_NO_DATA) {        // irgendein UART Error
    state_UART_MODE = ERROR;      // Status ändern zur weiteren Fehlerbehandlung
    index = 0;
    state_Read = false;
    state_Complete = false;
    state_Bypass = false;
    return false;            // es gibt nichts zum lesen
  }
  
  // ------------------------------------------------------------------
  c &= 0xFF;                // High Byte nullen vor Weiterverarbeitung
    
  if (state_Bypass == false) {            // Byte speziell auswerten
    if (c == ESC) {            // ESC Kennung ?
      state_Bypass = true;
      return false;
    }
    else if (c == ETX) {        // ENDE Kennung ?
      state_Read = false;
      state_Complete = true;
      allows_updateEncoder = YES;
    }
    else if (c == STX) {        // START Kennung ?
      index = 0;
      state_Read = true;
      state_Complete = false;
      allows_updateEncoder = NO;
      return false;
    }
  }  

  if (state_Read == true && (index < length)) {  // Bytes einsortieren
    empfDaten.asArray[index++] = (uint8_t)c;
    state_Bypass = false;
  }
  
  if (state_Complete == true && index >= length ) {    // Übertragungsende
    state_Complete = false;
    index = 0;
    if ( calc_CRC16(empfDaten.asArray, length) == 0) {  // Checksumme korrekt ?
      if (empfDaten.toAddr == myAddr) {        // bin ich gemeint?
        return true;
      }
    }
  }    
  return false;        // noch nicht fertig oder irgendwas ging schief
}

void handle_Serial_0_to_Serial_0 ()      // 0,5ms
{  
  if( read_Ringbuffer_0() == true)  {
    sendDaten.cmd = empfDaten.cmd;
    
    switch (empfDaten.cmd) {
      
      case   1:  sendDaten.data = TCNT1;            break;
      case   2:  sendDaten.data = OCR1A;            break;
      case   3:  sendDaten.data = OCR1B;            break;
      default:  sendDaten.data = last_MasterRequestTime;  break;
    }
    
    send_Nachricht();
    
  }
}

[Dieter F. (Gast)]

S. Landolt schrieb:
> Wie schnell fährt eigentlich so ein Modellbahnzug?

Schwallgeschwindigkeit :-)

Problem wird sein, die Weichen/Signale/... rechtzeitig auf Kurs zu 
bringen. Das würde ich dann aber eher im sensorischen Bereich bzw. der 
Auswertung der Sensoren sehen.

Ansonsten - wenn ein Tiny das nicht schafft, dann muss er halt Hilfe 
eines seiner Art bekommen oder ein "Mächtigerer" muss eingreifen ...

[Veit D. (devil-elec)]

Hallo,

die Modelleisenbahn fährt mit Maßstabsgerechter Geschwindigkeit, keine 
Sorge.  :-)    Hat jedoch nichts mit dem Problem zu tun.   ;-)

[S. Landolt (Gast)]

> Hat jedoch nichts mit dem Problem zu tun.
Vielleicht doch - wenn man von den fünfundzwanzigtausend Bytes pro 
Sekunde wegkäme.

[c-hater (Gast)]

Veit D. schrieb:

> OCR1B wird ja im COMPA ISR geändert. Bedeutet doch eigentlich, dass
> beide nicht syncron laufen können

Natürlich nicht.

1) Es gibt nur einen Rechenkern. Damit ist es vollig unmöglich, dass 
zwei ISRs "synchron" (eigentlich war wohl eher "parallel" gemeint) 
ablaufen. Die Dinger können immer nur nacheinander ablaufen. Die 
Reihenfolge kann man als "quasi-zufällig" betrachten, geregelt ist sie 
nur dann, wenn die beiden IRQs wirklich exakt gleichzeitig auftreten 
oder beide während einer bestehenden Interruptsperre (aus beliebiger 
anderer Quelle, insbesondere natürlich auch die exclusive Laufzeit 
weiterer konkurrierende ISRs).
Und zwar dann in beiden Fällen durch die wohldokumentierte 
Interrupt-Priorität (=Reihenfolge der Interrupt-Vektoren).

2) In den PWM-Modi wird ein neu gesetzter OCR-Wert niemals sofort 
übernommen, sondern immer erst bein Eintreten
einer Bedingung, die in der "WGM-Tabelle" steht (Spaltenname :"Update of 
OCRx").

> weil COMPB immer erst auf den compare
> wartet bevor der neue Wert übernommen wird.
> Dagegen wird OCR1A sofort übernommen, weil es in der eigenen COMPA
> geändert wird.

OMG. RTFM.

> Ich denke hier müssen wir neu ansetzen?

Ich denke eher DU musst einfach mal das verschissene DB richtig lesen. 
WIR (;o) haben das bereits vor langer Zeit getan...

[Veit D. (devil-elec)]

Hallo,

also die Lok Geschwindigkeiten haben ja nun wirklich nichts mit dem hier 
zu tun und auch nichts mit der Baudrate.

Ich habe nochwas vermessen, die "read_Ringbuffer_0() Funktions.

Die benötigt gemessen 32µs + unbekannten Overhead. Mit den Zeiten für 
die Timer 1 Compares sprengt das bestimmt die 40µs für ein Byte holen. 
Könnte gut sein das der Compare B mit seiner benötigten Zeit das 
Zünglein an der Waage ist. Ist das möglich oder Quatsch?

@ c Liebhaber:
das ist mir alles klar, nur undeutlich ausgedrückt. Syncron kann man 
auch anders verstehen, dass ein Compare immer genau um die exakte Zeit 
vor oder nach dem anderen aktiv wird, ist für mich auch syncron.

[Dieter F. (Gast)]

Veit D. schrieb:
> Syncron kann man
> auch anders verstehen, dass ein Compare immer genau um die exakte Zeit
> vor oder nach dem anderen aktiv wird, ist für mich auch syncron

Ja, wenn dem so ist - nur die Abarbeitung verzögert sich halt in 
gleicher Reihenfolge durch den "Jitter". Und wenn zufällig beide 
"parallel" auf dem gleichen Zeitpunkt landen "zieht" die 
Interrupt-Priorität (wieder zzgl. "Jitter").

[c-hater (Gast)]

Veit D. schrieb:

> das ist mir alles klar

Nein, ist es ganz offensichtlich nicht.

> Syncron kann man
> auch anders verstehen, dass ein Compare immer genau um die exakte Zeit
> vor oder nach dem anderen aktiv wird, ist für mich auch syncron.

Genau das ist aber eben nicht zwingend der Fall. Das klappt zuverlässig 
nur ohne sonstige Interruptsperren (also insbesondere weitere 
konkurrierende Interrupts) und unter der Bedingung, dass beide 
Timer-ISRs schneller abgehandelt sind, als ein Timer-Tick dauert und 
niemals exakt gleichzeitig ausgelöst werden.

Lies' endlich dieses verdammte Datenblatt! Diese permanente 
Realitätsverweigerung ist ja echt zum Kotzen!

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>OCR1B wird ja im COMPA ISR geändert. Bedeutet doch eigentlich, dass
>beide nicht syncron laufen können, weil COMPB immer erst auf den compare
>wartet bevor der neue Wert übernommen wird.

Falsche Formulierung. Die sind schon synchron. Aber das mit dem Update 
könnte ein Problem sein.

>Dagegen wird OCR1A sofort übernommen, weil es in der eigenen COMPA
>geändert wird.

>Ich denke hier müssen wir neu ansetzen?

Man sollte es prüfen.

Das Datenblatt sagt, daß im Timer Mode 4 (CTC) OCR1x sofort einen Update 
erfährt. Damit sollte das OK sein.

Ich glaube eher, daß sich dein Gesamtprogramm anderswo verhakt.

[Falk B. (falk)]

@ c-hater (Gast)

>Lies' endlich dieses verdammte Datenblatt! Diese permanente
>Realitätsverweigerung ist ja echt zum Kotzen!

Deine cholerischen Anfälle ebenso. Nimm die Pillen und sei glücklich. 
Wir sind es dann auch.

[Dieter F. (Gast)]

Falk B. schrieb:
> Die sind schon synchron.

Ggf. - nur die Abarbeitung ist (logischerweise) unterschiedlich - je 
nach Interrupt-Priorität (falls beide auf genau den gleichen Zeitpunkt 
fallen) - ansonsten zählt halt "wer zuerst kommt mahlt zuerst" (auf 
ATTiny-Ebene).

Aber das ist hier die falsche "Ebene" - bei der Sensorik und deren 
Auswertung muss man ansetzen. Ein Servo schafft es sicher, eine Weiche 
in einer 1/2 Sekunde umzustellen - oder?

[Falk B. (falk)]

Die Funktion bool read_Ringbuffer_0() ist ausbaufähig. Die Verarbeitung 
der ankommenden Daten sollte man in einer echten Statemachine 
machen. Das ist deutlich übersichtlicher und weniger fehleranfällig.

Aber prinzipiell sehe ich erstmal keine grundlegenden Probleme.

[Some Kind of Schniedelwutz (Gast)]

Dieter F. schrieb:
> Ein Servo schafft es sicher, eine Weiche
> in einer 1/2 Sekunde umzustellen - oder?

Das ist aber nicht der Sinn eines Servos zum Stellen der Weiche. Das 
soll (wie beim Vorbild) schön langsam und gleichmäßig erfolgen.

[Dieter F. (Gast)]

Some Kind of Schniedelwutz schrieb:
> Das
> soll (wie beim Vorbild) schön langsam und gleichmäßig erfolgen.

Schön, erzähl das mal Veit ...

[Veit D. (devil-elec)]

Hallo,

Leute, wir lassen das mit der Weiche außen vor, gehört hier nicht rein.
Danke.

So.
Habe mittlerweile die Baudrate auf 125kBaud halbiert. Damit dauert ein 
Byte 80µs. Ändert leider nichts am Problem. Auch mit Window bis 30 
Timertakte. So langsam wirds echt knifflig woran das liegen könnte.

Falk, nur mal so gefragt, kam dir die Idee mit dem Jitter gestern 
spontan oder hast du das schon mal woanders ans laufen bekommen?

If the new value written to OCRnA or ICRn is lower than the current value of TCNTn, the counter will miss the compare match. The counter will then have to count to its maximum value (0xFFFF) and wrap around starting at 0x0000 before the compare match can occur.

Im CompA ISR sehe ich da keine Probleme, TCNT1 ist ja in dem Zustand 
immer kleiner OCR1A.

Beim OCR1B bin ich mir da im Moment nicht mehr so sicher, weil der wird 
nicht in seiner eigenen ISR neu gesetzt. Obwohl es in der Theorie passen 
sollte.

[Dieter F. (Gast)]

Falk B. schrieb:
> Deine cholerischen Anfälle ebenso. Nimm die Pillen und sei glücklich.
> Wir sind es dann auch.

Ich bin selten seiner Meinung - aber heute:

Nix cholerisch - eher begründet. Problem ist nicht die Schnelligkeit der 
Servo-Bewegung - mehr der Auswertung der Sensoren und Steuerung der 
Aktoren, von der hier keine Rede ist.

Es bringt gar nichts, mit 250 kB/S irgendetwas durch die Gegend "zu 
brüllen" und auf schnelle Reaktion zu vertrauen, wenn ich das auch mit 
Vorausschau rechtzeitig und in Ruhe machen kann.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>Habe mittlerweile die Baudrate auf 125kBaud halbiert. Damit dauert ein
>Byte 80µs. Ändert leider nichts am Problem. Auch mit Window bis 30
>Timertakte. So langsam wirds echt knifflig woran das liegen könnte.

Geh mal testweise auf eine SEHR niedrige Baudrate, meinetwegen 10kBit/s. 
Wenn es dann immer noch klemmt, ist es weniger ein Timing- denn ein 
logisches Problem.

>Falk, nur mal so gefragt, kam dir die Idee mit dem Jitter gestern
>spontan

Nein.

> oder hast du das schon mal woanders ans laufen bekommen?

Das nicht, aber ähnliche Sachen.

>Im CompA ISR sehe ich da keine Probleme, TCNT1 ist ja in dem Zustand
>immer kleiner OCR1A.

Ja.

>Beim OCR1B bin ich mir da im Moment nicht mehr so sicher,

Dort auch, denn OCR1B ist ja immer OCR1A-TIMING_WINDOW, und das sind nur 
10-30 Takte.

> weil der wird
>nicht in seiner eigenen ISR neu gesetzt. Obwohl es in der Theorie passen
>sollte.

Tut es auch. Es ist der gleichen Zähler TCNT1.

[Falk B. (falk)]

@ Dieter F. (jim_quakenbush)

>> Deine cholerischen Anfälle ebenso. Nimm die Pillen und sei glücklich.
>> Wir sind es dann auch.

>Ich bin selten seiner Meinung - aber heute:

>Nix cholerisch - eher begründet.

Der Ton macht die Musik!

>Es bringt gar nichts, mit 250 kB/S irgendetwas durch die Gegend "zu
>brüllen" und auf schnelle Reaktion zu vertrauen, wenn ich das auch mit
>Vorausschau rechtzeitig und in Ruhe machen kann.

Ist prinzipiell richtig, die 250kBaud sin im Moment eher ein Stresstest 
der Software und sportlicher Ehrgeiz. Bei 250kBaud (DMX512) kann so ein 
AVR noch GANZ andere Dinge "sychnron" erledigen ;-)

[Dieter F. (Gast)]

Falk B. schrieb:
> Ist prinzipiell richtig, die 250kBaud sin im Moment eher ein Stresstest
> der Software und sportlicher Ehrgeiz. Bei 250kBaud (DMX512) kann so ein
> AVR noch GANZ andere Dinge "sychnron" erledigen ;-)

Ja, nur hier nicht erforderlich - offensichtlich. Mir sind die "wahren" 
Anforderungen und der Gesamt-Zusammenhang nach wie vor nicht bekannt.

[Veit D. (devil-elec)]

Dieter F. schrieb:
>Problem ist nicht die Schnelligkeit der
> Servo-Bewegung - mehr der Auswertung der Sensoren und Steuerung der
> Aktoren, von der hier keine Rede ist.
>
> Es bringt gar nichts, mit 250 kB/S irgendetwas durch die Gegend "zu
> brüllen" und auf schnelle Reaktion zu vertrauen, wenn ich das auch mit
> Vorausschau rechtzeitig und in Ruhe machen kann.

Okay, ich gehe mal darauf ein. Mir ist das durchaus bewusst. Nur die 
Steuerung der Aktoren und Sensorabfragen lasse ich bewusst in dem Thread 
außen vor. Außer die Servopulserzeugung im Moment. Weil das sonst den 
Thread unnötig verkompliziert. Das hat auch nichts mit dem aktuellen 
Problem zu tun. Völlig andere Baustelle.
Ich habe für Aktoren und Sensoren 2 konkrete Vorstellungen wie ich das 
machen werde. Welche Methode zum Zuge kommt hängt davon ab wie schnell 
die Kommunikation am Ende sein wird und wieviel Slave-Controller am Ende 
benötigt werden. Entweder bin ich schnell genug der Reihe nach alles 
abzufragen. Oder ich frage nur gezielt die Slaves und die Werte ab ich 
ich gerade benötige. Wahrscheinlich kommt letzte Methode zum Einsatz. 
Höchstwahrscheinlich, das zeichnete sich schon länger ab.
Würde aber die Programmierung auf dem Master verkomplizieren. Weil ich 
nicht klar getrennt erst alles abfragen, dann alles verarbeiten und am 
Ende Steuerbefehle ausgeben kann. Muss dann alles vermischt werden.

Dennoch möchte die Kommunikation so schnell wie möglich haben. Mehrere 
Abfragen addieren sich auch zu Verzögerungen. Noch eine andere Idee 
schwirrt mir rum. Ich könnte noch gewisse Slaves für sich arbeiten 
lassen. Wo zum Aktor die zugehörigen Sensoren an den gleichen Slave 
passen. Nur wäre das dann außerhalb der Kontrolle vom Master. Wäre nicht 
Sinn der Sache.

So genug abgeschweift.


@ Falk:   :-)

erstmal Danke das du mit am Ball bleibst.

Während ich hier tippe läuft es mit Baudrate 10kBit und Window 10 
fehlerfrei. Unter 7 kommen wieder sporadisch Fehler. Über 20min sind 
locker vorbei. Kann als stabil angenommen werden.

Ich denke das Window darf nicht zu kurz sein, sonst ist es zu dicht am 
CompA dran, dessen Aufruf. Zu lang und hoher Baudrate stört es die 
Kommunikation.

Man müßte also die Zeit ab CompB ISR Aufruf bis CompA ISR beendet ist 
betrachten. Das muss zeitlich mit der Baudrate passen damit kein Byte 
verloren geht.

[c-hater (Gast)]

Falk B. schrieb:

>>Beim OCR1B bin ich mir da im Moment nicht mehr so sicher,
>
> Dort auch, denn OCR1B ist ja immer OCR1A-TIMING_WINDOW, und das sind nur
> 10-30 Takte.

Mein Gott, noch deutlicher konntest du deine krasse Inkompetenz 
bezüglich Interrupts wirklich nicht mehr dokumentieren...

Ja ,die "sheduled time" mag immer in diesem Bereich liegen. Aber was 
sagt das über die tatsächliche Ausführungszeit der ISR? Darüber solltest 
du mal ernsthaft nachdenken...

[Dieter F. (Gast)]

Veit D. schrieb:
> Weil das sonst den Thread unnötig verkompliziert.

Nö - vereinfachen würde - wenn allen bekannt.

Veit D. schrieb:
> Dennoch möchte die Kommunikation so schnell wie möglich haben.

Was Du möchtest und was ggf. sinnvoll ist wäre noch zu verifizieren.

Womit ich wieder zur Eingangsfrage komme:

Dieter F. schrieb:
> Schön - was willst Du denn genau? So beschrieben, dass alle es verstehen
> :-)

[Carl D. (jcw2)]

Veit D. schrieb:
> Hallo,
>
> Leute, wir lassen das mit der Weiche außen vor, gehört hier nicht rein.
> Danke.
>
> So.
> Habe mittlerweile die Baudrate auf 125kBaud halbiert. Damit dauert ein
> Byte 80µs. Ändert leider nichts am Problem. Auch mit Window bis 30
> Timertakte. So langsam wirds echt knifflig woran das liegen könnte.


Der Jitter entsteht doch, weil die Uart-ISR manchmal läuft, wenn 
eigentlich der Timer wichtiger wäre. Das liegt daran, daß AVR8 (in 
Verbindung mit den Default-Werten des ISR-Macros) keine laufende ISR 
unterbrechen. Man kann aber die Uart-ISR so schreiben, daß sie die 
Interrupt sofort wieder freigibt. Dazu gibt es eine spezielle Version 
des ISR-Macros. Die Timer-ISR kann dann schon nach 2..3μs reagieren und 
die Uart hat ja 40..80μs Zeit, falls der Timer dazwischen kommt, was ja 
inzwischen eher selten passieren sollte. Eine "Disable-Uart-Int"-ISR 
bräuchte man dann gar nicht mehr.

Nur mal so zur Gedankenanregung ...

PS:

ISR(xyz_vect, ISR_NOBLOCK) {}

[c-hater (Gast)]

Falk B. schrieb:

> Der Ton macht die Musik!

Harhar. Der erste, der sich in diesem Thread ernsthaft im Ton vergriffen 
hat, warst ja wohl mehr als eindeutig du.

Dank der erstaunlicherweise doch eher etwas laschen Löschtätigkeit der 
Zensoren bei Regulars (a little bit of sarkasm is unavoidable here) 
kann das diesmal wirklich jeder im Detail nachvollziehen...

Ich geh' jetzt pennen. Aber ich werde den Thread morgen ganz sicher noch 
einmal besuchen. Bin gespannt, wie sich das weiter entwickelt. Vor allem 
eigentlich, ob der Veit sich doch noch entscheidet, uns endlich sein 
grausames Gesamtwerk zu präsentieren.

Weil: ich bin ziemlich sicher, dass ich jetzt schon ziemlich genau 
weiss, was da  falsch ist. Und es wird mir wie immer ein innerlicher 
Vorbeimarsch sein, das haarklein aufzudröseln und dabei wieder die 
übliche und natürliche Schlussfolgerung zu ziehen...

[Dieter F. (Gast)]

c-hater schrieb:
> und dabei wieder die
> übliche und natürliche Schlussfolgerung zu ziehen...

Na ja, da sind nicht alle unbedingt Deiner Meinung - wetten dass?
Guten Rutsch :-)

[H.Joachim S. (crazyhorse)]

Welche Servos hast du denn nun überhaupt? Digital, spielarmes Getriebe 
und Encoder? Oder eher die analoge Billigvariante mit einfachen 
Labberzahnrädern, Plastiklagern und Poti?

Ich tippe auf zweiteres :-)

Unabhängig davon, dass man das Problem lösen sollte (könnte für andere 
Sachen interessant sein) - fahr doch mal ohne serielle Kommunikation 
immer abwechselnd je 1s 1500µs/1505µs. Reagiert es darauf?

[Veit D. (devil-elec)]

Hallo,

nachdem Gesamtcode hat glaube ich noch niemand gefragt. Zumindestens die 
die wirklich an der Problemlösung interessiert sind. Falls ich das 
übersehen haben sollte möge man mir verzeihen. Ging ja bisher ganz schön 
zu Faden. Also, wenn ihr unbedingt sehen wollt, bitte, aktueller Stand. 
Die Formatierung hat beim kopieren leider wieder etwas gelitten.

Vorher noch 3 Screenshots vom Datalogger. Dabei sieht man im Fehlerfall 
das CompB nach CompA ausgelöst wurde und damit mitten im Empfang diesen 
abschaltet. Kanal "Sender" ist das was der ATtiny empfängt. Erkennt man 
auch in der zeitlichen Abfolge denke ich.

Timer 1 läuft im CTC Mode.

@ c Liebhaber:
wenn du wirklich helfen möchtest, dann rede bitte nicht um den heißen 
Brei, rede sachlichen Klartext wo du den Fehler vermutest.

/* 
 *  Projekt -> meinProjekt Properties -> Konfiguration > alle Konfigurationen
 *  Projekt -> meinProjekt Properties -> C/C++ Compiler > Symbols > Defined symbols:
 *  eintragen:   F_CPU=8000000UL
 *
 *  Projekt -> meinProjekt Properties -> C++ Compiler > Miscellaneous:
 *  eintragen:   -std=c++11    (wegen constexpr)
 *
 */ 

#include <avr/io.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <avr/interrupt.h>
#include <util/crc16.h>
#include <util/atomic.h>    // für cli() und sei() mit SREG Sicherung
#include "pinDefi.h"    // eigene I/O Definitionen
#include "usart.h"      // rechts > 2. > hinzufügen > vorhandenes Element
#include "timer.h"      // alles was mit Timern zu tun hat ausgelagert

#define NOP __asm__ __volatile__ ("nop")

#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))   // setzt das angegebene Bit auf 1
#endif
#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))  // setzt (löscht) das angegebene Bit auf 0
#endif


// UART Berechnungen des Wertes für das Baudratenregister aus Taktrate und gewünschter Baudrate
#define UART_BAUD_RATE  125000UL    // gewünschte Baudrate
#define UBRR_VAL ((F_CPU+UART_BAUD_RATE*8)/(UART_BAUD_RATE*16)-1)  // sauber runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))              // reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/UART_BAUD_RATE)        // Fehler in Promille, 1000 = kein Fehler.
#if ((BAUD_ERROR<995) || (BAUD_ERROR>1005))
  #error Systematischer Fehler der Baudrate groesser 0,5% und damit zu hoch! 
#endif


// Definitionen und Initialisierungen

uint32_t last_MasterRequestTime;

uint8_t org_OSCCAL;
bool done_cal_OSC = false;      // Merker ob 8MHz Oszillator syncronisiert wurde
typedef enum {STOP, RUN, CALC, REPEAT, FINISH, WAITSYNC, SYNC, UART, FREE, READ, BUSY, ERROR} Zustand;    // Steuerzustände
volatile Zustand state_UART_MODE = WAITSYNC;

uint32_t uart_Timeout;
extern volatile uint16_t UART0_RxBuf[UART_RX_BUFFER_SIZE];
extern volatile uint16_t UART0_TxBuf[UART_TX_BUFFER_SIZE];
uint16_t countCalibration;
uint32_t countErrorsUART0;    // uart0 Fehlerzähler

const uint8_t STX = '\xCC';    // Startkennzeichen der Nachricht
const uint8_t ETX = '\xEE';    // Endkennzeichen der Nachricht
const uint8_t ESC = '\xDD';    // 
const uint8_t MasterAddr = 0;  // #0 Adresse vom Master
const uint8_t myAddr = 3;    // #3 meine Slave Adresse

// definiere Nachricht
union Nachricht
{
  struct
  {
    uint8_t toAddr;
    uint8_t fromAddr;
    uint8_t cmd;
    int32_t data;
    uint16_t crc;
  };
  uint8_t asArray[9];      // Summe aller struct Datentypen, für Zugriff über Index
} empfDaten, sendDaten;      // zwei gleiche union Buffer anlegen


uint32_t global_ms;

// *** Funktion Deklarationen *** //
// *** USART *** //
void Txd0Rxd0_normalPortPins();
void uart0_disable();
bool read_Ringbuffer_0();
void delete_uart0_Transmit_Complete_Flag();
void uart0_flush();
void MAX487_Empfangsmodus ();
void MAX487_Sendemodus ();
void sendStruct(uint8_t *structPtr, uint8_t length);
void handle_Serial_0_to_Serial_0();
void handle_Function_UART0_Pins();
void send_Nachricht();
uint16_t calc_CRC16 (uint8_t feld[], uint8_t length);
// *** allgemeine *** //
void set_PCINT2();
void del_PCINT2();
void Calibration_RunMode();
void Calibration_Calculation();


int main(void)
{          
  Pin_TxD0_OUT;  // TxD0 Ausgang
  Pin_RxD0_IN;  // RxD0 Eingang
  Pin_RxD0_PULL;  // RxD0 Pullup aktiv
  
  MAX487_TXRX_OUT;  // PA0 Ausgang, MAX487 /RE_DE 
  MAX487_empfangen;  // MAX487 /RE_DE - umschalten auf empfangen
  
  Servo1_OUT;  // Pin auf Ausgang konfigurieren
  Servo2_OUT;
  Servo3_OUT;
  Servo4_OUT;
  Servo5_OUT;
  Servo6_OUT;
  Servo7_OUT;
  Servo8_OUT;
    
  uart0_disable();
  Txd0Rxd0_normalPortPins();
  set_Timer0();        // millis, seconds
  preSet_Timer1();
  preSet_Timer2();      // Timer zum einmessen/kalibrieren
         
  sendDaten.toAddr = MasterAddr;   
  sendDaten.fromAddr = myAddr;
  sendDaten.data = 123;
  org_OSCCAL = OSCCAL0;    // Debug
  
    while (1)  // Hauptprogramm
    {             
    handle_Function_UART0_Pins();
    
    global_ms = millis();
  }
}


/* *** Funktionen *** */

void handle_Function_UART0_Pins()      // im UART Modus max. 29µs
{   
  if (state_UART_MODE == UART) {                // UART0 wird benutzt
    handle_Serial_0_to_Serial_0();
  }
  
  if (state_UART_MODE == FINISH) {              // schaltet UART0 Funktion ein
    del_PCINT2();
    run_Timer0();
    run_Timer1();
    memset((void *)UART0_TxBuf, '\0', sizeof(UART0_TxBuf));  // Messbuffer löschen
    memset((void *)UART0_RxBuf, '\0', sizeof(UART0_RxBuf));  //
    uart0_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );
    state_UART_MODE = UART;
  }
  
  if (state_UART_MODE == SYNC) {                // schaltet UART0 Funktion ab
    uart0_disable();
    Txd0Rxd0_normalPortPins();
    state_UART_MODE = WAITSYNC;
  }
    
  if (state_UART_MODE == REPEAT) {              // Kalibrierung wiederholen
    set_PCINT2();
    countCalibration++;
    state_UART_MODE = WAITSYNC;
  }
  
  if (state_UART_MODE == WAITSYNC) {              // OSCCAL Calibration ready, dauert 85µs
    memset((void *)UART0_TxBuf, '\0', sizeof(UART0_TxBuf));  // Messbuffer löschen
    memset((void *)UART0_RxBuf, '\0', sizeof(UART0_RxBuf)); //
    Calibration_RunMode();
  }

  if (state_UART_MODE == CALC) {                // OSCCAL neu berechnen
    Calibration_Calculation();
  }
  
  if (state_UART_MODE == ERROR) {                // UART neu initialisieren, dauert 7µs
    countErrorsUART0++;
    uart0_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );
    state_UART_MODE = UART;
  }
}


void set_PCINT2()
{
  GIMSK = (1<<PCIE0);         // PCINT 7:0 Gruppe Trigger aktiv
  PCMSK0 = (1<<PCINT2);    // PCINT2, Pin Einzelauswahl
}


void del_PCINT2()
{
  GIMSK = 0;      // PCINT 7:0 Gruppe deaktivieren
  PCMSK0 = 0;    // PCINT2 deaktivieren
}


void Calibration_RunMode ()  
{
  stop_Timer0();
  stop_Timer1();
  set_PCINT2();
  run_Timer2();            // Timer 2 starten mit Prescaler 1
  state_UART_MODE = RUN;
}


void Calibration_Calculation ()      // dauert komplett max. 357µs
{
  const uint16_t Target = 128;    // gültig für Baudrate 62500 und 8MHz
  const uint16_t min = Target-8;    // falsche Messwerte filtern
  const uint16_t max = Target+8;
  uint16_t summe = 0;
  uint16_t diff = 0;
  uint16_t count_fail = 0;
  uint16_t Ticks = 0;
    
  // TCNT2 auswerten ... 59 Differenzen bilden
    ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {        // dauert 270µs
      for (uint8_t i=0; i<29; i++) {          // 0...28           
        diff = (UART0_RxBuf[i+1] - UART0_RxBuf[i]);  // 29 Differenzen
        if (min < diff && diff < max) {        // filtert falsche Werte
          summe = summe + diff;
        }
        else {
          count_fail++;        // Anzahl ungültiger Messwerte zählen
        }
      }

      diff = (UART0_TxBuf[0] - UART0_RxBuf[29]);    // 30. Differenz
      if (min < diff && diff < max) {          // filtert falsche Werte
        summe = summe + diff;
      }
      else {
        count_fail++;          // Anzahl ungültiger Messwerte zählen
      }

      for (uint8_t i=0; i<29; i++) {          // 0...28
        diff = (UART0_TxBuf[i+1] - UART0_TxBuf[i]);  // weitere 29 Differenzen
        if (min < diff && diff < max) {        // filtert falsche Werte
          summe = summe + diff;
        }
        else {
          count_fail++;        // Anzahl ungültiger Messwerte zählen
        }
      }
    }
  
    Ticks = (summe*1.0/(59-count_fail))+0.5;  // Durchschnitt berechnen und runden    
            
    if (Ticks > Target) {
      OSCCAL0--;
      state_UART_MODE = REPEAT;
    }
    
    if (Ticks < Target) {
      OSCCAL0++;
      state_UART_MODE = REPEAT;
      
    }
      
    if (Ticks == Target) {      // Ticks auf Ziel ?
      stop_Timer2();        
      state_UART_MODE = FINISH;  // Kalibrierung beenden
      done_cal_OSC = true;        // Merker Oszillator syncronisiert
    }
    
    if (count_fail > 9) {      // zu viele ungültige Messwerte
      state_UART_MODE = REPEAT;
      done_cal_OSC = false;       // Merker Oszillator nicht syncronisiert
    }    
}


ISR(PCINT0_vect)  // Interrupt Handler für PCINTs
{           // dauert ohne "if (index>59)" 3,46µs und mit 5,08µs
  uint16_t data = TCNT2;
  static uint8_t index = 0;    // index = cycle
  
  if ( index < 30 ) {        // 0...29
    UART0_RxBuf[index] = data;  // speichert TNCT2 im Rx Buffer
  }
  else {
    UART0_TxBuf[index-30] = data;  // 30...59 im Tx Buffer
  }

  index++;
  
  if (index > 59) {        // nach 60 Pegelwechsel Auswertung
    del_PCINT2();        // ISR temporär sperren
    state_UART_MODE = CALC;
    index = 0;
  }
}


void Txd0Rxd0_normalPortPins()
{
  Pin_TxD0_OUT;    // TxD0 Ausgang
  Pin_RxD0_IN;    // RxD0 Eingang
  Pin_RxD0_PULL;    // RxD0 Pullup aktiv
}


void uart0_disable()
{
  UBRR0H = 0;
  UBRR0L = 0;
  UCSR0B = 0;
  UCSR0C = 0;
}


bool read_Ringbuffer_0()
{   
  //  mit Fehlerbehandlung und nichts tun, no data, wird die Funktion nach  0,5 µs verlassen 
  // ohne Fehlerbehandlung und nichts tun, wird die Funktion nach 10,46 µs verlassen 
  
  static uint8_t index = 0;
  static bool state_Read = false;
  static bool state_Complete = false;
  static bool state_Bypass = false;
  uint8_t length = sizeof(Nachricht);
  
  uint16_t c = uart0_getc();        // nächstes Zeichen vom Ringbuffer holen
  
  // UART Lib Fehlercodes  (dezimal)
  //      4096        2048          1024         512                   256
  // UART_FRAME_ERROR, UART_OVERRUN_ERROR, UART_PARITY_ERROR, UART_BUFFER_OVERFLOW, UART_NO_DATA
  
  if ( c & UART_NO_DATA) {  
    return false;            // Abbruch nach 500ns, es gibt nichts zum lesen
  }
  
  if ( c > UART_NO_DATA) {        // irgendein UART Error
    state_UART_MODE = ERROR;      // Status ändern zur weiteren Fehlerbehandlung
    index = 0;
    state_Read = false;
    state_Complete = false;
    state_Bypass = false;
    return false;            // es gibt nichts zum lesen
  }
  
  // ------------------------------------------------------------------
  c &= 0xFF;                // High Byte nullen vor Weiterverarbeitung
    
  if (state_Bypass == false) {            // Byte speziell auswerten
    if (c == ESC) {            // ESC Kennung ?
      state_Bypass = true;
      return false;
    }
    else if (c == ETX) {        // ENDE Kennung ?
      state_Read = false;
      state_Complete = true;
    }
    else if (c == STX) {        // START Kennung ?
      index = 0;
      state_Read = true;
      state_Complete = false;
      return false;
    }
  }  

  if (state_Read == true && (index < length)) {  // Bytes einsortieren
    empfDaten.asArray[index++] = (uint8_t)c;
    state_Bypass = false;
  }
  
  if (state_Complete == true && index >= length ) {    // Übertragungsende
    state_Complete = false;
    index = 0;
    if ( calc_CRC16(empfDaten.asArray, length) == 0) {  // Checksumme korrekt ?
      if (empfDaten.toAddr == myAddr) {        // bin ich gemeint?
        return true;
      }
    }
  }    
  return false;        // noch nicht fertig oder irgendwas ging schief
  
}


void handle_Serial_0_to_Serial_0 ()      
{  
  if( read_Ringbuffer_0() == true)  {
    sendDaten.cmd = empfDaten.cmd;
    
    switch (empfDaten.cmd) {
      case   1:  sendDaten.data = TCNT1;            break;
      case   2:  sendDaten.data = OCR1A;            break;
      case   3:  sendDaten.data = OCR1B;            break;
      case   4:  sendDaten.data = countErrorsUART0;      break;  
      default:  sendDaten.data = last_MasterRequestTime;  break;
    }
    
    send_Nachricht();
    last_MasterRequestTime = seconds();      // Zeitstempel letzter Kommunikation merken
    
  }
  
}


void delete_uart0_Transmit_Complete_Flag ()
{
  UCSR0A |= (1<<TXC0);        // "UART Transmit Complete Flag" zurücksetzen mit "1" 
}


void uart0_flush ()
{
  while( !(UCSR0A & (1<<TXC0)) );    // warten bis Flag "TXC0 UART Transmit Complete" set
}


void MAX487_Empfangsmodus ()
{    
  uart0_flush();
  MAX487_empfangen;          // MAX487 /RE_DE - umschalten auf empfangen
}
  

void MAX487_Sendemodus ()
{
  MAX487_senden;            // MAX487 /RE_DE - umschalten auf senden
  delete_uart0_Transmit_Complete_Flag();
}


void send_Nachricht ()
{   
  uint8_t data = 0;
  sendDaten.crc = calc_CRC16(sendDaten.asArray, (sizeof(Nachricht)-sizeof(sendDaten.crc)) ) ;  
  MAX487_Sendemodus();
  uart0_putc(STX);
  for (uint8_t i=0; i < sizeof(Nachricht); i++) {
    data = sendDaten.asArray[i];
    if (data == ESC || data == ETX || data == STX) {
      uart0_putc(ESC);
    }
    uart0_putc(data);        // Bytes rausschieben
  }
  uart0_putc(ETX);
  MAX487_Empfangsmodus();
}


uint16_t calc_CRC16 (uint8_t feld[], uint8_t length)
{
  uint16_t crc = 0xFFFF;        // initial CRC value
  uint8_t b = 0;
  
  while (length--) {
    crc = _crc16_update(crc, feld[b++]);
  }
  return crc;
}


ISR(TIMER1_COMPA_vect)    // wird aller >1ms aufgerufen (Prescaler 8)
{
  Servo8_ON;  // zum messen mit Oszi/Datalogger Zweck entfremdet
  
  static uint8_t servo = 0;
  const uint8_t SERVO_CNT = 3;        // Anzahl Servos
  const uint8_t TIMING_WINDOW = 10;    // 6µs / 125ns / Prescaler 8 = 6,25 Timertakte
  uint16_t temp = 0;
    
  switch(servo) {    // ISR Zeit 4,75µs
    case 0: Servo5_OFF;  Servo6_ON;  temp =  4999; break;
    case 1: Servo6_OFF;  Servo7_ON;  temp =  4999; break;
    case 2: Servo7_OFF;        temp =  4999; break;  // virtuelle
    case 3:             Servo5_ON;  temp =  4999; break;
  }
    
  servo++;
    
  if (servo > SERVO_CNT)  servo = 0;
    
  OCR1A = temp;
  OCR1B = temp-TIMING_WINDOW;
  UCSR0B |= (1<<RXCIE0);    // enable USART0 RX Complete Interrupt
  
  // Count   999 =  1ms
  // Count  1999 =  2ms
  // Count 19999 = 20ms
  
  Servo8_OFF;
}


ISR(TIMER1_COMPB_vect)      // dauert 1,13µs
{  
  Servo1_ON;  // zum messen mit Oszi/Datalogger Zweck entfremdet
  UCSR0B &= ~(1<<RXCIE0);    // disable USART0 RX Complete Interrupt
  Servo1_OFF;
}

[Joachim B. (jar)]

als Anhang wäre es echt besser als so lang

als Anhang gibt es auch die Codeansicht und würde mein Mausrad nicht 
beleidigen ;)

[Veit D. (devil-elec)]

Hallo,

bitte schön. Habe noch in die Bilder einen Pfeil zur Markierung 
eingezeichnet. Bild c zeigt eins ohne Fehler, CompB vor CompA.

[Veit D. (devil-elec)]

Hallo,

wobei ich soeben auch einmal entdecke das CompB vor CompA ordnungsgemäß 
auslöst und dennoch kann er nicht antworten. Ominös.

[Falk B. (falk)]

@ Carl Drexler (jcw2)

>unterbrechen. Man kann aber die Uart-ISR so schreiben, daß sie die
>Interrupt sofort wieder freigibt. Dazu gibt es eine spezielle Version
>des ISR-Macros. Die Timer-ISR kann dann schon nach 2..3μs reagieren und

Ist totzdem Mist, denn auch das ist mehr Jitter, als technisch nötig. 
Die Variante mit COMPB funktioniert. Der Fehler des OP ist im Moment 
noch unklar.

>Nur mal so zur Gedankenanregung ...

Lahm!

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>nachdem Gesamtcode hat glaube ich noch niemand gefragt.

Doch ich.

>zu Faden. Also, wenn ihr unbedingt sehen wollt, bitte, aktueller Stand.
>Die Formatierung hat beim kopieren leider wieder etwas gelitten.

Geht's noch? Lange Quelltexte gehören in den Anhang! Siehe 
Netiquette!


"Wichtige Regeln - erst lesen, dann posten!

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

>Vorher noch 3 Screenshots vom Datalogger. Dabei sieht man im Fehlerfall
>das CompB nach CompA ausgelöst wurde und damit mitten im Empfang diesen
>abschaltet.

Damit kommen wir dem Problem näher.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>wobei ich soeben auch einmal entdecke das CompB vor CompA ordnungsgemäß
>auslöst

Na was denn nun?

Das kann man einfach testen. Schalten direcht nach dem ABSCHALTEN des 
UART RXC ein Testpin AUF LOW und ebenso in der anderen ISR nach dem 
EINSCHALTEN von RXC ISR das PIN auf HIGH! Damit ieht man am OSZI DIREKT, 
wann wie lange die ISR gesperrt ist!

> und dennoch kann er nicht antworten. Ominös.

Ich tippe mal, daß deine MAX487 Ansteuerung Unsinn macht, ich sehe da 
komische Dinge.

[Falk B. (falk)]

Das Programm ist ohne die anderen Dateien nich zu vestehen! Wo werden 
denn die Interrupts freigeschaltet? Arrrgghhhh. Immer diese 
Salamitaktik! Ein Schaltplan wäre auch nicht schlecht, denn du bist 
nicht der Erste, der bei RS485 Fehler macht.

[Veit D. (devil-elec)]

Hallo,

sorry.

Die RS485 Geschichte kann ich ausschließen. Sonst hätte ich bis heute 
Kommunikationsprobleme anderer Art, unabhängig von diesem neuen Problem, 
denke ich.

Im Datalogger Screenshot sieht man die längere Receive Int Abschaltung. 
Sollte Deckungsgleich sein mit einem vorherigen wo CompB nach CompA 
auslöst.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>Die RS485 Geschichte kann ich ausschließen. Sonst hätte ich bis heute
>Kommunikationsprobleme anderer Art, unabhängig von diesem neuen Problem,
>denke ich.

VORSICHT! Gerade bei Interrupts wäre ich mir da ganz und gar nicht 
sicher! Erst recht nicht beim TXC, denn der kann tricky sein!

>Im Datalogger Screenshot sieht man die längere Receive Int Abschaltung.
>Sollte Deckungsgleich sein mit einem vorherigen wo CompB nach CompA
>auslöst.

Schon mal ein aussagekräftiges Fehlerbild.

[Veit D. (devil-elec)]

Hallo,

dann bin gespannt was die komplette Offenlegung für Erkenntnisse bringt.

Tschau
Veit

[Falk B. (falk)]

Hmm, es fehlt ein richtiger Pull Up an IC2/Pin1/RO. Die LED + 
Vorwiderstand kann das NICHT sauber auf VCC ziehen bzw. halten. Damit 
kannst du dir sporadische Fehlpulse an deinem UART Receiver einfangen.

Auf dem Logic Analayzer Bild sieht man, daß der Fehler mit der UART-RXC 
Sperrung während des Sendens von Daten auftritt. Das ist zwar immer noch 
schlecht, sollte dort aber keine Rolle spielen. Allerdings ist das ja 
nur eine Momentaufnahme.

Die vielen if() in handle_Function_UART0_Pins() sind Unsinn, das macht 
man mit switch(). Das ist übersichtlicher.

Und man kann es auch mit der Strukturierung übertreiben, wenn man für 
eine Zeile Code eine Funktion erfindet 8-0, wie z.B.

void delete_uart0_Transmit_Complete_Flag ()
{
  UCSR0A |= (1<<TXC0);        // "UART Transmit Complete Flag" 
zurücksetzen mit "1"
}

Dein PCINT ISR kann dir auch in die Suppe spucken, vor allem da er höher 
als die Timer priorisiert ist. Was macht der eigentlich genau? Und vor 
allem, warum greifst du dort DIREKT auf den Speicher des UART-FIFOs zu? 
Das ist keine gute Idee! Mal screibest du die Daten in den RX-Buffer, 
mal TX-Buffer? Soll das ein Virus sein?

ISR(PCINT0_vect)  // Interrupt Handler für PCINTs
{           // dauert ohne "if (index>59)" 3,46µs und mit 5,08µs
  uint16_t data = TCNT2;
  static uint8_t index = 0;    // index = cycle

  if ( index < 30 ) {        // 0...29
    UART0_RxBuf[index] = data;  // speichert TNCT2 im Rx Buffer
  }
  else {
    UART0_TxBuf[index-30] = data;  // 30...59 im Tx Buffer
  }

  index++;

  if (index > 59) {        // nach 60 Pegelwechsel Auswertung
    del_PCINT2();        // ISR temporär sperren
    state_UART_MODE = CALC;
    index = 0;
  }
}

Das als ein paar Anmerkungen, wenn gleich ich keine heiße Spur habe.

[absolute (Gast)]

Falk B. schrieb:
> Die vielen if() in handle_Function_UART0_Pins() sind Unsinn, das macht
> man mit switch(). Das ist übersichtlicher.

Das sind ja eigentlich else if oder eben switch. ;)

Hoffentlich macht der Compiler daraus eine jump table.

[Veit D. (devil-elec)]

Hallo,

ich dachte du schaust dir das erstmal in Ruhe an. Ganz in Ruhe. Denn ich 
finde das voreilige Gemecker erstmal unpassend, wenn man noch nicht weiß 
was der Code macht. Ich kann erklären was welche Funktion macht.

Wegen fehlenden Pull-Up an IC2/Pin1/RO. An IC1 Pin 11-13 sind alle 20k 
Pullups dran. Genau wegen dem LED Effekt.

Den Code kann man noch aufräumen, ja, aber auch die vielen if in 
handle_Function_UART0_Pins() haben ihren Sinn bzw. Ursprung in der 
Enstehung. Mit if kann der Code in der Anordnung während der 
Kalibrierung gleich zur nächsten Funktion springen an statt aus einem 
möglichen switch-case komplett raus und wieder rein.

Was macht der Code überhaupt. Zu beginn wird OSCCAL kalibriert. Die 
TX/RX Pins sind Eingänge. Nach erfolgreicher Kalibrierung bleiben sie im 
USART Mode.

Der Ringbuffer wird wegen dem kleinen RAM des ATtiny doppelt verwendet 
und kommt sich nicht in die Quere. Für die Kalibrierwerte nutze ich 
diesen, dafür musste ich den allerdings 16Bit breit machen statt nur 
8Bit. Die Timer Counterwerte landen im Ringbuffer und werden am Ende 
ausgewertet. Am Ende wird der Ringbuffer vorsorglich gelöscht und steht 
ab da der UASRT zur Verfügung. Ganz normal wie von Peter Fleury 
vorgesehen.

Da ich mit 60 Kalibrierwerten handiere nutze ich beide, TX und RX 
Ringbuffer, die jeweils 32 Bytes groß sind. 32x uint16_t. Ich schreibe 
30 TCNT2 Werte in den RX Buffer und die anderen 30 Werte in den TX 
Buffer. Den Trick finde ich ziemlich cool. Eigene Erfindung.

Danach bewegt sich die handle_Function_UART0_Pins() Funktion nur noch im 
UART Modus. Hier wäre dann switch case von Vorteil. Ja. Oder ich setzte 
ein return ein. Deswegen kann der PCINT ISR auch nicht dazwischen 
funken, weil der abgeschalten wurde. Die TX/RX Pins sind ja im USART 
Modus.

Wegen den Einzeiler Funktionen. Auch hier kennst du die Entstehung 
nicht. Meine gesamte Sendefunktion sah vor vielen Monaten noch ganz 
anders aus. Da sieht das jetzt damit schon sehr sauber aus. Optimierung 
geht natürlich immer. Habe nur lieber sprechende Funktionsnamen wie eine 
Zeile kryptischen Code. Da geht jeder anders ran. Ich mach das 
schließlich als Hobby.

Lasst uns jetzt nicht über irgendwelchen Syntax streiten bzw. 
diskutieren. Das können wir am Ende machen. Echte Fehler ausgenommen.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>Wegen fehlenden Pull-Up an IC2/Pin1/RO. An IC1 Pin 11-13 sind alle 20k
>Pullups dran. Genau wegen dem LED Effekt.

Ok, die hab ich übersehen. Beim nächsten Mal den Schaltplan besser als 
PDF erstellen, da kann man besser zoomen und navigieren.

>Was macht der Code überhaupt. Zu beginn wird OSCCAL kalibriert. Die
>TX/RX Pins sind Eingänge. Nach erfolgreicher Kalibrierung bleiben sie im
>USART Mode.

OK.

>Danach bewegt sich die handle_Function_UART0_Pins() Funktion nur noch im
>UART Modus. Hier wäre dann switch case von Vorteil. Ja. Oder ich setzte
>ein return ein. Deswegen kann der PCINT ISR auch nicht dazwischen
>funken, weil der abgeschalten wurde. Die TX/RX Pins sind ja im USART
>Modus.

Gut.

>Lasst uns jetzt nicht über irgendwelchen Syntax streiten bzw.
>diskutieren. Das können wir am Ende machen. Echte Fehler ausgenommen.

Stimmt, es waren ja auch nur Anmerkungen.

Eine aber eher wichtige Sache ist hier, daß du state_UART_MODE auch in 
anderen Funktionen schreibst. Das ist maximal irreführend. Ein 
Lesezugiff ist OK, aber SCHREIBEN sollte das nur die eine Statemachine 
in dieser Funktion. Sonst wird man irre.

Außerdem sollte man die Sache mit der Kalibrierung und den normalen 
UART-Nutzung trennen, das verschafft viel und wichtige Übersicht. Jaja, 
ich weiß, historisch gewachsen.

Und wenn am Anfang kalibriert wird, sollte man auch die Interrupts zur 
Servosignalerzeugung ausschalten, denn die können da auch irgendwie 
reinspucken. Reine Vorsichtsmaßnahme.

Das hier ist aber ein heißer Kandidat

void uart0_flush ()
{
  while( !(UCSR0A & (1<<TXC0)) );    // warten bis Flag "TXC0 UART 
Transmit Complete" set
}

Das geht im Allgemeinen so NICHT! Denn du kannst nicht sicher sein, daß 
vorher immer alle Daten LÜCKENLOS in den USART geschoben wurden und 
ZWISCHENDURCH der Sende-FIFO im UART nie leer gelaufen ist und damit TXC 
IMMER nur am ENDE auf 1 geht! Damit bin ich schon mal RICHTIG aufs Maul 
gefallen und hab fast ne Woche gesucht!

Beitrag "Re: Problem mit Micro-SD-Karte"

Wie kriegt man es WIRKLICH wasserdicht?

Etwa so.

void uart0_flush ()
{
  uint8_t cnt;

  // warte auf leeren Software-FIFO, der UDRIE ausschaltet
  while ((UCSR0B & (1<<UART0_UDRIE)) );

  UCSR0A |= (1<<TXC0);   // TXC0 löschen

  // warte auf leeren Hardware-FIFO, welcher TXC setzt
  // Timeout nach cnt/2 Zeichen
  cnt=6;
  while (cnt > 0 ) {  
    if ( !(UCSR0A & (1<<TXC0)) ) {
      _delay_us(20);  // 1/2 Zeichen @250kBaud
      cnt--;
    }
  }
}

Damit sollte unter ALLEN komischen Umständen immer gewartet werden, bis 
deine Daten raus sind, ggf. ein paar Zeichen mehr, wenn vorher sie FIFOs 
schon leer waren.

Noch eine Idee. Wie du gemessen hast, scheint das Senden die COMPA , 
COMPB Interrupts durcheinanderzuwürfeln. Du arbeiteste im 
Halbduplexbetrieb, also immer nur Senden ODER Empfangen. Da kann das nur 
passieren, wenn der UDRE Interrupt sich ungünstig vor COMPB drängelt und 
länger als TIMING_WINDOW dauert. Eigentlich ist die ISR eher kurz und 
sollte kaum mehr als 10us dauern. Praktisch kommt es aber mitten beim 
Senden zu dem COMPA, COMPB Fehler!

OK, Trick! Tausche den Inhalt von COMPA und COMPB bzw. benenne einfach 
die ISRs um, mit Anpassung der Zuweisung von OCR1A/B! Denn dann wird, 
wenn durch diesen noch unklaren Fehler COMPA und COMPB gleichzeitig 
während eines anderen Interrupts aktiv werden, ZUERST COMPA ausgeführt, 
welcher  die RXC-ISR sperrt und sofort danach COMPB, welcher sie wieder 
freigibt! Damit kann sich die Sache nicht mehr temporär verklemmen! 
Sperren hat Priorität vor Freigeben, was aber bedeutet, das Freigeben 
immer als 2. ausgeführt wird, was "langfristig" für die nächsten 1-2ms 
deutlich besser ist.

ISR(TIMER1_COMPB_vect)    // wird aller >1ms aufgerufen (Prescaler 8)
{
  Servo8_ON;  // zum messen mit Oszi/Datalogger Zweck entfremdet
  
  static uint8_t servo = 0;
  const uint8_t SERVO_CNT = 3;        // Anzahl Servos
  const uint8_t TIMING_WINDOW = 10;    // 6µs / 125ns / Prescaler 8 = 6,25 Timertakte
  uint16_t temp = 0;
    
  switch(servo) {    // ISR Zeit 4,75µs
    case 0: Servo5_OFF;  Servo6_ON;  temp =  4999; break;
    case 1: Servo6_OFF;  Servo7_ON;  temp =  4999; break;
    case 2: Servo7_OFF;        temp =  4999; break;  // virtuelle
    case 3:             Servo5_ON;  temp =  4999; break;
  }
    
  servo++;
    
  if (servo > SERVO_CNT)  servo = 0;
    
  OCR1B = temp;
  OCR1A = temp-TIMING_WINDOW;
  UCSR0B |= (1<<RXCIE0);    // enable USART0 RX Complete Interrupt
  
  // Count   999 =  1ms
  // Count  1999 =  2ms
  // Count 19999 = 20ms
  
  Servo8_OFF;
}


ISR(TIMER1_COMPA_vect)      // dauert 1,13µs
{  
  Servo1_ON;  // zum messen mit Oszi/Datalogger Zweck entfremdet
  UCSR0B &= ~(1<<RXCIE0);    // disable USART0 RX Complete Interrupt
  Servo1_OFF;
}

[Veit D. (devil-elec)]

Hallo,

upps das sind ja viele neue Infos.   :-)

enum "state_UART_MODE":
reden wir am Ende nochmal drüber ...

Trennung, Kalibrierung <> USART Mode:
der µC ist voll belegt, ich dachte es ist eine geniale Idee gleich die 2 
Pins zu nutzen die eh mit dem Master-Controller verbunden sind. Die 
RS485 Leitung. Das zur näheren Info.

Die Änderungen probiere ich. Muss jedoch über den Jahreswechsel 
arbeiten.

Falls morgen was dazwischen kommt, wir "sehen" uns spätestens nächstes 
Jahr, wünsche bis dahin dir und allen anderen Beteiligten und 
Neugierigen einen guten feucht fröhlichen Rutsch.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>Trennung, Kalibrierung <> USART Mode:
>der µC ist voll belegt, ich dachte es ist eine geniale Idee gleich die 2
>Pins zu nutzen die eh mit dem Master-Controller verbunden sind. Die
>RS485 Leitung. Das zur näheren Info.

Mit Trennung meinte ich die Software, nicht die Hardware.

[Joachim B. (jar)]

@ Veit Devil

meine Hochachtung das du dich nicht beirren lässt, einige Kommentare 
waren ja demotivierend, der Thread gefällt mir immer noch ich hoffe ich 
kann irgendwann Nutzen daraus ziehen.

Allen wünsche ich einen guten Rutsch ins neue Ja(h)r

[Carl D. (jcw2)]

Hi Veit, wenn du eh Multiplexer für "selten benutzte Pin-Funktionen" auf 
deinem Board hast, warum nicht noch einen 74c4051er, der die per HW-OC 
erzeugten, mit 125ns Auflösung erzeugten Servo-Pulse an den richtigen 
Kanal weiterleitet. Dazu braucht es 3+1 Pin (3-Bit Auswahl/1-Bit OC1A/B) 
für 8 Servos. Oder wenn man OC1A/B gleichzeitig nutzt 2+2 mit einen 
4052er.
Wie gesagt HW erzeugt den Puls (das wichtige Timing) und ISR hat 
(gefühlt ewig) Zeit den Multiplexer weiter zu schalten.
BTW, damit ist Falks Vorderungen nach bestmöglicher Realisierung 
erfüllt. Wenn ich auch lieber ausprobieren würde, ob mindestens für 
fehlerfreie Funktion erforderliche Realisierung nicht doch reicht.
Der Tiny841 kann übrigens die OC-Ausgänge auf die verschiedenen Pins 
mappen, d.h. für die bis zu 2 Servos an Timer1 braucht es noch nicht mal 
eine HW-Änderung.

Edit:
Timer0/2 können das auch, sind aber wegen ihrer Kürze nicht so leicht 
bedienbar wie Timer1, der sowohl hohe Auflösung, als auch selber die zig 
ms Zykluszeit selber kann.
125ns Takt 2^16 -> 2^12μs max Zykluszeit

[Veit D. (devil-elec)]

Hallo

@ Carl:
ich habe auf dem Platinenmaß 10x10cm keinen Platz mehr. Die 
vermeintlichen Lücken sind alle durch Leiterbahnen "gefüllt".

Damit ihr eine Vorstellung bekommt wie mein Testaufbau z.Z. aussieht, 
zeige ich mal 2 Bilder.

So, habe etwas Zeit und habe weiter geforscht. Habe meine verfügbaren 8 
Messkanäle neu verkabelt sonst verliere ich den Überblick. Habe das 
genutzt um mehr Funktionen zum vermessen anzuzapfen.  :-)

Weiterhin alles mit 125kBaud. Timer läuft im Normalmode, weil CompA und 
CompB vertauscht habe

Vermutung Fehler in Sendefunktion:
Kann ich selbst immer noch nicht vermuten, weil der µC nicht einmal 
versucht zu senden, ich sehe bis jetzt keine verstümmelten Bytes auf der 
Leitung oder dergleichen, er sendet im Fehlerfall überhaupt nichts 
zurück, die Sendefunktion wird nicht ausgelöst und der MAX487 wird auch 
nicht in den Sendemodus geschalten. Irgendwie muss der Fehler beim 
einlesen zu suchen sein. So meine Vermutung.

Bild: B
Was ich jedoch sehe ist, dass die "handle_Serial_0_to_Serial_0()", die 
immer durchlaufen wird, im Fehlerfall scheinbar nichts  zu tun hatte. 
Die Pegelwechsel sind fast durchgehend gleichmäßig. Im Gegensatz dazu 
wenn alles läuft sind die Pegelwechsel unregelmäßiger. Das kann kein 
Zufall sein.

Jetzt dachte ich, lässt den Master etwas später senden, hilft auch 
nicht. Würde auch dem Datalogger widersprechen, weil der ATtiny nachdem 
er mit antworten fertig ist sofort auf Empfang schaltet, während der 
Zeit muss der Master die Daten erstmal verarbeiten und seinerseits 
umschalten zum neuen senden seinerseits. Zu schnelles erneutes senden 
schließe ich demzufolge aus.

Bild: C
Der letzte Sendemodus vom ATtiny ist auch okay, schaltet erst wieder um 
wenn alles raus ist. Wenn hier was faul wäre, könnte der Master nicht 
sofort neu senden. Dann schlägt sein Antwort-Timeout von 9ms zu bevor 
der Master neue sendet. Die gibts im Datalogger nicht zu sehen.

Bild: D
ohne aktiven Compare_A läuft alles wie am Schnürchen, ich kann 
Minutenlang auf die TimeOut LED vom Master schauen, dessen Terminal und 
im Datalogger, alles astrein. Es ist verhext. Obwohl der Compare_A 
Interrupt ja auch im Fehlerfall vorher nur kurz aktiv ist wie immer. Der 
ist auch nicht unbedingt aktiv wenn der ATtiny gerade empfängt. Er 
sollte damit nichts zu tun und hat dennoch irgendwas damit zu tun.

Bild: E
Was macht der Compare_A? Er schaltet den uart Empfang ab.
Wird das RXCIE0 Bit danach wirklich wieder eingeschaltet?
Code geändert um dieses eine Bit zu überprüfen ob wirklich immer gesetzt 
und gelöscht wird.
Ergebnis, verhält sich genau wie Compare_A.

Lasse ich Compare_A aktiv, kommentiere jedoch das enable/disable des 
RXCIE0 Bits jeweils aus, funktioniert auch alles wie am Schnürchen. 
Bedeutet, der Timer Interrupt hat keinen negativen Einfluss. Aber dieses 
RXCIE0 Bit hat irgendeinen negativen Effekt. Als wenn die uart nicht 
wirklich danach Empfangs bereit ist.

Vielleicht darf man den Empfang nicht einfach so knallhart weg und 
wieder zuschalten?

Habe zudem paar Einzeilerfunktion rausgenommen.
Kompletter Code ist "Code_A-D"
Letzt Code Änderung im Timer 1 Interrupt ist "Code_E"

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>Leitung oder dergleichen, er sendet im Fehlerfall überhaupt nichts
>zurück, die Sendefunktion wird nicht ausgelöst und der MAX487 wird auch
>nicht in den Sendemodus geschalten. Irgendwie muss der Fehler beim
>einlesen zu suchen sein. So meine Vermutung.

Klingt logisch.

>ist auch nicht unbedingt aktiv wenn der ATtiny gerade empfängt. Er
>sollte damit nichts zu tun und hat dennoch irgendwas damit zu tun.

Yep.

>Lasse ich Compare_A aktiv, kommentiere jedoch das enable/disable des
>RXCIE0 Bits jeweils aus, funktioniert auch alles wie am Schnürchen.
>Bedeutet, der Timer Interrupt hat keinen negativen Einfluss. Aber dieses
>RXCIE0 Bit hat irgendeinen negativen Effekt. Als wenn die uart nicht
>wirklich danach Empfangs bereit ist.

Scheint so.

[Veit D. (devil-elec)]

Hallo,

habe den Faden weiter gesponnen und die uart Receive ISR mitloggen 
lassen. Wann und ob diese immer aktiv wird wenn ein Byte reinkam. Siehe 
da, trotz schon lange wieder aktivierten RXCIE0 Bit wird die uart 
Receive ISR nicht aktiv. Die komplette Übertragung rauscht teilnahmslos 
vorbei, erst danach werden 3 Bytes eingelesen. Was auch immer das ist.
Jetzt bin ich wirklich ratlos was hier schief läuft. Ich weiß auch nicht 
mehr was ich sinnvoll noch testen kann.


diese ISR meine ich von der uart Lib.

ISR (UART0_RECEIVE_INTERRUPT)    
/*************************************************************************
Function: UART Receive Complete interrupt
Purpose:  called when the UART has received a character
**************************************************************************/
{     
  Led6_ON;
    unsigned char tmphead;
    unsigned char data;
    unsigned char usr;
    unsigned char lastRxError;
 
    /* read UART status register and UART data register */
    usr  = UART0_STATUS;
    data = UART0_DATA;
    
    /* get FEn (Frame Error) DORn (Data OverRun) UPEn (USART Parity Error) bits */
  #if defined(FE) && defined(DOR) && defined(UPE)
    lastRxError = usr & (_BV(FE)|_BV(DOR)|_BV(UPE) );
  #elif defined(FE0) && defined(DOR0) && defined(UPE0)
    lastRxError = usr & (_BV(FE0)|_BV(DOR0)|_BV(UPE0) );
  #elif defined(FE1) && defined(DOR1) && defined(UPE1)
    lastRxError = usr & (_BV(FE1)|_BV(DOR1)|_BV(UPE1) );
  #elif defined(FE) && defined(DOR)
    lastRxError = usr & (_BV(FE)|_BV(DOR) );
  #endif

    /* calculate buffer index */ 
    tmphead = ( UART0_RxHead + 1) & UART_RX_BUFFER_MASK;
    
    if ( tmphead == UART0_RxTail ) {
        /* error: receive buffer overflow */
        lastRxError = UART_BUFFER_OVERFLOW >> 8;
    } else {
        /* store new index */
        UART0_RxHead = tmphead;
        /* store received data in buffer */
        UART0_RxBuf[tmphead] = data;
    }
    UART0_LastRxError |= lastRxError;   
  Led6_OFF;
}

[Falk B. (falk)]

>Vielleicht darf man den Empfang nicht einfach so knallhart weg und
>wieder zuschalten?

Doch, darf man. Zum der UART an sich gar nicht angefaßt wird, es wird 
nur der RXC Interrupt kuzzeitig deaktiviert.

Auf dem Bild Logger_E sieht man ja, daß der kurze Abschaltpuls für den 
RXC NACH dem Empfang der Daten passiert! Da kann der Empfang doch gar 
nicht gestört werden. In deinem LED5 Testsignal gibt es dann auch eine 
kurze LOW-Phase. Dort muss man weiter suchen. Mögicherweise ein CRC 
Error in den Empfangsdaten?

[Carl D. (jcw2)]

Veit D. schrieb:
> Hallo
>
> @ Carl:
> ich habe auf dem Platinenmaß 10x10cm keinen Platz mehr. Die
> vermeintlichen Lücken sind alle durch Leiterbahnen "gefüllt".

100cm^2 und die paar Bauteile -> kein Platz??
Dann lass den ISP-Multiplexer weg und verpass dem Ding einen Bootloader.

[Veit D. (devil-elec)]

Hallo Carl,

von Bootloader Programmierung habe ich keine Ahnung. Bin schon stolz das 
ich die Steuerung soweit programmieren konnte. Zudem ich an der Lösung 
des Problems interessiert bin. Das möchte ich erstmal verstanden wissen. 
Wenn verstanden und klar ist es gibt dafür keine Lösung, kann man immer 
noch einen Weg drumherum bauen. Jetzt aber noch nicht. Ich renne nicht 
vor einem Problem weg. Dann tappe ich ins Nächste weil das vorherige 
noch nicht verstanden wurde. Zudem ich vermute das mit dem 
Servo-Multiplexer das Jitterproblem ebenso existiert. Der Takt wäre zwar 
astrein, aber die Puls-Schaltzeitpunkte hängen wieder vom Code ab. Die 
Slaves sind als Universal-Controller gedacht. Hängt nur von der Programm 
ab wofür die dann da sind und was die machen sollen.

@ Falk und Interessierte:

Das hat sich vorhin zeitlich überschnitten. 15:16 Uhr.
Habe CRC zum loggen mit aufgenommen. Ganz unten Led 3.
Kein CRC Fehler. Eigentlich kann da auch keiner sein, wenn die Receive 
ISR keine Bytes in den Ringbuffer schiebt.

Ich wette wir stehen mit der Nase davor, aber noch zu viele Bäume. :-)

Meine Frage lautet aktuell, warum ist die uart receive ISR lahm gelegt?

bool read_Ringbuffer_0()
{   
  //  mit Fehlerbehandlung und nichts tun, no data, wird die Funktion nach 0,5 µs verlassen 
  // ohne Fehlerbehandlung und nichts tun, wird die Funktion nach 10,46 µs verlassen 
  
  static uint8_t index = 0;
  static bool state_Read = false;
  static bool state_Complete = false;
  static bool state_Bypass = false;
  uint8_t length = sizeof(Nachricht);
  
  uint16_t c = uart0_getc();        // nächstes Zeichen vom Ringbuffer holen
  
  // UART Lib Fehlercodes  (dezimal)
  //      4096        2048          1024         512                   256
  // UART_FRAME_ERROR, UART_OVERRUN_ERROR, UART_PARITY_ERROR, UART_BUFFER_OVERFLOW, UART_NO_DATA
  
  if ( c & UART_NO_DATA) {  
    return false;            // Abbruch nach 500ns, es gibt nichts zum lesen
  }
  
  if ( c > UART_NO_DATA) {        // irgendein UART Error
    state_UART_MODE = ERROR;      // Status ändern zur weiteren Fehlerbehandlung
    index = 0;
    state_Read = false;
    state_Complete = false;
    state_Bypass = false;
    return false;            // es gibt nichts zum lesen
  }
  
  // ------------------------------------------------------------------
  c &= 0xFF;                // High Byte nullen vor Weiterverarbeitung
    
  if (state_Bypass == false) {            // Byte speziell auswerten
    if (c == ESC) {            // ESC Kennung ?
      state_Bypass = true;
      return false;
    }
    else if (c == ETX) {        // ENDE Kennung ?
      state_Read = false;
      state_Complete = true;
    }
    else if (c == STX) {        // START Kennung ?
      index = 0;
      state_Read = true;
      state_Complete = false;
      return false;
    }
  }  

  if (state_Read == true && (index < length)) {  // Bytes einsortieren
    empfDaten.asArray[index++] = (uint8_t)c;
    state_Bypass = false;
  }
  
  if (state_Complete == true && index >= length ) {    // Übertragungsende
    state_Complete = false;
    index = 0;
    if ( calc_CRC16(empfDaten.asArray, length) == 0) {  // Checksumme korrekt ?
      if (empfDaten.toAddr == myAddr) {        // bin ich gemeint?
        return true;
      }
    }
    else {
      Led3_ON;
      NOP; NOP; NOP; NOP; NOP; NOP; NOP; NOP;   // 1µs
      Led3_OFF;
    }
  }    
  return false;        // noch nicht fertig oder irgendwas ging schief
  
}

[Sebastian S. (amateur)]

Gibt es eigentlich die gute, alte Sprungtabelle nicht mehr?
Eine Abfrage ob erlaubt (<  >)
und dann einfach Indexhüpfen...

[Veit D. (devil-elec)]

Hallo Sebastian,

wie meinst du das?
Worauf beziehst du dich?

[Sebastian S. (amateur)]

@Veit Devil
Du legst eine Tabelle mit den Anfängen der Routinen an und machst dann 
einen Indexsprung, abhängig vom Wert.
Geht seit ewigen Zeiten in C.

[Arno (Gast)]

Kann man machen. Sollte die Optimierung des avr-gcc aber schon seit 
Jahren selbst aus einem switch-case-Block machen, wenn es sich lohnt. 
Und ändert nicht grundlegend etwas an deinen Problemen, vermute ich :)

Sieht ungefähr so aus (Pseudocode, vermutlich passen Klammern und 
Pointer nicht ganz zusammen):

void f(void)
{
}

void g(void)
{
}

void h(void)
{
}

void main(void)
{
  void * sprungtabelle[] = {&f, &g, &h};
  int i;
  if ( i >= 0 && i < 3 )
  {
    *(sprungtabelle[i])();
  }
}

MfG, Arno

[Veit D. (devil-elec)]

Hallo,

ich meinte, für welches Problem soll das die Lösung sein, dass verstehe 
ich nicht. Soll das ein verkapptes Basic goto sein? Ich verstehe immer 
noch nicht wo ich hinspringen soll? Deine Ausführungen sind zu kurz. Ich 
meine das Programm macht doch jetzt schon nichts anderes. Ob ich nun 
Funktionen aufrufe oder in diese anderweitig springe sollte Jacke wie 
Hose sein, wenn ich dich richtig verstehe.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>ich meinte, für welches Problem soll das die Lösung sein, dass verstehe
>ich nicht.

Für gar keines.

>Soll das ein verkapptes Basic goto sein?

Ein Gosub.

> Ich verstehe immer noch nicht wo ich hinspringen soll?

Er will switch() neu erfinden.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>noch einen Weg drumherum bauen. Jetzt aber noch nicht. Ich renne nicht
>vor einem Problem weg. Dann tappe ich ins Nächste weil das vorherige
>noch nicht verstanden wurde.

Gute Einstellung.

> Zudem ich vermute das mit dem
>Servo-Multiplexer das Jitterproblem ebenso existiert. Der Takt wäre zwar
>astrein, aber die Puls-Schaltzeitpunkte hängen wieder vom Code ab.

Eben!

>Ich wette wir stehen mit der Nase davor, aber noch zu viele Bäume. :-)

>Meine Frage lautet aktuell, warum ist die uart receive ISR lahm gelegt?

Ich hab sie nicht lahm gelegt ;-)

>  static bool state_Read = false;
>  static bool state_Complete = false;
>  static bool state_Bypass = false;

Das ist schon mal Mist. Drei Variablen zur Zustandsdefinition. Da kann 
man sich ggf. schön ins Knie schießen. Aber da es ja sonst auch geht, 
liegt das Problem dennoch woanders.

[Veit D. (devil-elec)]

Hallo,

ich merke schon, ich kann hier und da den Code wirklich noch einfacher 
gestalten. Ich denke manchmal zu kompliziert, daran bin ich wirklich 
gut.  :-)  Die 3 states brauche ich um das ESC Zeichen aus dem 
Datenstrom zu filtern. Jetzt wo du es ansprichts, kann man es auch hier 
mit enum und switch case machen.

Wenn ich die uart receive ISR und du auch nicht lahm legst, wer dann? 
:-)
Macht bestimmt unser C Liebhaber aus der Ferne.   :-)

Nochmal zurück auf Anfang.

UART, nur nochmal zum Verständnis das ich mich nicht verrenne.

---------------------------------------------------------------------

Dieses Flag wird generiert, wenn neue Bytes im uart Empfangsbuffer 
liegen. Dieses Bit löst den "ISR (UART0_RECEIVE_INTERRUPT)" aus wenn 
"1". Welche ich mit der Led 6 mitgeloggt habe.

UCSR0A: Bit7, RXC0 ... USART Receive Complete Flag

This flag is set when there is unread data in the receive buffer, and
cleared when the receive buffer is empty (i.e., does not contain any unread data).
If the receiver is disabled, the receive buffer will be flushed and consequently
the RXCn flag will become zero. The flag can be used to generate
a Receive Complete interrupt (see RXCIEn bit).

Mit diesem Bit steuern wir ob obiges Flag, ob es überhaupt generiert 
wird oder nicht. Bytes können dennoch in den uart Buffer landen, werden 
nur nicht abgeholt.

UCSR0B: Bit7, RXCIE0 ... RX Complete Interrupt Enable

Writing this bit to one enables interrupt on the RXCn flag.
A USART Receive Complete interrupt will be generated only if the RXCIEn bit,
the Global Interrupt Flag, and the RXCn bits are set.

Dieses Bit schaltet generell den Receiver ein und die Pin TX/RX in den 
UART Modus überhaupt. Das erfolgt einmalig bei uart Initialisierung.

UCSR0B: Bit4, RXEN0 ... Receiver Enable

Writing this bit to one enables the USART Receiver. When enabled, the receiver
will override normal port operation for the RxDn pin. Writing this bit to zero
disables the receiver. Disabling the receiver will flush the receive buffer,
invalidating FEn, DORn, and UPEn Flags.

-------------------------------------------------------------------


Ich denke wir machen für dieses Jahr erstmal Schluss, ihr habt bestimmt 
auch besseres zu tun wie hier zu lesen, für dich/euch hier am Ball zu 
bleiben strengt sicherlich auch an.

Ich versuche erstmal den Code laut deinen Hinweisen besser zugestalten. 
Das hilft allen.  :-)

Ich wünsche auf jeden Fall allen einen guten Rutsch. Denkt dran. Nur mit 
Helm, Handschuhen und feuerfesten Overall nach außen treten.  :-)

Tschau bis nächstes Jahr
Veit

[Carl D. (jcw2)]

Vermutlich bin ich einfach nicht schlau genug zu verstehen, warum 
Hardware-PWM jittern soll, abgesehen vom Jitter der Taktquelle.
aber sei's drum: viel Spass noch beim basteln.

[H.Joachim S. (crazyhorse)]

Nene, das tun sie schon, weil die Servopins nicht direkt von der 
Hardware angesprochen werden (mangels ausreichender Anzahl 
OCR-Register/direkt daran gekoppelter Pins). Es erfordert also Software 
in Form der ISR. Und der Eintritt kann verzögert sein, wenn gerade eine 
andere ISR (hier die UART) läuft.

[Carl D. (jcw2)]

H.Joachim S. schrieb:
> Nene, das tun sie schon, weil die Servopins nicht direkt von der
> Hardware angesprochen werden (mangels ausreichender Anzahl
> OCR-Register/direkt daran gekoppelter Pins). Es erfordert also Software
> in Form der ISR. Und der Eintritt kann verzögert sein, wenn gerade eine
> andere ISR (hier die UART) läuft.

Und was glaubst du sollte die Aufgabe des Multiplexers in meinem 
Vorschlag sein? HW macht einen Puls und feuert dann Compare, worin man 
jede Menge Zeit hat, OCR mit dem Wert für den nâchsten Puls zu laden und 
den Multiplexer auf den nächsten Ausgang weiter zu drehen. Aber wie 
schon gesagt, ich hab ja das Problem nicht und werd dazu auch nichts 
mehr schreiben.

[Carl D. (jcw2)]

Veit D. schrieb:
> Ich denke manchmal zu kompliziert, daran bin ich wirklich gut.  :-)

!!!

[Veit D. (devil-elec)]

Hallo,

Carl:
jetzt spiel mal nicht den Beleidigten, hast gar keinen Grund dazu. Nur 
verstehe ich immer noch nicht wie der Multiplexer den Takt genau für die 
Servopulse erzeugen soll? Ich weiß auch noch nicht recht wie du das 
verschalten wissen möchtest? Mach am besten einen Schaltplan, dann 
verstehe ich/wir das besser. Sonst reden wir aneinander vorbei.

Vielleicht haste auch nicht alles lesen können. Kann ja sein. Der Thread 
ist schon lang. Im Falle das ein Slave 8 Servos steuern soll, müssen 8 
unterschiedliche Pulse erzeugt werden. Wo sollen die OC Ausgänge 
herkommen? Kein Timer hat 8 Compare Toggle Pins. Vielleicht liegt hier 
das Missverständnis verborgen.

Wenn du immer noch von deiner Idee überzeugt bist, dann erkläre es bitte 
deutlicher, sodass ich es verstehe. Danke.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>verstehe ich immer noch nicht wie der Multiplexer den Takt genau für die
>Servopulse erzeugen soll?

Nicht direkt. Man erzeugt EIN Servosignal rein per Hardware Timer1 und 
einem PWM-Ausgang und schaltet den nach und nach auf mehrere Ausgänge 
mit einem Demultiplexer. Das Umschalten macht die Software im Interrupt, 
ist aber egal, weil es in den LOW Pausen passiert, da ist Jitter egal.

>unterschiedliche Pulse erzeugt werden. Wo sollen die OC Ausgänge
>herkommen?

Ein OC-Ausgang, zeitlich verteilt auf 8 Ausgänge per Demultiplexer.

Kann man machen, ist gut, kostet halt ein wenig Hardware. Die aktuelle 
Softwarevariente funktioniert auch, das aktuelle Problem hat damit nicht 
direkt was zu tun.

[c-hater (Gast)]

Carl D. schrieb:

> Vermutlich bin ich einfach nicht schlau genug zu verstehen, warum
> Hardware-PWM jittern soll, abgesehen vom Jitter der Taktquelle.

Hardware-PWM jittert bei konstaktem Takt natürlich nicht, solange man 
die Register nicht anfasst, die sie kontrollieren...

Tut man das aber, was für die meisten sinnvollen Awendungen der 
Normalfall ist, dann kann ein ungeeigneter Zeitpunkt für 
Registeränderungen die Sache aber natürlich mit erheblichem "Jitter" 
belasten.

Das Problem dabei ist: Es hängt vom Modus und vom zu ändernden Register 
ab, was passieren kann und damit auch, wo man die Änderungen am Besten 
schreibt. Praktisch immer ist der beste Moment dafür unmittelbar nach 
der Auslösung eines Timer-IRQs (natürlich: nicht immer desselben, auch 
wieder PWM-Modus-abhängig).

Blöd bloß: unmittelbar nach Auslösung eines IRQ kann man erstmal 
garnix setzen, man kann das leider frühestens nach Ablauf der statischen 
Interruptlatenz in der ISR tun. In der Praxis kann man es allerdings im 
worst case erst nach Verstreichen von statischer und variabler Latenz 
tun.

Und genau letzteres ist das Problem. Die variable Latenz ist nur 
berechenbar, wenn man das Timing deterministisch kontrolliert, also in 
Assembler programmiert. In Hochsprachen geht das nicht, weil halt kein 
Code mit deterministischem Zeitverhalten erzeugt wird (davon, dass er 
häufig auch sehr suboptimal ist, mal ganz zu schweigen).

D.h.: man muß entweder beten, dass es reicht oder den Code analysieren, 
den der Compiler produziert. Und zwar immer wieder neu und immer wieder 
von allen Codeteilen, die die variable Latenz beeinflussen, also 
insbesondere den von allen ISRs...

[Dieter F. (Gast)]

c-hater schrieb:
> Die variable Latenz ist nur
> berechenbar, wenn man das Timing deterministisch kontrolliert, also in
> Assembler programmiert.

Ich denke, man kann sich auch mit passender Hardware beschäftigen. MCs, 
die mit "double buffering" arbeiten z.B. :-) - oder?

[Carl D. (jcw2)]

Dieter F. schrieb:
> c-hater schrieb:
>> Die variable Latenz ist nur
>> berechenbar, wenn man das Timing deterministisch kontrolliert, also in
>> Assembler programmiert.
>
> Ich denke, man kann sich auch mit passender Hardware beschäftigen. MCs,
> die mit "double buffering" arbeiten z.B. :-) - oder?

Der ist meist damit beschäftigt seine bekannt guten Manieren zur Schau 
zu stellen und offenbar seltener mit Lesen/Nachdenken/Verstehen. Ist ja 
auch nicht so, daß Atmel die Timer nicht nur extra wegen genau dem 
Problem so gebaut hat. Nein, sie schreiben das sogarn noch für (fast) 
alle verständlich in die Doku.

[Veit D. (devil-elec)]

Hallo,

erstmal gesundes Neues an alle.  :-)
(auch wenn das in diesem Forum nicht so üblich ist)


Wenn ich ganz ehrlich bin, weiß ich immer noch wie die Pulse mit dem 
Multiplexer erzeugt werden soll, wenn nur der Takt an den nächsten 
Ausgang geschoben wird.

Zum Hauptproblem uart Receive ISR lahm gelegt.
Ich bin immer noch ratlos und weiß nicht was ich wie gezielt sinnvoll 
noch testen soll.

[H.Joachim S. (crazyhorse)]

Veit D. schrieb:
> Wenn ich ganz ehrlich bin, weiß ich immer noch wie die Pulse mit dem
> Multiplexer erzeugt werden soll, wenn nur der Takt an den nächsten
> Ausgang geschoben wird.

Es gibt diverse Möglichkeiten, dass spezielle I/O-Pins direkt vom OCR 
gesteuert werden können und damit unabhängig von einer ISR werden. So 
kann man ein H durch ein Schiebregister takten, dessen Taktsignal direkt 
von der Hardware des timers kommt. Zum nachladen des nächsten Wertes und 
Steuerung des Dateneingangs hat man dann alle Zeit der Welt, spielt 
keine Rolle.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>Wenn ich ganz ehrlich bin, weiß ich immer noch wie die Pulse mit dem

Da fehlt ein nicht, nicht?

>Multiplexer erzeugt werden soll, wenn nur der Takt an den nächsten
>Ausgang geschoben wird.

Ganz einfach. Ein 1:N DEMultiplexer gibt EIN (echtes) PWM Signal 
zeitlich versetzt auf mehrere seiner Ausgänge. Im Prinzpt so wie du das 
jetzt in Software machtst, nur daß eben der Demux ein extra Chip ist die 
die Pulserzeugung rein in Hardware erfolgt, die Umschaltung auf den 
nächsten Kanal in der unkrtitischen LOW-Phase in Software.

>Zum Hauptproblem uart Receive ISR lahm gelegt.
>Ich bin immer noch ratlos und weiß nicht was ich wie gezielt sinnvoll
>noch testen soll.

Tja, ich wohl leider auch. Das ist schon sehr mysteriös. Die 
Hauptausrede in solchen Situationen ist ein Compilerfehler ;-)

[Carl D. (jcw2)]

Veit D. schrieb:
> Hallo,
>
> erstmal gesundes Neues an alle.  :-)
> (auch wenn das in diesem Forum nicht so üblich ist)
>
>
> Wenn ich ganz ehrlich bin, weiß ich immer noch wie die Pulse mit dem
> Multiplexer erzeugt werden soll, wenn nur der Takt an den nächsten
> Ausgang geschoben wird.
Das ganze kann mit bis zu 2Kanälen ganz ohne HW-Änderungen getestet 
werden:
Servos brauchen alle 20ms einen 1,5..2,5ms langen Pulse. 2 davon kann 
man mit Timer1 erzeugen.
- Der läuft mit 16MHz Div8 2^16 -> 32ms Zyklus.
- OCR1A/B werden mit den Werten für 1,5..2,5ms geladen 2^16 * (pw/32) 
;pw pulse weite in ms
- Comp1A/B ISR (am Ende eines Pulses) setzt den nächsten Wert, der im 
PWM-Mode beim Overflow in die echten CompareRegister geladen wird. (Hier 
könnte man dann auch den externen 1:8-Multiplexer auf das nächste Servo 
umschalten)

> Zum Hauptproblem uart Receive ISR lahm gelegt.
> Ich bin immer noch ratlos und weiß nicht was ich wie gezielt sinnvoll
> noch testen soll.

[Veit D. (devil-elec)]

Hallo,

entweder bin ich zu blöd das zu raffen oder ich habe derzeit nicht den 
Kopf dafür frei. Sorry.

Ich hätte lieber noch paar Ideen zum Receive ISR Problem gehört. Was ich 
noch testen könnte, egal wie die Ideen aussehen. Also warum uart Receive 
tot ist obwohl enabled wurde.

[Veit D. (devil-elec)]

Hallo,

zeitliche Überschneidung, so langsam dämmert es wie das mit dem 
DeMultiplexer abläuft.

Receive ISR:

@Falk
ja ist schon mysteriös.
Ich Danke dir dennoch wie verrückt für deinen Einsatz. Hab viel gelernt.


Hat unser C Liebhaber eine Idee?
Jetzt würde seine große Stunde schlagen.   :-)


Edit:
Oder kommt die uart Lib mit ihren Ringbuffer durcheinander wenn das 
gerade ungünstig abgeschalten wurde? Oder der Hardware uart Reveice 
Buffer erstmal geleert werden muss, bevor wieder sauber empfangen werden 
kann?

Edit:
wenn ich mittendrin den uart buffer leere, kann er nie mehr das 
Protokoll lesen, weil dann Byte mittendrin verloren gehen, klappt auch 
nicht so richtig

[Falk B. (falk)]

Wenn wir die Esotherik mal beiseite lassen, stellen wir ganz sachlich 
fest. Es kommt ab und an dazu, daß der UART-RXC Interrupt ab und an NACH 
dem Senden einer Messeage deaktiviert wird und erst mit dem nächsten 
COMPA/COMPB Interrupt eingeschaltet wird. Dort werden dann die 3 
Datenbytes aus dem Hardware-FIFO gelesen und ins Software-FIFO 
geschrieben, was anatürlich nicht für eine vollständige Messeage 
ausreicht und der Timeout zuschlägt.

Es scheint so, als ob es irgendwo mal einen falschen Zugriff auf USCR0B 
gibt und dadurch das RXCIE0 Bit gelöscht würde. Soweit ich es sehe, 
gibit es aber nur einen Zugriff auf das Register, in uart0_putc(), dort 
wird aber nur UDRIE gesetzt.

Als Pflaster könnte man RXCIE0 am Ende von send_Nachricht () noch einmal 
explizit einschalten. Wenn das wirkt, hat man den Fehler weiter 
eingegrenzt. Dann muss irgendwo ein versteckter Zugriff auf RXCIE0 sein.

Es könnte auch sein, daß durch Nebeneffekte in der Funktion 
handle_Function_UART0_Pins() doch irgendwann mal ein paar andere Zweige 
aufgerufen werden und z.B. ein uart0_init() oder uart0_disable() 
ausgeführt wird. Man könnte ja mal die anderen Teile der Funktion 
auskommentieren und die Kalibierung am Anfang weglassen.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>Hat unser C Liebhaber eine Idee?
>Jetzt würde seine große Stunde schlagen.   :-)

In der Tat . . .

>Oder kommt die uart Lib mit ihren Ringbuffer durcheinander wenn das
>gerade ungünstig abgeschalten wurde?

Sollte nicht sein, zumal die Funktionen keinen Zugriff auf die 
UART-Steuerregister machen, von putc() mal abgesehen.

> Oder der Hardware uart Reveice
>Buffer erstmal geleert werden muss, bevor wieder sauber empfangen werden
>kann?

Nein.

[Veit D. (devil-elec)]

Hallo,

der Workaround mit dem zusätzlichen Receive enabled in der 
send_Nachricht() funktioniert tatsächlich. Jetzt muss ich mir den Code 
anschauen, als wenn ich das nicht schon oft genug gemacht hätte ...  :-)
Hast den richtigen Riecher.

Die handle Serial 0 baue ich gerade auf switch case um

[Falk B. (falk)]

@Veit Devil (devil-elec)

>Hast den richtigen Riecher.

Und das trotz massiver Erkältung!
SCHNIEEEEF ;-)

[Veit D. (devil-elec)]

Hallo,

mehr Nebenluft schadet also nicht wie man feststellt ...   :-)
Wünsche gute Besserung.

[Falk B. (falk)]

Hmmmm, ich hab was.

In read_Ringbuffer_0() gibt es

if ( c > UART_NO_DATA) {        // irgendein UART Error
    state_UART_MODE = ERROR;      // Status ändern zur weiteren 
Fehlerbehandlung
    index = 0;
    state_Read = false;
    state_Complete = false;
    state_Bypass = false;
    return false;            // es gibt nichts zum lesen
  }


Wenn jetzt dieser Fall eintritt, dann gibt es in 
handle_Function_UART0_Pins() das hier

  if (state_UART_MODE == ERROR) {                // UART neu 
initialisieren, dauert 7µs
    countErrorsUART0++;
    uart0_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );
    state_UART_MODE = UART;
  }

UHHH!!!!!

In den UART-Routinen des Herrn Fleury sind ein paar laxe Dinger drin, 
die ich so nicht machen würde. Denn dort wird mehrfach auf gobale, 
volative Variablen zugegriffen. Jaja, die sind nur 8 Bit, aber der 
Zugriff ist NICHT atomar. Da kann sich im Extremfall was 
dazwischenmoglen, u.a. bei UART0_LastRxError, da können einzelne Fehler 
verschluckt werden! Ich würde die Funktion so schreiben.

unsigned int uart0_getc(void)
{    
    unsigned char tmptail;
    unsigned char data;
    unsigned char lastRxError;


    if ( UART0_RxHead == UART0_RxTail ) {
        return UART_NO_DATA;   /* no data available */
    }
    
    /* calculate buffer index */
    tmptail = (UART0_RxTail + 1) & UART_RX_BUFFER_MASK;
    
    /* get data from receive buffer */
    data = UART0_RxBuf[tmptail];
    /* store buffer index */
    UART0_RxTail = tmptail; 
 
    ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {
      lastRxError = UART0_LastRxError;
      UART0_LastRxError = 0;  
    }

    return (lastRxError << 8) + data;

}/* uart_getc */

[Falk B. (falk)]

Und ich mein, bei einem Empfangsfehler muss man nicht gleich in die 
totale Panik verfallen und alles neu initialisieren. Ich würde, vor 
allem zum Testen, erstmal einfach ein paar Zähler für die einzelnen 
Fehler anlegen und hochzählen. So wie es den schon für countErrorsUART0 
gibt.

[Sascha W. (sascha-w)]

Falk B. schrieb:
> Es scheint so, als ob es irgendwo mal einen falschen Zugriff auf USCR0B
> gibt und dadurch das RXCIE0 Bit gelöscht würde. Soweit ich es sehe,
> gibit es aber nur einen Zugriff auf das Register, in uart0_putc(), dort
> wird aber nur UDRIE gesetzt.
Ich hab jetzt nicht in die Lib reingeschaut, aber wenn der 
Read-Modify-Write-Zugriff durch die Compare ISR unterbrochen wird 
bekommt das RXCIE-Bit nach Verlassen der ISR wieder den selben 
gelöschten Zustand.

Sascha

[Veit D. (devil-elec)]

Hallo,

bei einem reinen Byte Zugriff muss man auch atomic sicher zugreifen? Ich 
dachte immer das ist nur ab >=16Bit notwendig. Nun gut, habe sämtliche 
Registerzugriffe atomar gemacht, auch meine Timer run stop Funktionen, 
man weiß ja aktuell nicht was los ist.

Keine Besserung.

Danach habe ich die uart0_getc Funktion laut Falk geändert.

Keine Besserung.

Danach habe ich den Code radikal abgespeckt.
Dazu muss ich OSCCAL0 von Hand anpassen, weil Kalibrierung rausgenommen.
Ab jetzt arbeitet nur noch die Serielle und Timer 1.

Immer noch Aussetzter wie "gewohnt".

@ Sascha:
wir schalten in Timer 1 CompB ISR  uart receive wieder ein.
Oder wie meinst du das?

Der aktuelle Code im Anhang.

[Sascha W. (sascha-w)]

Veit D. schrieb:
> @ Sascha:
> wir schalten in Timer 1 CompB ISR  uart receive wieder ein.
> Oder wie meinst du das?
das da
UART0_CONTROL    |= _BV(UART0_UDRIE);
in uart0_putc
sieht so aus
1) in temp,UCSR0B
2) ori temp,(1<<UDRIE)
3) out UCSR0B,temp
wenn jetzt nach 1 oder 2 die ISR zuschlägt und das RXCIE-Bit setzt, so 
wird dieses mit 3 wieder gelöscht!

Sascha

[Carl D. (jcw2)]

Kennt eigentlich jemand einen validen Grund, warum in der Fleury-Lib der 
Puffer der uart0 aus uint16_t-Arrays besteht und beim Puffer der 
optionalen uart1 die (erwarteten) unsigned char-Arrays zu finden sind?
Immerhin hat das Ding nur ein halbes k RAM.

[Veit D. (devil-elec)]

Hallo,

also müsste man

UART0_CONTROL    |= _BV(UART0_UDRIE);

mit atomic sicher machen?



16 Bit Ringbuffer habe ich geändert, weil ich den mit zum kalibrieren 
verwende, am Anfang, sonst habe ich einen 2. Einmessbuffer der nur noch 
Speicher sinnlos Speicher wegnimmt.

Entweder hätte ich einen 8 Bit Ringbuffer und einen 16 Bit Einmessbuffer 
oder nur einen größeren 16 Bit Ringbuffer den ich für alles verwende.

Die µC RAM Auslastung ist mit kompletten Code laut Atmel Studio nicht 
größer 64% gewesen.

[Sascha W. (sascha-w)]

Veit D. schrieb:
> Hallo,
>
> also müsste man
>
> UART0_CONTROL    |= _BV(UART0_UDRIE);
>
> mit atomic sicher machen?
in deinem Fall schon,
oden die Zeile ganz rausnehmen wenn die entsprechende UDRE ISR nicht 
benötigt wird.

Sascha

[Veit D. (devil-elec)]

Hallo,

die uart wird doch in ihrer vollen Funktionalität benötigt, warum jetzt 
Code rausnehmen?

Übrigens scheint das atomic wirklich zu helfen. Ich werde noch eine 
Weile testen und den Code wieder zusammenbauen.

void uart0_putc(unsigned char data)
{
    unsigned char tmphead;

    
    tmphead  = (UART0_TxHead + 1) & UART_TX_BUFFER_MASK;
    
    while ( tmphead == UART0_TxTail ){
        ;/* wait for free space in buffer */
    }
    
    UART0_TxBuf[tmphead] = data;
    UART0_TxHead = tmphead;

    /* enable UDRE interrupt */
  ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {
    UART0_CONTROL    |= _BV(UART0_UDRIE);
  }

}

[Falk B. (falk)]

@Veit Devil (devil-elec)

>Übrigens scheint das atomic wirklich zu helfen.

Welches? Das bei uart0_putc()?

[Veit D. (devil-elec)]

Moment, z.Z. sind beide drin, deins und das von Sascha

[Veit D. (devil-elec)]

Hallo,

das atomic in uart0_getc() habe ich rausgenommen, jetzt ist nur noch 
atomic in uart0_putc() drin.

void uart0_putc(unsigned char data)
{
    unsigned char tmphead;

    
    tmphead  = (UART0_TxHead + 1) & UART_TX_BUFFER_MASK;
    
    while ( tmphead == UART0_TxTail ){
        ;/* wait for free space in buffer */
    }
    
    UART0_TxBuf[tmphead] = data;
    UART0_TxHead = tmphead;

    /* enable UDRE interrupt */
    ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {  // wegen ISR(TIMER1_COMPA_vect)
        UART0_CONTROL    |= _BV(UART0_UDRIE);
    }

}

Das läuft jetzt schon viele Minuten ohne Fehler, sodass ich sicher davon 
ausgehen kann der Fehler ist gefunden.   :-)  :-)

Soll ich vorsichtshalber das atomic in uart0_getc() wieder reinnehmen?

Großen Dank an Falk, der hier super mitgezogen und die Hauptarbeit 
geleistet hat. Respekt. Danke auch an Sascha der sich eingeklingt hat. 
Danke auch an alle anderen die heimlich mitgelesen haben.   :-)

Also nehme ich mit, auch bei Zugriffen auf nur Byte Register/Variablen 
ist atomic immer angebracht?

Darf ich in dem Thread weitere Fragen stellen zur Code Verbesserung?
Es wurden ja einige Dinge angesprochen die ich ändern 
sollte/könnte/müsste.

[Carl D. (jcw2)]

Veit D. schrieb:
>
> 16 Bit Ringbuffer habe ich geändert, weil ich den mit zum kalibrieren
> verwende, am Anfang, sonst habe ich einen 2. Einmessbuffer der nur noch
> Speicher sinnlos Speicher wegnimmt.
>
> Entweder hätte ich einen 8 Bit Ringbuffer und einen 16 Bit Einmessbuffer
> oder nur einen größeren 16 Bit Ringbuffer den ich für alles verwende.
>
> Die µC RAM Auslastung ist mit kompletten Code laut Atmel Studio nicht
> größer 64% gewesen.

uint16_t kann man aber zur Not auch in 2x uint8_t speichern. Dann 
braucht man nur einen Puffer.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>Das läuft jetzt schon viele Minuten ohne Fehler, sodass ich sicher davon
>ausgehen kann der Fehler ist gefunden.   :-)  :-)

Glückwunsch!

>Soll ich vorsichtshalber das atomic in uart0_getc() wieder reinnehmen?

Ja, denn die Funktion greift auch auf UCSR0B zu, getarnt als #define von

#define UART0_CONTROL     UCSR0B

UART0_CONTROL    |= _BV(UART0_UDRIE);

>Also nehme ich mit, auch bei Zugriffen auf nur Byte Register/Variablen
>ist atomic immer angebracht?

Ja, bei ALLEN Variablen oder IO-Registern, auf welche sowohl im 
Hauptprogramm als auch in Interrupts zugregriffen wird.

https://www.mikrocontroller.net/articles/Interrupt#Atomarer_Datenzugriff

>Darf ich in dem Thread weitere Fragen stellen zur Code Verbesserung?

Sicher

>Es wurden ja einige Dinge angesprochen die ich ändern
>sollte/könnte/müsste.

;-)

[Gerhard (Gast)]

Carl D. schrieb:
> uint16_t kann man aber zur Not auch in 2x uint8_t speichern. Dann
> braucht man nur einen Puffer.

Erzähl doch hier nicht so einen Schwachsinn :(

[Veit D. (devil-elec)]

Hallo,

naja, Glückwunsch auch an dich, du musst genauso viel Ehrgeiz besitzen 
wie ich um fremde Probleme zu lösen.   :-)

Gut, das atomic ist wieder drin.
Habe die Baudrate wieder auf 250kB erhöht und nun fällt mir der 
Sendemodus zum erstenmal auf die Füße. Das hattest du schon angesprochen 
das das passieren kann. Irgenwie muss der Code insgesamt schneller 
gewurden sein.  :-)

Das passiert jetzt, weil der uart Transmit Buffer durch die höhere 
Datenrate leer läuft und das complete Flag dadurch zu zeitig ausgelöst 
wird.
Das Servo Timing Window betrifft ja den uart receive, sollte damit 
nichts zu tun haben falls das zu groß sein sollte.
So weit mein Verständnis.

void uart0_flush ()
{
  uint8_t cnt;

  // warte auf leeren Software-FIFO, der UDRIE ausschaltet
  while ((UCSR0B & (1<<UART0_UDRIE)) );

  UCSR0A |= (1<<TXC0);   // TXC0 löschen

  // warte auf leeren Hardware-FIFO, welcher TXC setzt
  // Timeout nach cnt/2 Zeichen
  cnt=6;
  while (cnt > 0 ) {  
    if ( !(UCSR0A & (1<<TXC0)) ) {
      _delay_us(20);  // 1/2 Zeichen @250kBaud
      cnt--;
    }
  }
}

Warum jetzt halbe Zeichenlängen warten?
Ich könnte auch die Sendefunktion ändern.
Vor jeden Byte senden das "UART Transmit Complete Flag" löschen.



Code zum Bild H:

void MAX487_Empfangsmodus ()
{    
  while( !(UCSR0A & (1<<TXC0)) );    // uart0_flush, warten bis Flag "TXC0 UART Transmit Complete" set
  MAX487_empfangen;          // MAX487 /RE_DE - umschalten auf empfangen
}
  

void MAX487_Sendemodus ()
{  
  Led3_ON;
  MAX487_senden;      // MAX487 /RE_DE - umschalten auf senden
  UCSR0A |= (1<<TXC0);  // delete_uart0_Transmit_Complete_Flag            
              // "UART Transmit Complete Flag" zurücksetzen mit "1" 
}


void send_Nachricht ()
{   
  uint8_t data = 0;
  sendDaten.crc = calc_CRC16(sendDaten.asArray, (sizeof(Nachricht)-sizeof(sendDaten.crc)) ) ;  
  MAX487_Sendemodus();
  uart0_putc(STX);
  for (uint8_t i=0; i < sizeof(Nachricht); i++) {
    data = sendDaten.asArray[i];
    if (data == ESC || data == ETX || data == STX) {
      uart0_putc(ESC);
    }
    uart0_putc(data);        // Bytes rausschieben
  }
  uart0_putc(ETX);
  MAX487_Empfangsmodus();
  Led3_OFF;
}

[Veit D. (devil-elec)]

Hallo,

es müsste doch ausreichend sein wenn ich das Bit vorm letzten ETX Byte 
lösche.

void send_Nachricht ()
{   
  uint8_t data = 0;
  sendDaten.crc = calc_CRC16(sendDaten.asArray, (sizeof(Nachricht)-sizeof(sendDaten.crc)) ) ;  
  MAX487_Sendemodus();
  uart0_putc(STX);
  for (uint8_t i=0; i < sizeof(Nachricht); i++) {
    data = sendDaten.asArray[i];
    if (data == ESC || data == ETX || data == STX) {
      uart0_putc(ESC);
    }
    uart0_putc(data);        // Bytes rausschieben
  }
  UCSR0A |= (1<<TXC0);        // delete_uart0_Transmit_Complete_Flag  
  uart0_putc(ETX);
  MAX487_Empfangsmodus();
}

[Veit D. (devil-elec)]

Hallo,

damit sind ehemals 4 Funktionen in eine geschrumpft.
Momentan zeigen sich keine Fehler. Oder lauert der immer noch?
Ich mach erstmal Schluss für heute.

void send_Nachricht ()
{
  uint8_t data = 0;
  sendDaten.crc = calc_CRC16(sendDaten.asArray, (sizeof(Nachricht)-sizeof(sendDaten.crc)) ) ;
  
  Led3_ON;
  MAX487_senden;          // MAX487 /RE_DE - umschalten auf senden
  
  uart0_putc(STX);
  for (uint8_t i=0; i < sizeof(Nachricht); i++) {
    data = sendDaten.asArray[i];
    if (data == ESC || data == ETX || data == STX) {
      uart0_putc(ESC);
    }
    uart0_putc(data);      // Bytes rausschieben
  }
  UCSR0A |= (1<<TXC0);      // delete_uart0_Transmit_Complete_Flag
  uart0_putc(ETX);
  
  while( !(UCSR0A & (1<<TXC0)) );  // uart0_flush, warten bis Flag "TXC0 UART Transmit Complete" set
  MAX487_empfangen;        // MAX487 /RE_DE - umschalten auf empfangen
  Led3_OFF;
}

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>Das Servo Timing Window betrifft ja den uart receive,

Es trifft auch den UART UDRE Interrupt, der eigentlich auch kurz durch 
COMPA gesperrt werden muss, damit er keinen Jitter verursacht.

>Warum jetzt halbe Zeichenlängen warten?

Einfach so. Man kann auch mehrere Zehntel oder sonstwas warten. Es geht 
nur darum, daß man nicht ewig ohne Timeout wartet, denn unter bestimmten 
Konstellationen kann es passieren, daß TXC am Ende nie auf HIGH geht, 
weil vorher schon alle Daten rausgeschoben wurden. Und Teile eines 
Bytes, um im Normalfall möglichst schnell drauf zu reagieren, wenn TXC 
gesetzt wird.

>Vor jeden Byte senden das "UART Transmit Complete Flag" löschen.

Das geht so einfach nicht, weil das Ganze durch das Softwarefifo 
entkoppelt ist! Probier erstmal meinen Ansatz.

>es müsste doch ausreichend sein wenn ich das Bit vorm letzten ETX Byte
>lösche.

Nein!

Glaub mir, ich hab diese Erkenntnis TEUER bezahlt!

[Carl D. (jcw2)]

Gerhard schrieb:
> Carl D. schrieb:
>> uint16_t kann man aber zur Not auch in 2x uint8_t speichern. Dann
>> braucht man nur einen Puffer.
>
> Erzähl doch hier nicht so einen Schwachsinn :(

Das ist genau so schwachsinnig wie mit einem 8-Bit Rechner zu versuchen 
16-Bit Zahlen zu berechnen. Es scheint nämlich möglich zu sein!

Und im konkreten Fall werden ja in die "Byte-Queue" zwischen ISR und 
Hauptprogramm ganze Messagen aus noch mehr als 16Bit gesteckt. Immerhin 
werden die von der Uart sogar als Sammlung einzelner Bits übertragen.

[Veit D. (devil-elec)]

Hallo,

void uart0_flush ()
{
  uint8_t cnt;

  // warte auf leeren Software-FIFO, der UDRIE ausschaltet
  while ((UCSR0B & (1<<UART0_UDRIE)) );

  UCSR0A |= (1<<TXC0);   // TXC0 löschen

  // warte auf leeren Hardware-FIFO, welcher TXC setzt
  // Timeout nach cnt/2 Zeichen
  cnt=6;
  while (cnt > 0 ) {  
    if ( !(UCSR0A & (1<<TXC0)) ) {
      _delay_us(20);  // 1/2 Zeichen @250kBaud
      cnt--;
    }
  }
}

Ich verstehe wie das funktionieren soll. Mir gefällt daran jedoch eine 
Kleinigkeit nicht, weil das laut meinem Verständnis immer noch schwammig 
ist. Mein Protokoll umfasst 11 Bytes. Jetzt wird in der flush Funktion 
festgelegt, dass x-mal das leere data register abgefragt wird. Wenn das 
Hauptprogramm aus irgendwelchen Gründen, darum gehts ja um das 
abzufangen, die Bytes nicht sofort nacheinander aus dem Ringbuffer an 
die uart senden kann, dann liegt das Problem plötzlich umgekehrt vor. 
Das empty Flag wird 6x abgefragt und letzten 5 Bytes von 11 können nicht 
mehr gesendet werden.

Das Problem ist die Festlegung auf wieviel Bytes (hier 6) gewartet 
werden soll. Ich denke man kann keine feste Zahl festlegen. Entweder zu 
kurz oder zu lang. Eigentlich müsste das in die Sende ISR verlagert 
werden, diese müßte selbst mitzählen wieviel Bytes rausgeschickt wurden. 
Die Anzahl 11 steht unverändert fest.


@ Carl:
habe mir auch darüber Gedanken gemacht. 16Bit in zwei Byte. Ich meine, 
dass ist schon möglich. Man muss nur mit Bits schieben und Maske drüber 
die 16 Bits in 2x 8 Bit aufteilen, ein Buffer speichert alle LSB und der 
zweite Buffer bekommt alle MSB zum Bsp.. Beim auswerten alles rückwärts 
zusammen friemeln. Das zerlegen kostet im PCINT0 ISR allerdings Zeit. 
Gut, ich könnte zur Not das Takteinmesssignal langsamer machen. Will 
damit sagen, theoretisch ist das möglich, praktisch sicherlich auch, nur 
habe ich derzeit keine Notwendigkeit dafür. RAM ist noch genügend frei. 
Und falls der freie RAM schrumpfen sollte, würde ich als erstes den 
Ringbuffer von 32 auf 16 reduzieren und schauen ob ich auch mit 30 
Einmesstakten klar komme statt mit 60. Der Gedanke ist aber nicht 
schlecht, sollte man im Hinterkopf behalten. Diese Art Trickserei geht 
dann ans Eingemachte.  :-)

[Falk B. (falk)]

@Veit Devil (devil-elec)

>ist. Mein Protokoll umfasst 11 Bytes. Jetzt wird in der flush Funktion
>festgelegt, dass x-mal das leere data register abgefragt wird.

Aber erst dann, wenn der Software-FIFO leer ist!

>Wenn das
>Hauptprogramm aus irgendwelchen Gründen, darum gehts ja um das
>abzufangen, die Bytes nicht sofort nacheinander aus dem Ringbuffer an
>die uart senden kann, dann liegt das Problem plötzlich umgekehrt vor.

Nein.

>Das empty Flag wird 6x abgefragt und letzten 5 Bytes von 11 können nicht
>mehr gesendet werden.

Falsch.

>Das Problem ist die Festlegung auf wieviel Bytes (hier 6) gewartet
>werden soll.

Falsch.! Die Zahl 6 ist NICHT die Anzahl von Bytes sondern die Anzahl 
von Wartezyklen!

> Ich denke man kann keine feste Zahl festlegen. Entweder zu
>kurz oder zu lang. Eigentlich müsste das in die Sende ISR verlagert
>werden, diese müßte selbst mitzählen wieviel Bytes rausgeschickt wurden.

Nein.

>Die Anzahl 11 steht unverändert fest.

Das ist nebensächlich.


Die ganze Sache ist aber schon ein wenig kniffelig. Denn wir greifen mal 
wieder auf UCSR0B zu, wenn gleich auch nur lesend. Das Bit UDRIE muss 
von COMPA ebenfalls kurz deaktiviert werden, damit die UDR-ISR keinen 
Jitter erzeugen kann. Damit wird aber die Abfrage des leeren 
Software-FIFOs irritiert! Also muss man diese Abfrage anders machen, so 
wie es uart0_getc() macht.

// warte auf leeren Software-FIFO
while (UART0_RxHead != UART0_RxTail);

[c-hater (Gast)]

Dieter F. schrieb:

> Ich denke, man kann sich auch mit passender Hardware beschäftigen.

Man kann natürlich beliebig komplexe und teuere Hardware mit einem 
Problem beschäftigen, was auch mit der vorhandenen Hardware eines µC 
lösbar wäre, wenn man sie denn einfach nur wirklich vollständig (also 
auch hinsichtlich des Timing) beherrschen würde...

[Dieter F. (Gast)]

c-hater schrieb:
> Man kann natürlich beliebig komplexe und teuere Hardware mit einem
> Problem beschäftigen, was auch mit der vorhandenen Hardware eines µC
> lösbar wäre, wenn man sie denn einfach nur wirklich vollständig (also
> auch hinsichtlich des Timing) beherrschen würde...

Für mich ist z.B. ein ATXMega für ca. 3 € jetzt weder komplex noch 
teuer. Aber das ist, wie so oft, Ansichtssache ...

[c-hater (Gast)]

Dieter F. schrieb:

> Für mich ist z.B. ein ATXMega für ca. 3 € jetzt weder komplex noch
> teuer. Aber das ist, wie so oft, Ansichtssache ...

Nö. Der Punkt ist: Wen du die DMA-Fähigkeiten eines ATXMega benötigst, 
um eine Sachen zu realisieren, die man auch ohne DMA mit einem ATMega 
machen kann, bist du schlicht nur ein Programmierer mit deutlich 
unzureichenden Fähigkeiten.

Das muss nicht mal schlecht sein. Wenn du dein Produkt trotzdem 
gewinnbringend verkaufen kannst, spielt es z.B. keinerlei Rolle, wie 
Scheisse es eigentlich technisch gesehen ist...

[mr. mistoffelees (Gast)]

Ich habe nicht alle 177 Beiträge gelesen...

Was ich aus deiner ISR lese ist, dass hinter
>K6_'X'_OFF
warscheinlich ein Makro steht - vielleicht in einer board.h
Das bedeutet, dass es warscheinlich
>K6_'N'_ON ´s
gibt, die du alle zum "selbem" Moment einschaltest.

Du willst warscheinlich die Anzahl der Ausgänge leicht erweiterbar 
halten?

>> Mein Vorschlag:
Je nachdem was deine Randbedingungen sind, kannst du auch ein anderes 
Konzept anwenden, um die Servos zu steuern. Das PPM wie es im Modelbau 
aus historischen Gründen noch meist benutzt wird.
Dann würde der PWM Pin, der zu dem Timer gehört die 7 Sevors 
nacheinander bedienen und die Pins die du im Moment benutzt, würden das 
Signal multiplexen.

>>> SKEPTISCH
Da ist etwas was mich skeptisch macht, ob du einen sinnvollen Ansatz 
verfolgst: In der ISR hast du einen stop_Timer1(); Aufruf. 
Initialisiertst und startest du bei jedem "Servozyklus" den Timer neu? 
Wenn ja, warum? Bzw. hast du dir etwas konkretes dabei gedacht?

[Falk B. (falk)]

@mr. mistoffelees (Gast)

>Ich habe nicht alle 177 Beiträge gelesen...

Deswegen sind dir wesentliche Dinge entgangen.

>Das bedeutet, dass es warscheinlich
>>K6_'N'_ON ´s
>gibt, die du alle zum "selbem" Moment einschaltest.

Das Thema ist längst abgehakt.

>Du willst warscheinlich die Anzahl der Ausgänge leicht erweiterbar
>halten?

Nein.

>Konzept anwenden, um die Servos zu steuern. Das PPM wie es im Modelbau
>aus historischen Gründen noch meist benutzt wird.

Das haben wir schon lange in dieser Diskussion.

>verfolgst: In der ISR hast du einen stop_Timer1(); Aufruf.

Diese Code ist schon lange veraltet.

[Dieter F. (Gast)]

c-hater schrieb:
> Wen du die DMA-Fähigkeiten eines ATXMega benötigst,
> um eine Sachen zu realisieren,

Wieso DMA - ich wüsste nicht wozu? Aber Du bist der Profi, wirst schon 
Recht haben. Insofern ist der Hinweis auf

c-hater schrieb:
> deutlich
> unzureichenden Fähigkeiten

wohl korrekt.

c-hater schrieb:
> Das muss nicht mal schlecht sein. Wenn du dein Produkt trotzdem
> gewinnbringend verkaufen kannst, spielt es z.B. keinerlei Rolle, wie
> Scheisse es eigentlich technisch gesehen ist...

Hast Du da Erfahrungswerte? Würde sicher manchen interessieren, wenn Du 
bereit bist, diese zu Teilen.

[Veit D. (devil-elec)]

Hallo,

die Timer Compares ISR ergänzt sehen jetzt so aus, funktioniert soweit.

ISR(TIMER1_COMPB_vect)    // dauert 6,2µs, wird aller >1ms aufgerufen
{
  Led2_ON;              // für Datalogger, debuggen
  
  static uint8_t servo = 0;
  const uint8_t SERVO_CNT = 3;        // Anzahl Servos
  const uint8_t TIMING_WINDOW = 7;    // 6µs / 125ns / Prescaler 8 = 6,25 Timertakte
  uint16_t temp = 0;
    
  switch(servo) {    // ISR Zeit 4,75µs
    // Count   999 =  1ms
    // Count  1999 =  2ms
    // Count 19999 = 20ms
    case 0: Led7_OFF;  Led8_ON;  temp =  1999; break;
    case 1: Led8_OFF;        temp =  1999; break;  // virtuelle
    case 2:             temp = 13999; break;  // virtuelle
    case 3:             Led7_ON;  temp =  1999; break;
  }
    
  servo++;
    
  if (servo > SERVO_CNT)  servo = 0;
    
  OCR1B += temp;
  OCR1A = OCR1B-TIMING_WINDOW;
  UCSR0B |= (1<<RXCIE0);    // enable USART0 RX Complete Interrupt
  UCSR0B |= (1<<UDRIE0);    // enable USART0 Data Register Empty Interrupt
    
  Led1_OFF;          
  Led2_OFF;
}


ISR(TIMER1_COMPA_vect)      // dauert 1,8µs
{  
  UCSR0B &= ~(1<<RXCIE0);    // disable USART0 RX Complete Interrupt
  UCSR0B &= ~(1<<UDRIE0);    // disable USART0 Data Register Empty Interrupt
  Led1_ON;          // für Datalogger, debuggen
}

Wegen dem uart flush, ist wirklich glịtschig.   :-)
Eigentlich würde ich das nun so formulieren.

void send_Nachricht ()
{
  uint8_t data = 0;
  sendDaten.crc = calc_CRC16(sendDaten.asArray, (sizeof(Nachricht)-sizeof(sendDaten.crc)) ) ;
  
  Led3_ON;            // für Datalogger, debuggen
  MAX487_senden;          // MAX487 /RE_DE - umschalten auf senden
  
  uart0_putc(STX);
  for (uint8_t i=0; i < sizeof(Nachricht); i++) {
    data = sendDaten.asArray[i];
    if (data == ESC || data == ETX || data == STX) {
      uart0_putc(ESC);
    }
    uart0_putc(data);      // Bytes rausschieben
  }
  uart0_putc(ETX);
  
  while (UART0_TxHead != UART0_TxTail);  // warte auf leeren TX-Ringbuffer
  UCSR0A |= (1<<TXC0);          // delete_uart0_Transmit_Complete_Flag
  while( !(UCSR0A & (1<<TXC0)) );      // uart0_flush, warten bis Flag "TXC0 UART Transmit Complete" set
  
  MAX487_empfangen;            // MAX487 /RE_DE - umschalten auf empfangen
  Led3_OFF;
}

Allerdings muss ich dafür die Sichtbarkeit für UART0_RxHead und 
UART0_RxTail erweitern. Damit habe ich Probleme. Aktuell gibts die nur 
in der uart.cpp

static volatile unsigned char UART0_TxHead;
static volatile unsigned char UART0_TxTail;

Jetzt dachte ich, die muss ich nur in meiner main.cpp mit extern bekannt 
machen, so wie ich das mit dem Ringbuffer gemacht habe, klappt aber 
nicht.

extern static volatile unsigned char UART0_TxHead;
extern static volatile unsigned char UART0_TxTail;

conflicting specifiers in declaration of 'UART0_TxHead'  
conflicting specifiers in declaration of 'UART0_TxTail'  
'UART0_TxHead' was not declared in this scope
'UART0_TxTail' was not declared in this scope

Edit:
moment, wir wollen ja den Sendebuffer überwachen, alles Rx zu Tx 
geändert, der der Form halber.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>die Timer Compares ISR ergänzt sehen jetzt so aus, funktioniert soweit.

>  UCSR0B |= (1<<RXCIE0);    // enable USART0 RX Complete Interrupt
>  UCSR0B |= (1<<UDRIE0);    // enable USART0 Data Register Empty Interrupt

Das kann man problemlos in eine Zeile schreiben, ist auch ein paar Takte 
schneller.

  UCSR0B |= ((1<<RXCIE0) | (1<<UDRIE0));


>ISR(TIMER1_COMPA_vect)      // dauert 1,8µs
>{
>  UCSR0B &= ~(1<<RXCIE0);    // disable USART0 RX Complete Interrupt
>  UCSR0B &= ~(1<<UDRIE0);    // disable USART0 Data Register Empty
Interrupt

Ebenso hier, man muss nur passende Klammern setzen.

  UCSR0B &= ~((1<<RXCIE0) | (1<<UDRIE0));

>Allerdings muss ich dafür die Sichtbarkeit für UART0_RxHead und
>UART0_RxTail erweitern.

Ja.

>static volatile unsigned char UART0_TxHead;
>static volatile unsigned char UART0_TxTail;

Einfach das static weglassen. Und wenn du schon dabei bist, mach mal aus 
unsigned char ein uint8_t, auch wenn es praktisch beim AVR das Gleiche 
ist.

>extern static volatile unsigned char UART0_TxHead;
>extern static volatile unsigned char UART0_TxTail;

Ist Unsinn. extern und static widersprechen sich ;-)

[Veit D. (devil-elec)]

Hallo,

gut, Einzeiler daraus gemacht, Danke.
Habe in der uart Lib alle unsigned char durch uint8_t und alle unsigned 
int durch uint16_t ersetzt. Dabei fiel mir was in der originalen 
uart_getc auf.

unsigned int uart0_getc(void)
{    
    unsigned char tmptail;
    unsigned char data;
    unsigned char lastRxError;


    if ( UART0_RxHead == UART0_RxTail ) {
        return UART_NO_DATA;   /* no data available */
    }
    
    /* calculate buffer index */
    tmptail = (UART0_RxTail + 1) & UART_RX_BUFFER_MASK;
    
    /* get data from receive buffer */
    data = UART0_RxBuf[tmptail];
    lastRxError = UART0_LastRxError;
    
    /* store buffer index */
    UART0_RxTail = tmptail; 
    
    UART0_LastRxError = 0;
    return (lastRxError << 8) + data;

}/* uart_getc */

lastRxError und data sind ein Byte groß, zurückgegeben werden aber ein 
uint16_t. Macht der Compiler selbstständig die letzte Addition richtig? 
Sonst würde ich lieber vorbeugend lastRxError zum uint16_t machen.

Übrigens läuft das jetzt schon viele Minuten ohne Fehler.  :-)
Danke Falk, du hast echt was drauf.

Wäre für
UCSR0A |= (1<<TXC0);   // delete_uart0_Transmit_Complete_Flag
ein atomic übertrieben?

void send_Nachricht ()
{
  uint8_t data = 0;
  sendDaten.crc = calc_CRC16(sendDaten.asArray, (sizeof(Nachricht)-sizeof(sendDaten.crc)) ) ;
  
  Led3_ON;            // für Datalogger, debuggen
  MAX487_senden;          // MAX487 /RE_DE - umschalten auf senden
  
  uart0_putc(STX);
  for (uint8_t i=0; i < sizeof(Nachricht); i++) {
    data = sendDaten.asArray[i];
    if (data == ESC || data == ETX || data == STX) {
      uart0_putc(ESC);
    }
    uart0_putc(data);      // Bytes rausschieben
  }
  uart0_putc(ETX);
  
  while (UART0_TxHead != UART0_TxTail);  // warte auf leeren TX-Ringbuffer
  UCSR0A |= (1<<TXC0);          // delete_uart0_Transmit_Complete_Flag
  while( !(UCSR0A & (1<<TXC0)) );      // uart0_flush, warten bis Flag "TXC0 UART Transmit Complete" set
  
  MAX487_empfangen;            // MAX487 /RE_DE - umschalten auf empfangen
  Led3_OFF;
}

[Dieter F. (Gast)]

Veit D. schrieb:
> Danke Falk, du hast echt was drauf.

Irgendwie erinnerst Du mich an meinen Bruder :-). Der bekommt es auch 
immer wieder hin, dass andere seine Arbeit machen :-) Nix für ungut - 
ist nur eine Erinnerung.

Warum kommt es beim Modelleisenbahnverkehr auf 2 Grad oder wenige µs an? 
Das habe ich bisher nicht verstanden. Eine Weiche ist ist offen oder 
geschlossen (da machen 2 Grad nichts aus) - gleiches gilt für ein 
Signal, eine Lokschuppentür etc.

Mich würde das Konzept dahinter interessieren - kannst Du das bitte mal 
bekannt geben?

Warum muss es überhaupt der ATTiny841 sein - nicht die schlechteste Wahl 
aus meiner Sicht - aber warum?

Wenn ich Deinen Test-Aufbau sehe kommt mir das schon recht professionell 
vor -  in welcher Liga spielst du?

Beitrag "Re: ISR Code schneller machen?"

[Thomas (Gast)]

Dieter F. schrieb:
> Veit D. schrieb:
>> Danke Falk, du hast echt was drauf.
>
> Irgendwie erinnerst Du mich an meinen Bruder :-).

Ist der auch so ein Kriecher?

[Dieter F. (Gast)]

Thomas schrieb:
> Ist der auch so ein Kriecher?

Gottseidank ähnelt er Dir nicht :-) - er ist nämlich nicht feige :-)

[Falk B. (falk)]

@Veit Devil (devil-elec)
>    UART0_LastRxError = 0;
>    return (lastRxError << 8) + data;

>lastRxError und data sind ein Byte groß, zurückgegeben werden aber ein
>uint16_t. Macht der Compiler selbstständig die letzte Addition richtig?

Ja, weil er unsichtbar die beiden Operanden vor der Operation auf int 
erweitert, beim avr gcc sind das 16 Bit.

>Sonst würde ich lieber vorbeugend lastRxError zum uint16_t machen.

Nicht nötig, bestenfalls ein cast.

return ((uint16_t)lastRxError << 8) + data;

Ist aber hier auch eher Gürtel + Hosenträger ;-)

>Übrigens läuft das jetzt schon viele Minuten ohne Fehler.  :-)

WOW, Software die mehrere Minuten fehlerfrei läuft sieht man ja nicht 
alle Tage! ;-)

>Wäre für
>UCSR0A |= (1<<TXC0);   // delete_uart0_Transmit_Complete_Flag
>ein atomic übertrieben?

Braucht man nicht, da auf UCSR0A nirgendwo in einer ISR zugegriffen 
wird. Man kann es aber dennoch per atomic Block schützen, falls man mal 
irgendwann eine Erweiterung des Quelltextes vornimmt. Aber halt, da soll 
jetzt NICHT dazu führen, daß du ALLE IO-Registerzugriffe in deinem 
Programm mit einem atomic block "schützt", das wäre Unsinn^3!

Hast du ein Oszi? Hast du mal den Jitter der Servosignale gemessen? Denn 
es können immer noch ein paar einzelne Aussetzer passieren, denn dein 
uart_putc() schaltet immer fröhlich UDRIE ein, auch wenn es vorher vom 
COMPA ausgeschaltet wurde. Da muss man noch ein bisschen zaubern. Dafür 
braucht man entweder eine zusätzliche Variable oder man trickst und 
nutzt das ungenutztes Bit TXB80. Mit diesem Bit signalisieren wir, ob 
uart_putc() UDRIE einschalten darf oder ob es warten muss.

in COMPA muss dann rein

UCSR0B &= ~((1<<RXCIE0) | (1<<UDRIE0) | (1<<TXB80));

in COMPB muss dann rein

UCSR0B |= ((1<<RXCIE0) | (1<<UDRIE0) | (1<<TXB80));

uart0_putc() sieht dann so aus.

void uart0_putc(unsigned char data)
{
    unsigned char tmphead;
    
    tmphead  = (UART0_TxHead + 1) & UART_TX_BUFFER_MASK;
    
    while ( tmphead == UART0_TxTail ){
        ;/* wait for free space in buffer */
    }
    
    UART0_TxBuf[tmphead] = data;
    UART0_TxHead = tmphead;

    /* enable UDRE interrupt */
    ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {  // wegen ISR(TIMER1_COMPA_vect)
      if (UCSR0B & (1<<TXB80)) {
        UART0_CONTROL    |= _BV(UART0_UDRIE);
        return;
      }
    }
    
    // warte auf das Ende der ISR-Sperre
    // reiner Lesezugriff ist atomar, daher kein atomic block nötig
    while (!(UCSR0B & (1<<TXB80)));

    ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {  // wegen ISR(TIMER1_COMPA_vect)
      UART0_CONTROL    |= _BV(UART0_UDRIE);
    }
    
}/* uart_putc */

[Dieter F. (Gast)]

Falk B. schrieb:
> WOW, Software die mehrere Minuten fehlerfrei läuft sieht man ja nicht
> alle Tage! ;-)

Scheint ein Fieber zu sein :-) Gut für Veit, den "Devil" :-)

[Veit D. (devil-elec)]

Hallo,

@ Dieter

Ich denke ich bin schon alleine ganz schön weit gekommen. Allein schon 
die OSCCAL Kalibrierung war ein hartes Stück Arbeit. Damit fing alles 
an. Ich wurde nur in der Form korrigiert wie das grundlegend richtig 
gemacht wird. Ich hatte mich verrannt. Mit den Hinweisen und Atmel App 
Notes habe ich das dann ganz alleine umgesetzt. Das ist auch der erste 
Kalibriercode den du öffentlich in einem Forum siehst.  ;-)
Von daher, kann ich den Spruch so leider nicht unkommentiert stehen 
lassen. Auch wenn du das lustig meinst. Ich denke desweiteren das alles 
was hier zum Thema wurde schon ganz schön knifflige Dinge sind/waren, 
die nur jemand lösen kann der sich damit in den Tiefen auskennt. 
Desweiteren hatte ich ja nichts unfertiges gezeigt, lauffähiges mit 
sporadischen Hängern.

Genauigkeit. Ist eine meiner Eigenschaften. Halbe Sachen gibts bei mir 
nicht. Dauert zwar alles länger, aber am Ende wird es besser und man 
freut sich. Seit über einem Jahr (fast 2) baue ich schon rum. 
Programmieren und Leiterplatten erstellen. Die Leiterplatten sehen auch 
nur so gut aus, weil ich mir dafür Zeit genommen habe. Der Schaltplan 
konnte mit Hilfe des Forums verbessert werden. Den Rest hat mein 
Target3001 und elecrow gemacht.  :-)

Zurück wegen der Servogenaugigkeit. Wenn die neue Ansteuerungsmethode 
mehr Genauigkeit nebenbei mit abwirft, dann nehme ich das gern mit. Die 
Weichenzunge soll sauber anliegen. Nicht mit zu viel oder zu wenig 
Druck. Die Weichenpulse werden dann noch dahin gehend geändert, dass die 
nur 1-2s ans Servo ausgegeben werden. Die Servogetriebe sind soweit gut 
selbsthaltend. Dauerhaftes Servo brummen wird auch vermieden.

Konzept. Im Grunde ist das eine selbst gebaute SPS. Mit dieser kann ich 
alles steuern was ich möchte. Die Slaves sind die 
Eingangs/Ausgangskarten und der Master ist das Herz des Ganzen. Dazu ist 
alles komplett universal verwendbar. Oder habe ich die Frage falsch 
verstanden?

ATtiny841. Warum nicht? Ich benötigte zum Anfang zwei UARTs. Die zweite 
zum debuggen bis die Kommunikation nach der Kalibrierung auf der 
eigentlichen uart fertig war.


Zu guter letzt macht es mir einfach Spass zu basteln und zu 
programmieren. Man wird davon nicht dümmer.  :-)


@ Falk
> WOW, Software die mehrere Minuten fehlerfrei läuft sieht man ja nicht
> alle Tage! ;-)
hier musste ich laut lachen. Es läuft nun schon seit 2h ohne Fehler 
:-)
Mit Oszi habe ich noch nicht wieder gemessen, der restliche Jitter wird 
schwer erkennbar werden. Das geht nur mit Datalogger.

Deine neue Idee schaue ich mir noch genauer an.

[Dieter F. (Gast)]

Veit D. schrieb:
> Auch wenn du das lustig meinst.

Nein.

Veit D. schrieb:
> Ich denke desweiteren das alles
> was hier zum Thema wurde schon ganz schön knifflige Dinge sind/waren,
> die nur jemand lösen kann der sich damit in den Tiefen auskennt.

Ja.

Veit D. schrieb:
> Seit über einem Jahr (fast 2) baue ich schon rum.
> Programmieren und Leiterplatten erstellen. Die Leiterplatten sehen auch
> nur so gut aus, weil ich mir dafür Zeit genommen habe. Der Schaltplan
> konnte mit Hilfe des Forums verbessert werden.

Ja - nehme ich mal an.

Veit D. schrieb:
> Die
> Weichenzunge soll sauber anliegen.

Da spielen 2 oder 4 Grad doch überhaupt keine Rolle - das Material ist 
elastisch.

Veit D. schrieb:
> Die Weichenpulse werden dann noch dahin gehend geändert, dass die
> nur 1-2s ans Servo ausgegeben werden.

Und wir sind hier im µs-Bereich unterwegs - spannend :-)

Veit D. schrieb:
> Oder habe ich die Frage falsch
> verstanden?

Nein - glaube ich nicht - nur die Antwort scheust Du etwas :-)

Veit D. schrieb:
> Man wird davon nicht dümmer.  :-)

Da stimmen wir überein :-)

[Falk B. (falk)]

Über den Sinn und zweck derartig genauer Servopulse und 250kBaud für ne 
Modellbahn kann man streiten. Als sportliche Herausforderung in Punkto 
Software taugt es allemal und man kann es an anderer Stelle irgendwann 
sinnvoll einsetzen.

[Dieter F. (Gast)]

Falk B. schrieb:
> ber den Sinn und zweck derartig genauer Servopulse und 250kBaud für ne
> Modellbahn kann man streiten. Als sportliche Herausforderung in Punkto
> Software taugt es allemal und man kann es an anderer Stelle irgendwann
> sinnvoll einsetzen.

Ja.

[Veit D. (devil-elec)]

Hallo,

>>>  genau, sehe ich auch so


Dieter, was möchtest du denn wissen? Keine klare Frage - keine klare 
Antwort.

ohne TXB80 Bit
Der Jitter beträgt leider bis zu 30µs laut Oszi und Datalogger. Was mich 
erstaunt. Was man an 2 Servos hört und sieht.

Auflösung = 90°/1000µs = 0,09° pro Count
90°/1000µs*30µs = 2,7° Jitter

Mit Code für TXB80 Bit funktioniert leider nicht, der ATtiny kann nicht 
antworten. Laut Manual ist TXB80 für das 9. Datenbit zuständig. Ich 
verwende aber nur 8 Datenbits. ?

[guest (Gast)]

Veit D. schrieb:
> Die Weichenzunge soll sauber anliegen. Nicht mit zu viel oder zu wenig
> Druck. Die Weichenpulse werden dann noch dahin gehend geändert, dass die
> nur 1-2s ans Servo ausgegeben werden. Die Servogetriebe sind soweit gut
> selbsthaltend. Dauerhaftes Servo brummen wird auch vermieden.

Wenn Du noch etwas mehr basteln willst :)
Das Anliegen der Zunge läßt sich auch detektieren, solange sie irgendwo 
in der Mitte ist hat sie keine Verbindung zur Fahrspannung und ist 
sozusagen hochohmig. Über einen Timeout ließen sich damit auch Fehler 
(klemmen) erkennen.

[Veit D. (devil-elec)]

Hallo,

was mich auch wundert, dass die Kommunikation auch nicht mehr 
funktioniert, wenn ich in der uart0_putc() das setzen von UDRIE 
rausnehme. Wir setzen und löschen doch in den Timer Compares. Sollte 
doch völlig egal sein?

Edit:
ach ne, die
ISR (UART0_TRANSMIT_INTERRUPT)
löscht das ja. Mist.

@ guest, merke ich mir vor, Danke.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>ohne TXB80 Bit
>Der Jitter beträgt leider bis zu 30µs laut Oszi und Datalogger. Was mich
>erstaunt. Was man an 2 Servos hört und sieht.

Dein Logicanalyzer kann Jitter messen? Cool!
Aber 30us sind irgendwie zuviel, so lange dauert die UART UDRE ISR 
nicht.

Zoom mal beim Oszi auf 10us/DIV rein, da sieht man mehr.

Teste mal ohne Datenverkehr auf dem UART, dann dürften nur noch 1-2 
Takte, sprich 125-250ns Jitter sein.

>Mit Code für TXB80 Bit funktioniert leider nicht, der ATtiny kann nicht
>antworten. Laut Manual ist TXB80 für das 9. Datenbit zuständig. Ich
>verwende aber nur 8 Datenbits. ?

Hmm, keine Ahung, kann ich von hier nicht testen. Hast du ALLE 
Änderungen drin? Vielleicht hab ich auch was vergessen, war ja nur so ne 
schnelle Idee.

[Veit D. (devil-elec)]

Hallo,

die Software kann über das gesamte aufgezeichnete Signal wie gezeigt 
alle min/max Pegellängen analysieren.   :-)   Das aufgezeichnete Signal 
kann man auch speichern und irgendwann genauer anschauen. 30s sind 
z.Bsp. 113MB Filegröße. Aufzeichnungsdauer hängt nur vom Speicherplatz 
ab. Ist wirklich cool.

In der Zwischenzeit habe ich ohne Datenverkehr gemessen. Da ist der max. 
Jitter 10µs. Danach wollte ich wissen wie schlimm es denn wird wenn ich 
alle Verbesserungen rausnehme + Datenverkehr. Sprich das uart ISR 
aktiveren/deaktiveren in den Timer Compares rausnehme und nur noch 
Compare A verwende. Ernüchterung ist, es wird nicht schlechter, bleibt 
bei 30µs.

Mit 10µs/DIV am Oszi kann ich nicht messen, der Puls ist außerhalb des 
Schirms, also länger wie der Schirm.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>In der Zwischenzeit habe ich ohne Datenverkehr gemessen. Da ist der max.
>Jitter 10µs.

Dann stimmt was nicht. Ohne andere ISRs darf das nicht ansatzweise 
soviel jittern! Meßfehler?

>Mit 10µs/DIV am Oszi kann ich nicht messen, der Puls ist außerhalb des
>Schirms, also länger wie der Schirm.

Aber sicher, das kann JEDES Digitaloszi. Der Trigger kann nahezu 
beliebig weit links liegen (trigger delay). Ob das diese "Billiggurken" 
können weiß ich nicht, hab nur gute LeCroys in der Firma ;-)

Probier's einfach mal aus. Trigger auf steigende Flanke, fallende Flanke 
in Bildschirmmitte und dann auf 10us/DIV runterdrehen.

Ahhh, Moment! Du hast ja den internen RC-Oszillator! Der ist nicht 
sonderlich kurzzeitstabil! Da kann das schon mal bei 1ms Pulsbreite um 
10us jittern! Das liegt aber am Oszillator und NICHT an der Software! 
Hmm???

[Veit D. (devil-elec)]

Hallo,

Ergänzung.
Ohne Datenverkehr.
Das Oszi zeigt für das 1. Servo 0µs Jitter an.
Für das 2. Servo 10µs.
Nur das 2. Servo zuckt selten sporadisch.

[Falk B. (falk)]

https://scienceprog.com/avr-internal-oscillator-jitter-research/

Früher war alles besser . . .

[Veit D. (devil-elec)]

Oszi Trigger:

mit steigender Flanke Trigger außerhalb des Schirms kann es nicht mehr 
die Pegellängen messen, aber ich sehe die fallende Flanke zittern. Das 
sind weniger wie 5µs. Ohne Datenverkehr.

Mit Datenverkehr zittert es ca. 20µs, so gut man das eben erkennen kann.

LeyCroy kann ich mir nicht leisten.  :-)
Ich wäre auch Rohde & Schwarz Fan.   :-)

[Veit D. (devil-elec)]

Falk B. schrieb:
> https://scienceprog.com/avr-internal-oscillator-jitter-research/
>
> Früher war alles besser . . .

Das ist natürlich traurig zu sehen, weil ich annahm das der interne sehr 
stabil ist laut Manual. Ist ja Temperatur stabilisiert. Ich hatte auch 
zu Beginn der ganzen Geschichte mit Haarfön und Eiswürfel den ATtiny 
geärgert. Das Timer Taktsignal von damals 100kHz veränderte sich 
überhaupt nicht. Seitdem nahm ich an alles ist dufte.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>mit steigender Flanke Trigger außerhalb des Schirms kann es nicht mehr
>die Pegellängen messen,

Das ist egal.

> aber ich sehe die fallende Flanke zittern.

Das ist der Punkt!

> Das
>sind weniger wie 5µs. Ohne Datenverkehr.

Ist immer noch zuviel, wenn man von einer idealen Taktquelle ausgeht.

>Mit Datenverkehr zittert es ca. 20µs, so gut man das eben erkennen kann.

Immerhin ist ein Unterschied sichtbar

Letze Idee für heute. Generiere ein Servosignal rein in Hardware per 
OCR1A Pin ohne ISR etc, dazu die COMA1x Bits passend setzen. Damit kann 
man den Jitter des RC-Oszillators sicher messen.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>Das ist natürlich traurig zu sehen, weil ich annahm das der interne sehr
>stabil ist laut Manual.

Das ist relativ.

> Ist ja Temperatur stabilisiert.

Die Frequenz ja, aber Jitter ist, je nach Messung, ein Kurzzeiteffekt.

[Veit D. (devil-elec)]

Hallo,

der RC Jitter beträgt laut Link ca. 100ns, was ca. 1 Takt entspricht. 
Sollte sich das nicht permanent ausgleichen weil er ständig zittert?

Hardware OCR1A Messung mach ich morgen ... gute Nacht

[mr. mistoffelees (Gast)]

>@mr. mistoffelees (Gast)

>>Ich habe nicht alle 177 Beiträge gelesen...

>Deswegen sind dir wesentliche Dinge entgangen.

>>Das bedeutet, dass es warscheinlich
>>>K6_'N'_ON ´s
>>gibt, die du alle zum "selbem" Moment einschaltest.

>Das Thema ist längst abgehakt.

>>Du willst warscheinlich die Anzahl der Ausgänge leicht erweiterbar
>>halten?

>Nein.

>>Konzept anwenden, um die Servos zu steuern. Das PPM wie es im Modelbau
>>aus historischen Gründen noch meist benutzt wird.

>Das haben wir schon lange in dieser Diskussion.

>>verfolgst: In der ISR hast du einen stop_Timer1(); Aufruf.

>Diese Code ist schon lange veraltet.

Im Ganzen wäre es viel einfacher einem Thread zu folgen, wenn nicht 
grundsätzlich zwischendrin jemand anfangen würde dem TO eine andere 
Hardware zu empfehlen, woraufhin dann erstmal eine Diskussion über die 
vorgeschlagene Hardwareänderung entbrennt (in diesem Fall XMega) und das 
dann noch gemischt mit persönlichen Meinungen zwischen verschiedenen 
"Lagern".
Vielleicht sollten sich die Mods angewöhnen, solche Beitraäge ebenfalls 
zu löschen.
DESHALB lese ich nicht alle vorigen Beiträge weil die ganz schnell am 
Eröffnungsthred vorbeigehen.

[Dieter F. (Gast)]

Für Interessierte:

http://www.microsofttranslator.com/bv.aspx?from=ja&to=en&a=http://elm-chan.org/docs/avr/jitter.html

[Äxl (geloescht) (Gast)]

HI,
nachdem ja alles läuft (ich wollte nicht auch noch "mitmachen")...
Was macht deine crc16-Geschichte. Wie lange dauert denn das alles so?
Die Debug-LED wird ja erst danach eingeschaltet.
Da würde mich ja mal das asm Listing interessieren. Ist es hinderlich, 
mit dem "sizeof" Operator zu arbeiten oder sendDaten als Struct 
anzulegen, statt eine eigene Variable zu verwenden? Ich frag nur aus 
neugierde, ich bin eher in der Hardware zu Hause.

sendDaten.crc = calc_CRC16(sendDaten.asArray, (sizeof(Nachricht)-sizeof(sendDaten.crc)) ) ;

aus der Referenz:
http://www.microchip.com/webdoc/avrlibcreferencemanual/group__util__crc_1ga95371c87f25b0a2497d9cba13190847f.html


Ist das Pseudocode zu erklären oder warum muss die Zählvariable "i" ein 
16 bittiges int sein? Dann die ganzen Parameter-Übergaben an die 
Funktion. Das kommt mir alles total "viel" vor. Aber - ich hab nicht die 
Mega-Ahnung, was den ganzen Pointer-Kram angeht und weis auch nicht, wie 
weit der Compiler hier optimiert.

uint16_t
crc16_update(uint16_t crc, uint8_t a)
{
    int i;

    crc ^= a;
    for (i = 0; i < 8; ++i)
    {
        if (crc & 1)
            crc = (crc >> 1) ^ 0xA001;
        else
            crc = (crc >> 1);
    }

    return crc;
}

Ebenso möchte ich mich vorsichtig der oben gestellten Frage anschließen, 
ob man bei einer Modellbahn mit RS485-Bus, 250KBaud und CRC arbeiten 
muss.

Schade, das das Projekt für mich total undurchsichtig ist.
Ich lege immer alles in ein Verzeichns und zippe mir das weg.
Wenn dann jemand nach dem Code fragt, um mir helfen zu können, dann lade 
ich das ZIP-File hoch und gut.

Aber: schön, wenn jetzt alles (länger als 2Stunden lang?) läuft.

Grüße Äxl

[Falk B. (falk)]

@Veit Devil (devil-elec)

>der RC Jitter beträgt laut Link ca. 100ns, was ca. 1 Takt entspricht.

Aber nur nach 10us trigger delay. bei 2ms sieht das anders aus.

>Sollte sich das nicht permanent ausgleichen weil er ständig zittert?

Das hängt von den Details ab, genauer, von der Amplitude der 
Phasenmodulation. Wenn man will, kann man die Phase über große Zeiträume 
sehr stark driften lassen und sie dann wieder genausoviel in die 
Gegenrichtung driften lassen. im Langzeitmittel ist die Frequenz sehr 
genau, kurzzeitig ist die Phase sonstwo 8-0

>Hardware OCR1A Messung mach ich morgen ... gute Nacht

Tu das. Danach solltest du deine Taktauswahl überdenken und dir einen 8 
MHz Quarzoszillator besorgen und damit deinen AVR takten. Das kostet nur 
ein IO-Pin, bringt dir aber einen ASTREINEN Takt. Für deine Zwecke ist 
ein RC-Oszillator weder technisch noch ökonomisch sinnvoll bzw. nötig.

https://www.mikrocontroller.net/articles/AVR-Tutorial:_Equipment#Erg.C3.A4nzende_Hinweise_zur_Taktversorgung_.28kann_.C3.BCbersprungen_werden.29

[Falk B. (falk)]

@ Äxl (geloescht) (Gast)

>Da würde mich ja mal das asm Listing interessieren.

Warum? Das macht der Compiler schon ganz gut.

>Ist es hinderlich,
>mit dem "sizeof" Operator zu arbeiten

Keine Sekunde, denn das ist praktisch eine Konstante.

>oder sendDaten als Struct
>anzulegen, statt eine eigene Variable zu verwenden?

Auch kein Thema, das dröselt der Compiler normal auf und fertig.

>http://www.microchip.com/webdoc/avrlibcreferencema...

>Ist das Pseudocode zu erklären

Nö, echtes C.

> oder warum muss die Zählvariable "i" ein
>16 bittiges int sein?

Weil int halt Standard ist. Die Optimierer schreiben dort uint8_t hin, 
die High Speed Optimierer uint_fast8_t.

> Dann die ganzen Parameter-Übergaben an die
>Funktion. Das kommt mir alles total "viel" vor.

Was ist an ZWEI Parametern viel?

>Aber - ich hab nicht die
>Mega-Ahnung, was den ganzen Pointer-Kram angeht und weis auch nicht, wie
>weit der Compiler hier optimiert.

Weit genug. Wenn gleich man eine CRC nicht derartig krampfhaft noch in 
eine Unterfunktion zerlegt. Im Normalfall kann man das direkt in einer 
Funktion für einen Datenblock machen.

>Ebenso möchte ich mich vorsichtig der oben gestellten Frage anschließen,
>ob man bei einer Modellbahn mit RS485-Bus, 250KBaud und CRC arbeiten
>muss.

Muss man nicht, aber man kann.

[Veit D. (devil-elec)]

Hallo,

möchte wirklich jemand eine Steuerung bauen ohne Netz und doppelten 
Boden? Wenn ich einen Befehl auf Reise schicke, dann möchte ich sicher 
sein das genau dieser Befehl an der richten Adresse unverstümmelt 
ankommt. Stell euch mal vor ich baue keine Sicherheiten ein. Ich möchte 
zum Bsp. eine Weiche stellen. Jetzt läuft die Übertragung wegen 
irgendwas gegen den Baum. Danach fühlt sich der falsche Slave 
angesprochen und der stellt dann keine Weiche, was sowieso die falsche 
wäre, sondern schickt einen 2. Zug auf die Strecke. Möchte das wirklich 
jemand ernsthaft von vornherein als Restrisiko einplanen? Ich denke 
nicht.

Ich wundere mich ehrlich gesagt über die IoT Scheunentor offenen 
Gerätschaften nicht mehr wirklich, wenn man an solche Dinge schlaksig 
rangeht.

Die CRC Funktion wird mehrfach benötigt, deshalb als Funktion, zudem 
einfacher wartbar.

sizeof wurde schon geändert, nur nicht in diesem Code der dann zum 
Testcode wurde. Mache ich mit constexpr.

So, zurück zum Thema, RC Jitter. Ja der zappelt durchaus rum   :-(
https://youtu.be/ts-UkvS9csw
Am Ende gehe ich auf 10µs/DIV bis 5µs/DIV runter.

Auf den Quarz hatte ich verzichtet, weil ich das Servoproblem damals 
noch nicht kannte. Außerdem habe ich ohne Quarz genau 8 Pins frei, 
perfekt für Byte Übertragung. Zudem der Platinenplatz mit den Steckern 
auch gut ausgenutzt wird. Damit ich die Bauteile nicht umsonst gekauft 
habe, werde ich nun für die Servos eigene Platinen bauen, mit Quarz. Ich 
werde dann gleich einen 16MHz Quarz nutzen. Ich denke, dass klingt nach 
einem Plan.  :-)

[Veit D. (devil-elec)]

Hallo,

wegen deinem LeyCroy:
Kann das Pulse etc. auch vermessen wenn diese außerhalb des Schirms 
liegen?

zur Frage crc16 Funktion, wenn ich das so messe dauert es 28,2µs.

Led3_ON;
sendDaten.crc = calc_CRC16(sendDaten.asArray, (sizeof(Nachricht)-sizeof(sendDaten.crc)) ) ;
Led3_OFF;

wegen Jitter vs. Servo:
auch wenn das bis zu 2° ausmacht, bei genauerer Überlegung reduziert 
sich das wieder bis zur Weiche, durch Hebel ist da eine Untersetzung 
drin usw. Ich denke vorerst auf größere Neubauten kann ich erstmal 
Abstand nehmen. Wenn mich doch etwas stört, weiß ich gleich was ich 
machen muss. Umsonst war die Übung jedenfalls nicht.

Der nächste Punkt war die tausend if in der handle Serial Funktion. 
Umgebaut auf switch-case.

void handle_Function_UART0_Pins()
{
  switch (state_UART_MODE) {
  case RUN:  // Dummy, virtueller Zustand, Takteinmesszyklus läuft mittels ISR(PCINT0_vect)
        break;
    
  case UART:  // UART0 wird benutzt
        handle_Serial_0_to_Serial_0();
        break;  // minimal 7,7µs ... maximal 18,2µs
    
  case FINISH:  // schaltet UART0 Funktion ein
        del_PCINT2();
        run_Timer0();
        run_Timer1();
        memset((void *)UART0_TxBuf, '\0', sizeof(UART0_TxBuf));  // Messwerte löschen
        memset((void *)UART0_RxBuf, '\0', sizeof(UART0_RxBuf));
        uart0_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );
        state_UART_MODE = UART;
        break;
    
  case SYNC:  // schaltet UART0 Funktion ab
        uart0_disable();
        Txd0Rxd0_normalPortPins();
        state_UART_MODE = WAITSYNC;
        break;
    
  case REPEAT:  // Kalibrierung wiederholen
        set_PCINT2();
        countCalibration++;
        state_UART_MODE = WAITSYNC;
        break;
    
  case WAITSYNC:  // OSCCAL Calibration ready, dauert 85µs
        memset((void *)UART0_TxBuf, '\0', sizeof(UART0_TxBuf));  // Messwerte löschen
        memset((void *)UART0_RxBuf, '\0', sizeof(UART0_RxBuf)); //
        stop_Timer0();
        stop_Timer1();
        set_PCINT2();            // ISR(PCINT0_vect) scharf schalten
        run_Timer2();            
        state_UART_MODE = RUN;
        break;
        
  case CALC:  // OSCCAL neu berechnen
        Calibration_Calculation();
        break;
    
  case ERROR:  // Fehlerbehandlung noch nicht komplett
        countErrorsUART0++;
        //uart0_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );
        state_UART_MODE = UART;
        break;
        
  default:  break;
  }
}

Was würdest du wegen dem enum "state_UART_MODE" ändern?
In der ISR(PCINT0_vect) wird der nach 60 Messungen auf CALC gesetzt.
In der Berechungsfunktion je nach Ergebnis auf REPEAT oder FINISH.
In der Ringbuffer Funktion bei uart Fehler auf ERROR.
Ich wüßte jetzt nicht was man daran verbessern oder trennen sollte?
Das hängt doch alles zusammen bzw. voneinander ab.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>wegen deinem LeyCroy:
>Kann das Pulse etc. auch vermessen wenn diese außerhalb des Schirms
>liegen?

Nein. Aber für die Messung einer einfachen Pulsbreite reicht es, die 2. 
Flanke exakt auf die Bildschirmmitte zu legen. Dann entspricht die 
Triggerverzögerung (horizontal delay) exakt der Pulsbreite).


>drin usw. Ich denke vorerst auf größere Neubauten kann ich erstmal
>Abstand nehmen. Wenn mich doch etwas stört, weiß ich gleich was ich
>machen muss. Umsonst war die Übung jedenfalls nicht.

Ja, aber um den Effekt der Jitterreduzierung durch die clevere COMPA 
Abschaltung zu messen, solltest du dennoch testweise ein Board mit einem 
externen Quarzoszillator betreiben. Seeing is believing!

>Der nächste Punkt war die tausend if in der handle Serial Funktion.
>Umgebaut auf switch-case.

Fast gut.

>  case UART:  // UART0 wird benutzt
>        handle_Serial_0_to_Serial_0();
>        break;  // minimal 7,7µs ... maximal 18,2µs

Das break setze ich immer in die gleiche Einrückung wie das case, denn 
es ist praktisch mit einer schließenden Klammer identisch.

>  case CALC:  // OSCCAL neu berechnen
>        Calibration_Calculation();
>        break;

Hier fehlt der Übergang des States, der sollte/darf NICHT unsichtbar an 
anderen Stellen erfolgen. Das Gleiche gilt für deine anderen States. 
Dort müssen die Übergangsbedingen rein, damit sie direkt sichtbar sind! 
Die dürfen nicht im restlichen Programm verstreut sein, sonst wird man 
wahnsinnig!

>Was würdest du wegen dem enum "state_UART_MODE" ändern?

Siehe oben.

>In der ISR(PCINT0_vect) wird der nach 60 Messungen auf CALC gesetzt.

Schlecht. Dort setzt man ein Flag ala calc_buffer_full und wertet dies 
in der FSM aus und macht DORT den Zustandswechsel!

>In der Berechungsfunktion je nach Ergebnis auf REPEAT oder FINISH.
>In der Ringbuffer Funktion bei uart Fehler auf ERROR.
>Ich wüßte jetzt nicht was man daran verbessern oder trennen sollte?

Siehe oben. Man kann den Ablauf nicht nachvollziehen. Das Hin- und 
Herspringen in den Funktionen um den Ablauf nachzuvollziehen ist Murks, 
da würden dir die Kollegen in der Firma an die Gurgel gehen ;-)

>Das hängt doch alles zusammen bzw. voneinander ab.

Ja, aber es muss auch einfach und überschaubar dargestellt sein.

    case CALC:  // OSCCAL neu berechnen
      if (Calibration_Calculation() == true) {
        state_UART_MODE = FINISH;
      }
    break;

Außerdem ist es kosmetisch vorteilhaft, die States in der Reihenfolge 
aufzuschreiben, wie sie im Normalfall durchlaufen werden, das 
vereinfacht das Nachvollziehen ein wenig mehr.

[Falk B. (falk)]

>  case RUN:  // Dummy, virtueller Zustand, Takteinmesszyklus läuft
>        break;

Das würde im Normalfall bedeuten, daß dieser Zustand nie wieder 
verlassen wird. Das ist aber bei dir nicht so. Ergo, der Leser wird 
verarscht.

Regel: Schreibzugriffe auf die State-Variable erfolgen nur in der FSM 
selber. Lesezugriffe von anderswo sind erlaubt, besonders von anderen 
FSMs, damit die wissen, was ab geht.

[Veit D. (devil-elec)]

Hallo,

jetzt wird mir das Problem für andere Codeleser klarer. Danke.

Wegen dem Quarz, mal sehen ob ich einen Quarz habe, irgendwo muss einer 
rumliegen. Dann teste ich das nochmal.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>Wegen dem Quarz, mal sehen ob ich einen Quarz habe, irgendwo muss einer
>rumliegen. Dann teste ich das nochmal.

Quarzoszillator, das ist ein aktives Bauteil mit VCC, GND und Ausgang. 
Ein Quarz allein ist rein passiv mit 2 Anschlüssen.

[Veit D. (devil-elec)]

Hallo,

Tüte gefunden, sind 8MHz Quarze und die passenden Kondensatoren sind 
auch dabei.

Code aufgeräumt:
nur das break komplett vorrücken gefällt mir optisch nicht    :-)
Eine neue Zeile mit case ist mir für mich klar genug, zudem es farblich 
unterschiedlich dargestellt wird. Die Einrückung ist in AS noch ein TAB 
mehr, wird hier leider nicht dargestellt. Die enum Variable habe ich 
auch gleich lokal gemacht. Die Reihenfolge ist angepasst, bis auf UART, 
habe ich auf Anfang belassen, weil das der Standardzustand ist.

Die Nachrichtenlänge wird überall gleich als Konstante übergeben.

// definiere das Datenprotokoll
union Message
{
  struct
  {
    uint8_t toAddr;
    uint8_t fromAddr;
    uint8_t cmd;
    int32_t data;
    uint16_t crc;
  };
  uint8_t asArray[9];      // Summe aller struct Datentypen, für Zugriff über Index
} empfDaten, sendDaten;      // zwei gleiche union Buffer anlegen

constexpr uint8_t length_Message = sizeof(Message);

void handle_Function_UART0_Pins()
{
  static state_t state_UART_MODE = SYNC;      // Startbedingung
   
  switch (state_UART_MODE) {
    
  case UART:  // UART0 wird benutzt
        handle_Serial_0_to_Serial_0();
        if (countErrorsUART0 > 50000) {    // erstmal ne wilde Hausnummer
          state_UART_MODE = ERROR; }
      break;    // minimal 7,7µs ... maximal 18,2µs
  
  case SYNC:  // schaltet UART0 Funktionalität ab
        uart0_disable();
        Txd0Rxd0_normalPortPins();
        state_UART_MODE = WAITSYNC;
      break;
    
  case WAITSYNC:  // OSCCAL Calibration ready, dauert 85µs
        memset((void *)UART0_TxBuf, '\0', sizeof(UART0_TxBuf));  // Messwerte löschen
        memset((void *)UART0_RxBuf, '\0', sizeof(UART0_RxBuf)); //
        stop_Timer0();
        stop_Timer1();
        set_PCINT2();            // ISR(PCINT0_vect) scharf schalten
        run_Timer2();            
        state_UART_MODE = RUN;
      break;
  
  case RUN:  // Takteinmesszyklus läuft mittels ISR(PCINT0_vect)
        if (state_measurement_complete == true) {
          state_UART_MODE = CALC; }
      break;
        
  case CALC:  // OSCCAL neu berechnen
        if (Calibration_Calculation() == true) {
           state_UART_MODE = FINISH; }
        else { state_UART_MODE = REPEAT; }
        state_measurement_complete = false;    // Reset für ISR(PCINT0_vect) einmessen
      break;
        
  case REPEAT:  // Kalibrierung wiederholen
        set_PCINT2();
        countCalibration++;
        state_UART_MODE = WAITSYNC;
      break;
  
  case FINISH:  // schaltet UART0 Funktion ein
        del_PCINT2();
        run_Timer0();
        run_Timer1();
        memset((void *)UART0_TxBuf, '\0', sizeof(UART0_TxBuf));  // Messwerte löschen
        memset((void *)UART0_RxBuf, '\0', sizeof(UART0_RxBuf));
        uart0_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );
        state_UART_MODE = UART;
      break;
  
    
  case ERROR:  // Fehlerbehandlung noch nicht komplett
        // uart0_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );
        // oder 
        // state_UART_MODE = SYNC;
        state_UART_MODE = UART;
        countErrorsUART0 = 0;
      break;
        
  default:  break;
  }
}

Wenn das so näher an irgendwelchen Stil Standards ist, würde ich mich 
schon zufrieden geben. Dann würde ich die Ringbuffer Funktion angehen.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>nur das break komplett vorrücken gefällt mir optisch nicht    :-)

Naja, ist halt nicht perfekt.

>Eine neue Zeile mit case ist mir für mich klar genug, zudem es farblich
>unterschiedlich dargestellt wird. Die Einrückung ist in AS noch ein TAB
>mehr, wird hier leider nicht dargestellt.

Weil TABs immer ungünstig sind. Man sollte seinen Editio so einstellen, 
daß der immer gleich echte Leerzeichen draus macht. Oder wenigststens 
vor dem Kopieren ins einen Beitrag.

Die Nachrichtenlänge wird überall gleich als Konstante übergeben.

>constexpr uint8_t length_Message = sizeof(Message);

Was soll der High Tec Unsinn it constexpr? Braucht hier kein Mensch.
K.I.S.S.!

>  switch (state_UART_MODE) {

>  case UART:  // UART0 wird benutzt

case muss eingerückt werden.

>        handle_Serial_0_to_Serial_0();
>        if (countErrorsUART0 > 50000) {    // erstmal ne wilde Hausnummer
>          state_UART_MODE = ERROR; }

DAS ist GANZ schlechter Stil, die schließende Klammer ans Ende zu 
setzen! Das macht man nicht! Es gibt 2 wesentliche Formate, die 
allgemein akzeptiert sind. Entweder so

// Klammer auf jeweils eigener Zeile
if (bla)
{
  // yes
}
else
{
  // no
}

//Oder mein Favorit mit etwas kompakterer Schreibweise mit
//öffnender Klammer auf der gleichen Zeile wie das einleitende Statement.

if (bla) {
  // yes
} else {
  // no
}

Damit sieht man IMMMER die schließende Klammer zum öffnenen Statement in 
einer Ebene!

Alle diversen Mischformen haben wenig bis keine Akzeptanz unter echten 
Softwerkern. Das Gleiche gilt natürlich auch für andere Kontrukte wie 
for(), while() oder switch().

>  case CALC:  // OSCCAL neu berechnen
>        if (Calibration_Calculation() == true) {
>           state_UART_MODE = FINISH; }
>        else { state_UART_MODE = REPEAT; }

Wenn schon Klammern, welche prinzipiell besser sind, dann auch die 
Anweisung auf eine neue Zeile. Ist übersichlicher und leicher zu 
erweitern.

>Wenn das so näher an irgendwelchen Stil Standards ist, würde ich mich
>schon zufrieden geben.

Ist schon ganz OK.

[Veit D. (devil-elec)]

Hallo,

gut, die Klammersetzung nehme ich zurück, wollte paar Zeilen einsparen. 
Schlechter Stil, okay.

Bevor ich nun die Fuse setze für den Quarz frage ich lieber nochmal 
nach, weil das Auswahlmenü in AS für mich nicht ganz klar ist was 
gemeint ist, ich würde das blau ausgewählte nehmen. Richtig?
Quarz ist ein 8MHz, HC49.

[Falk B. (falk)]

Ext. Crystal Osz. 8.0- MHz, ganz unten auf deiner Liste.

[Joachim B. (jar)]

ich bevorzuge diesses, macht es einfach übersichtlicher

Falk B. schrieb:
> // Klammer auf jeweils eigener Zeile
> if (bla)
> {
>   // yes
> }
> else
> {
>   // no
> }

um Zeilen einzusparen geht auch

> { // yes
> }
> else
> { // no
> }

aber man sieht immer wo es beginnt und wo es endet

vor allem wenn es sowas gibt
{ // yes
  { // yes2
  }
}
else
{ // no
  { // no2
  }
}

[Veit D. (devil-elec)]

Hallo,

bist du dir sicher?
Laut der Einstellungen rückwärts geschaut sind alle 4 CKSEL Bits 
gesetzt, was laut Datenblatt für einen Quarz > 8MHz sein müßte.

Müsste ich nicht laut Datenblatt S.30 auf die Bitfolge 1101 (SUT 0) 
kommen? Das wäre dann die Auswahl über des blau markierten. Hab bammel 
...

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>Laut der Einstellungen rückwärts geschaut sind alle 4 CKSEL Bits
>gesetzt, was laut Datenblatt für einen Quarz > 8MHz sein müßte.

So kritisch ist das nicht. Ob man nun die Einstellung 3-8 MHz oder 
8-16MHz wählt.

>Müsste ich nicht laut Datenblatt S.30 auf die Bitfolge 1101 (SUT 0)
>kommen? Das wäre dann die Auswahl über des blau markierten. Hab bammel
>...

Wovor? Verfusen? Mein Gott, trag's wie ein Mann!

[Veit D. (devil-elec)]

Hallo,

is ja gut   :-)   ich ändere zum erstenmal die Fuse bezüglich der 
Taktquelle. Ansonsten hatte ich schon rumgefummelt. Es wäre Schade um 
den Aufwand falsche Takt-Fuse zu korrigieren. Das war mein Anliegen.

Gesagt getan, läuft mit reinen Timertakt astrein ohne zittern. Selbst 
mit 1µs/DIV nichts zu sehen.  :-)   Ich bau mal um und teste den 
"Servocode".

[Falk B. (falk)]

@Joachim B. (jar)

>ich bevorzuge diesses, macht es einfach übersichtlicher

Meine Meinung basiert hierauf.

Strukturierte Programmierung auf Mikrocontrollern

ftp://ftp.idsoftware.com/idstuff/doom3/source/CodeStyleConventions.doc

Wenn DIE Jungs das so machen und auch sinnvoll begründen, kann es nicht 
falsch sein. Und ich bin dann genau so cool wie die ;-)

Siehe Anhang, der Originallink ist im Moment nicht erreichbar.

[S. Landolt (Gast)]

> Mein Gott, trag's wie ein Mann!

Und das zu einem selbsternannten Teufel...
Überhaupt entbehrt der ganze Thread nicht einer gewissen Komik.

[Joachim B. (jar)]

Falk B. schrieb:
> Meine Meinung basiert hierauf.

also offen und zu Klammer in einer Spalte gefällt mir ja auch, das mit 
der offenen Klammer am Ende hat mich schon öfter aufs Glatteis geführt, 
das lehne ich weiterhin rundum ab!

wer guckt denn immer am Ende, doch nur Hunde ;)
ausserdem ist mein Monitor nicht UHD 27"

und wenn man ans Ende scrollt sieht man vorne nicht.

[Veit D. (devil-elec)]

Hallo,

ich habs jetzt so und so bleibt das jetzt. Punkt.   :-)

void handle_Function_UART0_Pins()
{
  //static state_t state_UART_MODE = SYNC;      // Startbedingung
  static state_t state_UART_MODE = FINISH;       // mit externen 8MHz Quarz
   
  switch (state_UART_MODE) {
    
  case UART:  // UART0 wird benutzt
              handle_Serial_0_to_Serial_0();
              if (countErrorsUART0 > 50000) {  // erstmal ne wilde Hausnummer
                state_UART_MODE = ERROR;
              }
      break;    // minimal 7,7µs ... maximal 18,2µs
  
  case SYNC:  // schaltet UART0 Funktionalität ab
           uart0_disable();
           Txd0Rxd0_normalPortPins();
           state_UART_MODE = WAITSYNC;
      break;
    
  case WAITSYNC:  // OSCCAL Calibration ready, dauert 85µs
           memset((void *)UART0_TxBuf, '\0', sizeof(UART0_TxBuf));  // Messwerte löschen
           memset((void *)UART0_RxBuf, '\0', sizeof(UART0_RxBuf)); //
           stop_Timer0();
           stop_Timer1();
           set_PCINT2();               // ISR(PCINT0_vect) scharf schalten
           run_Timer2();            
           state_UART_MODE = RUN;
      break;
  
  case RUN:  // Takteinmesszyklus läuft mittels ISR(PCINT0_vect)
           if (state_measurement_complete == true) {
             state_UART_MODE = CALC;
           }
      break;
        
  case CALC:  // OSCCAL neu berechnen
           if (Calibration_Calculation() == true) {
              state_UART_MODE = FINISH;
           }
           else {
              state_UART_MODE = REPEAT;
           }
           state_measurement_complete = false; // Reset für ISR(PCINT0_vect) einmessen
      break;
        
  case REPEAT:  // Kalibrierung wiederholen
           set_PCINT2();
           countCalibration++;
           state_UART_MODE = WAITSYNC;
      break;
  
  case FINISH:  // schaltet UART0 Funktion ein
           del_PCINT2();
           run_Timer0();
           run_Timer1();
           memset((void *)UART0_TxBuf, '\0', sizeof(UART0_TxBuf));  // Messwerte löschen
           memset((void *)UART0_RxBuf, '\0', sizeof(UART0_RxBuf));
           uart0_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );
           state_UART_MODE = UART;
      break;
  
    
  case ERROR:  // Fehlerbehandlung noch nicht komplett
           // uart0_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );
           // oder 
           // state_UART_MODE = SYNC;
           state_UART_MODE = UART;
           // countErrorsUART0 = 0;
      break;
        
  default:  break;
  }
}

[Veit D. (devil-elec)]

Hallo,

die Servopulse haben ein Zittern von 10µs-20µs laut Datalogger und 20µs 
laut Oszi. Egal ob uart Kabel angesteckt sind oder nicht. Das kleine 
Servo ist für mich jedoch praktisch ruhig. Das größere Servo zuckt noch 
ein klein wenig.

Laut Gehör zuckt das große Servo jedoch deutlich weniger, also fast 
nicht mehr, wenn die uart unterbrochen wird. Einen kleinen Unterschieds 
gibts laut Gehör noch.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>die Servopulse haben ein Zittern von 10µs-20µs laut Datalogger und 20µs
>laut Oszi.

Dann stimmt was nicht.

> Egal ob uart Kabel angesteckt sind oder nicht.

Dann erst recht nicht. 8-(

Hast du die letzte Änderung mit dem TXB80 Bit drin? Beim letzten Mal 
ging die ja noch nicht. Aber auch ohne diese Änderung darf ohne 
UART-Datenverkehr keine 10-20us Jitter passieren! Hast du die Fuses 
richtig gesetzt?

[Veit D. (devil-elec)]

Hallo,

das mit dem TXB80 Bit funktioniert nicht. Das ist das 9. Datenbit vom 
Frame. Ich habe kein 9. Databit. Spielt auch erste eine Geige wenn ich 
Unterschiede mit/ohne uart habe.

Ich habe nun auch die Compare A ISR rausgenommen, wird ohne uart nicht 
benötigt. An den Messungen ändert das nichts. So eine Sch ...

Fuse, was soll falsch sein, der µC läuft doch.

Morgen kürze ich den Code mal wieder radikal ein, sodass nur noch die 
Pulserzeugung stur läuft.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:

> Die Nachrichtenlänge wird überall gleich als Konstante übergeben.
>

> // definiere das Datenprotokoll
> union Message
> {
>   struct
>   {
>     uint8_t toAddr;
>     uint8_t fromAddr;
>     uint8_t cmd;
>     int32_t data;
>     uint16_t crc;
>   };
>   uint8_t asArray[9];      // Summe aller struct Datentypen, für Zugriff 
> über Index
> } empfDaten, sendDaten;      // zwei gleiche union Buffer anlegen
> 
> constexpr uint8_t length_Message = sizeof(Message);
>

An constexpr sehe ich, dass Du das ganze mit einem C++-11/14/17-Compiler 
übersetzt. War mir bislang gar nicht aufgefallen - habe aber auch nicht 
alles hier gelesen. Allerdings greifst Du dann sicher C-like in Deiner 
union auch über das nicht-aktive Member zu (das habe ich jetzt aber 
nicht in Deinem Code überprüft). Dies ist in C++ UB im Gegensatz zu C. 
Ich habe zwar wirklich noch nie bei primtiven DT in der union hier 
jemals ein Problem erlebt bei C++, aber es ist trotzdem UB und dem 
sollte man sich bewusst sein.

[Veit D. (devil-elec)]

Hallo,

ich habe die Option "-std=c++11" gesetzt.
Zu welchen Problem kann das führen mit dem nicht aktiven Member?
Das wird in der read_Ringbuffer  Funktion verwendet.

Den Code konnte ich noch kürzen, geht ja schnell. Was soll ich sagen, 
kein einziger Jitter. Obwohl der nichts anderes macht wie der komplette 
Code mit auskommentierten Funktionen.

#include <util/delay.h>
#include <avr/io.h>
#include <stdio.h>
#include <stdlib.h>
#include <avr/interrupt.h>
#include <util/atomic.h>      // für cli() und sei() mit SREG Sicherung
#include "pinDefi.h"          // eigene I/O Definitionen
#include "timer.h"         // alles was mit Timern zu tun hat ausgelagert

#define NOP __asm__ __volatile__ ("nop")

#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))   // setzt das angegebene Bit auf 1
#endif
#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))  // setzt (löscht) das angegebene Bit auf 0
#endif


int main(void)
{            
  Led1_OUT;  // Pin auf Ausgang konfigurieren
  Led2_OUT;
  Led3_OUT;
  Led4_OUT;
  Led5_OUT;
  Led6_OUT;
  // Led7_OUT;   Quarz
  // Led8_OUT;   Quarz
    
  
  preSet_Timer1();
  run_Timer1();
         
    while (1)  // Hauptprogramm
    {             
    
  }
}


/* *** Funktionen *** */
ISR(TIMER1_COMPB_vect)    // dauert 6,2µs, wird aller >1ms aufgerufen
{  
   Led1_ON;
  static uint8_t servo = 0;
  const uint8_t SERVO_CNT = 3;        // Anzahl Servos
  const uint8_t TIMING_WINDOW = 7;    // 6µs / 125ns / Prescaler 8 = 6,25 Timertakte
  static uint16_t temp = 0;
    
  switch(servo) {    // ISR Zeit 4,75µs
    // Count   999 =  1ms
    // Count  1999 =  2ms
    // Count 19999 = 20ms
    case 0: Led2_OFF;  Led5_ON;  temp =  1499; break;
      case 1: Led5_OFF;  Led6_ON;  temp =  1499; break; 
    case 2: Led6_OFF;          temp = 13999; break; // virtuelle
    case 3:           Led2_ON;  temp =  1499; break;
  }
    
  OCR1B += temp;
  OCR1A = OCR1B-TIMING_WINDOW;
  UCSR0B |= ((1<<RXCIE0) | (1<<UDRIE0));  // enable USART0 RX Complete Interrupt
                      // enable USART0 Data Register Empty Interrupt
  servo++;
  if (servo > SERVO_CNT)  servo = 0;
                      
  Led1_OFF;          
}


ISR(TIMER1_COMPA_vect)      // dauert 1,8µs
{  
  UCSR0B &= ~((1<<RXCIE0) | (1<<UDRIE0));  // disable USART0 RX Complete Interrupt
                      // disable USART0 Data Register Empty Interrupt
  Led1_ON;          // für Datalogger, debuggen
}

der Timer:

void preSet_Timer1 ()    // Normal Mode 4, Servo Pulserzeugung
{
  cli();      // Interrupts ausschalten
  TCCR1A = 0;    // Reset TCCR1A Register
  TCCR1B = 0;    // Reset TCCR1B Register
  TIMSK1 = 0;    // Reset TIMSK1 Register (disable Timer Compare Interrupts)
  TCNT1 = 0;    // Start 0
  OCR1A = 19979;  // Compare & Prescaler 8 = 20µs eher 
  OCR1B = 19999;  // Compare & Prescaler 8 = 20ms 
  TIMSK1  = (1<<OCIE1A);  // enable Compare Match A ISR
  TIMSK1 |= (1<<OCIE1B);  // enable Compare Match B ISR
  sei();          // Interrupts einschalten
}  


void run_Timer1 ()      
{
  ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {
    TCCR1B |= (1 << CS11);  // Prescaler 8, Timer starten
  }
}

[Falk B. (falk)]

@Veit Devil (devil-elec)

>das mit dem TXB80 Bit funktioniert nicht.

Mist.

>Das ist das 9. Datenbit vom
>Frame. Ich habe kein 9. Databit.

Ja eben darum kann man es für andere Dinge nutzen ;-)
Soweit die Theorie ;-)

>Spielt auch erste eine Geige wenn ich
>Unterschiede mit/ohne uart habe.

Ja.

>Ich habe nun auch die Compare A ISR rausgenommen, wird ohne uart nicht
>benötigt. An den Messungen ändert das nichts. So eine Sch ...

Du sagst es.

>Fuse, was soll falsch sein, der µC läuft doch.

Er könnte aber auch noch mit dem RC-oszillator laufen!
Die Fuses sehen aber OK aus! Quarz und beide Kondensatoren ordentlich 
kontaktiert?

>Morgen kürze ich den Code mal wieder radikal ein, sodass nur noch die
>Pulserzeugung stur läuft.

Falscher Ansatz. Für den reinen Pulstest schreibt man ein einfaches, 
extra Testprogramm und lädt das einfach. Immer dermaßen im Quelltext 
rumfuhrwerken ist nicht sinnvoll.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:

Noch eine Kleinigkeit:

>

>            memset((void *)UART0_TxBuf, '\0', sizeof(UART0_TxBuf)); 
>            memset((void *)UART0_RxBuf, '\0', sizeof(UART0_RxBuf));
>

Ich hoffe, dass an dieser Stelle z.B. UART0_TxBuf noch nicht zu einem 
Zeigertyp zerfallen (decay) ist, denn dann liefert UART0_TxBuf was 
falsches;-)

Wenn Du schon C++ nimmst, dann solltest Du für so etwas dann auch 
std::array verwenden.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>Den Code konnte ich noch kürzen, geht ja schnell. Was soll ich sagen,
>kein einziger Jitter.

Schon mal ein Ansatz. Jetzt musst du den Rest schrittweise wieder 
aktivieren.

[Falk B. (falk)]

@ Wilhelm M. (wimalopaan)

>Wenn Du schon C++ nimmst, dann solltest Du für so etwas dann auch
>std::array verwenden.

Falsch. Er sollte von C++ die Finger lassen und vernünftiges C ohne 
unsinnige Stunts programmieren! Das reicht für seine Anwendung als 
Hobbyprogrammierer vollkommen aus! Er braucht keine Sekunde C++11, 
bestenfalls C99.

[Wilhelm M. (wimalopaan)]

Falk B. schrieb:
> @ Wilhelm M. (wimalopaan)
>
>>Wenn Du schon C++ nimmst, dann solltest Du für so etwas dann auch
>>std::array verwenden.
>
> Falsch. Er sollte von C++ die Finger lassen und vernünftiges C ohne
> unsinnige Stunts programmieren! Das reicht für seine Anwendung als
> Hobbyprogrammierer vollkommen aus! Er braucht keine Sekunde C++11,
> bestenfalls C99.

Deswegen sage ich das ja!
Ich vermute, dass er constexpr nur an Stellen verwendet, wo es nicht 
notwendig ist und sonst nichts von C++ einsetzt. Dann kann er den Code 
auch einfach als C99/C11 mit einem C-Compiler übersetzen und er ist das 
UB los.

(Trotzdem ist m.E. std::array wesentlich besser rohe Arrays ...)

[Wilhelm M. (wimalopaan)]

Wilhelm M. schrieb:
> Veit D. schrieb:
>
> Noch eine Kleinigkeit:
>
>>

>>            memset((void *)UART0_TxBuf, '\0', sizeof(UART0_TxBuf));
>>            memset((void *)UART0_RxBuf, '\0', sizeof(UART0_RxBuf));
>>

>
> Ich hoffe, dass an dieser Stelle z.B. UART0_TxBuf noch nicht zu einem
> Zeigertyp zerfallen (decay) ist, denn dann liefert UART0_TxBuf was
> falsches;-)

Sorry, verschrieben: gemeint war ... dann liefert sizeof(UART0_TxBuf) 
was falsches ...

[Veit D. (devil-elec)]

Hallo,

alleine für bool benötigt man schon C++. Was ist denn an C++ nun wieder 
falsch? Ich kam auch darauf, weil ich bestimmte Berechnungen zur 
Compilerzeit erledigt habe, deswegen kenne ich constexpr. Ihr wollt mir 
das jetzt nicht verbieten?

Das Buffer löschen kann ich eigentlich rausnehmen, weil uart_init tail 
und Head sowieso gleich setzt. Meine Messwerte sollte es nicht 
verändern. Probiere ich aus. Wobei das alles keinen Einfluss haben 
sollte, uart Fehler habe ich keinen einzigen.

Hauptthema:
Habe den Kondensator an Pin 2 rausgenommen, lief immer noch. Kondensator 
an Pin 3 rausgenommen, zappelte alles, Quarz entfernt, es funktionierte 
nichts mehr, ich schlussfolgere Fuse passen.

Morgen bau ich die Funktionen Schrittweise wieder ein.

Erstmal Danke bis hier hin.

Edit:
Was meinst du mit UB?

[Falk B. (falk)]

@Veit Devil (devil-elec)

>alleine für bool benötigt man schon C++.

Keine Sekunde. C funktioniert seit über 40 Jahren ohne "echtes" bool. 
Wenn es tausende andere C-User können, kannst du das auch.

> Was ist denn an C++ nun wieder falsch?

Wer fliegen will, sollte erstmal laufen lernen. Man kann nicht mit dem 
Fliegen anfangen.
Lern erstmal SOLIDES C, dann kannst du dich VIELLEICHT mit C++ 
beschäftigen, denn das ist ein GANZ anderes Kaliber!

> Ich kam auch darauf, weil ich bestimmte Berechnungen zur
>Compilerzeit erledigt habe, deswegen kenne ich constexpr. Ihr wollt mir
>das jetzt nicht verbieten?

Doch, denn du brauchst es keine Sekunde. Das ist nur akademischer 
Unsinn.
Du hast keine hochdynamischen Datenstrukturen, nur ein triviales 
Datenpaket!

>Habe den Kondensator an Pin 2 rausgenommen, lief immer noch. Kondensator
>an Pin 3 rausgenommen, zappelte alles, Quarz entfernt, es funktionierte
>nichts mehr, ich schlussfolgere Fuse passen.

OK.

[2⁵ (Gast)]

Veit D. schrieb:
> Was meinst du mit UB?

Undefined Behavior -> 
https://de.wikipedia.org/wiki/Undefiniertes_Verhalten

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> Hallo,
>
> alleine für bool benötigt man schon C++.

Nein, hat C auch.

> Was ist denn an C++ nun wieder
> falsch? Ich kam auch darauf, weil ich bestimmte Berechnungen zur
> Compilerzeit erledigt habe, deswegen kenne ich constexpr. Ihr wollt mir
> das jetzt nicht verbieten?

Ich möchte Dir gar nichts verbieten, und bin hier ganz klar von der 
C++-Fraktion ;-)

Aber in Deinem Code, den ich aber nur sehr flüchtig angesehen habe, habe 
ich weder klassische OOP Ansätze (dyn. Polymorphie) (also eher 
Arduino-like und wie man es m.E. auf µC nicht machen sollte) noch stat. 
Polymorphie (also templates und TMP) noch eine starke Verwendung des 
Typsystems (domänenspezifische DT) gesehen. Insofern schließe ich mich 
der Vermutung von Falk an, dass vielleicht hier die Kenntnisse fehlen 
und es deswegen besser ist, sich auf C zu konzentrieren. Dies soll bitte 
keine Wertung sein ... Aber schon der Einsatz von rohen Arrays und ihren 
Problemen deuten eben darauf hin.

[Wilhelm M. (wimalopaan)]

Falk B. schrieb:

> Doch, denn du brauchst es keine Sekunde. Das ist nur akademischer
> Unsinn.

Sorry Falk: aber das ist jetzt ... Unsinn!

[Wilhelm M. (wimalopaan)]

Falk B. schrieb:
> @Veit Devil (devil-elec)
>
>>alleine für bool benötigt man schon C++.
>
> Keine Sekunde. C funktioniert seit über 40 Jahren ohne "echtes" bool.

Falsch: Seit C99 in C enthalten.

[Falk B. (falk)]

@ Wilhelm M. (wimalopaan)

>>>alleine für bool benötigt man schon C++.
>
>> Keine Sekunde. C funktioniert seit über 40 Jahren ohne "echtes" bool.

>Falsch: Seit C99 in C enthalten.

Erwischt, meine Aussage stimmt trotzdem. Es geht auch ohne echtes bool, 
wenn gleich es bisweilen etwas schwammig wird. Ich bin pragmatischer 
Hardwerker, noch Fragen? ;-)

[Joachim B. (jar)]

darüber lohnt nicht zu streiten
https://de.wikipedia.org/wiki/Varianten_der_Programmiersprache_C#C99

bool ist drin, vor 1995 wird ja heute keiner mehr Compiler hier im 
Thread nutzen (wollen)

[Falk B. (falk)]

Ein schneller Test scheint die freie Verwendbarkeit des TXB80 Bits zu 
bestätigen. Wenn es also in der Software nicht funktioniert, liegt der 
Fehler woanders.

/*
 * UART test for TXB80 bit use as software control bit
 */

 #include <util/atomic.h>
 
void setup() {
  Serial.begin(9600);
  Serial.println(F("UART TXB80 test."));
}

void loop() {

  ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
    UCSR0B ^= (1<<TXB80);   // toggle TXB80
  }
  
  Serial.print(F("TXB80 is "));
  if ( UCSR0B & (1<<TXB80) ) {
    Serial.print(F("HIGH"));
  } else {
    Serial.print(F("LOW"));
  }
  Serial.println();
  delay(500);
}

[Veit D. (devil-elec)]

Hallo,

können wir das mit C vs. C++ auf später verschieben? Sonst kämpfe ich an 
mehreren Fronten gleichzeitig. Ihr seit ja alle angemeldet und bekommt 
neue Beiträge gemeldet. Ich greife das am Ende wieder auf. Nur eine 
Frage brennt mir unter den Nägeln, memset ist doch Standard C, was soll 
da schief gehen? Mit sizeof verhindere ich auch ein schreiben ins 
Nirwarna.

Test:
habe den Timer 0 aktiviert und die Pulse zittern wieder - aber anders. 
Nicht ständig sondern alle Sekunde nach Gefühl. Mit Timer 0 habe ich mir 
einen ms und s Timer gebaut. Sekundenvariable rausgenommen. Pulse zucken 
dennoch ca. aller einer Sekunde. Wobei ich millis() noch nicht verwende, 
nur der Timer 0 läuft für sich alleine.

Ich baue den Code mal weiter zusammen, mal sehen wann es schlimmer wird 
oder der Timer 0 später noch mehr Störung verursacht. Der Timer 0 
alleine kann es nicht sein, laut meinem Gefühl.    ;-)

Auszug aus der timer.cpp

static volatile uint32_t millis_count;    // ISR Timer 0 Variable

void preSet_Timer0 ()    // millis, seconds
{
  cli();          
  TCCR0A = (1 << WGM01);      // CTC Modus
  TCCR0B = 0;
  OCR0A = 124;                // TOP, (F_CPU/PRESCALER)/1000-1
  TIMSK0 = (1 << OCIE0A);      // Compare A enable
  sei();
}


void run_Timer0 ()    // millis, seconds
{  
  ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {
    TCCR0B |= (1 << CS01) | (1 << CS00);  // Prescaler 64
  }
}


void stop_Timer0 ()    // millis, seconds
{    
  ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {              
    TCCR0B &= ~( (1<<CS02)|(1<<CS01)|(1<<CS00) );  
  }
}


ISR(TIMER0_COMPA_vect)
{  
  millis_count++;      // Zähler für Millisekunden
}


uint32_t millis()
{
  uint32_t value = 0;
  ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {
    value = millis_count;
  }
  return value;
}

[Falk B. (falk)]

@Veit Devil (devil-elec)

>können wir das mit C vs. C++ auf später verschieben? Sonst kämpfe ich an

Sicher. Hat mit dem aktuellen Problem auch gar nichts zu tun.

>Frage brennt mir unter den Nägeln, memset ist doch Standard C, was soll

Ja.

>da schief gehen?

Nix.

>habe den Timer 0 aktiviert und die Pulse zittern wieder - aber anders.

Was macht denn Timer 0? Ich dachte, der ist nur während der Kalibrierung 
aktiv?

>Nicht ständig sondern alle Sekunde nach Gefühl. Mit Timer 0 habe ich mir
>einen ms und s Timer gebaut. Sekundenvariable rausgenommen. Pulse zucken
>dennoch ca. aller einer Sekunde. Wobei ich millis() noch nicht verwende,
>nur der Timer 0 läuft für sich alleine.

Ja klar! Es müssen ALLE Interrupts außer COMPB im COMPA gesperrt werden, 
das ist ja der Trick! Daß Timer 0 da im Hintergrund noch läuft war mir 
bis jetzt nicht klar!

>Ich baue den Code mal weiter zusammen, mal sehen wann es schlimmer wird
>oder der Timer 0 später noch mehr Störung verursacht. Der Timer 0
>alleine kann es nicht sein, laut meinem Gefühl.    ;-)

FALSCH! Das hast du doch selber gerade bewiesen, denn ohne Timer 0 gibt 
es keinen Jitter.

[Carl D. (jcw2)]

Brauchst du wirklich Millisekunden oder nur etwas "in dem Bereich"?
Was ist der Bereich den du auswertest/auf den du wartest? __ms...__ms

Falls sich das irgendwie mit dem Timer1-Zyklus deckt, dann nimm Comp1A 
zum millis zählen.
BTW, wie groß ist millis? Mit 16Bit kann man bis zu 65,x Sekunden 
warten. Die 2^32/1000/60/60/24 oder 49 Tage der Arduino-Lib braucht man 
nicht wirklich.

[Wilhelm M. (wimalopaan)]

Falk B. schrieb:
> @Veit Devil (devil-elec)
>
>>können wir das mit C vs. C++ auf später verschieben? Sonst kämpfe ich an
>
> Sicher. Hat mit dem aktuellen Problem auch gar nichts zu tun.
>
>>Frage brennt mir unter den Nägeln, memset ist doch Standard C, was soll
>
> Ja.
>
>>da schief gehen?
>
> Nix.

Doch. Das kommt ganz darauf an.

Anhand des zitierten Beispiels konnte ich nicht sagen, wie / wo das 
Ziel(Array) deklariert / definiert ist.
Wenn der Compiler die vollständige Definition gesehen hat und der 
Array-Bezeichner nicht zu einem Zeiger zerfallen ist, wird die Größe 
korrekt durch sizeof() ermittelt. In diesem Fall wird also das ganze 
Array(?) genullt.

Ist es aber kein Array-Bezeichner mehr, sondern nur noch ein Zeiger 
(etwa weil Du den Array-Bezeichner als Zeiger an eine Funktion 
übergibst), so bestimmt sizeof() die Größe des Zeigers (wohl 2 Bytes auf 
einem AVR8). Dann werden nur die ersten zwei Bytes des Ziels genullt.

[Wilhelm M. (wimalopaan)]

Nur so zur Info: ich habe so einen RC-Controller mit dem 
AtMega328PB@20MHz. Der bedient einen Uart mit 115KB/VollDuplex, einen 
Uart mit 19200B/VollDuplex, eine SoftPPM mit 8-Kanälen per ISR wie bei 
Dir, eine I2C, eine OneWire, zwei HardPWM, zwei Drehzahlsensoren und 
8-AD-Kanäle. Relevant sind hier die beiden im Interrupt betriebenen 
Uarts und die SoftPPM per Timer-Interrupt. I2C läuft im Polling-Mode und 
OneWire arbeitet mit kurzen ISR-Sperren. Hard-PWM braucht keine CPU und 
die A/D-Kanäle werden gepollt.

Da habe ich 1 - 1,5 µs Jitter auf den SoftPPM-Kanälen und meine analogen 
Servos bleiben ruhig. Rechnet man linear auf 8MHz runter wären das 2,5 - 
3,75µs Jitter.

[Veit D. (devil-elec)]

Hallo,

ich nutze Timer 2 zum kalibrieren. Steht in der ISR(PCINT0_vect) drin, 
habe daran nie etwas geändert. Tut mir leid wenn das jemand nicht 
gesehen hat. Ich weiß wie schwer es ist fremden Code zu lesen.

Kurzer Umriss, ich habe mit Arduino vor paar Jahren angefangen. Beim 
nackten ATtiny möchte ohne Arduino IDE zurechtkommen. Allein schon wegen 
Speicherplatz. Deswegen Atmel Studio und die millis Funktion nachgebaut. 
Damit wollte ich später noch einen TimeOut realisieren wenn was seitens 
ATtiny schief geht. Kann ich aber wie ich sehe und ihr gesehen habt nun 
auch mit Timer 1 machen und ein 1ms Intervall benötige ich sicherlich 
auch nicht.

Auf Grund von Timer 0 habe ich den dann auch flux mit in der Timer 1 
Compare ISR getoppt und gestartet. Brachte leider noch nichts. Erst als 
ich das Timing-Window erhöht habe wurde es besser. Hatte bis jetzt immer 
7 Timercounts.
Mit 10 Counts (Led1 15µs) immer noch leichter Jitter aber mit starken 
sporadischen Ausreißern.
Ab 15 Counts (Led1 20µs) wird es besser, nur noch minimaler Jitter ohne 
Ausreißer. Eine weitere Erhöhung bringt nichts.

Erst wenn ich in der Hauptschleife die millis Abfrage auskommentiere ist 
fast absolute Jitterruhe. Ich denke ein Restjitter wird immr bleiben, 
weil das Programm ja immer ertst wohin springen muss. Oder? Kann ja 
nicht alles gleichzeitig machen.

Das Timingwindow muss doch nur soweit vorher aktiv werden, für die Zeit 
im voraus, wie alle Maßnahmen in der Timer 1 Compare A benötigen? Also 
so lange wie ein uart Byte abholen dauern würde und zusätzlich wie lange 
die Timer 0 Compare ISR benötigt. So war das doch gedacht?

Nur wird Timer 1 nicht regelmäßig aufgerufen. Das schwankt ja zwischen 
1ms und 20ms bis zur kompletten Abschaltung was ich ganz am Ende machen 
möchte. Oder ich muss gänzlich auf einen Zeitzähler verzichten. Ich 
mache erstmal das Timer 0 Aufrufintervall größer 1ms.

Aktueller Stand hängt dran.

[Wilhelm M. (wimalopaan)]

Warum ist das nicht in "usart.h"?

Zudem sind das weder Definitionen noch Initialisierungen.

// Definitionen und Initialisierungen

extern volatile uint16_t UART0_RxBuf[UART_RX_BUFFER_SIZE];
extern volatile uint16_t UART0_TxBuf[UART_TX_BUFFER_SIZE];
extern volatile uint8_t UART0_TxHead;
extern volatile uint8_t UART0_TxTail;

Zu memset(): mit den o.g. Deklarationen ist es in Ordnung, da 
UART_Tx_Buf ein Array-Bezeichner ist und bei memset() nicht zu einem 
Zeiger zerfallen ist. Trotzdem ist sowas gefährlich. Warum benutzt Du 
nicht gleich UART_RX_BUFFER_SIZE?

[Veit D. (devil-elec)]

Wir kommen der Sache jedoch schon näher, dass stimmt bestimmt nicht nur 
mich glücklich ...    :-)

[Carl D. (jcw2)]

Wilhelm M. schrieb:
>
> Ist es aber kein Array-Bezeichner mehr, sondern nur noch ein Zeiger
> (etwa weil Du den Array-Bezeichner als Zeiger an eine Funktion
> übergibst), so bestimmt sizeof() die Größe des Zeigers (wohl 2 Bytes auf
> einem AVR8). Dann werden nur die ersten zwei Bytes des Ziels genullt.

Was noch fehlt:
Würde man statt
  xy_t array[32]
schreiben
  std::array<xy_t,32> array;
dann könnte man dieses als Referenz an eine Funtion übergeben
  void func( std::array<xy_t,32>& array);
und hätte die komplette Typ-Info.

BTW, std::array macht das mit Zero-Overhead. Keine extra Daten, kein 
extra Code, kein malloc.

@Wilheml: ich benutze das bei AVR in einer eigenen 
(minimalst)Implementierung. Kennst du eine für AVR?

[Veit D. (devil-elec)]

Hallo,

@Wilhelm:
ich nutze den uart Ringbuffer mit zum kalibrieren. Damit ich keinen 2. 
Buffer anlegen muss der danach sinnlos Speicher frist. Deswegen muss ich 
die Sichtbarkeit erweitern. Die letzten beiden Zeilen nutzen wir zum 
uart ISR steuern. Eben wegen dem Jitter.

[Wilhelm M. (wimalopaan)]

Carl D. schrieb:
> Wilhelm M. schrieb:
>>
>> Ist es aber kein Array-Bezeichner mehr, sondern nur noch ein Zeiger
>> (etwa weil Du den Array-Bezeichner als Zeiger an eine Funktion
>> übergibst), so bestimmt sizeof() die Größe des Zeigers (wohl 2 Bytes auf
>> einem AVR8). Dann werden nur die ersten zwei Bytes des Ziels genullt.
>
> Was noch fehlt:
> Würde man statt
>   xy_t array[32]
> schreiben
>   std::array<xy_t,32> array;
> dann könnte man dieses als Referenz an eine Funtion übergeben
>   void func( std::array<xy_t,32>& array);
> und hätte die komplette Typ-Info.

Das hatte ich doch oben schon vorgeschlagen ...

> @Wilheml: ich benutze das bei AVR in einer eigenen
> (minimalst)Implementierung. Kennst du eine für AVR?

Ja, meine eigene ;-)

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> Hallo,
>
> @Wilhelm:
> ich nutze den uart Ringbuffer mit zum kalibrieren. Damit ich keinen 2.
> Buffer anlegen muss der danach sinnlos Speicher frist. Deswegen muss ich
> die Sichtbarkeit erweitern. Die letzten beiden Zeilen nutzen wir zum
> uart ISR steuern. Eben wegen dem Jitter.

Ja, aber man will doch die Deklaration nicht in jeder 
Implementierungsdatei wiederholen, deswegen gehört das in die 
korrespondierende Header-Datei.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>Erst wenn ich in der Hauptschleife die millis Abfrage auskommentiere ist
>fast absolute Jitterruhe.

Die Abfrage ist ein Kopieren unter ISR Sperre und das mit maximaler 
CPU-Last, wenn nix zu tun ist! Das ist Irrsinn! Und es wirkt ebenso wie 
eine ISR, sie erzeugt Jitter.

> Ich denke ein Restjitter wird immr bleiben,
>weil das Programm ja immer ertst wohin springen muss. Oder?

Oder! Wenn im normalen Programm KEINE (kurzzeitge) ISR-Sperre genutzt 
wird, wie in deiner millis() Funktion, dann wird bei einerem Interrupt 
nur der aktuelle Assemblerbefehl zu Ende ausgeführt und sofort die ISR 
ausgeführt. Der dadurch entstehende Jitter liegt bei max. 1-2 
CPU-Takten!

>Kann ja nicht alles gleichzeitig machen.

Muss es auch nicht, aber Interrupts

>Das Timingwindow muss doch nur soweit vorher aktiv werden, für die Zeit
>im voraus, wie alle Maßnahmen in der Timer 1 Compare A benötigen?

Nein, wie alle anderen ISRs im Extremfall (worst case) dauern können).

>Also
>so lange wie ein uart Byte abholen dauern würde und zusätzlich wie lange
>die Timer 0 Compare ISR benötigt. So war das doch gedacht?

Ja.

>Nur wird Timer 1 nicht regelmäßig aufgerufen. Das schwankt ja zwischen
>1ms und 20ms bis zur kompletten Abschaltung was ich ganz am Ende machen
>möchte. Oder ich muss gänzlich auf einen Zeitzähler verzichten. Ich
>mache erstmal das Timer 0 Aufrufintervall größer 1ms.

Musst du nicht, wenn du auch Timer 0 im COMPA kurz deaktiverst und in 
COMPB wieder einschaltest. Aber du mußt die unsinnige und wahnsinnige 
Kopierei mit deiner millis() Funktion rausnehmen.

[Falk B. (falk)]

>ich nutze Timer 2 zum kalibrieren. Steht in der ISR(PCINT0_vect) drin,
>habe daran nie etwas geändert. Tut mir leid wenn das jemand nicht
>gesehen hat. Ich weiß wie schwer es ist fremden Code zu lesen.

In gut strukturiertem Quelltext würde man das direkt sehen . . .

[Dieter F. (Gast)]

Falk B. schrieb:
> Der dadurch entstehende Jitter liegt bei max. 1-2 > CPU-Takten!

Sicher?

z.B. (max. Dauer)

RCALL  3
ICALL  3
RET    4
RETI   4
CPSE   1/2/3
SBRC   1/2/3
SBRS   1/2/3
SBIC   1/2/3
SBIS   1/2/3

[Veit D. (devil-elec)]

Hallo,

@ Wilhelm:
das ist doch in der uart Lib deklariert, nur muss ich ja irgendwie 
darauf zugreifen wegen der Doppelnutzung, deswegen musste ich die 
Sichtbarkeit erweitern. Ich weiß im Moment nicht worauf du hinaus 
möchtest.
kompletter Code >> Beitrag >> Datum: 29.12.2017 23:37
Beitrag "Re: ISR Code schneller machen?"

@ Falk:
Habe das Timer 0 Intervall auf 10ms erweitert. Ändert nichts.
Wie auch, millis() wird ja dennoch ständig aufgerufen. Ich weiß nicht 
wie ich sonst den aktuellen Zählerstand von millis abfragen soll? 
Irgendwie muss ich ja auf zugreifen und wegen >Byte atomar.

Habe mal vermessen.
ohne uart, keine Kabel dran, ohne ohne millis() ... 1µs Jitter
ohne uart, keine Kabel dran, mit millis() ......... 3µs Jitter
mit uart, Kabel dran, ............... 16µs Jitter, egal ob mit/ohne 
millis()

[Falk B. (falk)]

@Dieter F. (jim_quakenbush)

>> Der dadurch entstehende Jitter liegt bei max. 1-2 > CPU-Takten!

>Sicher?

Nicht ganz ;-)

>RCALL  3
>ICALL  3
>RET    4

OK, ist einer der längsten Befehle.

>RETI   4

Kann nicht durch eine ISR unterbrochen werden, es sei denn man macht 
verschachtelte Interrupts per Software.

>CPSE   1/2/3
>SBRC   1/2/3
>SBRS   1/2/3
>SBIC   1/2/3
>SBIS   1/2/3

Das sind meistens nur 1-2 Takte, weil selten eine 2-Wort Anweisung 
danach kommt.

[Dieter F. (Gast)]

Falk B. schrieb:
> Das sind meistens nur 1-2 Takte, weil selten eine 2-Wort Anweisung
> danach kommt.

Meistens <> max. - darum ging es mir :-) (und hier speziell um RET)

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>das ist doch in der uart Lib deklariert,

Aber nur lokal (static), damit man es von außen nicht sieht.

> nur muss ich ja irgendwie
>darauf zugreifen wegen der Doppelnutzung, deswegen musste ich die
>Sichtbarkeit erweitern.

Eben das static weglassen ;-)

>Habe das Timer 0 Intervall auf 10ms erweitert. Ändert nichts.
>Wie auch, millis() wird ja dennoch ständig aufgerufen.

Und warum? Was soll der Unsinn?

> Ich weiß nicht
>wie ich sonst den aktuellen Zählerstand von millis abfragen soll?

Deine "Abfrage" ist im Moment 100% sinnlos!

>Irgendwie muss ich ja auf zugreifen und wegen >Byte atomar.

Dazu muss man aber nicht STÄNDIG 32 Bit Variablen kopieren! Das macht 
man nur dann, wenn es WIRKLICH nötig ist. Ist es in deinem Programm im 
Moment nie!

Und wenn man das nur für einen Timeout braucht, zählt man den in der ISR 
runter. Dann braucht man immer nur eine direkte Abfrage im normalen 
Programm, im Idealfall direkt atomar mit nur 8 Bit. Die reichen für 
normale Timeouts locker. Dann braucht man NIRGENDWO eine ISR-Sperre und 
alles ist gut und es gibt keinen zusätzlichen Jitter.

volatile uint8_t timeout;

...

isr(timer0) {
...
  if (timeout) timeout--;
}

...

im Programm

timeout = 100;

irgendwo anders 

if (!timeout) { // timeout }

>ohne uart, keine Kabel dran, ohne ohne millis() ... 1µs Jitter

Das muss weniger sein, aber dein Logicanalyzer zeigt die Zeiten nur mit 
1us Auflösung an, dem kann man da nicht mehr vertrauen. Miss mit dem 
Oszi.

>ohne uart, keine Kabel dran, mit millis() ......... 3µs Jitter

Siehe oben, das millis() ist Unsinn.

>mit uart, Kabel dran, ............... 16µs Jitter, egal ob mit/ohne
>millis()

Weil das mit dem UDRIE im usart0_putc() noch nicht funktioniert, da mußt 
du nochmal ran. Das sollte so wie von mir skizziert eigentlich laufen. 
Wenn GAR NICHTS gesendet wird, gibt es irgendwo einen grundlegenden 
Fehler, den findet man aber. Das TXB80 ist frei verfügbar, wenn man 
nicht im 9 Bit UART-Modus arbeitet.

[Arno (Gast)]

Falk B. schrieb:
> @Veit Devil (devil-elec)
>
>>Erst wenn ich in der Hauptschleife die millis Abfrage auskommentiere ist
>>fast absolute Jitterruhe.
>
> Die Abfrage ist ein Kopieren unter ISR Sperre und das mit maximaler
> CPU-Last, wenn nix zu tun ist! Das ist Irrsinn! Und es wirkt ebenso wie
> eine ISR, sie erzeugt Jitter.

Jetzt haben wir den Übeltäter endlich :) Respekt Falk, dass du so lange 
drangeblieben bist.

Was dagegen tun?

1) millis() seltener aufrufen (so wie aktuell hast du geschätzt 2/3 der 
Zeit die Interrupts deaktiviert, kein Wunder, dass das dauernd Jittert) 
dann tritt der Jitter immerhin seltener auf
2) in millis() nicht alle Interrupts deaktivieren, sondern nur 
denjenigen, der deine >1Byte-Variable ändern kann - dann wird sich den 
Servosignal nicht mehr daran stören
3) andere Infrastruktur, z.B. im Millisekunden-Timer keine 
32Bit-Variable hochzählen, sondern ein Flag setzen oder eine 
8Bit-Variable weiterzählen und das im Hauptprogramm auswerten -> bietet 
allerdings das Risiko, dass du Millisekunden verlierst

Dass du mit uart+Kabel noch mehr Jitter erhältst - lass mich raten, in 
irgendeinem der case-Äste in handle_Function_UART0_Pins(); schaltest du 
auch für "lange" Zeit Interrupts ab? Und zwar in einem, der nur aktiv 
ist, wenn du Daten empfängst? Oder dein Receive-ISR ist "zu lang", 
länger als dein Timing-Window?

MfG, Arno

[Veit D. (devil-elec)]

Hallo,

die in main verwendeten uart Variablen sind nicht static.

in uart.cpp

volatile uint16_t UART0_TxBuf[UART_TX_BUFFER_SIZE];
volatile uint16_t UART0_RxBuf[UART_RX_BUFFER_SIZE];
volatile uint8_t UART0_TxHead;
volatile uint8_t UART0_TxTail;

in main.cpp

extern volatile uint16_t UART0_RxBuf[UART_RX_BUFFER_SIZE];
extern volatile uint16_t UART0_TxBuf[UART_TX_BUFFER_SIZE];
extern volatile uint8_t UART0_TxHead;
extern volatile uint8_t UART0_TxTail;

das andere lass ich mir durch den Kopf gehen ...

[Falk B. (falk)]

@Veit Devil (devil-elec)

>die in main verwendeten uart Variablen sind nicht static.

Ach?

>in uart.cpp
>volatile uint16_t UART0_TxBuf[UART_TX_BUFFER_SIZE];

>in main.cpp
>extern volatile uint16_t UART0_RxBuf[UART_RX_BUFFER_SIZE];

Merkt er was?

[Veit D. (devil-elec)]

Hallo,

ich sehe aktuell nicht worauf du hinaus möchtest. Man muss es doch 
extern bekannt machen.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>Man muss es doch extern bekannt machen.

Ja, aber die Deklaration von Variablen in uart.cpp gehört in uart.h, 
welche dann wo auch immer per #include eingefügt wird.

[Veit D. (devil-elec)]

Hallo,

du machst mich jetzt total irre. Wenn ich das in die uart.h verschiebe, 
dann meckert die main.cpp und uart.cpp rum. Dann geht gar nichts mehr. 
Angeblich ist alles nicht deklariert.
In main.cpp und uart.cpp ist jedoch schon immer    #include "usart.h" 
inkludiert.

Anfangs dachte ich ich hätte den Mechanismus dahinter verstanden, je 
länger der Thread dauert umso weniger verstehe ich.

In der main.cpp sind die 4 Zeilen raus und in der uart.h steht

#include <avr/pgmspace.h>

#if (__GNUC__ * 100 + __GNUC_MINOR__) < 405
#error "This library requires AVR-GCC 4.5 or later, update to newer AVR-GCC compiler !"
#endif


// module global variables

volatile uint16_t UART0_TxBuf[UART_TX_BUFFER_SIZE];
volatile uint16_t UART0_RxBuf[UART_RX_BUFFER_SIZE];
volatile uint8_t UART0_TxHead;
volatile uint8_t UART0_TxTail;
volatile uint8_t UART0_RxHead;
volatile uint8_t UART0_RxTail;
volatile uint8_t UART0_LastRxError;

[Veit D. (devil-elec)]

Hallo,

habe das erstmal wieder rückgängig gemacht und mich danach nochmal ans 
TXB80 Bit gemacht. Ich hatte übersehen das ich das auch von Hand setzen 
soll. Ich dachte die uart soll das setzen und löschen und hatte mich die 
ganze Zeit gewundert wie das funktionieren soll wenn ich das 9. Bit 
nicht nutze im Datenframe. Jetzt gehts damit.

Laut Datenlogger hat Servo 1 einen 5µs Jitter. Die anderen beiden 2µs. 
Muss ein Messfehler sein, weil laut Oszi alle gleich zucken. Alles mit 
Kommunikation aber ohne millis() Abfrage. Mit millis Abfrage zuckt es am 
Oszi wieder etwas wilder.

Jetzt mal eine grundlegende Frage. Ohne millis. Dieser Restjitter ist 
doch jetzt System bedingt oder muss der auch noch weg? Also ist das 
überhaupt möglich?

Das Timer 0 Intervall hatte ich erhöht, damit nicht aller 1ms sondern 
erst aller 10ms dessen ISR zuschlägt.

[Veit D. (devil-elec)]

Hallo,

Nachfrage

/* enable UDRE interrupt */
ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {  // wegen ISR(TIMER1_COMPA_vect)
   if (UCSR0B & (1<<TXB80)) {
      UART0_CONTROL    |= _BV(UART0_UDRIE);  // enable UDRE interrupt
      return;
   }
}

Wenn man den atomic Block mittendrin verlässt, wird dann das SREG 
Register noch richtig behandelt?

[Jan K. (jan_k)]

Veit D. schrieb:
> Hallo,
>
> du machst mich jetzt total irre. Wenn ich das in die uart.h verschiebe,
> dann meckert die main.cpp und uart.cpp rum. Dann geht gar nichts mehr.
> Angeblich ist alles nicht deklariert.
> In main.cpp und uart.cpp ist jedoch schon immer    #include "usart.h"
> inkludiert.
>
 #include "usart.h"  oder  #include "uart.h"?
> Anfangs dachte ich ich hätte den Mechanismus dahinter verstanden, je
> länger der Thread dauert umso weniger verstehe ich.
>

Auch wenn es manchmal noch anders gemacht wird, die extern Deklaration 
einer Variable kommt in den Header (foo.h oder foo.hh) des selben Moduls 
(foo.c oder foo.cpp), wo die Variable definiert wird.

[Veit D. (devil-elec)]

Hallo,

die Dateien heißen alle usart.xxx und werden auch so mit usart.h 
inkludiert, sonst hätte das noch nie funktioniert. Das war hier im 
Thread ein Tippfehler. Geläufig sagt man uart obwohl es eine usart ist.

Auch wenn ich die in der usart.h als extern volatile deklariere werden 
diese nicht gefunden.

[Veit D. (devil-elec)]

Hallo,

der aktuelle Stand ist jedenfalls der, ohne millis() Abfrage, dass die 
Servos selbst nicht zucken, auch wenn ich am Oszi das restliche zittern 
sehe mit 1µs/DIV bzw. Datalogger. Das ist schon einmal sehr sehr schön 
das mit Euch (Falk) geschafft zu haben. Vielen Dank.

Was nun mit der geänderten usart.h falsch ist weiß ich nicht. Könnt ihr 
mir da helfen?

Die millis() Funktion gehe ich an.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>TXB80 Bit gemacht. Ich hatte übersehen das ich das auch von Hand setzen
>soll.

OMG!

> Ich dachte die uart soll das setzen und löschen und hatte mich die
>ganze Zeit gewundert wie das funktionieren soll wenn ich das 9. Bit
>nicht nutze im Datenframe. Jetzt gehts damit.

AHA!

>Laut Datenlogger hat Servo 1 einen 5µs Jitter. Die anderen beiden 2µs.
>Muss ein Messfehler sein, weil laut Oszi alle gleich zucken.

Bist du sicher, daß dein Logicanalyzer immer mit voller Abtastrate von 
24 MHz arbeitet und nicht irgendwann mal auf eine geringere Rate 
runterschaltet?

> Alles mit
>Kommunikation aber ohne millis() Abfrage. Mit millis Abfrage zuckt es am
>Oszi wieder etwas wilder.

Klingt schon mal gut, wenn gleich da theoretisch noch etwas weniger 
Jitter drin sein müßte.

>Jetzt mal eine grundlegende Frage. Ohne millis. Dieser Restjitter ist
>doch jetzt System bedingt oder muss der auch noch weg?

Muss nicht, aber kann.

> Also ist das
>überhaupt möglich?

Ich meine ja. Hast du Timer 0 deaktiviert bzw. schaltest du ihn im COMPA 
kurzzeitig aus?

Man sollte auf ca. 0,5us Jitter runterkommen, das sind 4 Takte bei 8 
MHz.

>Das Timer 0 Intervall hatte ich erhöht, damit nicht aller 1ms sondern
>erst aller 10ms dessen ISR zuschlägt.

Ist weniger oft aber immer noch oft genug. Siehe oben.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>>ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {  // wegen ISR(TIMER1_COMPA_vect)
>>   if (UCSR0B & (1<<TXB80)) {
>>      UART0_CONTROL    |= _BV(UART0_UDRIE);  // enable UDRE interrupt
>>      return;
>>   }
>>}

>Wenn man den atomic Block mittendrin verlässt, wird dann das SREG
>Register noch richtig behandelt?

Ja, darum kümmern sich das Macro und diverse Compilertricks hinter 
ATOMIC_BLOCK.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>du machst mich jetzt total irre. Wenn ich das in die uart.h verschiebe,
>dann meckert die main.cpp und uart.cpp rum.

Weil irgendwelche anderen Abhängigeiten nicht passen. Aber das kann man 
korrigieren.


> Dann geht gar nichts mehr.
>Angeblich ist alles nicht deklariert.

Ist wahrscheinlich auch so.

Lange Rede, kurzer Sinn. Lad mal dein GESAMTES Projekt als Zip-File 
hoch, dann kann ich das anschauen und gerade rücken. Das alles per 
Beitrag zu kommentieren ist irgendwann ermüdend.

>Anfangs dachte ich ich hätte den Mechanismus dahinter verstanden, je
>länger der Thread dauert umso weniger verstehe ich.

;-)

Eigentlich (tm) ist es einfach. In jeder Headerdatei steht drin, was der 
Rest der Welt von der .c Datei wissen muss.

- Funktionsdeklarationen von Funktion, die von außen sicht- und nutzbar 
sein sollen
- Variablendeklarationen von Funktion, die von außen sicht- und nutzbar 
sein sollen
- #define
- Typdesfinitonen
- Inline-Funktionen mit echtem C-Code (nicht nur Deklarationen)

https://www.mikrocontroller.net/articles/FAQ#Header_File_-_wie_geht_das

[Veit D. (devil-elec)]

Hallo,

okay soweit. Timer 0 wird in Timer 1 Compare aus- und eingeschalten.
Der Datalogger wird sicherlich mit 4 Kanälen nicht mehr mit 24MHz 
abtasten.

Zurück wegen der usart.h und extern volatile

Ich halte mich aktuell genau an das Bsp., in einem c++ Forum gesehen.

in main.c
int var=5;
und in header.h
extern int var;

usart.h
nach der UART_TX_BUFFER_SIZE / UART_RX_BUFFER_SIZE  Definition

extern volatile uint16_t UART0_TxBuf[UART_TX_BUFFER_SIZE];
extern volatile uint16_t UART0_RxBuf[UART_RX_BUFFER_SIZE];
extern volatile uint8_t UART0_TxHead;
extern volatile uint8_t UART0_TxTail;

in main.cpp
[c]
volatile uint16_t UART0_TxBuf[UART_TX_BUFFER_SIZE];
volatile uint16_t UART0_RxBuf[UART_RX_BUFFER_SIZE];
volatile uint8_t UART0_TxHead;
volatile uint8_t UART0_TxTail;
/c]

>> multiple definition

Lasse ich das in main.cpp weg, so wie ihr sagt, dann ist alles komplett 
undefined reference. Ich blicke nicht mehr durch was vorne und hinten 
ist.

Ich lade das mal hoch Danke für die Unterstützung. Ich bringe es vorher 
in den Urzustand wie es bis jetzt immer funktionierte ...........

Möchtest du als Dank für die sportliche Herausforderung ein oder zwei 
ATtiny841 haben? Unbenutzt. Kann den Quarz mit reinlegen. Kann die auch 
noch auf eine Adapterplatine löten.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>    ATtiny841_MAX487_032_Slave3.zip (128 KB, 0 Downloads)

Schau ich mir gleich mal an.

>Der Datalogger wird sicherlich mit 4 Kanälen nicht mehr mit 24MHz
>abtasten.

Doch, aber nicht unbedingt bei jeder Zeitauflösung. Das machen 
Digitaloszis auch nicht.

>Ich halte mich aktuell genau an das Bsp., in einem c++ Forum gesehen.

Was zum Geier hast du immer mit deinem C++? Du kannst nicht mal richtig 
gut C.

>in main.c
>int var=5;
>und in header.h
>extern int var;

Stimmt.

>usart.h
>nach der UART_TX_BUFFER_SIZE / UART_RX_BUFFER_SIZE  Definition

>extern volatile uint16_t UART0_TxBuf[UART_TX_BUFFER_SIZE];
>extern volatile uint16_t UART0_RxBuf[UART_RX_BUFFER_SIZE];
>extern volatile uint8_t UART0_TxHead;
>extern volatile uint8_t UART0_TxTail;


>in main.cpp
>volatile uint16_t UART0_TxBuf[UART_TX_BUFFER_SIZE];
>volatile uint16_t UART0_RxBuf[UART_RX_BUFFER_SIZE];
>volatile uint8_t UART0_TxHead;
>volatile uint8_t UART0_TxTail;
>/c]

Ist Murks, weil man nicht quer durch Dateien Deklarationen schreibt.

>Lasse ich das in main.cpp weg, so wie ihr sagt, dann ist alles komplett
>undefined reference. Ich blicke nicht mehr durch was vorne und hinten
>ist.

Das wird wieder. Dauert nicht allzu lang.

>Ich lade das mal hoch Danke für die Unterstützung. Ich bringe es vorher
>in den Urzustand wie es bis jetzt immer funktionierte ...........

Gut.

>Möchtest du als Dank für die sportliche Herausforderung ein oder zwei
>ATtiny841 haben? Unbenutzt. Kann den Quarz mit reinlegen.

Mach mal. Leg noch ne Flasche Martini Bianco rein und alles wird gut ;-)

>Kann die auch noch auf eine Adapterplatine löten.

Nein, wenn dann beides getrennt. Löten kann ich im Fall der Fälle 
selber.

[Veit D. (devil-elec)]

>>Möchtest du als Dank für die sportliche Herausforderung ein oder zwei
>>ATtiny841 haben? Unbenutzt. Kann den Quarz mit reinlegen.
>
> Mach mal. Leg noch ne Flasche Martini Bianco rein und alles wird gut ;-)
>
>>Kann die auch noch auf eine Adapterplatine löten.
>
> Nein, wenn dann beides getrennt. Löten kann ich im Fall der Fälle
> selber.

Das mach ich doch glatt.  :-)   Den Rest per PN/Mail.

[Carl D. (jcw2)]

Arno schrieb:
> Falk B. schrieb:
>> @Veit Devil (devil-elec)
>>
>>>Erst wenn ich in der Hauptschleife die millis Abfrage auskommentiere ist
>>>fast absolute Jitterruhe.
>>
>> Die Abfrage ist ein Kopieren unter ISR Sperre und das mit maximaler
>> CPU-Last, wenn nix zu tun ist! Das ist Irrsinn! Und es wirkt ebenso wie
>> eine ISR, sie erzeugt Jitter.
>
> Jetzt haben wir den Übeltäter endlich :) Respekt Falk, dass du so lange
> drangeblieben bist.
.
> Was dagegen tun?
>
> 1) millis() seltener aufrufen (so wie aktuell hast du geschätzt 2/3 der
> Zeit die Interrupts deaktiviert, kein Wunder, dass das dauernd Jittert)
> dann tritt der Jitter immerhin seltener auf

Wenn millis() aufgerufen wurde und noch weiter gewartet werden soll, 
dann braucht man nicht weiter nach millis() zu fragen, sondern kann in 
IDLE Sleep gehen, denn erst beim nächsten Interrupt besteht die Chance 
daß sich millis() geändert haben könnte. Und selbst wenn viele andere 
Interrupts kommen, dann sorgt dieses Vorgehen dafür, daß mills() erst 
NACH einem Int die INT's global für kurze Zeit sperrt.

[Veit D. (devil-elec)]

Hallo,

irgendein Sleep Mode kommt nicht in Frage. Wenn ich auf einem Slave 
nicht alle freien Pins für Servos benötige, dann werden das wohl 
Eingänge werden um Sensoren abzufragen. Entweder ich frage im 
Hauptprogramm so oft es geht ab oder aller paar ms (mit millis) so wie 
es angedacht war. Eigentlich benötige ich einen globalen Zeitzähler den 
ich dann wie von Arduino gewohnt in den Funktionen lokal verarbeiten 
kann. Um damit irgendwelche Funktionen zum Bsp. aller 20 oder 30ms 
aufzurufen. Dort macht man das so. Was ja nicht dumm ist.

void update ()
{
  static unsigned long last_ms = 0;
  const byte zeit = 20;           // intervall
  
  if (millis() - last_ms > zeit) {
    last_ms = millis();
    ...
  mach was sinnvolles
  ...
  }
}

oder

void update ()
{ 
  static unsigned long last_ms = 0;
  const byte zeit = 20;           // intervall
  
  if (millis() - last_ms < zeit) return; 
  last_ms += zeit; 
  
  ...
  mach was sinnvolles
  ...
}

Ich denke erstmal über den Vorschlag von Falk nach, wie man millis 
anders macht. Wenn man hier wie aktuell verstanden jedoch nur auf ein 
Zeitintervall festgelegt ist, dann ist das auch blöd. Dann kann man 
nicht eine Funktion aller 10ms und eine andere aller 50ms aufrufen. Was 
ich mit den beiden Bsp. jedoch locker machen könnte.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> Hallo,
>
> Nachfrage
>

> /* enable UDRE interrupt */
> ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {  // wegen ISR(TIMER1_COMPA_vect)
>    if (UCSR0B & (1<<TXB80)) {
>       UART0_CONTROL    |= _BV(UART0_UDRIE);  // enable UDRE interrupt
>       return;
>    }
> }
>

>
> Wenn man den atomic Block mittendrin verlässt, wird dann das SREG
> Register noch richtig behandelt?

Wenn Du Dir das Macro anschaust (oder die Doku dazu liest) stellst Du 
fest, dass dort eine Gcc C-Extension verwendet wird, die in C etwas 
nachbildet, was in C++ ein ganz einfaches und ganz oft genutztes Idiom 
ist: RAII. Sprich: wenn der Block auf irgendeinem Weg verlassen wird, 
wird in C eine spezielle cleanup-function aufgerufen. Das erreicht man 
in C++ durch einen DTor (eines lokalen Objektes) ohne jede 
non-Standard-Spracherweiterung ;-)

[Wilhelm M. (wimalopaan)]

Falk B. schrieb:

>>in main.cpp
>>volatile uint16_t UART0_TxBuf[UART_TX_BUFFER_SIZE];
>>volatile uint16_t UART0_RxBuf[UART_RX_BUFFER_SIZE];
>>volatile uint8_t UART0_TxHead;
>>volatile uint8_t UART0_TxTail;
>>/c]
>
> Ist Murks, weil man nicht quer durch Dateien Deklarationen schreibt.

Das obige sind keine Deklarationen, sondern Definitionen. Also schlägt 
hier die ODR (one-definition-rule) zu und Du erhälst eine multiple 
definition.

Deklarieren kann man eine Entität sooft wie man will, solange alle 
Deklarationen übereinstimmen. Genau deswegen darf / sollte man das in 
Header-Dateien machen.

>>Lasse ich das in main.cpp weg, so wie ihr sagt, dann ist alles komplett
>>undefined reference. Ich blicke nicht mehr durch was vorne und hinten
>>ist.

Ist nicht nachvollziehbar.
Du solltest Dir vielleicht mal an einem Beispiel klar machen, was 
Programm-globale oder Übersetzungseinheit-globale Variable sind, wie man 
sie definiert und deklariert.

[Falk B. (falk)]

@Veit Devil (devil-elec)

So, ich hab mal deinen Code gesichtet. Ich hab kein Atmelstudio 7, nur 
6.2, d.h. ich mußte ein neues Projekt erstellen und die Quelltexte rüber 
kopieren (die Projekte sind nicht rückwärtskompatibel, naja)
Dann hab ich mal deine .cpp Endungen wieder in .c umbenannt, den mit C++ 
hat dein Projekt rein gar nichts zu tun!

Dabei kommen beim 1. Kompilieren 3 Fehler.

1. bool ist unbekannt, wird durch #include <stdbool.h> behoben
2. PCINT2 kennt er nicht, fehlt auch in iotn841.h, hab ich mal manuell 
korrigiert
3. 'Message' undeclared here (not in a function),

Das ist dein Eiertanz mit den Deklarationen. Hab ich geändert, indem ich 
sizeof(empfDaten) geschrieben habe. Denn messeage ist weder eine 
Variable noch ein Datentyp, deswegen kann sizeof nichts berechnen. Die 
restlichen, verwirrenden Details dürfen andere erklären ;-)

uart0_putc() hab ich noch ein bisschen aufgebohrt, um die kurze 
Interruptsperre zu vermeiden, wenn die "kritische Phase" zwischen COMPA 
und COMPB ISR durchlaufen wird. Sieht komisch aus (doppelt gemoppelt), 
sollte aber funktionieren und muss so gemacht werden!

In read_Ringbuffer_0() hast du die UART-Fehlercodes dezimal drin, das 
ist Unsinn. In Hex ist das besser sichtbar, welches Bit was 
signalisiert. Außerdem sind die schon in uart.h definiert, das reicht. 
Doppelt aufschreiben bringt nix, eher Fehler. Außerdem besteht der Witz 
von enums oder auch einfachen #define darin, daß man sich mit den 
kodierten Zahlen NICHT beschäftigen muss und nur mit den 
selbsterklärenden Worten arbeitet.

Wenn du Timer 0 in COMPA abschaltest, solltest du alle CSxy Bit auf 0 
setzen, damit es auch bei anderen Prescalern ohne Änderung funktioniert, 
so wie du es schon in stop_Timer0() gemacht hast.

In main hab ich am meisten aufgeräumt und sämtliche Deklarationen und 
typedefes in main.h verschoben. Die UART-Deklarationen natürlich in 
uart.h
War eigentlich unkompliziert. Schau's dir mal an.

[Arno (Gast)]

Falk B. schrieb:
> Wenn du Timer 0 in COMPA abschaltest, solltest du alle CSxy Bit auf 0
> setzen, damit es auch bei anderen Prescalern ohne Änderung funktioniert,
> so wie du es schon in stop_Timer0() gemacht hast.

Halt, der Plan war doch, da nur den IRQ abzuschalten, oder?

MfG, Arno

[Joachim B. (jar)]

#pragma once
wieder was gelernt

ich mag aber weiterhin
#ifndef usart_h
#define usart_h

weil
https://msdn.microsoft.com/de-de/library/4141z1cx.aspx
Wir empfehlen das #include-Schutz-Idiom, wenn Code für Compiler portabel 
sein muss, die die #pragma once-Richtlinie nicht implementieren, um die 
Konsistenz mit vorhandenem Code aufrechtzuerhalten

[Falk B. (falk)]

@ Arno (Gast)

>> Wenn du Timer 0 in COMPA abschaltest, solltest du alle CSxy Bit auf 0
>> setzen, damit es auch bei anderen Prescalern ohne Änderung funktioniert,
>> so wie du es schon in stop_Timer0() gemacht hast.

>Halt, der Plan war doch, da nur den IRQ abzuschalten, oder?

Stimmt, das war der Plan! Ist wohl durchgerutscht 8-0
Denn so geht der Timer 0 falsch!

[Carl D. (jcw2)]

Wenn kein sleep möglich ist, dann vielleicht das versuchen, was das 
sleep einfach sicherstellen sollte: weniger oft die Ints sperren.
Man kann in millis() auch ohne Sperre auskommen, in dem man
- zusätzlich zum Wert selber ein Bit/Byte anlegt,
- in das die ISR wenn sie am Wert gefummelt hat eine 1 reinschreibt.
 millis():
- setzt als erstes das Bit/Byte auf 0, was atomar ist,
- liest den Wert in eine temp. Variable und
- überprüft danach das "geändert" Flag
Sollte es gesetzt sein, einfach nochmal lesen. Das Flag muß dabei nicht 
mehr angesehen werden, falls man sich sicher ist, daß die diversen ISRen 
millis() nie länger als 1ms unterbrechen.
Damit wird man zuverlässig die Interruptsperren los und kann millis 
bedenkenlos in einer Warteschleife benutzen.

[Wilhelm M. (wimalopaan)]

Joachim B. schrieb:
> #pragma once
> wieder was gelernt
>
> ich mag aber weiterhin
> #ifndef usart_h
> #define usart_h
>
> weil
> https://msdn.microsoft.com/de-de/library/4141z1cx.aspx
> Wir empfehlen das #include-Schutz-Idiom, wenn Code für Compiler portabel
> sein muss, die die #pragma once-Richtlinie nicht implementieren, um die
> Konsistenz mit vorhandenem Code aufrechtzuerhalten

Die Vorteile überwiegen m.E. allerdings. Und: welcher Compiler 
unterstützt heute kein #pragma once ?

[Falk B. (falk)]

Hier die korrigierten ISRs mit der Abschaltung des Timer 0 Interrupts 
anstatt des Timers selber

ISR(TIMER1_COMPB_vect)    // dauert 6,2µs, wird aller >1ms aufgerufen
{   
    static uint8_t servo = 0;
    const uint8_t SERVO_CNT = 3;        // Anzahl Servos
    const uint8_t TIMING_WINDOW = 20;   // 1 Count = 1µs
    static uint16_t temp = 0;
    
    switch(servo) {     // ISR Zeit 4,75µs
        // Count   999 =  1ms
        // Count  1999 =  2ms
        // Count 19999 = 20ms
        case 0: Led2_OFF;   Led5_ON;    temp =  1499; break;
        case 1: Led5_OFF;   Led6_ON;    temp =  1499; break; 
        case 2: Led6_OFF;               temp = 13999; break; // virtuelle
        case 3:             Led2_ON;    temp =  1499; break;
    }
    
    OCR1B += temp;
    OCR1A = OCR1B-TIMING_WINDOW;
    // enable USART0 RX Complete Interrupt
    // enable USART0 Data Register Empty Interrupt
    UCSR0B |= ((1<<RXCIE0) | (1<<UDRIE0) | (1<<TXB80));
                                           
    TIMSK0 |= (1 << OCIE0A);        // enable Timer0 COMPA ISR
   
    servo++;
    if (servo > SERVO_CNT)  servo = 0;
                                            
    Led1_OFF;                   
}


ISR(TIMER1_COMPA_vect)          // dauert 1,8µs
{   
    TIMSK0 &= ~(1 << OCIE0A);   // disable Timer0 COMPA ISR
   
    // disable USART0 RX Complete Interrupt
    // disable USART0 Data Register Empty Interrupt
    UCSR0B &= ~((1<<RXCIE0) | (1<<UDRIE0) | (1<<TXB80));
                                  
    Led1_ON; // für Datalogger, debuggen
}

[Veit D. (devil-elec)]

Hallo,

oh ha, so muss man das also machen. Man sieht auch sofort die 
Handschrift eines richtigen Programmierers. Alles aufgeräumter. Letzte 
Code Korrektur ist auch vollzogen. Vielen vielen herzlichen Dank - Falk. 
Und alle anderen die ihre Idee eingebracht haben. Kann man nicht in 
Worte fassen was in den letzten Tagen alles mit dem Code passiert ist 
nur um den Jitter in den Griff zubekommen.

Falls jemand die ATtiny841 Definitionsdatei benötigt, hängt dran.

Jetzt muss ich natürlich fragen was der funktionale Unterschied ist 
zwischen

if ( UCSR0B & (1<<TXB80) ) {
        
      /* enable UDRE interrupt */
      ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {  // wegen ISR(TIMER1_COMPA_vect)
         if (UCSR0B & (1<<TXB80)) {
            UART0_CONTROL |= _BV(UART0_UDRIE);  // enable UDRE interrupt
            return;
         }
      }
}

und dem

if ( UCSR0B & (1<<TXB80) ) {
        
      /* enable UDRE interrupt */
      ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {  // wegen ISR(TIMER1_COMPA_vect)
          UART0_CONTROL |= _BV(UART0_UDRIE);  // enable UDRE interrupt
          return;
      }
}

für mich sieht das gleich aus.

Zum Abschluss noch ein Filmchen zur Jittermessung. Alles nur ohne millis 
Abfrage.
https://youtu.be/Y5rib4x1k60
Man beachte die Zeiteinstellung von 500ns/DIV.

Bewegt sich alles innerhalb 1µs, ganz ganz selten scheint es einen 
größeren Ausschlag zugeben. Der stört aber nicht, die Servos verhalten 
sich ruhig. Deswegen kann ich auf die Servoabschaltung verzichten, was 
ich am Anfang drin hatte. Kein zucken, kein brummen, keine 
Stromaufnahme. Der Code zur Pulserzeugung ist auch in der Hinsicht 
besser das nicht alle Servos zeitgleich Strom ziehen.

@Carl, den Timer 0 Compare müssen wir aber kurz sperren, auf alles 
andere kann verzichtet werden nach Umbau.

Wegen mehreren Zeitvergleichen habe ich auch eine Idee, brachte mich 
eure Flag Idee drauf, wenn ich zum Bsp. 3 Intervalle benötige, kann ich 
diese in die Timer 0 Comp ISR schreiben und entweder ein Flag setzen mit 
> Vergleich und nullen oder mit Modulo. Mit Modulo Vergleich benötige 
ich keine zusätzlichen Variablen, nur noch so viele Flags wie ich 
Intervalle benötige.

Zum Bsp.

ISR(TIMER0_COMPA_vect)
{  
  millis_count++;           // der ms Zähler
  
  if (millis_count % 20) {
    Flag 1 setzen ...     // für Funktion die aller 20ms aufgerufen werden soll
  }
  if (millis_count % 30) {
    Flag 2 setzen ...     // für Funktion die aller 30ms aufgerufen werden soll
  }
  if (millis_count % 40) {
    Flag 3 setzen ...     // für Funktion die aller 40ms aufgerufen werden soll
  }
}

Wäre das sinnvoll und Ressourcen schonend? In der Funktion frage ich 
dann das Flag ab ob sie ausgeführt werden soll oder nicht, wenn ja, 
setze ich das Flag zurück.

[Carl D. (jcw2)]

Veit D. schrieb:
>
> Zum Bsp.
>

> ISR(TIMER0_COMPA_vect)
> {
>   millis_count++;           // der ms Zähler
> 
>   if (millis_count % 20) {
>     Flag 1 setzen ...     // für Funktion die aller 20ms aufgerufen 
> werden soll
>   }
>   if (millis_count % 30) {
>     Flag 2 setzen ...     // für Funktion die aller 30ms aufgerufen 
> werden soll
>   }
>   if (millis_count % 40) {
>     Flag 3 setzen ...     // für Funktion die aller 40ms aufgerufen 
> werden soll
>   }
> }
>

>
> Wäre das sinnvoll und Ressourcen schonend? In der Funktion frage ich
> dann das Flag ab ob sie ausgeführt werden soll oder nicht, wenn ja,
> setze ich das Flag zurück.

vor allem: verzichte auf 16-Bit Modulo in einer ISR! das dauert!

Nochmal ein Versuch:
Wenn du nicht exakt 10/20/30 ms, sondern eher n*Größenordnung 
Timer1-Zyklus (vielleicht ist der ja auch nicht in Stein gemeißelt, dann 
das millis-Zählen am Ende des Comp1B. Da ist der Jitter-kritische Puls 
durch.

[Nico W. (nico_w)]

Dauert nicht nur. So ist sie auch falsch.
if (!(millis % 30)) ist wahrscheinlich das was gewünscht ist.

[Carl D. (jcw2)]

Nico W. schrieb:
> Dauert nicht nur. So ist sie auch falsch.
> if (!(millis % 30)) ist wahrscheinlich das was gewünscht ist.

Vermutlich doch:
Im Abstand von 30ms ein Flag setzen, denn nur dann ist der Rest einer 
Division durch 30 nicht ungleich 0.

Nur, wenn das die einzige Verwendung von millis ist, warum dann nicht 
nur alle 10ms auf 1/2/3 zählen?

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>Falls jemand die ATtiny841 Definitionsdatei benötigt, hängt dran.

Hier sind die PCINTx jetzt drin

>Jetzt muss ich natürlich fragen was der funktionale Unterschied ist
>zwischen

Ist es aber nicht, weil das spezielle Timings von ISRs berücksichtigt 
wird.

>für mich sieht das gleich aus.

Da muss man den gesamten Codeabschnitt betrachten.

Außerdem sollte man sich das Timing von COMPA und COMPB ISR vor Augen 
halten.

      -------------A-B-------------A-B-------------A-B---
TXB80 --------------__--------------__--------------__---

In der kurzen Zeit zwischen COMPA und COMPB sind alle anderen ISRs 
gesperrt und auch das normale Hauptprogramm sollte KEINE ISR-Sperren 
durchführen, um den Jitter von COMPB zu minimieren. Ebenso dürfen in der 
Zeit vom Hauptprogramm keine ISRs freigegeben werden.

void uart0_putc(uint8_t data)
{
    uint8_t tmphead;

    tmphead  = (UART0_TxHead + 1) & UART_TX_BUFFER_MASK;
    
    while ( tmphead == UART0_TxTail ){
      ;/* wait for free space in buffer */
    }
    
    UART0_TxBuf[tmphead] = data;
    UART0_TxHead = tmphead;
    
/*
Wenn hier TXB80 HIGH ist, befinden wir uns zeitlich vor der
COMPA-ISR. Eine kurze ISR-Sperre durch ATOMIC_BLOCK erzeugt keinen Jitter für COMPB.
*/        
    if ( UCSR0B & (1<<TXB80) ) {
        /* enable UDRE interrupt */
/*
Die COMPA-ISR kann aber JEDERZEIT aktiv werden, auch 1 CPU-Takt nach
dem erfolgreichen Vergleich! Also muss die endgültige Abfrage + Setzen von
UART0_UDRIE unter Interruptsperre erfolgen, damit eben nicht aus Versehen
COMPA schon aktiv wurde und UART0_UDRIE gelöscht ist!!! Wenn während der ISR-Sperre COMPA aktiv wird, wird in COMPA Jitter erzeugt, das ist aber unkritisch.
*/
        ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {  // wegen ISR(TIMER1_COMPA_vect)
            if (UCSR0B & (1<<TXB80)) {
/*
Wenn TXB80 immer noch HIGH ist, können wir UART0_UDRIE sicher löschen und die Funktion verlassen, alles palletti!
*/
                UART0_CONTROL    |= _BV(UART0_UDRIE);  // enable UDRE interrupt
                return;
            }
        }
    }    
   
/*
Hier kommen wir hin, wenn

-TXB80 beim 1. Vergleich ohne ISR-Sperre LOW war, dann befinden wir uns zeitlich zwischen COMPA und COMPB ISR. Während dieser Zeit darf keinerlei anderer Interrupt freigegeben werden, wir müssen auf das Ende von COMPB warten

-TXB80 beim 2. Vergleich mit ISR-Sperre LOW war, weil COMPA in der kurzen Zwischenzeit aktiv wurde.

Der doppelte Vergleich, einmal ohne und einmal mit ISR-Sperre wird gemacht, um keinen zusätzlichen Jitter für COMPB zu erzeugen, welche eine ISR-Sperre erzeugt. Denn wenn TXB80 schon beim 1. Vergleich LOW ist, wissen wir, daß gerade die heiße Sperrphase der Interrupts aktiv ist und wir keine ISR-Sperre durchführen dürfen. Wenn das beim 2. Vergleich passiert ist es unkritisch, denn das ist der ANFANG der Sperrphase, da ist noch genug Zeit bis zum COMPB Interrupt und es entsteht kein Jitter, denn der zeitliche Abstand TIMING_WINDOW verhindert das.
*/   
   // warte auf das Ende der ISR-Sperre
   // reiner Lesezugriff ist atomar, daher kein atomic block nötig
   while (!(UCSR0B & (1<<TXB80)));

   ATOMIC_BLOCK (ATOMIC_RESTORESTATE) {  // wegen ISR(TIMER1_COMPA_vect)
      UART0_CONTROL    |= _BV(UART0_UDRIE);  // enable UDRE interrupt
   }

} // uart_putc

>Zum Abschluss noch ein Filmchen zur Jittermessung. Alles nur ohne millis
>Abfrage.
>Youtube-Video "OpenCam 20180105 112525"
>Man beachte die Zeiteinstellung von 500ns/DIV.

>Bewegt sich alles innerhalb 1µs, ganz ganz selten scheint es einen
>größeren Ausschlag zugeben.

Super! Die Messung wird noch ein wenig besser, denn du das Nachleuchten 
im Oszi einschaltest (display persistance, da gibt es irgendwo ein 
Menu).

>eure Flag Idee drauf, wenn ich zum Bsp. 3 Intervalle benötige, kann ich
>diese in die Timer 0 Comp ISR schreiben und entweder ein Flag setzen mit
>> Vergleich und nullen oder mit Modulo.

Modulo ist aber ungünstig, denn das braucht eine echte Division und die 
ist auf einem AVR relativ langsam. Außerdem wird die meist mit einem 
Funktionsaufruf gemacht, was in einer ISR zusätzlichen Aufwand fürs 
Registersichern kostet. Zählen und Vergleichen ist deutlich schneller 
und einfacher.

>Wäre das sinnvoll und Ressourcen schonend?

Nur ohne Modulo.

>In der Funktion frage ich
>dann das Flag ab ob sie ausgeführt werden soll oder nicht, wenn ja,
>setze ich das Flag zurück.

Genau.

[Frank (Gast)]

Die Controller gibts fuer 1,60 beim Chinesen
https://learn.adafruit.com/16-channel-pwm-servo-driver/overview

[Nico W. (nico_w)]

Carl D. schrieb:
> Nico W. schrieb:
>> Dauert nicht nur. So ist sie auch falsch.
>> if (!(millis % 30)) ist wahrscheinlich das was gewünscht ist.
>
> Vermutlich doch:
> Im Abstand von 30ms ein Flag setzen, denn nur dann ist der Rest einer
> Division durch 30 nicht ungleich 0.

Denke nicht.

28 % 30 == 28 -> !(28) == 0
29 % 30 == 29 -> !(29) == 0
30 % 30 == 0  ->  !(0) == 1
31 % 30 == 1  ->  !(1) == 0

Im Interrupt könnte man sowas basteln, wenn der pro ms einmal aufgerufen 
wird:

static uint8_t counter_1ms;
static uint8_t counter_10ms;
counter_1ms++;
if (counter_1ms >= 10) {
  counter_1ms -= 10;
  flag_1ms = 1;
  counter_10ms++;
  if (counter_10ms >= 10) {
    counter_10ms = 0;
    flag_10ms = 1;
  }
}

Und irgendwo außerhalb vom ISR

for (;flag_1ms;flag_1ms=0) {
  do_stuff_1ms();
  for (;flag_10ms;flag_10ms=0) {
    do_stuff_10ms();
  }
}

[Veit D. (devil-elec)]

Hallo,

das IC kenne ich, möchte ich aber nicht.


TXB80. Danke für die Erklärung, jetzt verstehe ich das auch.

Der Module Vergleich sollte eigentlich so aussehen.   :-)

if (millis_count % 20 == 0) {
    Flag 1 setzen ...     
}

Aber ihr habt recht mit euren neuen Hinweisen. Das Timer 0 Comp 
Intervall ist nicht in Stein gemeißelt. Der Timer 0 kann ja auf das 
kleinste benötigte Intervall eingestellt werden. Und mit der Methode 
reicht ein Byte als Zähler. Größere Intervalle wie 255ms werden nicht 
benötigt. Guter Hinweis. Muss aber auch sagen, dass sind alles 
Optimierungen die ganz schön ans Eingemachte gehen. Hoffe ich versaue 
das durch spätere Programmerweiterungen nicht wieder. Wobei nicht mehr 
viel dazu kommt.

ISR(TIMER0_COMPA_vect)
{  
  static uint8_t millis_count = 0;
  static uint8_t last_1;
  static uint8_t last_2;
  static uint8_t last_3;
  
  millis_count++;           // der ms Zähler
  
  if (millis_count - last_1 > 20) {
    last_1 = millis_count;
  Flag 1 setzen ...     
  }
  if (millis_count - last_2 > 30) {
    last_2 = millis_count;
  Flag 2 setzen ...     
  }
  if (millis_count - last_3 > 40) {
    last_3 = millis_count;
  Flag 3 setzen ...     
  }
}

Oder wäre jeweils ein Vergleich auf 0 noch besser? Hatte mal wo gelesen 
das  dies noch 1-2 Takte sparen würde?

[Dieter F. (Gast)]

Dieter F. schrieb:
> Falk B. schrieb:
>> ber den Sinn und zweck derartig genauer Servopulse und 250kBaud für ne
>> Modellbahn kann man streiten. Als sportliche Herausforderung in Punkto
>> Software taugt es allemal und man kann es an anderer Stelle irgendwann
>> sinnvoll einsetzen.
>
> Ja.

Nachdem Du nun Scheibchenweise weitergekommen bist und sicher die Bilder

Beitrag "Re: ISR Code schneller machen?"

noch im Hinterkopf hast - glaubst Du immer noch an die 
Modellbahn-Version?

Sportlich würde ich eine hardwarenahe Lösung vorziehen - möglichst ohne 
Jitter (wobei das bei 08/15-Modellbau-Servos keine Rolle spielen 
dürfte). Interrupts sind eher hinderlich - obwohl es da auch 
Möglichkeiten gibt, den Jitter (ohne den MC-Jitter) weitgehend zu 
eliminieren.

Die 250 kB-Kommunikation im Hobby-Bereich kann ich nach wie vor nicht 
nachvollziehen - genau wie die Festlegung auf den ATTiny841 mit 12 Pins 
incl. Quarz und Reset - wenn auch noch Pins für Sensoren etc. geplant 
sind.

Nur mal so - am Rande ... (und z. B. Open-DCC im Blickfeld) :-)

[Falk B. (falk)]

@Frank (Gast)

>Die Controller gibts fuer 1,60 beim Chinesen
>https://learn.adafruit.com/16-channel-pwm-servo-dr...

Den Lerneffekt aber nicht.

[Dieter F. (Gast)]

Falk B. schrieb:
> Den Lerneffekt aber nicht.

Mit komplettem Link aber schon :-)

https://learn.adafruit.com/16-channel-pwm-servo-driver/overview

[Falk B. (falk)]

@Dieter F. (jim_quakenbush)

>noch im Hinterkopf hast - glaubst Du immer noch an die
>Modellbahn-Version?

Ist mir eigentlich schnuppe, MIR ging es nur um den Beweis der 
Jitterminimierung der Servosignale.

>Sportlich würde ich eine hardwarenahe Lösung vorziehen - möglichst ohne
>Jitter

Kann man machen, erfordert aber eine Hardwareänderung.

[Falk B. (falk)]

@ Dieter F. (jim_quakenbush)

>> Den Lerneffekt aber nicht.

>Mit komplettem Link aber schon :-)

>https://learn.adafruit.com/16-channel-pwm-servo-dr...

Was lernt man da? Wie man 16 Sollwert per I2C an einen IC schickt? 
C'mon!

[Dieter F. (Gast)]

Falk B. schrieb:
> Kann man machen, erfordert aber eine Hardwareänderung.

Yep - analog des zusätzlichen Quarzes ... im Cent-Bereich, wobei es im 
"Hobby-Bereich" auf 1 - 10 (oder wie auch immer) € nicht ankommen sollte 
:-)

[Dieter F. (Gast)]

Falk B. schrieb:
> Was lernt man da? Wie man 16 Sollwert per I2C an einen IC schickt?
> C'mon!

K. A. - nur Dein Link war (und ist) nicht vollständig :-)

[Dieter F. (Gast)]

Falk B. schrieb:
> Was lernt man da?

Exakt: Was man über die Arduino-Servo-Library lernen kann :-)

Nicht mein Fall und auch nicht meine Intension - aber gut abgelenkt :-)

[Dieter F. (Gast)]

Falk B. schrieb:
> Ist mir eigentlich schnuppe, MIR ging es nur um den Beweis der
> Jitterminimierung der Servosignale.

Ist der Jitter weg?

[Veit D. (devil-elec)]

Hallo,

Dieter, ich baue mir meine Steuerung genauso wie ich es möchte. Ich 
möchte eben nicht irgendwo eine riesige Zentrale mit hunderten 
Porterweiterungen stehen haben um dann von dort aus tausende Drähte 
unter der Anlage zuverlegen. Ich möchte nah vor Ort die Slaves setzen 
und kurze Wege zu dem was sie steuern oder abfragen sollen. Das ist 
modern. Warum 841er? Habe ich auch schon mehrfach erklärt. Auf der 
10x10cm Platine bekomme ich nicht mehr unter. Selbst wenn ich einen 
größeren IC nehme, fehlt mir der Platz für die zusätzlichen 
Klemmleisten. Komplett auf LED Anzeige möchte ich aber auch nicht 
verzichten. 10x10 deshalb, weil die mich bei elecrow praktisch nichts 
kosten im Vergleich zu anderen Größen. In Summe aller Kosten Nutzung 
Rechnungen ist das für mich optimal. Das macht auch kein größerer IC und 
dann weniger Platinen wieder gut. Die Platinenkosten explodieren 
förmlich und im dümmsten Fall sitzt dann irgendwo eine Platine die kaum 
genutzt wird. Nur wenige der möglichen Pins meine ich.
Ganz blöd bin ich nun auch nicht!

Die Frage "ob ich jetzt noch sicher bin ..." verstehe ich nun nicht 
wirklich. Gerade jetzt wo der Jitter weg ist bzw. so klein ist, dass er 
nicht stört. Hast du scheinbar überlesen. Das unterstelle ich dir mal im 
positiven Sinne. Denn ich unterstelle niemanden was negatives den ich 
nicht kenne.

Bei Vollbestückung kosten mich die Bauteile ca. 17,- Euro pro Platine + 
2,- Euro Platine. Die erste Bauteilbestellung bei Mouser war für 10 
Platinen ausgelegt. Für 30 Platinen ginge auf 15,- runter.

-----------------------------------------------------------------

Übrigens gehts jetzt sogar ohne Quarz. Der Code ist jetzt dermaßen 
optimiert, dass selbst der größere Jitter vom internen RC die Servos 
nicht animiert zu zucken. Wie geil ist das denn.   :-)

ATtiny841, Quarz, Jittermessung, mit nachleuchten
https://youtu.be/HxyHFqIxtho

ATtiny841, interner RC, Jittermessung, mit nachleuchten
https://youtu.be/tvNKzUWxUtY

[Dieter F. (Gast)]

Veit D. schrieb:
> Ich
> möchte eben nicht irgendwo eine riesige Zentrale mit hunderten
> Porterweiterungen stehen haben um dann von dort aus tausende Drähte
> unter der Anlage zuverlegen.

Du weisst aber schon, dass DCC eine Bus-Lösung ist?

Veit D. schrieb:
> Warum 841er? Habe ich auch schon mehrfach erklärt. Auf der
> 10x10cm Platine bekomme ich nicht mehr unter.

Mir kommen die Tränen - der Chip verliert sich auf der Prototyp-Platine.

Veit D. schrieb:
> Selbst wenn ich einen
> größeren IC nehme, fehlt mir der Platz für die zusätzlichen
> Klemmleisten.

Rundum - bei aktuell max. 10 Pins incl. Reset - da fühle ich mich leicht 
veralbert :-) bei 10 * 10 cm

Veit D. schrieb:
> In Summe aller Kosten Nutzung
> Rechnungen ist das für mich optimal.

Im Hobby-Bereich - klar.

Veit D. schrieb:
> Das macht auch kein größerer IC und
> dann weniger Platinen wieder gut. Die Platinenkosten explodieren
> förmlich und im dümmsten Fall sitzt dann irgendwo eine Platine kaum
> genutzt wird.

dto.

Veit D. schrieb:
> Bei Vollbestückung kosten mich die Bauteile ca. 17,- Euro pro Platine +
> 2,- Euro Platine. Die erste Bauteilbestellung bei Mouser war für 10
> Platinen ausgelegt. Für 30 Platinen ginge auf 15,- runter.

Hobby - klar.

Veit D. schrieb:
> Übrigens gehts jetzt sogar ohne Quarz. Der Code ist jetzt dermaßen
> optimiert, dass selbst der größere Jitter vom internen RC die Servos
> nicht animiert zu zucken. Wie geil ist das denn.   :-)

Für jemanden der große Chargen plant - Supergeil :-)

[Carl D. (jcw2)]

Nico W. schrieb:
> Carl D. schrieb:
>> Nico W. schrieb:
>>> Dauert nicht nur. So ist sie auch falsch.
>>> if (!(millis % 30)) ist wahrscheinlich das was gewünscht ist.
>>
>> Vermutlich doch:
>> Im Abstand von 30ms ein Flag setzen, denn nur dann ist der Rest einer
>> Division durch 30 nicht ungleich 0.
.
> Denke nicht.
>

> 28 % 30 == 28 -> !(28) == 0
> 29 % 30 == 29 -> !(29) == 0
> 30 % 30 == 0  ->  !(0) == 1
> 31 % 30 == 1  ->  !(1) == 0
>

Ja stimmt, irgendwo hatte ich das Ausrufezeichen gesehen, vermutlich 
weil ich das gar nicht anders erwartet hatte.

[Joachim B. (jar)]

Veit D. schrieb:
> Warum 841er? Habe ich auch schon mehrfach erklärt. Auf der
> 10x10cm Platine bekomme ich nicht mehr unter

echt jetzt?

da würde ich doch locker auch den ATmega328p sehen als DIL oder als SMD 
auch den m1284p nach Bedarf.

Kosten bei Hobby? die CPU machts da ja wohl nicht

[Falk B. (falk)]

@Veit Devil (devil-elec)

>nicht animiert zu zucken. Wie geil ist das denn.   :-)

TOP!

>ATtiny841, Quarz, Jittermessung, mit nachleuchten
>Youtube-Video "Oszi Restjittermessung mit nachleuchten"

Hier sieht man schön die diskreten Linien im Jitter, weil der Quarz sehr 
stabil ist.

>ATtiny841, interner RC, Jittermessung, mit nachleuchten
>Youtube-Video "Oszi Jitter Messung mit nachleuchten"

Beim RC-Oszillator verschwimmt alles. Trotzdem noch relativ gut.

[Dieter F. (Gast)]

Veit D. schrieb:
> Die Frage "ob ich jetzt noch sicher bin ..." verstehe ich nun nicht
> wirklich.

Übrigens habe ich nicht Dich gefragt, sonden Falk :-)

[Dieter F. (Gast)]

Falk B. schrieb:
> TOP!

Darf ich das als kostenloses Beratungs-Angebot für künftige Projekte 
verstehen?

[Falk B. (falk)]

@Dieter F. (jim_quakenbush)

>Falk B. schrieb:
>> TOP!

>Darf ich das als kostenloses Beratungs-Angebot für künftige Projekte
>verstehen?

???

Meine Kommentare hier im Forum sind für alle kostenlos, wenn gleich 
sicher nicht umsonst ;-)

[Dieter F. (Gast)]

Falk B. schrieb:
> Meine Kommentare hier im Forum sind für alle kostenlos, wenn gleich
> sicher nicht umsonst ;-)

d'accord :-) - manches Mal halt nur für Andere lukrativ ...

[Veit D. (devil-elec)]

Joachim B. schrieb:
> Veit D. schrieb:
>> Warum 841er? Habe ich auch schon mehrfach erklärt. Auf der
>> 10x10cm Platine bekomme ich nicht mehr unter
>
> echt jetzt?
>
> da würde ich doch locker auch den ATmega328p sehen als DIL oder als SMD
> auch den m1284p nach Bedarf.
>
> Kosten bei Hobby? die CPU machts da ja wohl nicht

Hallo,

bitte alles im Zusammenhang lesen und verstehen, sonst macht das alles 
keinen Sinn. Zuerst müsste mehr Platz für weitere Klemmleisten 
geschaffen werden. Hier sehe ich keine Chance. Erst wenn das möglich 
wäre, macht ein größer µC Sinn.

[Joachim B. (jar)]

Veit D. schrieb:
> bitte alles im Zusammenhang lesen und verstehen,

hatte ich, deine liegenden R  verbrauchen viel Platz, stehend würde auch 
gehen, oder gar SIL Array oder wenns seriell sein muss als DIL Arrays.
Einige KerKos könnten auch in SMD sein.
Die Jumper mit 3 Reihen könnten auch DIP switch sein?

spart alles etwas Platz

[Veit D. (devil-elec)]

Hallo,

das ändert jetzt was am Platz der Klemmleisten außen herum?

[Falk B. (falk)]

@Veit Devil (devil-elec)

>das ändert jetzt was am Platz der Klemmleisten außen herum?

Nichts. Trotzdem herrscht auf deiner Platine gähnende Leere. Wenn man 
auf moderate SMD-Bauteile umschwenkt, ist mindestens ein ATmega88/328 im 
TQFP32 Gehäuse drin. Man muss ja nicht auf 0402er Kondensatoren gehen, 
0805 geht hier auch locker. Dann bleibt immer noch Platz für ein 
Mäusefußballfeld ;-)

Deine 3x1 Jumper kann man ins normale 2,54mm Raster ohne Lücke setzen, 
spart Platz und man kann einfach eine passende 3reihige Stiftleiste 
einlöten.

Und selbst wenn man bei THT Bauteilen bleiben will ist da Platz für 
einen ATmega328 im DIL28 Gehäuse. Das kriegt man auch verdrahtet, 
schließlich hast du 2 Lagen + VIAs, das war vor 30 Jahren selbst im 
Massenkonsumerbereich purer Luxus! ;-)

[Dieter F. (Gast)]

Veit D. schrieb:
> das ändert jetzt was am Platz der Klemmleisten außen herum?

Wie viele Pins hast Du nochmal an Deinem ATTiny841?

[Carl D. (jcw2)]

Da wäre auch Platz für 2x 8-Fach-Mux um bis zu 16 Servos per HW ohne 
Softwareverränkungen jitterfrei bekommt. Aber vielleicht lernt ja die 
Version 3 etwas aus der Software V2.2

[Dieter F. (Gast)]

Carl D. schrieb:
> Da wäre auch Platz für 2x 8-Fach-Mux um bis zu 16 Servos per HW ohne
> Softwareverränkungen jitterfrei bekommt

Ja - da gibt es Beispiele.

Aber - unsportlich :-) - wobei ich das bei einem Pin mit 16 Servos und 
20 ms "Fenster" gerne sehen würde; (ein Pin bei max. 8 Servos mit max. 
2,5 ms/Servo wäre so meine Vorstellung) ...

Aber - zeig mal :-)

[Veit D. (devil-elec)]

Hallo,

aus Eurer Sicht mag die Platine leer sein, aus meiner Sicht ist die 
schon gut gefüllt. Für Leiterbahnen muss ja auch Platz sein. Und solange 
ich außen herum nicht mehr Platz habe, macht es keinen Sinn innen mehr 
Platz zu schaffen. Das sollte einleuchten. Zudem THT Bauteile auch 
Vorteile beim routen haben. Ich werde nochmal darüber nachdenken, mal 
sehen was mir noch so einfällt, vielleicht verabschiede ich mich von den 
praktischen Steckklemmleisten, nur dann wäre mehr Platz. Es ist ja nicht 
so als wenn ich das mal soeben ohne Überlegungen hingerotzt hätte. Dafür 
sieht das viel zu gut aus.  :-)
Auf der anderen Seite hatte ich auch schon angeführt, macht es keinen 
echten Sinn mehr Pins pro Slave zu haben, sonst ziehe ich wieder endlose 
Drähte unter der Anlage von A nach B.


Zurück zur Softwarethematik.
Auch auf die Gefahr hin das dieses Thema ein heißes Eisen ist.

Was war falsch daran den Code als C++ kompilieren zulassen?
C++ wird laut meiner Meinung ständig weiterentwickelt. Version C++ 18 
steht in den Startlöchern. C ist mit Version C11 irgendwie stehen 
geblieben.

Zudem ich angefangen habe das Buch "C++ Die Programmiersprache" von 
Bjarne Stroustrup zu lesen. Hier stehen sehr informative Dinge drin. 
Irgendwann möchte auch Templates usw. anwenden.

[Falk B. (falk)]

@ Veit Devil (devil-elec)

>Was war falsch daran den Code als C++ kompilieren zulassen?

Sagte ich bereits.

Beitrag "Re: ISR Code schneller machen?"

>C++ wird laut meiner Meinung ständig weiterentwickelt. Version C++ 18
>steht in den Startlöchern. C ist mit Version C11 irgendwie stehen
>geblieben.

Wenn du das "alte C" einigermaßen gut beherrscht, kannst du fast alle 
machen.

>Zudem ich angefangen habe das Buch "C++ Die Programmiersprache" von
>Bjarne Stroustrup zu lesen. Hier stehen sehr informative Dinge drin.
>Irgendwann möchte auch Templates usw. anwenden.

Auf kleinen Mikrocontrollern? Vergiss es! Du kannst dir bestenfalls in 
Arduino-Manier ein paar nette Klassen mit Vererbung und bissel 
Polymophie zusammenbastlen, das reicht locker, um sehr gute, 
leistungsfähige Programme zu entwickeln.

Die Gefahr für dich und andere Anfänger/Fortgeschritte liegt bei C++ 
schlicht im deutlich größeren Funktionsumfang sowie der deutlich 
größeren Komplexität. Da kann man sich ganz fix verheddern und 
beschäftigt sich dann nur noch mit dem Werkzeug C++ anstatt dem 
eigentlichen Problem.

Uund wie immer gilt. SOLIDE Grundlagen sind durch NICHTS zu ersetzen. 
Grundlagen lernt man aber eher mit einfachen Werkzeugen wie C und nicht 
mit C++ oder Java. Das kleine 1x1 der Mathematik lernt man auch nicht 
mit dem Smartphone, im GEGENTEIL!

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:

> Zurück zur Softwarethematik.
> Auch auf die Gefahr hin das dieses Thema ein heißes Eisen ist.

In der Tat ;-)

> Was war falsch daran den Code als C++ kompilieren zulassen?

Hatte ich bereits geschrieben: ggf. UB bei unions.

Ansonsten: m.E. nur Vorteile!

> C++ wird laut meiner Meinung ständig weiterentwickelt.

Ist wirklich so.

> Version C++ 18
> steht in den Startlöchern.

Nein. C++20. Der Release-Zyklus ist ab C++11 alle 3 Jahre.

[Dieter F. (Gast)]

Wilhelm M. schrieb:
> Nein. C++20. Der Release-Zyklus ist ab C++11 alle 3 Jahre

C steht still - seit der Steinzeit?

Nein - merkwürdig ...

https://www.gnu.org/software/gcc/releases.html

[Wilhelm M. (wimalopaan)]

Falk B. schrieb:

> Auf kleinen Mikrocontrollern? Vergiss es!

Falsch!
Richtig gemacht, d.h. eben nicht so wie Arduino, ist es definitiv 
zero-overhead.

> Du kannst dir bestenfalls in
> Arduino-Manier ein paar nette Klassen mit Vererbung und bissel
> Polymophie zusammenbastlen,

Wenn möglich sollte man dynamische Polymorphie vermeiden. Man kann 
(meistens) alles in statische Polymorphie umformen lassen, d.h mit 
Template-Meta-Programmierung. Auf die Art spart man sich V-Tables im Ram 
und zusätzliche Indirektionen.

> Die Gefahr für dich und andere Anfänger/Fortgeschritte liegt bei C++
> schlicht im deutlich größeren Funktionsumfang sowie der deutlich
> größeren Komplexität.

Was m.E. sehr wichtig ist, aber von den meisten Leuten übersehen wird, 
ist, dass es ohne Overhead möglich ist, sich ein "reiches" Typsystem zu 
schaffen, mit dem man schon zur Compile-Zeit viele Fehler ausschließen 
kann. Leider denken viele bei C++ zunächst an OOP im klassichen Sinn, 
also dyn. Polymorphie und Liskov. Das ist aber in der µC-Welt nur 
nachrangig. Viel wichtiger ist stat. Polymorphie (templates) und 
Typ-Algebren/-Systeme (Template-Meta-Programmierung). Zugegeben: das 
lernt man nicht in 21 Tagen und es weicht vom gängigen Programmierschema 
eben stark ab.

> Uund wie immer gilt. SOLIDE Grundlagen sind durch NICHTS zu ersetzen.
> Grundlagen lernt man aber eher mit einfachen Werkzeugen wie C und nicht
> mit C++ oder Java. Das kleine 1x1 der Mathematik lernt man auch nicht
> mit dem Smartphone, im GEGENTEIL!

Wer C++ wirklich lernen will, und das heißt dann neben der OOP auch 
funktionale und generische Programmierung, der sollte m.E. zunächst gar 
nicht C lernen ("stop teaching C") und er sollte nicht versuchen, C++ in 
Verbindung mit µC zu lernen. C++ Stärke ist die Abstraktionsmöglichkeit, 
da ist ein µC zunächst nur hinderlich. Das lernt man mit einer guten IDE 
am PC - und natürlich mit guten Büchern, die man allerdings auch lesen 
muss ;-)

[Dieter F. (Gast)]

Wilhelm M. schrieb:
> Was m.E. sehr wichtig ist, aber von den meisten Leuten übersehen wird,
> ist, dass es ohne Overhead möglich ist, sich ein "reiches" Typsystem zu
> schaffen, mit dem man schon zur Compile-Zeit viele Fehler ausschließen
> kann. Leider denken viele bei C++ zunächst an OOP im klassichen Sinn,
> also dyn. Polymorphie und Liskov. Das ist aber in der µC-Welt nur
> nachrangig. Viel wichtiger ist stat. Polymorphie (templates) und
> Typ-Algebren/-Systeme (Template-Meta-Programmierung). Zugegeben: das
> lernt man nicht in 21 Tagen und es weicht vom gängigen Programmierschema
> eben stark ab.

Sei mir nicht böse - aber was will ich ich auf einem (Hardare-nahen) MC 
mit C++. Polymorphie etc. Diese sind nicht unbedingt angebracht auf 
einem 8-Bit-Prozessor - oder?

[Wilhelm M. (wimalopaan)]

Dieter F. schrieb:
> Wilhelm M. schrieb:
>> Was m.E. sehr wichtig ist, aber von den meisten Leuten übersehen wird,
>> ist, dass es ohne Overhead möglich ist, sich ein "reiches" Typsystem zu
>> schaffen, mit dem man schon zur Compile-Zeit viele Fehler ausschließen
>> kann. Leider denken viele bei C++ zunächst an OOP im klassichen Sinn,
>> also dyn. Polymorphie und Liskov. Das ist aber in der µC-Welt nur
>> nachrangig. Viel wichtiger ist stat. Polymorphie (templates) und
>> Typ-Algebren/-Systeme (Template-Meta-Programmierung). Zugegeben: das
>> lernt man nicht in 21 Tagen und es weicht vom gängigen Programmierschema
>> eben stark ab.
>
> Sei mir nicht böse - aber was will ich ich auf einem (Hardare-nahen) MC
> mit C++. Polymorphie etc. Diese sind nicht unbedingt angebracht auf
> einem 8-Bit-Prozessor - oder?

Sorry, hast Du das obige gelesen ... und verstanden?

Welche Art von Polymorphie meinst Du(!) denn?

[Dieter F. (Gast)]

Wilhelm M. schrieb:
> Sorry, hast Du das obige gelesen ... und verstanden?
>
> Welche Art von Polymorphie meinst Du(!) denn?

Erkläre es bitte mal :-) - bin ich wahrscheinlich zu unbedarft ...

[Veit D. (devil-elec)]

Hallo,

>> Zurück zur Softwarethematik.
>> Auch auf die Gefahr hin das dieses Thema ein heißes Eisen ist.

> In der Tat ;-)

solange es sachlich bleibt wie bis jetzt sollten alle damit kein Problem 
haben.

Wenn in C keine Klassen mit Vererbung möglich ist, dann habe ich ein 
Problem. Denn ich habe eine Klasse mit Vererbung schon fertig. Das müßte 
ich demzufolge zurück in Funktionen "zerlegen"?

Wilhelm. Ich merke du bist C++ Programmierer. Ich lese auch daraus, dass 
C++ nur Sinn bei PC Anwendungen bringt. Da ich nur meine µC 
programmieren werde, macht da aus deiner Sicht C++ noch Sinn? Weil ich 
bin auch der Meinung das man C und C++ beim erlernen nicht mischen 
sollte. Momentan stecke ich dummerweise dazwischen ohne es richtig 
bemerkt zu haben und muss mich entscheiden um irgendwann programmieren 
zu können. Egal ob das dann C oder C++ wird.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> Hallo,
>
>>> Zurück zur Softwarethematik.
>>> Auch auf die Gefahr hin das dieses Thema ein heißes Eisen ist.
>
>> In der Tat ;-)
>
> solange es sachlich bleibt wie bis jetzt sollten alle damit kein Problem
> haben.
>
> Wenn in C keine Klassen mit Vererbung möglich ist, dann habe ich ein
> Problem. Denn ich habe eine Klasse mit Vererbung schon fertig. Das müßte
> ich demzufolge zurück in Funktionen "zerlegen"?
>
> Wilhelm. Ich merke du bist C++ Programmierer. Ich lese auch daraus, dass
> C++ nur Sinn bei PC Anwendungen bringt.

Habe ich mich oben so undeutlich ausgedrückt. C++ macht m.E. auf µC 
absolut Sinn! Ich programmieren nur in C++. Aber eben in einer 
speziellen Art - hatte ich oben kurz angerissen. Wie gesagt, der 
Schlüssel zum Erfolg liegt in stat. Polymorphie, d.h. generischer 
Programmierung mit templates. Und eine besondere Variante sind sog. 
Meta-Funktionen, die die wiederum der Template-Meta-Programmierung 
bedient.

> Da ich nur meine µC
> programmieren werde, macht da aus deiner Sicht C++ noch Sinn?

Ja.

[Dieter F. (Gast)]

Wilhelm M. schrieb:
> Habe ich mich oben so undeutlich ausgedrückt. C++ macht m.E. auf µC
> absolut Sinn! Ich programmieren nur in C++. Aber eben in einer
> speziellen Art - hatte ich oben kurz angerissen. Wie gesagt, der
> Schlüssel zum Erfolg liegt in stat. Polymorphie, d.h. generischer
> Programmierung mit templates. Und eine besondere Variante sind sog.
> Meta-Funktionen, die die wiederum der Template-Meta-Programmierung
> bedient.

Ja :-)

[Michael R. (Firma: Brainit GmbH) (fisa)]

Veit D. schrieb:
> Egal ob das dann C oder C++ wird.

Zuerst C, und dann wende dich von den stark typisierten Sprachen ab 
<duckundwegrenn>

[Falk B. (falk)]

@Wilhelm M. (wimalopaan)

>> Auf kleinen Mikrocontrollern? Vergiss es!

>Falsch!
>Richtig gemacht, d.h. eben nicht so wie Arduino, ist es definitiv
>zero-overhead.

Kann sein, weiß ich nicht, hab von C++ nicht wirklich Ahnung ;-)
Das ist aber gar nicht der Punkt.

>Wenn möglich sollte man dynamische Polymorphie vermeiden. Man kann
>(meistens) alles in statische Polymorphie umformen lassen, d.h mit
>Template-Meta-Programmierung. Auf die Art spart man sich V-Tables im Ram
>und zusätzliche Indirektionen.

Glaubst du ernsthaft, daß der OP auf DEM Level ist, um mit diesem Zeug 
was anfangen kann? Als Hobbybastler?

>> Die Gefahr für dich und andere Anfänger/Fortgeschritte liegt bei C++
>> schlicht im deutlich größeren Funktionsumfang sowie der deutlich
>> größeren Komplexität.

>Was m.E. sehr wichtig ist, aber von den meisten Leuten übersehen wird,
>ist, dass es ohne Overhead möglich ist, sich ein "reiches" Typsystem zu
>schaffen, mit dem man schon zur Compile-Zeit viele Fehler ausschließen
>kann.

Dito! Das berfordert in der Situation mehr als es hilft!

>Leider denken viele bei C++ zunächst an OOP im klassichen Sinn,
>also dyn. Polymorphie und Liskov. Das ist aber in der µC-Welt nur
>nachrangig. Viel wichtiger ist stat. Polymorphie (templates) und
>Typ-Algebren/-Systeme (Template-Meta-Programmierung). Zugegeben: das
>lernt man nicht in 21 Tagen und es weicht vom gängigen Programmierschema
>eben stark ab.

AHA!

>Wer C++ wirklich lernen will,

Will das der OP? Braucht das der OP? Nein!

>Verbindung mit µC zu lernen. C++ Stärke ist die Abstraktionsmöglichkeit,
>da ist ein µC zunächst nur hinderlich.

AHA!

> Das lernt man mit einer guten IDE
>am PC - und natürlich mit guten Büchern, die man allerdings auch lesen
>muss ;-)

Und durcharbeiten = denken!

C++ ist für die meisten uCs und Hobbybastler genauso daneben wie 
Assembler!  Assembler kann zu wenig, C++ viel zu viel!

[Falk B. (falk)]

@Veit Devil (devil-elec)

>Wenn in C keine Klassen mit Vererbung möglich ist,

In C gab es noch nie Klassen und Vererbung, nur schnöde Funktionen.

> dann habe ich ein
>Problem. Denn ich habe eine Klasse mit Vererbung schon fertig.

Wirklich? Zeig mal.

> Das müßte ich demzufolge zurück in Funktionen "zerlegen"?

Kann sein.

>sollte. Momentan stecke ich dummerweise dazwischen ohne es richtig
>bemerkt zu haben und muss mich entscheiden um irgendwann programmieren
>zu können. Egal ob das dann C oder C++ wird.

In der Tat!

[Veit D. (devil-elec)]

Hallo,

so sieht das aus. Beim programmieren stehe ich sicherlich noch am 
Anfang, dass gebe ich gern zu. Den "normalen" Encoder (nicht den für 
Alps) brauche ich mehrfach pro µC. Der Gray Code basiert auf dem von 
Peter Dannegger.

[Wilhelm M. (wimalopaan)]

Falk B. schrieb:

>>Wenn möglich sollte man dynamische Polymorphie vermeiden. Man kann
>>(meistens) alles in statische Polymorphie umformen lassen, d.h mit
>>Template-Meta-Programmierung. Auf die Art spart man sich V-Tables im Ram
>>und zusätzliche Indirektionen.
>
> Glaubst du ernsthaft, daß der OP auf DEM Level ist, um mit diesem Zeug
> was anfangen kann? Als Hobbybastler?

Nein, derzeit kann er nicht mal richtig C. Aber das ist nicht 
entscheidend: ich traue es zunächst mal jedem zu ;-)

>>Was m.E. sehr wichtig ist, aber von den meisten Leuten übersehen wird,
>>ist, dass es ohne Overhead möglich ist, sich ein "reiches" Typsystem zu
>>schaffen, mit dem man schon zur Compile-Zeit viele Fehler ausschließen
>>kann.
>
> Dito! Das berfordert in der Situation mehr als es hilft!

Und genau das ist m.E. ein Trugschluß: Programme, die nicht compilieren, 
weil sie fehlerhaft sind, sind besser als Programme, die compilieren und 
zur Laufzeit fehlerhaft sind.


>>Leider denken viele bei C++ zunächst an OOP im klassichen Sinn,
>>also dyn. Polymorphie und Liskov. Das ist aber in der µC-Welt nur
>>nachrangig. Viel wichtiger ist stat. Polymorphie (templates) und
>>Typ-Algebren/-Systeme (Template-Meta-Programmierung). Zugegeben: das
>>lernt man nicht in 21 Tagen und es weicht vom gängigen Programmierschema
>>eben stark ab.
>>Wer C++ wirklich lernen will,
>
> Will das der OP? Braucht das der OP? Nein!

Ob er es braucht, weiß ich nicht. Aber wenn er es will: warum nicht. 
Doch sollte er dabei völlig losgelöst von irgendwelchen µC 
Fragestellungen es zunächst in einer normalen Laufzeitumgebung (aka PC) 
erlernen.

>>Verbindung mit µC zu lernen. C++ Stärke ist die Abstraktionsmöglichkeit,
>>da ist ein µC zunächst nur hinderlich.
>
> AHA!

Die Betonung lag auf: zunächst! Hat man diese Möglichkeiten erst einmal 
begriffen, kann man sie sehr gewinnbringend auch auf dem µC einsetzen 
(s.o. reiches Typsystem).

>> Das lernt man mit einer guten IDE
>>am PC - und natürlich mit guten Büchern, die man allerdings auch lesen
>>muss ;-)
>
> Und durcharbeiten = denken!

Ganz genau: und die Menge der guten(!) Bücher ist sehr begrenzt.

> C++ ist für die meisten uCs und Hobbybastler genauso daneben wie
> Assembler!  Assembler kann zu wenig, C++ viel zu viel!

Ich denke, man sollte grob Assembler lesen können. Schreiben braucht man 
es m.E. nicht.

[Carl D. (jcw2)]

Dieter F. schrieb:
> Carl D. schrieb:
>> Da wäre auch Platz für 2x 8-Fach-Mux um bis zu 16 Servos per HW ohne
>> Softwareverränkungen jitterfrei bekommt
>
> Ja - da gibt es Beispiele.
>
> Aber - unsportlich :-) - wobei ich das bei einem Pin mit 16 Servos und
> 20 ms "Fenster" gerne sehen würde; (ein Pin bei max. 8 Servos mit max.
> 2,5 ms/Servo wäre so meine Vorstellung) ...
>
> Aber - zeig mal :-)

Bekanntlich hat der Timer1 2 Compare-Kanäle, deshalb auch 2x 1:8 Mux.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> Hallo,
>
> so sieht das aus. Beim programmieren stehe ich sicherlich noch am
> Anfang, dass gebe ich gern zu. Den "normalen" Encoder (nicht den für
> Alps) brauche ich mehrfach pro µC. Der Gray Code basiert auf dem von
> Peter Dannegger.

Was sind denn Deiner Ansicht nach Getter? Vllt sollte man sie besser 
Beobachter nennen (nein, ich meine nicht das Observer-Pattern). Hast 
schon mal die verschiedenen Bedeutungen von const gehört?

Möchtest Du Deine Klasse mit dyn. Polymorphie verwenden? Dann ist sie 
klassisch falsch.

Aber ich glaube, dieser Thread sollte nicht als Grundkurs C++ 
"missbraucht" werden. Vllt machst Du einen neuen auf?

[Falk B. (falk)]

@Veit Devil (devil-elec)

>    GrayEncoder.h (1,73 KB, 0 Downloads) | Codeansicht
>    GrayEncoder.cpp (1,54 KB, 0 Downloads) | Codeansicht

Soso, ein "Klasse". ;-)

Das ist un gefähr so, wie wenn ich ne Tütensuppe koche und mich dann als 
"Koch" bezeichnen würde . . .

>so sieht das aus. Beim programmieren stehe ich sicherlich noch am
>Anfang, dass gebe ich gern zu.

Eben darum ist C++ gar nichts für dich.

> Den "normalen" Encoder (nicht den für
>Alps) brauche ich mehrfach pro µC. Der Gray Code basiert auf dem von
>Peter Dannegger.

Ja und? Wo braucht man da C++? Das kriegt man mit plain, old C SPIELEND 
hin! Sogar in Mehrfachausführung!

Beitrag "Re: Mehrere Drehencoder gleichzeitig abfragen"

[Falk B. (falk)]

@Wilhelm M. (wimalopaan)

>Aber ich glaube, dieser Thread sollte nicht als Grundkurs C++
>"missbraucht" werden. Vllt machst Du einen neuen auf?

Weise Worte. Danke.

[Wilhelm M. (wimalopaan)]

Falk B. schrieb:

> Eben darum ist C++ gar nichts für dich.

Warum so abfällig?

Ich bin nur der Meinung, er sollte C++ eben nicht versuchen in µC 
Anwendungen zu erlernen (s.o.).

>> Den "normalen" Encoder (nicht den für
>>Alps) brauche ich mehrfach pro µC. Der Gray Code basiert auf dem von
>>Peter Dannegger.
>
> Ja und? Wo braucht man da C++? Das kriegt man mit plain, old C SPIELEND
> hin! Sogar in Mehrfachausführung!

Ich denke, dass weiß er. Es geht ihm um den Lerneffekt ...

[Falk B. (falk)]

@ Wilhelm M. (wimalopaan)

>> Eben darum ist C++ gar nichts für dich.

>Warum so abfällig?

Weil es so ist! Gibt man einem 3 Jährigen, der Spaß an Musik hat, ein 50 
Mann Orchester?

>Ich bin nur der Meinung, er sollte C++ eben nicht versuchen in µC
>Anwendungen zu erlernen (s.o.).

Er will aber nur uCs programmieren!

Kennst du keinen Rückwärtsgang?

>> Ja und? Wo braucht man da C++? Das kriegt man mit plain, old C SPIELEND
>> hin! Sogar in Mehrfachausführung!

>Ich denke, dass weiß er. Es geht ihm um den Lerneffekt ...

Das glaube ich nicht. Er ist verliebt in den "SchickMicki" von C++.
Ist ja auch viel cooooler und plain old C was für Doofe.
Würde ich mal so interpretieren.

[Carl D. (jcw2)]

Wilhelm M. schrieb:
> Falk B. schrieb:
>
>> Eben darum ist C++ gar nichts für dich.
>
> Warum so abfällig?
>
> Ich bin nur der Meinung, er sollte C++ eben nicht versuchen in µC
> Anwendungen zu erlernen (s.o.).
.
>>> Den "normalen" Encoder (nicht den für
>>>Alps) brauche ich mehrfach pro µC. Der Gray Code basiert auf dem von
>>>Peter Dannegger.
>>
>> Ja und? Wo braucht man da C++? Das kriegt man mit plain, old C SPIELEND
>> hin! Sogar in Mehrfachausführung!
>
> Ich denke, dass weiß er. Es geht ihm um den Lerneffekt ...

Es spricht doch nichts dagegen einfache Klassen-Hierachien zu bauen. 
Blos weil das in C noch geht, soll man es in C++ nicht machen? Wie 
sonst, wenn nicht mit einfachen Beispielen soll man Neues lernen. Was 
bei "Lernen an Kompliziertem" rauskommt, kann man hier ja lesen: 
Ablehnung.

[Falk B. (falk)]

@ Carl Drexler (jcw2)

>Es spricht doch nichts dagegen einfache Klassen-Hierachien zu bauen.
>Blos weil das in C noch geht, soll man es in C++ nicht machen?

Klassen in C? Hab ich was verpaßt?

> Wie
>sonst, wenn nicht mit einfachen Beispielen soll man Neues lernen.

Der OP sollte erstmal ein paar mehr solide Grundlagen lernen als sich 
mit "SchickiMicki" abzulenken.

> Was
>bei "Lernen an Kompliziertem" rauskommt, kann man hier ja lesen:
>Ablehnung.

Zu Recht. Lernen tut man schrittweise erstmal an einfachen Beispielen 
mit stiegendem Schwierigkeitsgrad. Man fängt in der 1.Klasse an und 
nicht beim Abitur.

[Veit D. (devil-elec)]

Hallo,

Getter Methoden sind doch Standard um irgendwelche Werte abzuholen etc.

Nur warum das obige keine Klasse sein soll verstehe ich nicht. Was ist 
"plain"? Noch nie davon gehört. Habe mal gegoogelt. Gibts in C gar 
nicht.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>ist der Fall wo klar. Nur warum das obige keine Klasse sein soll
>verstehe ich nicht.

Das ist bestenfalls ein Grundgerüst einer Klasse. Aber für die Lösung 
deiner Aufgabe, mehreren Drehgeber abzufragen braucht man das 
Werkzeug "Klasse" nicht. Ist ungefähr so wie wenn man sagt, man braucht 
unbedingt ein Smartphone mit Navi, um von Dresden nach Berlin zu fahren 
8-0

> Was ist "plain"? Noch nie davon gehört. Habe mal
>gegoogelt. Gibts in C gar nicht.

Willst du mich verarschen? "plain" ist was es im Englischen immer war. 
"einfach"

plain, old C ist einfaches, altes C. ;-)

[Dieter F. (Gast)]

C++ - Alarm!!

Ihr habt recht!

Ist O. K., wenn ihr jetzt geht ... kommt nur noch uninterressantes ... 
:-)

[Veit D. (devil-elec)]

Hallo,

Falk, sorry, ich möchte niemanden verarschen, war nur dermaßen mit all 
den C vs. C++ beschäftigt, dass ich nicht mehr unterscheiden konnte.

Naja, irgendwo hat unser C Liebhaber auch recht. Letztenendes macht 
jeder Compiler daraus Assembler bzw. dann Maschinencode. Nur sind 
Hochsprachen einfacher zu erlernen und zu lesen. Man muss sich nicht um 
jedes Bit selbst kümmern. Meine persönliche Meinung. Zudem ich schon 
soweit in C stecke, dass ich mir bestimmte Dinge nicht vorstellen kann 
wie man die in Assembler schreiben soll mit dem begrenzten Befehlssatz. 
Dabei muss man wie er schon sagte komplett anders denken, was mir jetzt 
schwer fallen würde komplett umzudenken. Zudem dass dann auch um Faktor 
x mehr Codezeilen werden, schon deshalb leidet die Lesbarkeit.

[Falk B. (falk)]

@Veit Devil (devil-elec)

>Naja, irgendwo hat unser C Liebhaber auch recht.

Hat er nicht.

> Letztenendes macht
>jeder Compiler daraus Assembler bzw. dann Maschinencode.

Darum geht es gar nicht.

> Nur sind
>Hochsprachen einfacher zu erlernen und zu lesen.

Darum schon eher! Der entscheidende Vorteil von Hochsprachen ist, daß 
sich der Compiler um viel Verwaltungskram kümmert, Speicheraufteilung, 
Variablenverwaltung, Typprüfung etc. Krümelkram, der gut automatisierbar 
ist. Durch die größere Abstraktion kann man auch viel komplexere 
Probleme viel leichter und flexibler angehen! C ist, wenn man es 
halbwegs gescheit nutzt, plattformunabhängig. Assembler nie im Leben.

> Man muss sich nicht um
>jedes Bit selbst kümmern. Meine persönliche Meinung.

Eben.

> Zudem ich schon
>soweit in C stecke, dass ich mir bestimmte Dinge nicht vorstellen kann
>wie man die in Assembler schreiben soll mit dem begrenzten Befehlssatz.

Man muss jeden Krümlkram von der Pike auf neu erfinden. Viel Spaß!

[Veit D. (devil-elec)]

Hallo,

da hier sowieso die Fronten aufeinander prallen, macht eine weitere 
Diskussion zwischen Assembler und C keinen Sinn. Ich denke jeder soll in 
der Sprache programmieren die für ihn am leichtestens erlernbar ist. Man 
hat ja freie Wahl. Ich sehe es auch nicht für schlimm an, wenn man aus 
Speichermangel einen größeren µC nimmt. Warum manche Ausführungen so arg 
knapp ausgestattet sind weiß wohl nur der Hersteller.

Für mich nehme ich mit, ich muss mich alleine zwischen C oder C++ 
entscheiden.

Ich bedanke mich bei allen für die aufschlussreiche Unterhaltung zum 
Thema Programmiersprachen. Ich werde den Thread nochmal überfliegen, 
paar Themen hatte ich bewusst zurückgestellt. Falls die noch wichtig 
sind greife ich diese auf. Ansonsten war es das erstmal aus meiner 
Sicht.

Tschau
Veit

[Veit D. (devil-elec)]

Hallo,

die letzten beiden gelöschten konnte ich nicht mehr lesen. Naja, ich 
werde es überleben. Falls die provokant gegen meine Person gerichtet 
waren, dann vielleicht besser so.

Die beiden gelöschten darüber darüber hatten wirklich keinen Grund zur 
Klage. War alles sachlich gewesen. Weiß auch nicht warum. Den letzten 
Beitrag von Dieter hätte er in dem Zuge dann mit löschen können.

Ansonsten gibts aus dem Thread wirklich viel zum mitnehmen worüber ich 
mir Gedanken machen kann und sollte. Man muss nicht immer einer Meinung 
sein, man muss nur zuhören, den anderen verstehen wollen, mitdenken, 
sachlich bleiben. Wenn das alle machen hat jeder etwas davon. Aus meiner 
Sicht ist alles i.O.

Tschau
Veit

[Np R. (samweis)]

Wilhelm M. schrieb:
> Ganz genau: und die Menge der guten(!) Bücher ist sehr begrenzt.
Ich möchte den (interessanten) Thread ja nicht hijacken, aber wenn sie 
so begrenzt ist, dann wäre doch Platz für ein oder zwei Beispiele, oder?
Oder im Wiki...

[Wilhelm M. (wimalopaan)]

np r. schrieb:
> Wilhelm M. schrieb:
>> Ganz genau: und die Menge der guten(!) Bücher ist sehr begrenzt.
> Ich möchte den (interessanten) Thread ja nicht hijacken, aber wenn sie
> so begrenzt ist, dann wäre doch Platz für ein oder zwei Beispiele, oder?
> Oder im Wiki...

Dafür erscheint es mir am besten, Du / jemand stellt eine konkrete Frage 
;-)

Und auch nicht in diesem Thread, sondern mach dazu einen eigenen auf. 
Wenn ich den Thread dann entdecke und Zeit habe, werde ich gerne 
antworten und eigene Vorschläge machen. Auf der anderen Seite gibt es 
hier ja schon einige andere Threads, in denen auch ich schon ne ganze 
Menge inkl. Beispiele gepostet habe. Vielleicht einfach mal da anfangen 
...

[Np R. (samweis)]

Wilhelm M. schrieb:
> sondern mach dazu einen eigenen auf.
Nein.
Warum nicht? Weil:
Wilhelm M. schrieb:
> Auf der anderen Seite gibt es hier ja schon einige andere Threads, in
> denen auch ich schon ne ganze Menge inkl. Beispiele gepostet habe.
jeder Thread in diesem Forum, in dem jemand nach "guten" Büchern oder 
Wegen fragt, um C++ "richtig" (tm) zu erlernen, die Gefahr birgt, in 
einen Flame-War C vs. C++ auszuarten. Und Java, Assembler oder Tofu ist 
sowieso viel besser.

Der Grund, dass ich überhaupt gefragt habe, ist dieser:
Du hast mehrfach "gute Bücher" als Notwendigkeit bezeichnet. Ohne 
irgendeines beim Namen zu nennen, ist diese "Hilfestellung" für den TO 
und alle Mitleser wertlos und nur eine "Selbstbeweihräucherung".


Edit: Wobei ich sagen muss, dass dieser Thread für dieses Forum 
überraschend friedlich und konstruktiv verlaufen ist. Kompliment!

[Carl D. (jcw2)]

np r. schrieb:
>
> Edit: Wobei ich sagen muss, dass dieser Thread für dieses Forum
> überraschend friedlich und konstruktiv verlaufen ist. Kompliment!

Es macht ja auch keinen Sinn mit bestimmten Teilnehmern diskutieren zu 
wollen, in der Zeit beschäftige ich mich lieber mit dem 
Diskussionsobjekt.

[Wilhelm M. (wimalopaan)]

np r. schrieb:
> Wilhelm M. schrieb:
>> sondern mach dazu einen eigenen auf.
> Nein.
> Warum nicht? Weil:

Ok, Deine Entscheidung.

> Wilhelm M. schrieb:
>> Auf der anderen Seite gibt es hier ja schon einige andere Threads, in
>> denen auch ich schon ne ganze Menge inkl. Beispiele gepostet habe.
> jeder Thread in diesem Forum, in dem jemand nach "guten" Büchern oder
> Wegen fragt, um C++ "richtig" (tm) zu erlernen, die Gefahr birgt, in
> einen Flame-War C vs. C++ auszuarten. Und Java, Assembler oder Tofu ist
> sowieso viel besser.

Das ist aber m.E. kein Grund, nicht trotzdem das Thema anzuschneiden. 
Ansonsten ist es ja ein Bankrotterklärung.

> Der Grund, dass ich überhaupt gefragt habe, ist dieser:
> Du hast mehrfach "gute Bücher" als Notwendigkeit bezeichnet. Ohne
> irgendeines beim Namen zu nennen, ist diese "Hilfestellung" für den TO
> und alle Mitleser wertlos und nur eine "Selbstbeweihräucherung".

Hier ist extra ein Thread zu dem Thema:

Beitrag "Informationen zu C vs C++ / aka Futter für die Diskussion"

Und hier wurde auch schon viele besprochen:

Beitrag "AVR GPIOR Bit Verwaltung C++"

Und mit ein klein bisschen Suchen findest Du hier ne ganze Menge.

Als Bücher füge ich hinzu (wenn man schon ein Grundverständnis der 
Sprache hat):

Meyers: Effective modern C++

Kormanyos: RealTime C++

Josuttis: C++ Standard Library

Vandervoorde: C++-Templates

Pohmann: C++17

Zu TMP kenne ich wirklich kein gutes Buch. Die Ideen kann man sich aber 
anhand diverser aktuelle Vorträge auf CppCon15/16/17 abholen.

[Np R. (samweis)]

Carl D. schrieb:
> Es macht ja auch keinen Sinn mit bestimmten Teilnehmern diskutieren zu
> wollen

Ohne Teilnehmer zu diskutieren kann aber sehr mühsam werden. ;-)
Wenn man ausschließlich mit Sachargumenten und nicht mit ad hominem 
diskutiert, gerät das Diskussionsobjekt auch nicht aus dem Blick.
Dann ist es auch egal, ob der Diskussionspartner C liebt oder hasst, 
Praktiker oder Hochschullehrer oder gestern 12 geworden ist.
Oder ob Veit sich nun (wie oben schon einmal anklang) gnadenlos 
bereichert hat und die Steuerung samt Software in Großserie verkauft. 
;-)

Wilhelm M. schrieb:
> Als Bücher füge ich hinzu
Danke!
Jeder Beitrag besteht ja naturgemäß in unterschiedlichen Anteilen aus 
Meinung und Information.
Hiermit hast Du Deiner Meinung die Information hinzugefügt. ;-)

[Veit D. (devil-elec)]

np r. schrieb:

> Oder ob Veit sich nun (wie oben schon einmal anklang) gnadenlos
> bereichert hat und die Steuerung samt Software in Großserie verkauft.

Solch falsche Unterstellung verbitte ich mir. Völlig egal wie diese 
gemeint sind.

[Johann L. (gjlayde)]

Falk B. schrieb:
> @Veit Devil (devil-elec)
>>  case UART:  // UART0 wird benutzt
>>        handle_Serial_0_to_Serial_0();
>>        break;  // minimal 7,7µs ... maximal 18,2µs
>
> Das break setze ich immer in die gleiche Einrückung wie das case, denn
> es ist praktisch mit einer schließenden Klammer identisch.
>

Das break ist schon ok und die Einrückung entspricht üblichen 
Coding-Rules.

Case / break ist auch keine "Klammer": Während "break" eher wie eine 
normale Anweisung agiert, ist "case" eher als Code-Label anzusehen.  Zum 
Beispiel würde die Einrückung bei bedingtem break sein:

  case XXX:
        if (cond) {
           break;
        }
        // code
        // fallthru
  case YYY:

und nicht etwa:

  case XXX:
        if (cond) {
  break;
        }
        // code
        // fallthru
  case YYY:

[Np R. (samweis)]

Veit D. schrieb:
> Solch falsche Unterstellung verbitte ich mir.

Öhm - meinst Du jetzt mich?

[Veit D. (devil-elec)]

Hallo,

als letzte öffentliche Ergänzung zum Thema zeige ich noch die verzögerte
Servopulsabschaltung. Wurde doch wieder notwendig, weil die Servos bei
leichten Gegendruck anfangen zu brummen, wollen ja gegen regeln.

Timer 1 ist auf 5ms konfiguriert. Setzt aller 5ms ein flag auf true.


das alles in die "Hauptschleife" eingebaut sieht dann so aus.

void handle_Function_UART0_Pins()
{
  //static state_usart state_USART_MODE = SYNC;      // Startbedingung
  static state_usart state_USART_MODE = FINISH;       // mit externen 8MHz Quarz
   
  switch (state_USART_MODE) {
    
  case USART:  // UART0 wird benutzt
               handle_Serial_0_to_Serial_0();
               if (countErrorsUART0 > 50000) {  // erstmal ne wilde Hausnummer
                  state_USART_MODE = ERROR;
               }
               
               turn_on_off_servos();
               if (flag_servos_updated == true) {
                  calc_ServoPositions();
                  flag_servos_updated = false;
               }
               break;

und wenn die Servos nicht abschalten sollen, dann nimmt man den
Funktionsaufruf 'turn_on_off_servos()' einfach raus. Die neue
Servoposition kommt über die serielle rein in 'servo[x].pulscount_New'