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!
Angehängte Dateien:
-
H_Term.PNG
82 KB
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?
Angehängte Dateien:
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.
uC-Anwender schrieb: > #define F_CPU 8000000UL Ich würde das so umdefinieren: #define F_CPU "ungefähr 8MHz" Hat's bezüglich der Baudrate geklingelt?
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.
Angehängte Dateien:
-
Schaltplan_BT.png
44 KB
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.