Schwierigkeiten mit dem UART AtTiny2313A

[Maximilian G. (chainex)]

Hallo liebes Forum,

ich habe leider ein sehr peinliches Problem.
Ich versuche nun schon seit geraumer Zeit mit meinem AtTiny2313A mittels 
UART (Asynchron) Daten zu senden.

Soweit hab ich das Datenblatt auch einigermaßen verstanden und der Code 
läuft im Simulator Debugger einwandfrei durch. Nur leider kommt aus dem 
realen Baustein an PD1 nichts heraus (kein Signal nur LOW).
Eine weitere komische Sache ist wenn ich im Debugger auf die Zeile 
springe in der ich UDR beschreibe steht nach dem beschreiben immernoch 
0x00 drin?.


Jetzt wollte ich einmal fragen ob jemand vielleicht etwas an meine Code 
auffällt was daran schuld sein könnte, ich bin leider noch etwas 
unbeholfen...

PS: Ich hatte das ganze auch mal mit einem festen Zahlenwert (12) statt 
dem String versucht kam aber auch nichts bei raus.

#include <avr/io.h>
#include <avr/interrupt.h>

#define   F_CPU 8000000
#define   Baud_Multip_H 0
#define   Baud_Multip_L 51    // BAUD 9600
#define   Prellzeit 100

#define Debug 1  


int  Senden(unsigned char Zeichensatz[255],int Datenlange)
{
  int Senden_erfolgreich = 0;  
  
  UCSRB  |=  (1 << TXEN);    // Senden aktivieren
  
  
  for (int Durchlauf = 0;   Durchlauf <= Datenlange;  Durchlauf++)
  {
    while (!( UCSRA & (1 << UDRE)) )  // UDRE gecleart? "DATA REGISTER EMPTY" (Senden Abgeschlossen!)
    {  /*  warten */  }
    
    if(Debug == 1)  {PORTB  |=  (1 << PORTB1);}          // Senden starten sig
    UDR  =  Zeichensatz[Durchlauf];  
    if(Debug == 1)  {PORTB  &=  ~(1 << PORTB1);}        // Senden abgeschlossen sig
    
    
    
    
    while (!( UCSRA & (1 << TXC)) )
    {  /*  warten */  }
  
    if (    ( UCSRA & (1 << UDRE))   &&    ( UCSRA & (1 << TXC))  )
    {
      Senden_erfolgreich = 1;    // wenn Buffer leer und gesendet war Senden okay
    }
  
    
    UCSRA &= ~(1 << TXC);    // Transmit Flag löschen
    
  }
  
  UCSRB  &=  ~(1 << TXEN);    // Senden deaktivieren
  
  
  return Senden_erfolgreich;
}





int main(void)
{
  int Prellen = 0;
  
  PORTB  =  (1 << PORTB0);      // Pull UP
  DDRB  =  (1 << PORTB1);
  UBRRL  =  Baud_Multip_L;      // Baudrate
  UBRRH  &=  0b11110000;        // Register Löschen
  
  // Settings Register  
  
  UCSRC  |=  (1 << UCSZ0) | (1 << UCSZ1) ;
  
    while (1) 
    {
    
    if (  !(PORTB  &  (1 << PORTB0)))            // Taster Da?
    {
      Prellen = 0;
      
      while (Prellen < Prellzeit)              // Entprellen
      {  
        if ((PORTB  &  (1 << PORTB0)))    {  Prellen++;    }  
        else                {  Prellen = 0;  }  
      }
      
      
    Senden("Hallo!"  ,  6  );  
      
  }
  
    }
}

[conundrum (Gast)]

PORTD1 ist nirgendwo als Ausgang definiert. Aber wenn D1 ein Eingang 
ist, dann müsste er hochohmig sein und nicht 0.

Wie hast du das LOW gemessen? Mit Multimeter und Oszi kriegst du 0 
angezeigt, aber das ist nicht unbedingt ein Ausgang auf Low, ohne Pullup 
kann das auch ein Eingang sein. Ein Logiktester zeigt den wahren 
Zustand.

Bin mir nicht ganz sicher, aber es ist einen Versuch wert.

[Marc V. (Firma: Vescomp) (logarithmus)]

Maximilian G. schrieb:
> Jetzt wollte ich einmal fragen ob jemand vielleicht etwas an meine Code
> auffällt was daran schuld sein könnte, ich bin leider noch etwas
> unbeholfen...

 Wenn etwas nicht klappt, dann macht man den Code so kurz wie nur
 irgendwie möglich und schmeisst alles unnötige raus...

 Irgendwelche Taster auf Prellen abfragen kann man später, wenn
 überhaupt - hat sowieso nichts mit deinem Problem zu tun, kann
 aber sehr wohl selbst Probleme verursachen.
 Ich habe gerade keinen 2313 zur Hand aber folgender Code läuft
 im Simulator ohne Probleme:

