UART Problem (Assembler zu C) II

[Flo S. (tuxianer)]

hi,
ich hab mal der Übersicht halber nen neuen Zhread aufgemacht...alter: 
Beitrag "UART Programm (Umwandlung von Assembler zu C)"

ich hatte die Platine jetzt mal am PC. Und wenn ich 15 (Hexa) sende 
kommt nix
einmal hatte der µC "D3" gesendet, aber das war wohl nen Fehler...also
irgendwie reagiert er nicht auf den Interrupt.


noch was. Gleich am Anfang wird ja Receive1 aufgerufen:

int Receive0(void)
{
while (!ucUDR_valid)
{
}
ucUDR_valid = 0;
return ucUDR;
}

und dort hängt es ja die ganze Zeit fest, bis ein Interrupt ausgelöst
wurde. Das finde ich etwas ungünstig, da ich ja mit 2 Geräten an den µC
senden möchte.


Im Anhang nochmal der C Code

[Flo S. (tuxianer)]

Und hier der ASM

[Flo S. (tuxianer)]

ich kann das Programm leider auch nicht simulieren, da ich noch nix 
derartiges für einen Mac gefunden habe.

[Stefan B. (stefan)]

> Gleich am Anfang wird ja Receive1 [korr. Receive0] aufgerufen und
> dort hängt es ja die ganze Zeit fest, bis ein Interrupt ausgelöst wurde.

Genau, Receive0 wartet, bis ein Zeichen empfangen wurde. Das ist in 
deinem ASM-Code eigentlich genauso.

> Das finde ich etwas ungünstig, da ich ja mit 2 Geräten an den µC
> senden möchte.

Dann prüfe doch vor dem Aufruf von Receive0, ob ein Zeichen empfangen 
wurde.

Speck das Programm soweit ab, bis nur die reine Kommunikation auf UART0 
getestet werden kann. Ein einfaches ECHO-Programm wäre z.B.

#include <avr/io.h>
#include <avr/interrupt.h>
#include <inttypes.h>
#include <util/delay.h>

#define BAUD 9600L                // Baudrate, das L am Ende ist wichtig, NICHT UL verwenden!

#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)   // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))     // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD-1000) // Fehler in Promille

int temp, Data, Count, activevar1, activevar0, i;
int Header[50];
int Content[16];
volatile unsigned char ucUDR = 0;        // 1 Byte Puffer
volatile unsigned char ucUDR_valid = 0;  // Puffer gefuellt oder leer?
volatile unsigned int uiVerloreneZeichen;

#ifdef STEFB
#define USART0_RXC_vect  USART_RXC_vect
#define UCSR0A    UCSRA
#define UCSR0B    UCSRB
#define UCSR0C    UCSRC
#define UDRE0    UDRE
#define UDR0    UDR
#define URSEL0    URSEL
#define USBS0    USBS
#define UCSZ10    UCSZ1
#define UCSZ00    UCSZ0
#define RXCIE0    RXCIE
#define RXEN0    RXEN
#define TXEN0    TXEN
#define UBRR0H    UBRRH 
#define UBRR0L    UBRRL 
#endif

ISR(USART0_RXC_vect)
{
  if (ucUDR_valid)
  {
     uiVerloreneZeichen++;
     // Die Auswertung dieser Zahl kann spaeter helfen, wenn man den
     // 1 Byte Puffer in einen Mehrbyte-Puffer nach dem FIFO Prinzip
     // umruesten will. Damit kann man eine Abschaetzung der guenstigen
     // Puffergroesse vornehmen.
  }

  ucUDR = UDR0;
  ucUDR_valid = 1;
  // Nicht mehr!
}

#ifndef STEFB
ISR(USART1_RXC_vect)
{
  // Derzeit unbenutzt.
  // Muss aber vorhanden sein, weil dieser Interrupt in main()
  // aktiviert wird
}
#endif

int Receive0(void)
{
  while (!ucUDR_valid)
  {
  }
  ucUDR_valid = 0;
  return ucUDR;
}

void Transmit0(int Senden) {
  //Senderoutine UART0

  //WARTESCHLEIFE!!!!!!!
  _delay_ms(4.35);

  //Warten bis gesendet werden kann
  while (!(UCSR0A & (1<<UDRE0)))
  {
  }

  UDR0 = Senden;
}

int main (void) {

  //Baudrate 9k6
  UBRR0H = UBRR_VAL >> 8;
  UBRR0L = UBRR_VAL & 0xFF;

#ifndef STEFB
  UBRR1H = UBRR_VAL >> 8;
  UBRR1L = UBRR_VAL & 0xFF;
#endif

  //Uebertragungsart
#ifndef STEFB
  UCSR1C |= (1<<URSEL1)|(1<<USBS1)|(1<<UCSZ11)|(1<<UCSZ01);
#endif
  UCSR0C |= (1<<URSEL0)|(1<<USBS0)|(1<<UCSZ10)|(1<<UCSZ00);

  //Interrupts, Senden und Empfangen aktivieren
#ifndef STEFB
  UCSR1B |= (1<<RXCIE1)|(1<<RXEN1)|(1<<TXEN1);
#endif
  UCSR0B |= (1<<RXCIE0)|(1<<RXEN0)|(1<<TXEN0);

  sei();

  while(1)
  {
    if (ucUDR_valid)     // Laut ISR Zeichen an UART0 da?
    {
       unsigned char c;
       c = Receive0();   // ja! Dann holen...
       Transmit0(c);     // ...und als Echo zurueck
#if 0
       // Option: plus Debuginfo zurueck
       Transmit0(uiVerloreneZeichen >> 8);
       Transmit0(uiVerloreneZeichen & 0xFF);
#endif
    }
  }

}

Ich habe mir das mit dem Makro STEFB etwas zurecht gemacht, weil ich 
keinen Atmega162 zum Testen habe. Ich habe es auf einem Atmega32 (hat 
nur ein UART) @ 13,560 MHz laufen lassen. Da drauf läuft es bei 
Terminaleinstellung 9600,8N2

[Flo S. (tuxianer)]

Ich hab grad auch noch was geschrieben für 2 Geräte...nur leider kommt 
bei der While Schleife nen Fehler (expectet ")" before "or")

