ATtiny2313 mit BTM222

[Alex K. (rie)]

Hey Leute ich habe da eine Frage hoffe ihr könnt mir da helfen.

Ich benutze einen ATtine2313, welcher über USART mit Bluetoothmodul 
BTM222 kommuniziert, dieses schickt dann die Daten an HTerm. Im HTerm 
ist auch die richtige Bausrate eingestellt und in der COM-Schnittstelle 
auch. Parity- und Stopbit sollten auch richtig eingestellt sein. Ich 
verwende beim tiny den internen Oszillator auf 4MHz und den achter 
Divisor ausgeschaltet.

Das BTM ist noch im Auslieferungszustand, das heißt die Baudrate und 
alles ist noch auf Default.

Hoffe das reicht an Informationen.

Aufjedenfall schicke ich ein Zeichen oder 8Bit raus, es kommt auch etwas 
an jedoch nicht das was ich rausschicke. Ich weiß auch nicht mehr was 
ich noch probieren soll..

Achja, ich habe auch nur vom MC die TXC mit RXC vom BTM verbunden, 
müsste doch eigentlich reichen, oder?

Hier ist mein Quellcode wahrscheinlich ist ja was falsch, sonst bin ich 
für jeden Tipp dankbar.

#include <avr/io.h>
#include <avr/interrupt.h>
#define F_CPU 1000000UL
#include <util/delay.h>

int main(void)
{
  
//USART initialisieren
UBRRH=0;
UBRRL=0b00011001;
UCSRB=(1<<TXEN);
UCSRA=(1<U2X);

  

while(1)
{
_delay_ms(5000);
USART_Transmit();
_delay_ms(1000);
}
  
}

  
void USART_Transmit()
{
while(!(UCSRA & (1<<UDRE)));
UDR=0b00110000;
}

[Karl H. (kbuchegg)]

Alex K. schrieb:

> Das BTM ist noch im Auslieferungszustand, das heißt die Baudrate und
> alles ist noch auf Default.

Nämlich welcher?

>  Ich verwende beim tiny den internen Oszillator auf 4MHz und den achter Divisor 
ausgeschaltet.

Dafür hast dir aber reichlich Mühe gegeben, deinen Code möglichst so zu 
gestalten, dass man möglichst nur nicht auf einen Blick erfassen kann, 
was du da in der Baudrate eigentlich eingestellt hast.

Das beginnt mit einem falschen Wert für F_CPU und endet bei der 
blödsinnigsten Art und Weise, wie du den Baudraten-Faktor im Programm 
angeben konntest.

[Ben S. (theben)]

Verbinde doch mal den RX und den TX pin vom Bluetoothmodul und gebe was 
ins terminal Programm ein das müsste dann als echo zurück kommen.

Hast du einen UART to USB wandler?
Wenn ja stecke den an deinen AVR und versuche damit zu kommunizieren.

Alles häppchenweise

Wobei mir gerade auffällt du musst die #define F_CPU 1000000UL auf 
#define F_CPU 4000000UL stellen

[Mark R. (stevestrong)]

Beide ICs mit 5V oder 3,3V versorgt?

[Alex K. (rie)]

Ben S. schrieb:
> Verbinde doch mal den RX und den TX pin vom Bluetoothmodul und gebe was
> ins terminal Programm ein das müsste dann als echo zurück kommen.

Ja, werde ich mal versuchen, aber ich dachte, bevor ich den schritt 
gehe, mache ich nur in eine Richtung die Kommunikation und wenn eine 
Richtung klappt dann beide ausprobieren.

> Hast du einen UART to USB wandler?
> Wenn ja stecke den an deinen AVR und versuche damit zu kommunizieren.

Nein, leider nicht.

> Alles häppchenweise
>
> Wobei mir gerade auffällt du musst die #define F_CPU 1000000UL auf
> #define F_CPU 4000000UL stellen

Danke, sorry habe vergessen zu ändern, weil ich auch ein anderes BTM 
(Bluegiga WT41) ausprobiert habe und dafür hatte ich das geändert. Aber 
habs noch mal geändert und kein Unterschied.

[Alex K. (rie)]

Mark R. schrieb:
> Beide ICs mit 5V oder 3,3V versorgt?

Beide ICs mit 3,3V

[Mark R. (stevestrong)]