int main(void)
{
  int Prellen = 0;
  
  PORTB  =  (1 << PORTB0);      // Pull UP
  DDRB  =  (1 << PORTB1);
  UBRRL  =  Baud_Multip_L;      // Baudrate
  UBRRH  &=  0b11110000;        // Register Löschen
  
  // Settings Register  (Das braucht man aber normalerweise nicht, das ist schon Init Value)
  UCSRC  |=  (1 << UCSZ0) | (1 << UCSZ1) ;
  
    Senden("Hallo!"  ,  6  );  
}

Maximilian G. schrieb:
> Eine weitere komische Sache ist wenn ich im Debugger auf die Zeile
> springe in der ich UDR beschreibe steht nach dem beschreiben immernoch
> 0x00 drin?.

 Da machst du etwas falsch.

[Marc V. (Firma: Vescomp) (logarithmus)]

conundrum schrieb:
> PORTD1 ist nirgendwo als Ausgang definiert.

 Egal, hiermit wird das schon richtig gemacht:

  UCSRB  |=  (1 << TXEN);    // Senden aktivieren

[S. Landolt (Gast)]

Eingänge werden mit PIN abgefragt, also zweimal PINB statt PORTB.

[S. Landolt (Gast)]

> noch etwas unbeholfen...

Ein Kopieren des Aufrufs von Senden vor die while-Schleife hätte 
gezeigt, dass das Problem nicht beim USART liegt.

[holm (Gast)]

Wartest Du auf PD1 auf ein Signal während Du PB1 programmierst?

Gruß,
Holm

[Marc V. (Firma: Vescomp) (logarithmus)]

S. Landolt schrieb:
> Ein Kopieren des Aufrufs von Senden vor die while-Schleife hätte
> gezeigt, dass das Problem nicht beim USART liegt.

 Genau.
 Oder die (falsche) Abfrage vorerst ganz rausschmeissen.

[Maximilian G. (chainex)]

S. Landolt schrieb:
> Eingänge werden mit PIN abgefragt, also zweimal PINB statt PORTB.

Danke mal wieder ein Anfängerfehler. :(

Habs nun geändert mal schauen wie es sich nun verhält... wenn es das 
gewesen wäre wäre das schon sehr peinlich.

[Marc V. (Firma: Vescomp) (logarithmus)]

Maximilian G. schrieb:
> Habs nun geändert mal schauen wie es sich nun verhält... wenn es das
> gewesen wäre wäre das schon sehr peinlich.

 Tja, dann fang schon mal an, dich zu schämen...

[Karl B. (gustav)]

Hi,
je nachdem welche inc. Datei Du nimmst,
gibt es Unterschiede.
also mit der "tn2313def.inc" fahre ich ganz gut.

Die nimmt dann auch das Adressenincrement.
Spart Code.

Quarz/Takt/Baudrate
weißt Du wie abändern, brauche ich nicht drauf einzugehen.

ciao
gustav

[c-hater (Gast)]

Karl B. schrieb:

> je nachdem welche inc. Datei Du nimmst,
> gibt es Unterschiede.

Logisch. Deswegen nimmt man der Einfachheit halber schlicht die Richtige 
für das Target. Das Verfahren hat sich gut bewährt. ;o)

> also mit der "tn2313def.inc" fahre ich ganz gut.

Ist aber eigentlich die falsche für einen Tiny2313A. Stört allerdings 
nicht weiter, solange man nicht die zusätzlichen Features des 2313A 
benutzen will.

> Die nimmt dann auch das Adressenincrement.

???

Die beiden Includes unterscheiden sich nur sehr wenig, eigentlich 
praktisch nur dadurch, dass die zusätzlichen Features des 2313A halt nur 
in dessen Include auftauchen.

Auf jeden Fall gibt es aber keine Unterschiede, die irgendwas mit 
irgendeinem Adressincrement, welches irgenwer oder irgendwas "nimmt" 
oder "nicht nimmt", zu tun haben könnten...

[Karl B. (gustav)]

Hi,
ist im Codeschnipsel auch nicht drin.
Was ich meinte:
Der lpm
nimmt dann nicht x+ y+ z+
print_0:
lpm
lpm  temp, z+  ; Inhalt des vom Z-Pointer adressierten ....

dann meckert der Assembliervorgang an:
 Error
no such instruction
oder instruction unknown bei
Benutzung von der "falschen" inc.

was mehr nervt, sind Synonyme
UCSRA
UCSRB
statt UCS
und so fort. Das "B" gibts nicht bei der anderen.
"For compatibility purposes you may use ...instead of..."