[Flo S. (tuxianer)]

Anhang:

[Stefan B. (stefan)]

   
      while(!(ucUDR_valid0 OR ucUDR_valid1))

OR ;-)

Das logische ODER ist in C ein ||

Solange in nicht (UART0 gültig oder UART1 gültig) Däumchendrehen. Das 
ist auf Deutsch solange UART0 ungültig und UART1 ungültig.

Das ist zwar OK, aber ein unötiger Bugfix für den folgenden vermurksten 
if-Fall ;-)

Wenn (if) UART0 gültig dann
  prüfe UART0 auf 0x15, ...
andernfalls (else)
  prüfe UART1 auf 0x15, ...

Ich würde eher diese Programmstruktur als logisch ansehen:

Wenn UART0 gültig dann
  prüfe UART0 auf 0x15, ...

Wenn UART1 gültig dann
  prüfe UART1 auf 0x15, ...

Ansonsten im Rest steckt ein Schlampifehler:

   
      ucUDR1 = 0;
      
      if(ucUDR1 == 0x15)

[Flo S. (tuxianer)]

Oh sorry hab mich schon gewundert, warum das nicht blau wurde im Editor 
^^. Jo der Fehler ist blöd...das muss einfach nen valid dahinter!

[Flo S. (tuxianer)]

gehen tuts leider immer noch nicht...es kommt sofort, wenn ich was sende 
nen Error...irgendwie erkennt der den Interrupt nicht oder irgendwas 
geht da schief...wie gesagt ich kann leider nicht emulieren...

[Flo S. (tuxianer)]

noch was beim Ersten mal senden Kommt der Error sofort...beim 2. Mal 
dauert es länger. D.h. beim ersten mal bekommt er schon irgendwie ne 
Antwort aber irgendwas ist falsch. Und beim 2. mal hängt er irgendwo und 
reagiert gar nicht mehr...

[Stefan B. (stefan)]

Sorry, da kann ich dir nicht helfen. Ich kann dir nur den Tipp geben, 
mit einem PC das Echo Programm vom µC zu testen.

Was passiert, wenn du den Casio an den PC anhängst und in einem 
Terminalprogramm für die serielle Schnittstelle die µC Seite von Hand 
emulierst?

> ich kann das Programm leider auch nicht simulieren, da ich noch nix
> derartiges für einen Mac gefunden habe.

Du hast keinen PC sondern einen Mac? Welchen? Hat der eine RS232 
serielle Schnittstelle? Dafür gibt es Programme...

http://homepage.mac.com/dalverson/zterm/
http://www.furrysoft.de/?page=goserial

Tipp: 0x06 ist CONTROL-E
http://www.cs.tut.fi/~jkorpela/chars/c0.html

[Flo S. (tuxianer)]

Nein ich hab keine Serielle Schnittstelle. Also Rechner an PC ist nicht 
wirklich interessant...da weis ich ja wie es funktioniert und was 
passiert. Den µC hatte ich ja auch schon mal am Rechner (anderer PC). 
Und wenn ich da 0x15 gesendet habe ist nix passiert bei der ASM Variante 
schon. Also kann es eigentlich nur was formales am Code sein.

[Flo S. (tuxianer)]

