Atmega328P + HC-06 (Bluetooth-Modul)

[Sören K. (foxalem)]

Moin liebe Community.
Ich habe mir gestern den halben Tag um die Ohren gehauen und mir einen 
abgebrochen meinen Atmega328P mit dem HC-06 Modul zu verbinden.
Ich dachte es kann ja nich so schwer sein, einfach einen Char/String 
über USART an den HC-06 zu schicken und der gibts raus per Bluetooth an 
diverse Peripherie.

Wie auch immer, ich komm nichtmehr weiter, denn ich bekomm nur (zum 
Glück gleichmäßigen) mist raus, wenn ich dem uC etwas schicke. Das 
Programm soll lediglich das empfangene Zeichen wieder zurückschicken. 
(code: siehe unten)

Das Kurriose von 0x80 - 0xFF, kommen die Zeichen korrekt zurück, von 
0x00 - 0x79 kommen die Zeichen mit +0x80 zurück.

Ist also Bit7 (8.Bit) des zu übertragenden zeichens(byte) nicht gesetzt, 
so wird dies dazuaddiert.

Eine weitere merkwürdigkeit ist folgende:
0x80 wird gesendet, 0x00 empfängt der uC, schickt dies zurück und 0x80 
kommt wieder an.
Dies hängt also auch wieder mit dem 8.Bit zusammen.

Lange rede kurzer Sinn: Das byte wird zwischen dem uC und dem HC-06 
während der übertragung anscheinend "geshiftet". Allerdings ist davon 
nur der 2. nibble betroffen.

Ich habe gestern diverse Sachen überprüft:
- Stimmt die eingestellte Frequenz des uC's (ich benutze die 
system-clock von 1MhZ)
- Stimmt die BAUD-Rate (Angeblich 9600Baud, habe es aber mit div. 
anderen auch probiert)
- Stimmt die Berechnung der BAUD-Rate.

Der uC befindet sich auf meinem AVR-Dragon im DebugWIRE mode (aus dem 
ich ihn mit AmtelStudio6.1 nichtmehr raus bekomme -.-). Im Schaltplan 
habe ich lediglich ein Schema dargestellt, wie er weiter mit dem 
BT-Dongle 
(http://www.amazon.de/XINTE-Drahtlose-Bluetooth-Serial-Arduino/dp/B00H07UJL6/ref=sr_1_1?ie=UTF8&qid=1390934427&sr=8-1) 
verbunden ist.

Ich werde nicht schlau aus dem Spaß. Vielen Dank schonmal für die Hilfe, 
die ich hier sicherlich bekommen werde.

P.s.: Die eingstellten BAUD im screenshot von HTerm bezieht sich auf die 
Bluetooth-Verbindung.

/*
 * Bluetooth_Dongle_test.cpp
 *
 * Created: 18.01.2014 16:59:18
 *  Author: h0d3nt3uf3l
 */ 

#define F_CPU 1000000
#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#define BAUD 9600
#define MYUBRR F_CPU/16/BAUD-1

uint8_t data;


void USART_Init(unsigned int ubrr)
{
  /*Set baud rate*/
  UBRR0H = (unsigned char)(ubrr>>8);
  UBRR0L = (unsigned char)(ubrr);
  /* Enable receiver and transmitter  & Interrupts for RX & TX*/
  UCSR0B = (1<<RXEN0) | (1<<TXEN0) | (1<<RXCIE0) | (1<< TXCIE0);
  /* Set frame format: 8data, 1stop bit */
  UCSR0C = (1<<UCSZ00) | (1<<UCSZ01);
  
}

void USART_transmit()
{
   UDR0 = (data);
}

int main(void)
{

sei();

USART_Init(MYUBRR);
_delay_ms(10);
  
    while(1)
  ;
}

ISR(USART_RX_vect) //Receive complete
{
  data = UDR0;
  USART_transmit();
}

ISR(USART_TX_vect) //Transmit complete
{
  data = 0;
}

[Sören K. (foxalem)]

So,
nach weiteren Stunden des Hirn zermaterns, habe ich den Fehler gefunden.

Ich habe bei den Fuses die CKDIV8 deaktiviert. Somit läuft die system 
clock (verantwortlich für die clocks beim BAUD generator) mit 8Mhz.
Die 8Mhz habe ich im programm als F_CPU übernommen sodass meine MYUBRR 
richtig berechnet wird. Und dann hat es endlich funktioniert.
Ich bekomme nun eine Fehlerfreie Übertragung.

Auch das Problem des wechselns von debugWIRE auf ISP konnte ich lösen.
Ich hab meinen uC direkt auf dem avrdragon drauf (über einen angelöteten 
sockel und diversen stiftleisten zum verdrahten)
Dieser Aufbau ist wohl von AtmelStudio so nicht gedacht, da man es ja 
normalerweise über eine ISP-Stecker macht.
Wenn ich nun den VTS-Stift (von der ISP-Schnittstelle auf dem dragon) 
mit externen 5V belege, kann ich zwar per AtmelStudio immernoch nicht 
die funktion "Disable debugWire and Close", allerdings kann ich über 
avrdude mit dem befehl "avrdude -c dragon_isp..." den ISP-Mode wieder 
aktivieren (Achtung: Muss zwei mal gemacht werden, da es beim ersten mal 
den uC in den ISP-Mode zu versetzen versucht)
Danach (VTS wieder auf VCC vom dragon stecken) konnte ich wieder wie 
gewohnt über AtmelStudio "DeviceProgramming" auf die Fuses zugreifen und 
DWEN wieder deaktivieren.

Mfg
Sören