Hallo liebes Forum,
ich habe ein Problem mit meinem uC, welcher durch ein Bluetooth-Modul
Daten senden und empfangen soll. Andere Beiträge im Forum konnten mir
bisher auch nicht weiterhelfen. Folgende Situation liegt vor:
Ich verwende einen ATMega88 mit einem internen Takt von 8 MHz. Daran
habe ich das Bluetooth-Modul RN 42 von Sparkfun angeschlossen. Dies ist
ein 0815 Bluetooth-Modul: Arbeitet mit 3,3V und ist auf 9600 Baud und
8N1 eingestellt. Die am BT-Modul ankommenden Pegel werden durch einen
Spannungsteiler auf 3,3V heruntergeteilt. Die vom BT-Modul ausgehenden
Signale werden direkt an den uC angeschlossen. Da dieser mit 5V arbeitet
erkennt dieser Spannungen größer Ub/2 als logische 1. Das
Bluetooth-Modul stammt aus einer vorhergehenden Arbeit, bei der das
Modul einwandfrei gearbeitet hat. Am Modul sollte meiner Meinung nach
der Fehler also nicht liegen.
An das BT-Modul werden lediglich die TX- und RX-Leitungen sowie die
Versorgungsspannung angeschlossen. Die Anbindung an den uC erfolgt über
die UART-Schnittstelle. RX wird mit TX und TX wird mit RX verbunden.
Auf meinem PC (Windows 7) verwende ich die Tools H Term als auch Tera
Term. Bei beiden kann ich mich mit dem BT-Modul verbinden. Nun kann ich
Daten vom uC an den PC senden --> funktioniert einwandfrei. Jedoch kann
ich keine Daten vom PC an den uC senden.
Testweise habe ich auf einem zweiten PC (MAC OS X) Cool Term (ähnlich
wie Tera Term und H Term) installiert. Auch hier kann ich mich mit dem
BT-Modul verbinden aber nur Daten vom uC empfangen!!!
Hier ist der C-Code für den uC:
#define F_CPU 8000000UL
#include <avr/io.h>
#include <avr/wdt.h>
#include <util/delay.h>
#include "stdlib.h"
#include <avr/interrupt.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#define BAUD 9600UL
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD)
#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
#error Systematischer Fehler zu groß!
#endif
void uart_init(void)
{
UBRR0 = UBRR_VAL;
UCSR0B |= (1<<RXEN0)|(1<<TXEN0) ;
UCSR0C = (1<<UCSZ01)|(1<<UCSZ00);
}
int uart_putc (char data, FILE* stream)
{
while(!(UCSR0A & (1 << UDRE0)));
UDR0 = (char)data;
return 0;
}
unsigned char uart_getc(void) // Zeichen empfangen
{
while (!(UCSR0A & (1<<RXC0))); // warten bis Zeichen verfuegbar
return UDR0; // Zeichen aus UDR an Aufrufer
zurueckgeben
}
//uart_putcund uart_getcals Standard IO eintragen
FILE mystdout = FDEV_SETUP_STREAM(uart_putc, uart_getc, _FDEV_SETUP_RW);
int main(void)
{
int i = 0;
char Buffer [20];
uart_init();
DDRD &= ~(1<<PD0); //PD0 = RX als Eingang
PORTD |= (1<<PD0); //Pullup ein
DDRD |= (1<<PD1); //PD1 = TX als Ausgang
stdout= stdin= &mystdout; // IO Funktionen als Standard IO eintragen
while(1)
{
printf("Test BT 1 \r \n"); //Ausgabe 1
scanf("%d \r \n%", &i); //Eingabe 1
printf("Eingelesen: %d \r \n", i); //Ausgabe 2
}
}
Dazu ist zu Sagen, dass mehr Bibliotheken eingebunden wurden, als
hierfür notwendig sind. Dies liegt daran, dass der uC die empfangenen
Daten wieterverarbeiten soll. Dies sollte erstmal nicht stören.
Auf dem PC kann ich die Ausgabe 1 sprich "Test BT 1" sehen. Wenn ich
bspw. in H Term als Type Dec einstelle und eine Zahl eingebe und mit
Enter bestätige passiert nichts mehr. Ausgabe 2 wird nicht ausgeführt.
Der uC scheint beim Einlesen hängen zu bleiben.
Die Einstellungen in H Term sollten auch stimmem. Dort ist die Baudrate
auf 9600 und 8N1 eingestellt. Es wird die COM4 Schnittstelle des PCs
verwendet.
Im Anhang ist die H Term Konsole zu sehen.
Ich bin über jeden Tipp dankbar!
uC-Anwender schrieb:> An das BT-Modul werden lediglich die TX- und RX-Leitungen sowie die> Versorgungsspannung angeschlossen.
Von einem 5V µC kommend? Dann brennt Dir die RX Leitung wegen
Überspannung durch. Das Datenblatt sagt: VDD+0,4V maximale Spannung,
also deutlich weniger als 4 Volt.
Du hättest da also zwingend einen Pegelwandler einbauen oder den Atmega
mit 3,3V versorgen müssen.
Das Modul ist vermutlich in die ewigen Jagtgründe gegangen.
Hallo,
Jim M. schrieb:> Du hättest da also zwingend einen Pegelwandler einbauen oder den Atmega> mit 3,3V versorgen müssen.
vielleicht hättest Du den Post vom TO komplett lesen sollen?
uC-Anwender schrieb:> Die am BT-Modul ankommenden Pegel werden durch einen> Spannungsteiler auf 3,3V heruntergeteilt. Die vom BT-Modul ausgehenden> Signale werden direkt an den uC angeschlossen. Da dieser mit 5V arbeitet> erkennt dieser Spannungen größer Ub/2 als logische 1.
Gruß aus Berlin
Michael
Jim M. schrieb:> Du hättest da also zwingend einen Pegelwandler einbauen oder den Atmega> mit 3,3V versorgen müssen.
Danke für die schnelle Antwort. Das hatte ich vergessen zu erwähnen. Auf
der Platine mit dem BT-Modul ist ein Pegelwandler verbaut. Es werden
also 5V an der Platine angeschlossen und das Modul wird mit 3,3V
versorgt.
Sonst noch Ideen woran mein Fehler liegen kann?
Im Anhang der Schaltplan. Rechts ist das Bluetooth-Modul zu sehen. Es
handelt sich im Schaltplan um das Modul RN 41 - welches von der
Bedrahtung und der Funktion laut Datenblatt identisch zum RN 42 ist. Wie
schon erwähnt habe ich das BT-Modul und den Schaltplan aus einer
früheren Arbeit übernommen. Das Modul funktionierte damals einwandfrei.
Einen Fehler schließe ich deshalb in diesem Teil des Schaltplans aus.
Links ist der ATmega88. Die ISP-Schnittstelle, die 10er-Buchse sowie die
beiden Taster können erstmal ignoriert werden. Diese sind für die
spätere Ausgabe der übertragenen Daten vorgesehen.
Über Rückmeldungen freue ich mich.
uC-Anwender schrieb:> Da dieser mit 5V arbeitet> erkennt dieser Spannungen größer Ub/2 als logische 1.
Möööp.
Laut Datenblatt Kapitel "DC Characteristics" brauchst du 0,6V x VCC,
damit es sicher als High erkannt wird. Das sind genau 3V.
Normalerweise kommt das hin, weil die mir bekannten Bluetooth Module
deutlich mehr als 3V ausgeben. Doch vielleicht ist das bei deinem Modul
anders. Das kannst du mit einem Multimeter ganz leicht kontrollieren,
denn der Ruhepegel ist ja High.
Ein anderer Knackpunkt könnte deine Empfangsmethode sein. Du verwendest
keinen Empfangspuffer. Das Empfgangsregister des UART wird nur in dem
kurzen Moment gelesen, wo du scanf() aufrufst. Danach kommen zwei
printf() die relativ lange dauern. Wenn du in dieser Zeit mehr als ein
Byte empfängst, geht der größte Teil der Nachricht verloren.
Guck mal von meiner Hello-World Vorlage
(http://stefanfrings.de/avr_hello_world/index.html) ab, da wird das
Gleiche gemacht, aber mit einem kleinen Empfangspuffer. Das läuft
stabil.
PS: Bei der Kompression des Schaltplans hast du etwas übertrieben, er
ist kaum lesbar.
Stefanus F. schrieb:> Normalerweise kommt das hin, weil die mir bekannten Bluetooth Module> deutlich mehr als 3V ausgeben.
Da hast du recht. Das Modul liefert 3,28V am Ausgang - somit ausreichend
für eine logische 1. Ich werde im Laufe dieser Woche mit einem Oszi den
Ausgang messen, um zu sehen, ob das Modul überhaupt Daten empfängt.
uC-Anwender schrieb:> Ich werde im Laufe dieser Woche mit einem Oszi den> Ausgang messen, um zu sehen, ob das Modul überhaupt Daten empfängt.
Bei niedrigen Baudraten reicht dazu eine simple LED. Die könnte
allerdings den High Pegel herunter ziehen, deswegen schließe sie anders
herum an - so dass sie bei Low Pegel leuchtet.
Schrecklich was so alles passiert schrieb:> Hat's bezüglich der Baudrate geklingelt?
Der Compiler hat keinen Fehler gemeldet. Die Abweichung zur realen
Baudrate sollte also im erlaubten Rahmen liegen. Es können ja Daten vom
uC an den PC gesendet werden. Die Baudrate sollte doch somit stimmen?!
9600 baud sollten gehen.
Warum benutzen hier eigentlich alle immer eigene Markos zur Berechnung
der Baudraten-register-Werte benutzt, anstatt einfach die setbaud.h zu
benutzen?
Du solltest aber einen Quarz verwenden. Mit dem R/C Oszillator klappt
das oft aber nicht immer.
uC-Anwender schrieb:> Bildschirmfoto_2019-03-18_um_09.15.44.png
Mit "Schaltplan" meinte ich irgendetwas, bei dem man nicht auf
detektivischen Spürsinn und Vermutungen angewiesen ist, um Signale und
Werte zu erraten :-(
In Eagle gab es - zumindest bis zur Version 6.6 - im Menü "Datei" einen
Menüpunkt "Exportieren ..." / "Image", der - man glaubt es kaum - in der
Lage ist, vernünftig lesbare Schaltpläne als Bild im PNG-Dateiformat zu
erzeugen.
Wolfgang schrieb:> In Eagle gab es - zumindest bis zur Version 6.6 - im Menü "Datei" einen> Menüpunkt "Exportieren ..." / "Image"
Danke für den Hinweis. Im Anhang nochmal der Schalplan in besserer
Qualität.
uC-Anwender schrieb:> Danke für den Hinweis.
Willst du damit sagen du hast es beim ersten Mal nicht gemerkt
was du für einen Scheiss Schaltplan geliefert hast?
uC-Anwender schrieb:> Der Compiler hat keinen Fehler gemeldet. Die Abweichung zur realen> Baudrate sollte also im erlaubten Rahmen liegen.
Käse!
Der Compiler kann gar nichts melden weil er von Baudraten keine
Ahnung hat.
Ob die Abweichung "im erlaubten Rahmen liegt" bekommst du erst
heraus wenn du die reale Taktfrequenz gemessen hast.
Stefanus F. schrieb:> Du solltest aber einen Quarz verwenden. Mit dem R/C Oszillator klappt> das oft aber nicht immer.
Schrecklich was so alles passiert schrieb:> Der Compiler kann gar nichts melden weil er von Baudraten keine> Ahnung hat.
Nicht einmal die Taktfrequenz des µC kennt der Compiler.
Der glaubt blind, was in F_CPU steht.
Eine eigene Frage?
Dieser Thread ist über 7 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
H_Term.PNG
(82 KB)