ich hab jetzt mla zum Debuggen 2 Pins auf high gesetzt an verschiedenen 
Stellen...

  while(1){
  
    while(!(ucUDR_valid0 || ucUDR_valid1))
    {
    }
    PORTA = 0x03; 
    
    if(ucUDR_valid0 == 1)
    {

der Port wird high, auch wenn ich noch gar nix gesendet habe. Da muss 
doch nen AND hin oder?

[Flo S. (tuxianer)]

so ich hab den Fehler jetzt schonmal eingegrenzt...

int Receive0(void)
{


  while (!ucUDR_valid0)
  {
  }
  ucUDR_valid0 = 0;
  return ucUDR0;
}

wenn ich den Port nach cdUDR_valid0 = 0; auf high setze wird er high...

        // Header Rrecieve 0
        for (Count=0; Count < 50; Count++) 
        {
          //Header speichern
          Header0[Count] = Receive0();
        }
        
        PORTA = 0x03;

hinter diese schleife kommt er nicht mehr. Also hängt es da drinn!


Das: sbis UCSR0A, RXC habe ich doch noch gar nicht umgesetzt oder 
geschieht das automatisch durch den Interrupt?

[Flo S. (tuxianer)]

es muss was beim Empfangen schiefgehen...der Controller geht zu schnell 
kann eigentlich nicht sein in ASM gehts auch ohne Wait...oder wie gesagt 
der µC wartet nicht, bis das byte empfangen wurde und der Rechner bricht 
dann ab...und er hängt in der Schleife fest und wartet darauf, das etwas 
gesendet wird...

[Stefan B. (stefan)]

> in ASM gehts auch ohne Wait...

Der Vergleich mit dem ASM-Programm nervt mich inzwischen etwas. Dann 
beschäftige dich mit deinem ASM-Programm. Ich versuche keinesfalls den 
kruden Mix aus Interrupt-Betrieb und Polling-Betrieb mit 
Kreuzundquersprüngen in einem so toll kommentierten ASM-Listing 
aufzudröseln. Ich helfe aber gerne die grundlegende Umsetzung auf einen 
sauberen Interruptbetrieb in C-Code zu zeigen (weil das etwas ist, was 
auch mich im Lernstoff "UART und Interrupts" weiter bringt). Wenn du 
damit Probleme hast, sag's und ich nerve dich nicht weiter.

Das "Hängen in der Schleife" ist in der derzeitigen C-Version fast 
unausweichlich. Ein Minimal-1-Byte-Puffer ist prädestiniert für 
verlorene Zeichen. Ich hatte dir eine Variable eingebaut, wo du prüfen 
kannst, ob Zeichen verloren gehen.

Da wie beschrieben Receive0() wartet bis ein Zeichen da ist und weil 
dein for() unbedingt 50 Zeichen für den Header haben will, hängt dein 
Programm, wenn der Casio keine 50 Zeichen sendet und/oder Zeichen 
verloren gegangen sind.

Ich kann auch gerne eine Variante aufzeigen, mit einem grösseren Puffer. 
Oder eine Variante mit einem Zähler für die empfangenen Zeichen. Hast du 
am kompletten PORTA Debug-LEDs (8 Stück?), so dass man da eine Zahl 
0..255 (verlorene Zeichen oder empfangene Zeichen) ausgeben kann?

[Flo S. (tuxianer)]

Es tut mir ja leid mit dem ASM Vergleich, aber an irgend etwas muss ich 
mich ja orientieren. In C habe ich wie gesagt noch nicht soviel Praxis 
Erfahrung. Ich habe an PortA gar keine LED's leider ist das teil wie 
gesagt schon auf einer Platine. Ich habe aber mit einem Multimeter 
nachgemessen. Du kannst mir ja mal bitte deine Variante geben. Ich mess 
dann einfach den Kompletten Port durch.

[Karl H. (kbuchegg)]

Florentin S. wrote:
> Es tut mir ja leid mit dem ASM Vergleich, aber an irgend etwas muss ich
> mich ja orientieren.

Ja. Du sollst dir aus dem Assembler Code rausholen, welche
Bytes in welcher Reihenfolge daherkommen. Eventuell kann
man aus dem Assembler Code auch noch die Auswertung studieren
und rausfinden was in welchem Fall gemacht werden muss.

Aber ansonsten: Vergiss den Assembler Code und setzte eine
ordentliche C Struktur auf.

Blöd ist natürlich, dass du keine vernünftigen Debug-
Möglichkeiten hast. Ein paar LED an einem Port sind
nicht wirklich ein Ersatz um die Kommunikation zu
überprüfen.

Ich würde mal folgendes machen:
Ein minimal UART Programm aufsetzen, das Interrupt getrieben
ist und beim Empfang eines Zeichens einen Port Pin auf
High (oder Low) setzt. Um das Handling zu vereinfachen einfach
mal mit ein paar Drähten eine Led (samt Vorwiderstand) an
besagtem Port Pin anlöten (wenn deine Platine schon soweit
fertig ist, dass du keine Led mehr einbauen kannst. Welcher
Teufel hat dich eigentlich geritten eine fertige Platine zu
machen, noch bevor ein Testaufbau auf einem Steckbrett oder
auf Streifenraster die grundsätzliche Funktionsweise nachgewiesen
hat).

Warteschleifen sind Mist!
Du willst sie nicht haben. Die einzige Warte/Endlosschleife ist
die Schleife in main.

....

ISR(USART0_RXC_vect)
{
  if (ucUDR_valid)
  {
     uiVerloreneZeichen++;
     // Die Auswertung dieser Zahl kann spaeter helfen, wenn man den
     // 1 Byte Puffer in einen Mehrbyte-Puffer nach dem FIFO Prinzip
     // umruesten will. Damit kann man eine Abschaetzung der guenstigen
     // Puffergroesse vornehmen.
  }

  ucUDR = UDR0;
  ucUDR_valid = 1;
  // Nicht mehr!
}

int main()
{
  ...

  sei();

  while( 1 ) {    // dies ist die einzige Schleife, die auf etwas
                  // wartet. Sie wartet auf Arbeit

    if( ucUDR_valid0 ) {   // Ein Zeichen ist auf UART 0 angekommen
      cli();
      c = ucUDR0;          // hier ist es

      PORTxxxx = .....     // Led ein
      ucUDR_valid0 = 0;
      sei();
    }
  }
}

ergänze mal die fehlenden Teile für Initialisierung und sieh nach,
ob deine LED eingeschaltet wird. Wenn ja, dann hat der Interrupt
ausgelöst.

[Flo S. (tuxianer)]

ich werd das dann mal ausprobieren. Aber der Interrupt löst aus...das 
habe ich ja schon probiert es hängt definitiv in der Warteschleife in 
der Reveive Routine. Es müssten eigentlich Zeichen verloren gehen...denn 
die Anzhal in der Schleife stimmt laut Protokoll.

Die Platine ist fertig, weil das ASM Prog wie gesagt lief...und ich habe 
mich jetzt nur entschlossen, das nochmal in C zu schreiben, weil ich von 
ASM weg will und es mir zu kompliziert zu erweitern ist.

[Karl H. (kbuchegg)]

Florentin S. wrote:
> habe ich ja schon probiert es hängt definitiv in der Warteschleife in
> der Reveive Routine.

Eine derartige Warteschleife willst du nicht haben.
Die ganze Funktion ist unnötig.

Dein Programm will nicht aktiv darauf warten, dass auf der
Seriellen Schnittstelle 50 Bytes eintrudeln.
Du musst deine Denkweise umstellen und anfangen Ereignis-
orientiert zu denken: Auf der UART ist ein Byte engetrudelt,
was mache ich damit?
Für diesen Gedankengang ist die adequate Programmierweise die
Hauptschleife in main(). Wenn ein Byte an der UART eintrudelt,
dann teilt die Interrupt Routine das dem Rest der Welt mit,
indem sie eine globale Variable (das berüchtigte ucUDR_valid)
auf 1 setzt. Und dein 'Eventdispatcher' (ein schönes Wort
für sowas einfaches) reagiert darauf, indem er im nächsten
Durchlauf diese 1 sieht und entsprechend reagiert.
Aber dein Programm wartet nirgends aktiv darauf, dass diese
Variable irgendwann 1 wird. Dein Programm prüft ständig in
einer Schleife ob irgendeine dieser Benachrichigungsvariablen
zu 1 geworden ist und behandelt dann diesen Fall (dieses Ereignis)

  while( 1 ) {     // diese Schleife ist dein 'Eventdispatcher'

    if( ucUDR_valid ) {    // und das ist der Event der aufgetreten
                           // ist. Wenn das hier auf 1 geht, dann
                           // ist das Ereignis: 'UART hat ein Byte
                           // empfangen' eingetreten. Jetzt heist
                           // es auf dieses Ereignis zu reagieren.

                           // reagieren kann zb heissen, dass das
                           // Byte in einem Buffer zwischengespeichert
                           // wird und geprüft wird ob das nicht schon
                           // das 50.te Byte war. Wenn es das 50.te
                           // Byte war, dann ist zb. der Header fertig
                           // empfangen worden und kann ausgewertet
                           // werden (nur so als Beispiel).
       ...
    }
  }

Das ist deine Grundstruktur. Für jedes Ereignis welches auftreten
kann, findet sich in dieser while Schleife eine if-Abfrage.
Der Code der dann ausgeführt wird, behandelt dieses Ereignis.
Nirends muss auf irgendwas gewartet werden (schon alleine
deshalb, weil es keine Warteschleifen mehr gibt) und quasi
zeitgleiche Ereignisse werden nacheinander so schnell wie möglich
abgearbeitet.

[Stefan B. (stefan)]

Karl heinz Buchegger wrote:
> Eine derartige Warteschleife willst du nicht haben.
> Die ganze Funktion ist unnötig.

Sag' doch so was nicht ;-)

Wenn unbedingt X Bytes eingelesen werden müssen, kann man das schon 
sinnvoll mit einer wartenden Funktion machen. Die Alternative zur 
Funktion wäre ja eine Latte Statements direkt im in Hauptcode. Und 
gewartet werden müsste ja trotzdem.

Ich gebe dir Karl heinz so weit Recht, als dass eine 
"Programm-muss-jetzt warten-bis-50-Bytes-angekommen-sind" Strategie in 
der Praxis ziemlich unglücklich ist. Aber das zu beheben, würde einen 
Programmablauf z.B. mit Timeoutbehandlung im Protokoll voraussetzen. So 
weit sind wir noch lange nicht ;-)

In the meantime... ist bloss nachzusehen ob bzw. sicherzustellen, dass 
beim Empfang keine Zeichen verloren gehen. Ich mache heute abend 
Beispielcode fertig.

Schade, dass Florentin immer noch keine Möglichkeit gefunden hat, um den 
Datenverkehr mit dem µC ohne den Casio zu testen. Es wäre einfacher, 
wenn man gleiche Testmöglichkeiten hat und auch abgespeckte Teilaspekte 
lösen kann, statt mit der Meldung "Error!" irgendwo in einem 
achtstufigen Protokoll stecken zu bleiben.

ADD: Karl heinz, ich sehe gerade, dass du die Antwort ergänzt hast. Der 
Ansatz gefällt mir gut. Es ist doch kein so grosser Schritt es gleich 
richtig zu machen.

[Flo S. (tuxianer)]

hi,
danke nochmal die Hinweise. Die Main habe ich jetzt so umgewandelt, dass 
die auch ohne die Schleife Funktioniert. Nur verstehe ich jetzt nicht 
ganz, was du meinst...soll ich die Receive Funktion jetzt komplett 
weglassen? Und alles in die Main integrieren? Im Anhang nochmal der 
Code. Soll ich einen Zähler machen, der die Bytes zählt? Oder wie?

Mit dem UART ist mist, das ich das nicht am PC testen kann...ich werde 
mir so einen USB RS232 Wandler besorgen, damit ich auch am Mac debuggen 
kann.

[Stefan B. (stefan)]

Entweder hast du den falschen Code hochgeladen oder du hast das Prinzip 
nicht verstanden.

Ich sehe im Moment nur, dass die Vorschläge von Karl heinz nicht 
realisiert sind und der wichtige Bugfix (cli()-sei()-Klammer um Zugriff 
auf gemeinsame Variablen zwischen ISR und Nicht-ISR-Code) wieder fehlt.

Was anderes...

Was hat es mit dem UART1 auf sich? Im Moment ist dort der gleiche Code 
wie auf UART0. Willst du zwei Casio an ein Atmega162-Board hängen? Wenn 
ja, was ist die Aufgabe des Atmega162-Boards, Datentransfer zwischen den 
beiden Casio (würde aber so nicht funktionieren, weil beide zum 
Atmega162 senden)?

[Flo S. (tuxianer)]

Ich habe das Prinzip schon teilweise verstanden, aber wenn ich die 
Interrupts deaktiviere funktioniert das Receive ja logischerweise so 
nicht mehr. Ich bin noch am überlegen, wie ich das am besten umsetze. Ja 
an den anderen UART kommt ein 2. Rechner ran. Der µC ermöglicht die 
direkte Kommunikation
 zwischen 2 Rechnern im Programm, was so nicht funktioniert, da der 1ne 
Rechner ein anderes Handshake sendet, als der andere erwartet.

[Flo S. (tuxianer)]

> 
> int main()
> {
>   ...
> 
>   sei();
> 
>   while( 1 ) {    // dies ist die einzige Schleife, die auf etwas
>                   // wartet. Sie wartet auf Arbeit
> 
>     if( ucUDR_valid0 ) {   // Ein Zeichen ist auf UART 0 angekommen
>       cli();
>       c = ucUDR0;          // hier ist es
> 
>       PORTxxxx = .....     // Led ein
>       ucUDR_valid0 = 0;
>       sei();
>     }
>   }
> }
>

Der test hatte übrigens funktioniert. Der Port war auf High.

Nur wie gesagt ich müsste ja jetzt das empfangen anders gestalten, wenn 
ich nach dem ersten empfangen die Interrupts deaktiviere.

[Flo S. (tuxianer)]

Ich hab Receive0 jetzt nochmal geändert:

[Karl H. (kbuchegg)]

vorweg: Ich weiss nicht, wie ich es dir noch anders erklären
soll, ohne dass ich dein Programm schreibe.

> was du meinst...soll ich die Receive Funktion jetzt komplett
> weglassen?

  Ja

> Und alles in die Main integrieren?

Na ja. Soviel bleibt in der Receive Funktion nicht übrig,
wenn man die Warteschleife rauswirft. Im Grunde bleibt dann
ja nur eine Zuweisung übrig :-)