Auch ich würde zuerst den Test machen wie vom Ben.S. vorgeschlagen.
Mit dem ATTiny hab ich am Anfang auch probleme gehabt weil ich eine 
Variable in Register gelegt hab, leider hat der compiler das nicht 
berücksichtigt, und das verursachte unerklärliche Phänomene.

[Mark R. (stevestrong)]

Ah so, und es fehlt dein UART reception code, kann es vielleicht da 
etwas fehlerhaft sein?

[Alex K. (rie)]

Ok, habe ich gerade gemacht.

Folgendes passiert: Ich kann mich nur mit BTM verbinden wenn RXC und TXC 
nicht verbunden sind.

Wenn die Verbindung aufgebau ist und ich die beiden Adern verbinde kommt 
automatisch ein Zeichen im Terminal an. Dann alles was ich sende kommt 
genauso wieder an.


Das heißt es liegt wohl am µC..
Ich bin eigentlich genau nach dem Datenblatt gegangen..
Jemand einen Vorschlag?

[Alex K. (rie)]

Mark R. schrieb:
> Ah so, und es fehlt dein UART reception code, kann es vielleicht da
> etwas fehlerhaft sein?

Was meinst du damit? Also was ist der UART reception code?

Achso und nebenbei.. mir war aufgefallen, dass die Character Size 
vergessen habe einzustellen, ist jetzt auf 8-Bit.

[Karl H. (kbuchegg)]

Alex K. schrieb:

> Das heißt es liegt wohl am µC..
> Ich bin eigentlich genau nach dem Datenblatt gegangen..
> Jemand einen Vorschlag?

Nimm die µC UART erst mal völlig unabhängig von den BTM Modulen in 
Betrieb.

In der Kette

   +----+  Kabel  +-------+   Funk     +------+  Kabel    +-----+
   | µc |<------->| BTM   | <########> | BTM  |<--------->| PC  |
   +----+         +-------+            +------+           +-----+

hast du zu viele unbekannte, auch wenn davon auszugehen ist, dass die 
Verbindung BTM-PC problemlos funktioniert.
Der springende Punkt ist die erste Verbdinung µc-BTM. In der jetzigen 
Konstellation kannst du nichts darüber aussagen, ausser, dass sie nicht 
funktioniert.

Auf einem µC ist man gut beraten, wenn man erst mal abspeckt. D.h. bau 
dir so ein System auf

       +-----+          Kabel                  +-------+
       | µC  | <-----------------------------> | PC    |
       +-----+                                 +-------+

Eine sinnvolle Vorgehensweise ist es, den µC erst mal nur senden zu 
lassen. Läuft auf dem PC ein Terminalprogramm, dann muss dort im 
Terminalprogramm genau das auftauchen, was du vom µC wegsendest. Wenn 
dem nicht so ist, dann ist im µC irgendwo der Wurm drinn, wobei 98% 
aller Fehler auf eine nicht korrekt eingestellte Baudrate zurückzuführen 
sind, wobei der häufigste Fehler da drinn wieder darin besteht, dass der 
µC nicht mit der Taktfrequenz läuft, die der Programmierer denkt, das er 
läuft.

Mit der Konstellation kannst du das erst mal rausfinden, weil du am PC 
untersuchen kannst, was der µC sendet. In deiner Konstellation kannst du 
das nicht, weil du nicht weißt, inwiefern da das/die BTM MOdule noch mit 
reinspielen. Wenn man etwas nicht 100% sicher weiß, dann muss man besten 
trachten, das erst mal loszuwerden, wenn es geht. Bei dir geht es. Um 
die UART im µC zu überprüfen brauchst du die BTM Module nicht - also weg 
damit und erst mal den µC direkt mit dem PC verbinden, der als dein 
Testwerkzeug fungiert.
Nicht immer gleich mit der komplexesten Situation anfangen, die 25 
Unbekannte Fehlermöglichkeiten bietet. Mit einfachen Systemen anfangen 
und das ganze schrittweise in Betrieb nehmen! Dann wird das auch was, 
weil man in jedem Schritt sich auf eine einzige Sache konzentrieren kann 
und feststellen kann ob die so funktioniert oder nicht. Und erst dann 
kommt das nächste Teilsystem dazu, welches wieder neue 
Fehlermöglichkeiten einbringt.

[Alex K. (rie)]

Danke, werde ich gucken, dass ich was finde wie ich das verbinden kann

[Karl H. (kbuchegg)]

Und das hier