wie gesagt,
ich nehme jetzt "tn2313def.inc"
anstelle von "2313def.inc"
Und für"A" "Extrawurst" ok.

ciao
gustav

[Maximilian G. (chainex)]

Also es funktioniert jetzt...

Mich wundert allerdings immernoch warum das im Debugger nicht erkannt 
wird (bzw funktioniert...).

Trotzdem vielen Dank ans Forum!

Gruß Max

[c-hater (Gast)]

Karl B. schrieb:

> Was ich meinte:
> Der lpm
> nimmt dann nicht x+ y+ z+

lpm nimmt bei einem Tiny2313 und auch bei einem Tiny2313A niemals x+ 
oder y+, ganz egal mit welchem Include. Die lpm-Instruktion kann nur 
zwei Adressierungsarten, nämlich indirekt und indirekt mit 
postincrement. Und sie kann das beides ausschließlich mit dem 
Z-Register, also lpm reg,Z oder lpm reg,Z+. Auch das ist völlig 
unabhängig vom Include, funktioniert also sowohl beim 2313 als auch beim 
2313A gleichermaßen.

> print_0:
> lpm
> lpm  temp, z+  ; Inhalt des vom Z-Pointer adressierten ....
>
> dann meckert der Assembliervorgang an:
>  Error
> no such instruction
> oder instruction unknown bei
> Benutzung von der "falschen" inc.

Ja, wenn man ein Include von einem Target verwendet, was überhaupt keine 
lpm-Instruktion kennt, dann kann sowas passieren. Eben deswegen benutzt 
man sinnvollerweise das RICHTIGE für das Target.

> wie gesagt,
> ich nehme jetzt "tn2313def.inc"
> anstelle von "2313def.inc"

2313def.inc ist auch nicht für den Tiny2313 und schon garnicht für den 
Tiny2313A. Die ist für den ATS902313...

[Bernd (Gast)]

Der TO postet C-Quelltext für AVR.
Dann kommt irgendwann Karl Gustav mit Assembler um die Ecke und faselt 
was von Adressenincrement.

Finde den Fehler.

[c-hater (Gast)]

Bernd schrieb:

> Der TO postet C-Quelltext für AVR.
> Dann kommt irgendwann Karl Gustav mit Assembler um die Ecke und faselt
> was von Adressenincrement.
>
> Finde den Fehler.

Es gibt keinen. Auch in C muß man das richtige Include wählen, wenn was 
Sinnvolles und Funktionierendes rauskommen soll. Nur die Methode, wie 
man das konkret tut, ist üblicherweise eine andere...

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

c-hater schrieb:
> Auch in C muß man das richtige Include wählen

Ist doch alles da:

Maximilian G. schrieb:
> #include <avr/io.h>
> #include <avr/interrupt.h>

Wobei interrupt.h im Moment noch nicht gebraucht wird. Mehr brauchts 
unter C nicht, das richtige Device stellt man im Projekt ein.

[c-hater (Gast)]

Matthias S. schrieb:

> Ist doch alles da:

Nö.

> das richtige Device stellt man im Projekt ein.

Eben.

Ob das tatsächlich geschehen ist, geht aus dem geposteten Zeug nicht 
hervor...

Er wäre nicht der erste C-Dengler, dem nicht klar ist, dass das getan 
werden muss und wie man das genau tut...

[Karl B. (gustav)]

Maximilian G. schrieb:
> Mich wundert allerdings immernoch warum das im Debugger nicht erkannt
> wird (bzw funktioniert...).

Tja,
siehe oben.
#define Debug 1

was passiert da im Einzelnen?

ciao
gustav

[Maximilian Gaus (Gast)]

Karl B. schrieb:
> Maximilian G. schrieb:
> Mich wundert allerdings immernoch warum das im Debugger nicht erkannt
> wird (bzw funktioniert...).
>
> Tja,
> siehe oben.
> #define Debug 1
> was passiert da im Einzelnen?
>
> ciao
> gustav

Wie meinen?
Der Gedanke war das oszi mit dem ausgang zu triggern. Um zu sehen ob pd 
sendet...

[Karl B. (gustav)]

Maximilian G. schrieb:
> Code
> läuft im Simulator Debugger einwandfrei durch.

Also ich verstehe das so:
Debugger Simulatoren können ( normalerweise) nicht auf Ereignisse von 
außen reagieren.
Ist doch keine Hardware mit echten Interfacen.
Ebensowenig auf Interrupts.
Die Simulatoren dienen bei mir in erstere Linie dazu, Syntaxschnitzer 
herauszufinden.

Oder die Zeitschleifen in Echtzeit laufen lassen.
Da hängt sich der Debugger meistens auf.
Stack overflow

(Er rattert immer noch.
Aber irgendwann crashed der.)

ciao
gustav