> Nur wie gesagt ich müsste ja jetzt das empfangen anders gestalten, wenn
> ich nach dem ersten empfangen die Interrupts deaktiviere.

Die Interrupts werden eaktiviert, damit dieser Programmteil

>       c = ucUDR0;          // hier ist es
>
>       PORTxxxx = .....     // Led ein
>       ucUDR_valid0 = 0;
>       sei();

nicht von einem UART Interrupt unterbrochen werden kann.
Das macht sich nämlich nicht so gut, wenn hier in diesem
Programmteil ucUDR_valid auf 0 gesetzt wird und kurz vorher
ein Interrupt versucht hat, den auf 1 zu setzen.

Aber schau doch mal ans Ende der Sequenz. Da steht ein kleiner
verträumter sei(), der nach Abschluss dieser Operation die
Interrupts wieder zulässt.

[Flo S. (tuxianer)]

Also wird der Interrupt nur beim ersten empfangenen Byte ausgelöst und 
wenn alle Bytes empfangen sind und die Übertragung komplett ist wieder 
aktiviert. Meinst du das so (siehe Anhang)?

[Karl H. (kbuchegg)]

Florentin S. wrote:
> Also wird der Interrupt nur beim ersten empfangenen Byte ausgelöst und
> wenn alle Bytes empfangen sind und die Übertragung komplett ist wieder
> aktiviert. Meinst du das so (siehe Anhang)?