#include <avr/io.h>
#include <avr/interrupt.h>
#define F_CPU 1000000UL
#include <util/delay.h>

int main(void)
{
  
//USART initialisieren
UBRRH=0;
UBRRL=0b00011001;
UCSRB=(1<<TXEN);
UCSRA=(1<U2X);

schreibst du besser so

#define F_CPU 4000000UL
#define BAUD  4800

#include <avr/io.h>
#include <util/delay.h>
#include <util/setbaud.h>

int main(void)
{
  //USART initialisieren
  UBRRH = UBRRH_VALUE;
  UBRRL = UBRRL_VALUE;

#if USE_2X
   UCSRA |= (1 << U2X);
#else
   UCSRA &= ~(1 << U2X);
#endif

  UCSRB = (1 << TXEN);
...

der Unterschied dürfte augenscheinlich sein. Keine Binärkoknstanten, 
sondern ordentliche Zahlenwerte. Solange F_CPU und BAUD der Realität 
entsprechen, rechnen sich die Makros die Werte für UBRRH bzw. UBRRL 
selber aus, bzw. ob U2X einen kleineren Fehler bringt, so dass du dort 
keinen Fehler machen kannst. Was dann auch das Verändern von zb der 
Baudrate einfach macht: bei BAUD einfach nur eine andere Baudrate 
eintragen und den Rest erledigt der Compiler. Mit der tatsächlichen 
Berechnung der Werte, die in die Register zu laden sind, hast du selbst 
gar nichts mehr zu tun.


PS.
Hast du bemerkt, dass in

  UCSRA=(1<U2X);

keine Verschiebeoperation steht?
Ich auch nicht. Erst als ich diesen Beitrag geschrieben habe, ist es mir 
aufgefallen, als ich deinen Code ein wenig zurechtgerückt habe.
Fazit: Es ist unklug, alles dicht an dicht zu schreiben, auch wenn es 
die Sprache erlaubt. Seit du 6 Jahre alt bist, hast du dein Gehirn 
darauf trainiert, dass beim Lesen zwischen Wörtern ein Leerraum steht. 
Nutze das doch, in dem du es deinem Gehirn erst mal leichter machst, die 
einzelnen Bestandteile einer Anweisung (die Wörter) ohne großen Aufwand 
zu identifizieren. So

  UCSRA = (1 < U2X);

sieht man viel schneller, dass die rechte Seite keine 
Verschiebeoperation ist, sondern ein Vergleich. Und der ist natürlich an 
dieser Stelle falsch.

Ja! Eine ordentliche Programmoptik kann den Unterschied zwischen Fehler 
finden und Fehler nicht (oder nur sehr schwer) finden ausmachen.

[Mark R. (stevestrong)]

Oder wenn Du einen Oszilloskop hast, einfach an ATTiny Tx ranhängen und 
Baudrate prüfen.

[Karl H. (kbuchegg)]

Karl Heinz schrieb:

> Ja! Eine ordentliche Programmoptik kann den Unterschied zwischen Fehler
> finden und Fehler nicht (oder nur sehr schwer) finden ausmachen.


Hier dasselbe

void USART_Transmit()
{
while(!(UCSRA & (1<<UDRE)));
UDR=0b00110000;
}

wenn du das Zeichen '0' übertragen willst, dann schreibs auch so!

void USART_Transmit()
{
  while(!(UCSRA & (1<<UDRE)))
    ;

  UDR = '0';   // oder UDR = 'a'; 
}

es gibt keinen Grund, warum du hier selber den ASCII Code eines Zeichens 
einsetzen sollst. Und dann noch dazu in Binärschreibweise. Das grenzt 
doch schon an mutwilliges Prügel zwischen die Beine werfen!

[Alex K. (rie)]

Danke Leute für all die guten Tipps werde sie alle beherzigen.

Hab so weit alles umgesetzt.. Fehler noch da..

Das mit dem Oszilloskop müsste ich mal probieren eins aufzutreiben, wenn 
ich so nicht voran komme.

[Alex K. (rie)]

Ich weiß nicht warum aber jetzt funktioniert es!

Ich habe nur Fuses geändert von 4MHz auf 8MHz und dann natürlich auch 
#define F_CPU 8000000UL und jetzt kommt auch das an was ich abschicke!

Hat jemand ne erklärung dafür? Konnte der µC die 4MHz nicht genaugenug 
generieren?