Nein.
Der Interrupt wird nur kurzzeitig abgeschaltet, während
ein (in Worten: 1) empfangenes Zeichen verarbeitet wird.

Ob die Übertragung aller Zeichen komplett ist, kann ich doch
zu diesem Zeitpunkt noch gar nicht sagen. Das weis ich doch
erst nachdem ich den Zähler hochgezählt habe, der mir sagt
wieviele Bytes jetzt schon empfangen wurden! Wenn der auf
50 steht, dann war das das letzte zu Empfangende Byte auf
dieser Schnittstelle.

uint8_t ByteCounter0;
uint8_t ByteBuffer0[50];

uint8_t ByteCounter1;
uint8_t ByteBuffer1[50];

int main()
{
  uint8_t c;

   ...

   ByteCounter0 = 0;
   ByteCounter1 = 0;

   ....

   while( 1 ) {

     if( ucUDR_valid0 ) {   // Ein Zeichen ist auf UART 0 angekommen
       cli();
       c = ucUDR0;          // hier ist es
       ucUDR_valid0 = 0;
       sei()

       ByteBuffer0[ ByteCounter0 ] = c;
       ByteCounter0++;

       if( ByteCounter0 == 50 ) {
         // Hurra, die 50 Bytes für den Header sind
         // allesamt beisammen
         //
         // mach was damit

         ByteCounter0 = 0;
       }
     }

// das ganze nochmal für UART 1

     if( ucUDR_valid1 ) {   // Ein Zeichen ist auf UART 1 angekommen
       cli();
       c = ucUDR1;          // hier ist es
       ucUDR_valid1 = 0;
       sei()

       ByteBuffer1[ ByteCounter1 ] = c;
       ByteCounter1++;

       if( ByteCounter1 == 50 ) {
         // Hurra, die 50 Bytes für den Header sind
         // allesamt beisammen
         //
         // mach was damit

         ByteCounter1 = 0;
       }
     }

  }
}

[Flo S. (tuxianer)]

ok daran hatte ich auch schonmal gedacht nur wird dann die auswertung 
etwas umständlicher. Da ich ja nicht nur den haeder empfangen habe. Aber 
so müsste es gehen. Ich wollte wie gesagt Header Und Daten etc einzeln 
abspeichern.

[Karl H. (kbuchegg)]

Obiges ist natürlich nur ein Skelett um das Prinzip aufzuzeigen.
Wenn ich mir dein Protokoll mal so ansehe, dann fällt mir dazu
ein, dass ich da noch einen Status mit einbauen würde.
Deine Empfangs-'Maschine' ist eine Machschine die in
bestimmten Stati sein kann. Zb. wartet die Maschine auf
das erste Sync byte (die 0x15), das ihr mitteilt, das
in bälde mit der Übertragung des Headers zu rechnen sein
wird.
Nun, das sind schon mal 2 Zustände. Welche gibts noch?

   die Maschine ist untätig (engl. idle) und wartet auf die 0x15
   was ist zu tun, wenn die 0x15 empfangen werden?
     Die Maschine muss 0x13 zurücksenden und geht in den
     Zustand EmpfangeHeader über

   Was ist im Zustand EmpfangeHeader zu tun?
   Nicht viel, die empfangenen Bytes, 50 an der Zahl sind
   abzuspeichern (oder auch nicht). Wie auch immer. Auf jeden
   Fall muss die Maschine 0x06 schicken und geht dann in den
   Zustand EmpfangeDaten über

   Was ist im Zustand EmpfangeDaten zu tun?
   Bytes speichern, 16 an der Zahl und nachdem die Daten da
   sind, wird ein 0x06 gesendet und die Maschine geht in
   den Zustand EmpfangeFooter (als gegenstück zum 'Header')
   über.

   Was ist im Zustand EmpfangeFooter zu tun?
   Kennen wir schon. 50 Bytes empfangen und hinten nach wieder
   ein 0x06 wegschicken.
   Dadurch ist ein Telegram beendet und die Maschine kann wieder
   in den Zustand Idle übergehen.

#define IDLE       0
#define REC_HEADER 1
#define REC_DATA   2
#define REC_FOOTER 3


uint8_t DataCounter0;
uint8_t DataBuffer0[16];
uint8_t ByteCounter0;
uint8_t ByteBuffer0[50];
uint8_t State0;

uint8_t DataCounter1;
uint8_t DataBuffer1[16];
uint8_t ByteCounter1;
uint8_t ByteBuffer1[50];
uint8_t State1;

int main()
{
  uint8_t c;

   ...

   DataCounter0 = 0;
   ByteCounter0 = 0;
   State0 = IDLE;

   DataCounter1 = 0;
   ByteCounter1 = 0;
   State1 = IDLE;

   ....

   while( 1 ) {

     if( ucUDR_valid0 ) {   // Ein Zeichen ist auf UART 0 angekommen
       cli();
       c = ucUDR0;          // hier ist es
       ucUDR_valid0 = 0;
       sei();

       if( State0 == IDLE && c == 0x15) {     // was hat im Zustand Idle zu geschehen?
         Transmit0( 0x13 );
         State0 = REC_HEADER;
       }

       else if( State0 == REC_HEADER ) {
         ByteBuffer0[ ByteCounter0 ] = c;
         ByteCounter0++;

         if( ByteCounter0 == 50 ) {
           Transmit0( 0x06 );
           ByteCounter0 = 0;
           State0 = REC_DATA;
         }
       }

       else if( State0 == REC_DATA ) {
         Data0[ DataCounter0 ] = c;
         DataCounter0++;

         if( DataCounter0 == 16 ) {
           Transmit0( 0x06 );
           DataCounter0 = 0;
           State0 = REC_FOOTER;
         }
       }

       else if( State0 == REC_FOOTER ) {
         ByteBuffer0[ ByteCounter0 ] = c;
         ByteCounter0++;

         if( ByteCounter0 == 50 ) {
           Transmit0( 0x06 );
           ByteCounter0 = 0;
           State0 = IDLE;
         }
       }

     }

// das ganze nochmal für UART 1

     if( ucUDR_valid1 ) {   // Ein Zeichen ist auf UART 1 angekommen
       cli();
       ........

[Karl H. (kbuchegg)]

Florentin S. wrote:
> ok daran hatte ich auch schonmal gedacht nur wird dann die auswertung
> etwas umständlicher.

Etwas umständlicher schon. Aber dafür funktioniert sie aber auch.
Ausserdem: so wild ist das dann auch wieder nicht.

Mit eine paar Funktionen, in denen die State-Machine ausgelagert
wird, wird das eine schöne, kleine, schnucklige Hauptschleife.

[Flo S. (tuxianer)]

So ich habs jetzt mal danach gestaltet. Gibt es nicht noch eine 
Möglichkeit Header und Daten einzeln zu speichern? Und was ist eine 
State-Maschine?

[Flo S. (tuxianer)]

und leider geht das Programm immer noch nicht über den Header hinaus...

[Flo S. (tuxianer)]

ich finde nicht raus, woran das liegen kann auf jeden Fall sendet er den 
2. Handshake nicht mehr. eigentlich werden doch alle Handshakes an der 
richtigen Stelle gesendet. Vlt läuft der µC zu schnell...aber durch das 
Interrupt empfängt er doch eigentlich nur, wenn auch was da ist...

[Flo S. (tuxianer)]

Ich komm nicht weiter aber ich habe mir jetzt mal so einen USB - Seriell 
Converter bestellt und hoffe mal, das der mich weiter bringt.

[STK500-Besitzer (Gast)]

Wie wäre es, wenn du mal die Aufgabe deines Programmes hinschreiben 
würdest?!
Dann könnten dir auch Leute helfen, die keine/wenig Ahnung von Assembler 
haben.

[Stefan B. (stefan)]

Die Aufgabe ist schnell umrissen:

Ein Atmega162 soll mit einem "Casio GTR" (genaue Modellbezeichnung oben) 
Taschenrechner Daten austauschen. Dabei sollen beide UARTS des Atmega 
benutzt werden, wenn 2 Taschenrechner angesprochen werden sollen.

Die regen User dieser Casio-Reihe haben einen Teil des Protokolls bei 
den Send/Receive Befehlen des Caso und der Struktur der gesendeten Daten 
herausgefunden. Einen Link zu einer PDF Datei mit dieser Beschreibung 
hat Florentin in dem ganz oben angegebenen Thread angegeben. Ausserdem 
liegt ein funktionierendes ASM-Programm vor (auch oben angegeben).

Das derzeitige Teilziel ist, die Ausgabe des Casio-Befehls Send per 
UART0 auf den Atmega162 zu schaffen. Ein UART-Empangsinterrupt-Programm 
in C mit einer Teilimplementation der Funktionalität des ASM-Programms 
hängt mitten in dem empfangenen Telegramm (genauer: beim Empfangen des 
ersten Headers). Die sinnvollen Vorschläge von Karl heinz zur Abwicklung 
des Telegramms per state /machine/ (endlicher Automat) sind allerdings 
noch nicht eingebaut (Hausaufgaben machen Florentin!).

Die Hardware auf AVR Seite ist derzeit eine fertige, nicht näher 
beschriebene Platine mit wenigen Zugangsmöglichkeiten fürs Debugging. 
Erschwerend (neudeutsch: herausfordernd) ist, dass Florentin keine RS232 
Test- und Debugmöglichkeiten hat. Ein Anhängen des AVR oder des Casio an 
einen PC funktioniert bei ihm nicht, weil sein MAC keine RS232 
Schnittstelle hat, sondern nur USB. Ein USB-RS232 Konverter beschafft 
sich Florentin gerade. Ob der dafür erforderliche TTL-RS232-Pegelwandler 
vorhanden ist und an die fertige AVR Platine angebaut werden konnte, 
weiss ich im Moment nicht. Wir hatten das diskutiert, aber das Resultat 
ist mir nicht präsent. AVR und Casio sind jedenfalls direkt über TTL 
miteinander verbunden. Die derzeitige Debugmöglichkeit von Florentin 
ist, PORTA als Output-Port zu nutzen und die Pegel an den Pins mit dem 
Multimeter nachzumessen.

Mir war lange unklar, was hinter diesem Projekt stecken könnte...

...ich habe eine Seite im Netz gefunden, wo ähnliche Bauteile und auch 
beide UARTS benutzt werden. Es wird damit ein Chatprogramm zwischen zwei 
Taschenrechnern aufgebaut ;-) 
http://www.frangenberg.info/Michael/gtr/chat/index.html

Florentins Platine und Anwendung können auch ganz anders aussehem, so 
dass man nicht dortige Hardware als Grundlage für weitere 
Debuggingoptionen voraussetzen kann.

Es wäre nicht schlecht, wenn Florentin näher aus die Platine eingehen 
würde. Und wenn Florentin schon dabei ist: Mit welchem Programmer und 
welcher Programmersoftware schaffst du die Programme in den Atmega162? 
Vielleicht kann man da was in Richtung Debugging drehen...

[Falk B. (falk)]

@  Karl heinz Buchegger (kbuchegg)

>vorweg: Ich weiss nicht, wie ich es dir noch anders erklären
>soll, ohne dass ich dein Programm schreibe.

Dann nimm doch einach mal alle deine sehr ausführlichen Erklärungen und 
pack sie in einen Wikiartikel + Beispielcode. Denn das sicher nicht die 
letzte Anfrage zum UART Interrupt.

MFG
Falk

[Stefan B. (stefan)]

Die Idee hatte ich so ähnlich gestern auch. Und das ist auch der Grund, 
warum ich mich relativ stark in diesen Thread reinhänge. Ich will den 
UART Interrupt selbst auch verstehen.

Daraufhin hatte ich genau diese Baustelle im AVR-GCC-Tutorial 
angelegt (=> UART => Interruptbetrieb). Ob es dort oder hinter dem 
Interruptteil des Tutorials stehen wird ist noch offen. Kommt darauf an, 
was vom Lernen hersinnvoller ist.

Im Moment bin ich am Herstellen und Testen von Beispielcode. Mitarbeit 
ist sehr willkommen.

[Karl H. (kbuchegg)]

Falk Brunner wrote:
> @  Karl heinz Buchegger (kbuchegg)
>
>>vorweg: Ich weiss nicht, wie ich es dir noch anders erklären
>>soll, ohne dass ich dein Programm schreibe.
>
> Dann nimm doch einach mal alle deine sehr ausführlichen Erklärungen und
> pack sie in einen Wikiartikel + Beispielcode. Denn das sicher nicht die
> letzte Anfrage zum UART Interrupt.

Na, ja.
Sein Problem dürfte doch jetzt eigentlich nicht mehr der Interrupt
sein, sondern die Datenauswertung, wenn ich die letzten Meldungen
richtig interpretiere.

Leider ist Florian etwas hilflos wenn es zum Thema Debugging geht.
Hilft aber alles nichts, da muss er durch. Debugging hat auch
immer was mit Intuition, Ideen haben und auch ein klein wenig
Glück zu tun. Wenn ich nichts vernünftiges zum Debuggen habe,
dann hab ich meistens immer noch eine Led an einem Port, die
dann herhalten muss um mir anzuzeigen ob bestimmte Zustände
im Programm eingetreten sind. Und wenn das alles ist, was
ich als externen Indikator habe, dann muss halt das genügen
um mir ein Bild darüber zu verschaffen was im Programm abgeht.
Dazu muss ich mir aber überlegen, was ich überhaupt mit einer
Ja/Nein Entscheidung (und was anders erlaubt mir meine LED ja
nicht) als Statusinformation herausgeben kann und was ich mit
dieser Information anfangen, bzw. welchen Rückschluss ich daraus
ziehen kann.

[Flo S. (tuxianer)]

Hi,
danke nochmal für die Hinweise. Über eine State-Maschine werde ich mich 
erkundigen, was das ist. Ich habe den Assemblercode zusammen mit Michael 
entwickelt (Link oben). Meine Platine ist ähnlich aufgebaut. Also nur 
das nötigste und halt an den Uarts die Kabel zum Rechner. Der Serielle 
Adapter ist wie gesagt bestellt und ich hoffe, dass er morgen ankommt. 
Einen Pegelwandler (Max232) habe ich zur Verfügung. Das ist nicht das 
Problem.

Das Problem muss wie gesagt irgendwo beim empfangen des Haders liegen. 
Entweder geht was zu schnell oder was anderes läuft schief. Ich hoffe 
das ich morgen mal ordentlich Debuggen kann um den Fehler noch genauer 
zu lokalisieren.

Vielen Dank noch mal für die Hinweise.

Gruß Florentin

[Flo S. (tuxianer)]

Ich hab nochmal wegen der State Maschine geschaut...soll ich damit die 
Zustände schreiben wie Header wurde empfangen oder in wiefern kann ich 
diese einsetzen?


Was ich noch vergessen hatte ich flashe den Atmega mittels AVRDude.

[Jörg W. (dl8dtl) (Moderator)]

Florentin S. wrote:

> soll ich damit die
> Zustände schreiben wie Header wurde empfangen oder in wiefern kann ich
> diese einsetzen?

Das hat dir Karl Heinz hier schon erläutert:

Beitrag "Re: UART Problem (Assembler zu C) II"

Das Gerippe der state machine steht da schon.

Das Prinzip ist, dass du mit jedem empfangenen Byte guckst, was du
damit anfangen kannst.  Wenn dieses Byte dazu führt, dass du
(basierend auf dem aktuellen Zustand des Automaten) einen bestimmten
Abschnitt des Headers jetzt erkannt hast, dann schaltet der
Automat weiter und guckt, was danach kommt.  Auf diese Weise
hangelt man sich Stück für Stück weiter.  Wenn irgendetwas
unerwartetes im Datenstrom ankommt, bricht der Zustandsautomat
(so der offizielle deutsche Name) ab und fällt auf den Grundzustand
zurück.

[Flo S. (tuxianer)]

Danke den hab ich ja noch gar nicht gelesen.

@Karl Heinz hasst du den Beitrag mal ediert? Oder habe ich den schlicht 
weg überlesen? Danke. Dann bau ich sowas in der Art mal noch ein.

[Karl H. (kbuchegg)]

Florentin S. wrote:
> Hi,
> danke nochmal für die Hinweise. Über eine State-Maschine werde ich mich
> erkundigen, was das ist.

Genau das was ich als letztes Programmfragment weiter oben
gepostet habe.
In einer Variablen wird der aktuelle Zustand (der State)
gespeichert und wenn die Maschine arbeiten soll, entscheidet
sie anhand des States und dem neuen Input (und eventuell irgendwelchen
Zusatzbedingungen) was zu geschehen hat und in welchen neuen
State (das ist dann einfach eine Zuweisung an die State-Variable)
sie überwechseln soll.

Eine Statemaschine hat den Vorteil, dass man die Logik die
dahintersteckt, sehr einfach graphisch veranschaulichen kann
(siehe beiliegendes gif). Die Umsetzung aus so einer Graphik
in die tatsächliche Implementierung ist dann reine
Routinearbeit.

Im Gif gilt:
 die Kreise sind die Zustände (jweils mit dem Namen des Zustands)
 die grauen Pfeile sind die Zustandsübergänge
 bei Pfeil steht jeweils dabei:
    in blau: welche Voraussetzung muss gelten, damit dieser
             Pfad genommen wird
    in rot:  welche Aktion ist dabei durchzuführen

Wenn du dieses Bild mit meinem Code vergleichst, wirst du auch
feststellen, dass ich im Code ein paar Fehler gemacht habe.
Das liegt daran, dass ich den Code direkt eingetippt habe
und vor dem Posten nicht getestet habe. Durch die Grafik kannst
du die Logik deiner Maschine in einer abstrakten Art und Weise
festlegen und dich nur auf die richtigen Abläufe konzentrieren.
Du kannst dann auch auf dem Papier mal deine Maschine mit
einem simulierten Input durchspielen und die Abläufe kontrollieren.
Läuft das ganze auf dem Papier, dann setzt man das in Code um.
(und nicht so wie ich das gemacht habe: zuerst coden und dann
zeichnen. Wie du siehst schleichen sich da Fehler ein).

[Karl H. (kbuchegg)]

Nachtrag.
Da diese State Maschine nur 4 Zustände kennt, würde es sich
zb. anbieten die State Nummer auf 2 Leds auszugeben und dann
mal ganz gemütlich Zeichen in die Maschine einzuspeisen.
Die Leds zeigen dir dann ganz genau an, in welchem Zustand
die Maschine ist und du kannst kontrollieren ob wenigstens
das funktioniert.

(PS: Der Fehler von dem ich im Codeteil gesprochen habe,
betrifft die Initialisierung der diversen Counter. Da liegt
einiges im Argen)

[Flo S. (tuxianer)]

Ja vielen Dank nochmal das mit den Fehlern habe ich schon gemerkt das da 
ein paar Namen falsch waren etc. Die hab ich mal korrigiert. Ich muss 
nur nochmal schauen, ob inhaltlich alles stimmt. Der Code ist im Anhang. 
Muss aber nochmal alles durchprüfen.

[Flo S. (tuxianer)]

So. Der Code funktioniert so anscheinend auch noch nicht. Wenn ich 0x15 
sende sendet er wenn überhaupt "0xD3" zurück oder sendet ununterbrochen 
"0xC6" Wenn ich den µC vom Strom trenne sendet er 2 Bytes genau weis ich 
nicht mehr was, aber ich glaub es war "F0". Vlt könnt ihr mit den 
Informationen was anfangen. Mir kommt das bald vor, wie Baudrate falsch 
eingestellt.

Edit:

Ich hab auch mal den Rechner an den PC geklemmt und den µC emuliert das 
Klappt wunderbar.

[Stefan B. (stefan)]

Ah, du bist jetzt so weit, dass du entweder den Casio oder den µC an die 
serielle Schnittstelle eines PC hängen kannst?

Zur Baudrate...

Aus dem gesetzten UBRR0L Wert (0x2F bzw. 47) im LSS-File letztens ist 
erkennbar, dass der µC in die UBRR_VAL Berechnung F_CPU = 7372800 Hz 
eingeflossen ist. Das ist die gleiche Taktrate wie im ASM-File. Das 
ASM-Programm funktionierte auch auf der gleichen Platine. D.h. die 
Taktrate fürs C-Programm stimmt und dann wird die Baudrate auch stimmen.

Und den anderen UART-Parametern...

Die habe ich auch in dem Programm im Anhang verwendet. Wenn ich meinen 
den PC auf 9600 Baud 8N2 einstelle, funktioniert die Kommunikation mit 
dem µC.

Tipp: In vielen Terminalprogrammen auf dem PC kann man die Kommunikation 
in eine Datei mitspeichern lassen. Das kann ungemein nützlich sein, um 
anderen die Ergebnisse zu zeigen...

[Flo S. (tuxianer)]

Ich hatte Gelegenheit, das Teil an einem anderen Rechner zu testen. Es 
war ein Windows Rechner mit HTerm.

[Flo S. (tuxianer)]

Irgend etwas ist komisch...ich habs jetzt nochmal an einem anderen 
Rechner getestet und weder dein Debug Programm funktionieren noch meine 
C Variante. Rechner Funktioniert und ich hab mal das ASM drauf geladen 
sobald ich 15 eigebe kommt 13 zurück. Ich sende 50 Bytes danach kommt 6 
und so weiter. Aber bei den C Varianten kommt nix!

[Flo S. (tuxianer)]

ok ich habs...

ich sende 0x15

der µC antwortet mit 0xD3

dann sende ich 50 Bytes

der µC antwortet mit 0xC6

dann 16 Bytes

µC: 0xC6

dann 50

µC: 0xC6


das Programm hat also schon früher funktioniert siehe erster Beitrag. Da 
antwortete der µC auch mit 0xD3 nur woran kann das liegen? Im Anhang 
nochmal das Makefile:

Es muss also an dem Wert liegen, der Transmit übergeben wird oder etwas 
an der Baud stimmt nicht, was aber unrealistisch ist, da der µC ja auf 
0x15 antwortet.

[Stefan B. (stefan)]

Seltsam. Schick doch mal das LSS-File von dem jetzigen C-Code, damit man 
sehen kann, was auf unterster Ebene gemacht wird. Ich bin allerdings bis 
Montag nicht mehr online, da ich das schöne Schweinfurth besuche ;-)

[Thomas (Gast)]

hier der Aktuelle...ich hab aber noch nen bisschen was gemacht nicht 
wundern.

[Flo S. (tuxianer)]

mist ist grad nen Freund bei mir der was wissen wollte siehe GCC. 
Deswegen der andere Name nicht wundern ^

[Stefan B. (stefan)]

Das ist mir total unerklärlich, denn das LSS sieht für mich OK aus.

Gut, Transmit0(int Senden) wäre besser ein Transmit0(unsigned char 
Senden) sein, damit Code eingespart wird, aber daran liegt es eher 
nicht.

Als echte Verzeiflungstat würde ich in Transmit0() die letzte Zeile in 
UDR0 = Senden & 0x1F; ändern, um herauszufinden, ob das Phänomen (Bit 6 
und 7 gesetzt) vom Hauptcode her kommt (ohne &) oder vom UART selbst 
(mit &).

[Flo S. (tuxianer)]

so ich hab jetzt mal den Rest eingespeist (Erstmal nur UART0). Ist das 
so in Ordnung oder kann man noch was optimieren? Der Compiler meckert 
nicht. Nur kann ichs leider noch nicht testen, bevor ich das allgemeine 
Problem beseitigt habe.