Linvor Bluetooth Modul antwortet Atmega8 nicht wie erwartet

[Frank G. (darksban)]

Hallo,

ich versuche mit einem DC3.6V-6V Mini Wireless Bluetooth Transceiver 
Modul rs232 Bluetooth Modul 
[http://www.ebay.de/itm/DC3-6V-6V-Mini-Wireless-Bluetooth-Transceiver-Modul-rs232-TTL-/251208178554?pt=Wissenschaftliche_Ger%C3%A4te&hash=item3a7d2c9b7a], 
eine serielle Verbindung zwischen einem Atmega8 und einem Android Handy 
herzustellen.

Es gelingt mir offenbar, eine Verbindung von meinem Handy zum Bluetooth 
aufzubauen. Wenn ich Daten via Bluetoothterminal an das Linvor – Modul 
sende, kommen auch Daten (oder zumindest irgendetwas) am Mikrocontroller 
an, d.h. Serial.available gibt einen Wert größer 0 zurück. Jedoch kommen 
nicht die Daten, die ich gesendet habe an. Ich habe versucht, mit Hilfe 
der ctype.h Funktionen herauszufinden, was ankommt aber alle Funktionen 
geben ein FALSE zurück. Ich habe insgesamt drei 
Android-Bluetooth-Terminals getestet.

Das Bluetooth-Modul antwortet auch nicht auf AT-Commands. Wenn ich z.B. 
Serial.println(“AT“) an das Modul sende, kommen keine Daten zurück. Also 
Serial.available()=0.

Hier der Code, den ich verwende:

#include <ctype.h>
#define FALSE 0
#define TRUE  1

char val;         // saves incoming data
int ledPin = 9;
int alphaNumPin=10;
int ledDataReadPin =5; // The led which we are going to turn on and off via bluetooth
int dataRead;
int i;
int ledCount;

signed char cHighLow=1;

void setup() {
  dataRead=0;
  pinMode(ledPin, OUTPUT);  // use pin 13 as output
  Serial.begin(9600);       // the bluetooth module default rate is 9600
  digitalWrite(ledDataReadPin, HIGH);    // turn the LED off by making the voltage LOW
  digitalWrite(alphaNumPin, HIGH);    // turn the LED off by making the voltage LOW
  digitalWrite(ledPin, HIGH);
  Serial.println('AT');

  }

  void loop() {
    // only do something if incoming data is available
    if( Serial.available() > 0) {
      val = Serial.read();

      if (isalpha(val) == TRUE) {
        digitalWrite(alphaNumPin, LOW);
      }
      else if (iscntrl(val) == TRUE) {
        digitalWrite(alphaNumPin, LOW);
      }
      else if (isgraph(val) == TRUE) {
        digitalWrite(alphaNumPin, LOW);
      }
      else if (isprint(val) == TRUE) {
        digitalWrite(alphaNumPin, LOW);
      }
      else if (ispunct(val) == TRUE) {
        digitalWrite(alphaNumPin, LOW);
      }
      else if (isspace(val) == TRUE) {
        digitalWrite(alphaNumPin, LOW);
      }
      else {
        digitalWrite(alphaNumPin, LOW);
        delay(80);
        digitalWrite(alphaNumPin, HIGH);
        delay(80);
        digitalWrite(alphaNumPin, LOW);
        delay(80);
        digitalWrite(alphaNumPin, HIGH);
      }

      if ( val == '0' ) {
        digitalWrite(ledPin, LOW);
      }
      else if ( val == '1')
        digitalWrite(ledPin, HIGH);
    }
    delay(10);
  }

Meine Vermutung ging dahin, dass möglicherweise eine falsche BAUD-Rate 
eingestellt sein könnte. Allerdings ändert auch die Verwendung von 
anderen BAUD-Raten nicht viel. Bei 1200 und 2400 kommt nichts mehr am 
Controller an. Bei 4800 bis 38400 zeigt sich das gleiche wie oben 
beschriebene Verhalten. Bei höheren BAUD-Raten kommen offenbar mehr 
Daten an. Jedenfalls wird die Datenverarbeitungsschleife mehrfach 
durchlaufen.

Lediglich bei der BAUD-Rate 460800 wurde der if-Block mit der Bedingung 
val=“0“ durchlaufen,. Die Ctype-Funktionen haben aber auch hier alle 
FALSE zurückgegeben, was in mir Zweifel verusacht hat, ob ich die 
Funktionen korrekt verwende. Das Senden von 1 schaltet die LED aber auch 
nicht wieder an.

Der Code wurde mit dem Arduino-Compiler erstellt. Ich verwende aber 
keinen Arduino, sondern habe den Controller auf einem Breadbord 
programmiert. Die Installation dürfte korrekt sein, da es gelingt, von 
meinem PC einzelne LEDs gezielt zu kontrollieren.

Das Bluetooth-Modul ist wie folgt angeschlossen. VCC an +5V, Ground an 
Ground, TX-Bluetooth an RX-Controller, RX-Bluetooth an TX-Controller. 
Die RX-TX-Verknüpfung habe ich überprüft. Das Vertauschen von beiden 
führt zu einem sehr hochfrequenten flackern der LED am Bluetoothmodul 
und es kommen keine Daten mehr an. Ich habe festgestellt, dass RX und 
TX, wenn keine Daten gesendet werden HIGH sind. Ist das korrekt oder 
liegt evtl. der Fehler im Setup von RX und TX am Controller?

Um einen Fehler bei der RX-TX –Verschaltung noch weiter auszuschließen, 
nochmal etwas Präziser: Wenn ich die Kerbe des Controllers anschaue und 
diese oben ist, dann habe ich TX-Bluetooth an den zweiten Pin von links 
oben und RX-Bluetooth an den dritten Pin von links oben angeschlossen.

Der Controller arbeitet mit einer Geschwindigkeit von 1000MHz

Abschließend noch der Hinweis, dass ich mich erst seit einigen Wochen 
mit Microcontroller-Programmierung befasse und auch die Sprache C noch 
fremd für mich ist. Dementsprechend könnten auch Dinge die erfahrenen 
Controllerprogrammieren banal escheinen verkehrt sein.

Jede Hilfe ist willkommen. Ich stoße langsam an die Grenze meiner 
Kreativität :)

[Sebastian W. (sebastian_w27)]

1000Mhz? Das wäre sehr viel für einen AVR.

Wenn du 1000Khz = 1Mhz meinst, dann liegt da auch das Problem. Es kann 
nicht aus jeder Taktrate jede Baud Rate generiert werden. Aus einem 
Prozessortakt von 1Mhz kann keine Baudrate von 9600kbps generiert 
werden. 2Mhz würde gehen. Oder 8Mhz.

Die Schnittstelle empfängt ansonsten nämlich nur Müll.

Habe selber schon mit dem Linvor ein paar Sachen gemacht. Eigentlich 
klappt das ganz gut. Beachte, dass das Modul erst seine Antwort auf "AT" 
schickt, wenn eine Sekunde lang nichts mehr an das  Modul gesendet wird. 
Also:

"AT" schreiben
1 Sekunde warten in der nichts gesendet wird
"ATOK" sollte zurück kommen


Gruß

[Frank G. (darksban)]

Hallo Sebastian,

natürlich 1MHz. Ich habe eigentlich vorher extra nochmal nachgeschaut. 
Irgendwie sind mir die Nullen dann doch noch drangerutscht...

Ich hatte bisher zuviel Respekt, um mich an den Fuses zu vergehen aber 
ich habe mich dann heute abend mal drangewagt und den Chip jetzt auf 
8MHz eingestellt. Leider ändert sich nur, dass die LEDs jetzt schneller 
blinken.

Ist es möglich, dass die Serial-Klasse in irgendeiner Weise auf die 
Arduinoboards zugeschnitten ist? Wenn mich morgen niemand davon abhält, 
werde ich mal versuchen, den Code im Atmel-Studio lauffähig zu bekommen. 
Heute Abend hat es über implizite Deklarationen gemeckert. Du kennst 
nicht zufällig ein Tutorial, bei dem ich die Entsprechungen für 
digitalWrite und die Serial-Klasse finden kann?

Auf jeden Fall schonmal vielen Dank für deine Hilfe!!

[Sebastian W. (sebastian_w27)]

Hi


leider hab ich nicht viel Zeit. Aber auf die schnelle:

1. RX und TX müssen HIGH sein wenn nichts gesendet wird. Das ist normal 
und richtig so.

2.Ich glaube nicht das die Serial-Klasse auf Arduino Boards 
zugeschnitten ist. Das macht keinen Sinn.

3. Eigentlich dürften dein LEDs nicht schneller blinken wenn du den Takt 
änderst, denn der Compiler müsste Automatisch die Delays auch neu 
berechnen. Wenn du im Projekt einen andern Prozessortakt einstellst. 
(Hast du das gemacht?) Warum blinken da überhaupt LEDs? Sollte doch nur 
die eine Blinken wenn du was empfängst, oder?

4. Ich benutz weder Arduino noch Atmel Studio. Also zu dem Bereich kann 
ich Dir nicht viel weiter helfen. Aber die entsprechungen zu 
digitalWrite und den Serial klassen sollten relativ simpel ausfallen.


Gruß

[Frank G. (darksban)]

Hallo,

also ich bin mir ziemlich sicher, dass die schneller geblinkt haben. Die 
Delay-Funktion von Arduino hat, als der Chip auf 1MHz getaktet war, auch 
nicht mit der tasächlich Zeit übereingestimmt. Ich werde das später 
nochmal überprüfen.

Ich habe mir in den letzten Abenden aus verschiedenen Beiträgen 
folgenden Code zusammenkopiert, der mindestens so seltsame Ergebnisse 
produziert wie vorher der Arduino-Code:

#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert 
   (z. B. durch Übergabe als Parameter zum Compiler innerhalb 
   des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
   "nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 8000000UL     /* Takt 8 Mhz */
#endif
#include <util/delay.h> 

int main (void)                   // <=== (1)
{
  DDRB = 0xFF;                    // PORTB Ausgang <=== (2)
  DDRC = 0xFF;

  UCSRB |= (1<<RXEN);             //Empfangen aktivieren
  UCSRC |= (1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1); // 8N1
  UBRRH = (unsigned char)(51>>8);
  UBRRL = 51;

  while (1)                       // <=== (3)
  {
    long_delay(500);
    PORTC |= ( (1<<PC0) | (1<<PC1) | (1<<PC2) | (1<<PC3) );
    PORTB |= ( (1<<PB0) | (1<<PB1) | (1<<PB2) | (1<<PB3) ); 
    long_delay(150);
    PORTC &= ( ~(1<<PC0) & ~(1<<PC1) & ~(1<<PC2) & ~(1<<PC3) );
    PORTB &= ( ~(1<<PB0) & ~(1<<PB1) & ~(1<<PB2) & ~(1<<PB3) );

    while ( !(UCSRA & (1<<RXC)) ) { //warten bis senden fertig
      long_delay(300);
      PORTC |= ( (1<<PC0) | (1<<PC1) | (1<<PC2) | (1<<PC3) );
      long_delay(300);
      PORTC &= ( ~(1<<PC0) & ~(1<<PC1) & ~(1<<PC2) & ~(1<<PC3) );
      long_delay(300);
      PORTB = UDR;
      PORTC = ( UDR >> 4);                 //Zeichen auf PORTB-LEDs anzeigen
      long_delay(2000);
    }
        //
  }
}

void long_delay(uint16_t ms)
{
  for(; ms>0; ms--) _delay_ms(1);
}

Ich habe dann auf meinem Breadboard 8 LEDs angebracht. Da der Atmega8 
nur an Port B 8 Ein- und Ausgänge hat, die unglücklicherweise teilweise 
auch für die Programmierung des Chips notwendig sind, habe ich 4 grüne 
für die 4 hohen Bits an Port C und 4 rote für die 4 niedrigen Bits an 
Port B angschlossen.

Wenn ich den Chip nun starte, blinken gemäß Intention zuerst 1 mal alle 
8 LEDs. Danach wird (nicht gemäß Intention) die Schleife für das 
empfangen von Daten durchlaufen. Dort blinken wieder wie gewollt erstmal 
alle grünen LEDs. Allerdings bleibt dann das Programm in der Schleife 
und wiederholt das Blinken der grünen LEDs.

Erst wenn ich von meinem Handy Daten an den Linvor-BT sende, wird die 
Schleife verlassen. Soweit kenne ich das ja schon vom Arduino-Code. Wenn 
ich nun ein "a" (&h61 gemäß ASCII-Tabelle) sende, würde ich eigentlich 
eine 0110.0001 zurückerwarten. Stattdessen erhalte ich eine 0000.0001. 
Ich kann so korrekt bis "z" hochzählen, nur dass nie die hohen 4 Bits 
gesetzt werden. Wenn ich nun eine "1" (&h31) sende, würde ich 0011.0001 
erwarten, erhalte aber 0000.0001. Bis "9" lässt sich wieder korrekt 
hochzählen. Ab "10" aufwärts erhalte ich nur noch 0011.0001.

Man könnte meinen, dass einfach mit den 4 hohen Bits etwas nicht stimmt, 
aber wenn ich "A" (&h65) an den Bluetooth sende, würde ich 0110.0101 
erwarten und erhalte (man halte sich fest) wieder 0000.0001.

Egal wieviele Zeichen ich sende, ich erhalte nur ein Byte vom Linvor. 
Nur bei einer leeren Zeile, kann ich ein weiteres Byte empfangen, aber 
die Empfangs-Schleife wird nicht verlassen. Nach dem Empfangen aller 
anderen Daten, tritt das Programm nie wieder in die Empfangs-Schleife 
ein, egal wieviele Daten man noch sendet. Es blinken in regelmäßigen 
Abständen 8 LEDs bis zum jüngsten Gericht oder bis ich meine 
Stromrechnung nicht mehr bezahle.

Da tun sich einige Fragen auf:

1) Warum tritt das Programm in die Schleife für das Empfangen von Daten 
ein, wenn noch gar keine Daten gesendet wurden?
2) Wenn das Programm schon in diese Schleife eintritt, warum holt es 
dann keine Daten heraus, sondern faulenzt in der Schleife rum?
3) Woher kommen die seltsamen Muster, beim Senden der Zeichen?
4) Warum tritt das Programm nach dem einmaligen Empfang nicht wieder in 
die Schleife ein?
5) Muss ich mir einen neuen Bluetooth kaufen?
6) Liest überhaupt irgendwer diesen Roman?

Vielen Dank für jede konstruktive Antwort!

[Equinox (Gast)]

Hi Frank

ich bin weiß gott kein C-Guru wie viele andere hier, insofern bitte 
meine Hinweise mit Vorsicht genießen. Aber im Rahmen eines Praktikums 
hab ich auch gerade mit dem USART zu tun, deshalb denke ich das ich dein 
Programm nachvollziehen kann.

Ich denke, dass du dir die while-Schleife nochmal vornehmen solltest, 
mit der du die Nachrichten ausliest.

while ( !(UCSRA & (1<<RXC)) ) {
 --> wenn in RXC-Flag eine 0 steht, dann gehe durch diese Schleife. 
Sprich, er geht solange durch die Schleife, wie das Flag sagt "mein 
Puffer ist noch nicht voll"

Ich denke das erklärt auch die seltsamen Muster die du auf deinen LED's 
erhälst, du holst ja permanent Daten aus deinem Empfangsregister, auch 
wenn es noch nicht voll ist.
Frage an alle, da ich es nicht weiß: Kann es sein, dass das UDP-Register 
mit jedem Lesevorgang wieder mit 0 initialisiert wird ? Hier hätte es ja 
dann garnichts die Chance ein ganzes Byte zu empfangen, da es ja 
permanent halb gefüllt ausgelesen, und dann vielleicht erneut 
initialisiert wird ? Würde auch erklären, dass du in deine 
while(1)-Schleife nicht mehr rein kommst.

Meine Vermutung wäre jedenfalls, dass das Problem da zu suchen ist. Die 
Negation im Schleifenkopf weg zu nehmen dürfte schon helfen.

[Stefan (Gast)]

Mit dem 8Mhz R/C Oszillator kannst Du auch nicht ordentlich seriell 
kommunizieren. Du musst einen Quarz verwenden, vorzugsweise einen mit 
14,768Mhz.

Welche seriellen Bitraten bei welchen Quarzen gehen, kannst Du dem 
Datenblatt des Mikrocontrollers entnehmen. Dazu gibt es extra eine 
Tabelle und ein paar Sätze Erklärung dazu.

Beim compilieren des Quelltextes muss die Taktrate bekannt sein, da der 
Code dementsprechend angepasst wird. Wenn Du danach die Taktrate 
änderst, funktioniert die Initialisierung des seriellen Ports nicht 
mehr. Du musst dann neu compilieren.

Wenn Du den Quarz oder den R/C Oszillator änderst, wird warscheinlich 
auch der Bootloader des Arduino nicht mehr funktionieren. Du brauchst 
dann einen ISP Programmer.

[Frank G. (darksban)]

Hallo,

so wie ich das Datenblatt S. 153 
[http://www.atmel.com/Images/Atmel-2486-8-bit-AVR-microcontroller-ATmega8_L_datasheet.pdf] 
interpetiere, lässt sich der Atmega8 sogar schon ab 1MHz mit 9600 BAUD 
betreiben. Mit 8MHz sogar schon mit einer ziemlich niedrigen Fehlerrate. 
Korrigiert mich, wenn ich das Datenblatt falsch lese.

Ich habe meinen Code nocheinmal ein wenig modifiziert und um eine gelbe 
LED an Port C4 ergänzt:

#include <avr/io.h>
#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert 
   (z.&nbsp;B. durch Übergabe als Parameter zum Compiler innerhalb 
   des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
   "nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 8000000UL     /* Takt 8 Mhz */
#endif
#include <util/delay.h> 

int main (void)                   // <=== (1)
{
  DDRB = 0xFF;                    // PORTB Ausgang <=== (2)
  DDRC = 0xFF;

  UCSRB |= (1<<RXEN);             //Empfangen aktivieren
  UCSRC |= (1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1); // 8N1
  UBRRH = (unsigned char)(51>>8); //9600 BAUD
  UBRRL = 51; //9600 BAUD
  
  unsigned char cReceive;


  while (1)                       // <=== (3)
  {
    cReceive=0;
    if ( !(UCSRA & (1<<RXC)) ) { //warten bis senden fertig
      long_delay(300);
      PORTC |= ( (1<<PC0) | (1<<PC1) | (1<<PC2) | (1<<PC3) );
      
      long_delay(300);
      PORTC &= ( ~(1<<PC0) & ~(1<<PC1) & ~(1<<PC2) & ~(1<<PC3) );
      PORTB &= ( ~(1<<PB0) & ~(1<<PB1) & ~(1<<PB2) & ~(1<<PB3) );
      long_delay(700);
      cReceive=UDR;
      PORTB = cReceive;
      PORTC = ( cReceive >> 4);                 
      long_delay(2000);
    }

      PORTC |= (1<<PC4);
      long_delay(500);
      PORTC &= ~(1<<PC4);
      long_delay(150);
  }
}

Equinox hatte einen ganz guten Riecher... Das UDR Register wird nach 
jedem lesen gelöscht und mit neuen Daten aus dem Puffer versorgt, was zu 
meinen seltsamen Daten vom letzten mal geführt hat. Durch das 
Zwischenspeichern der Daten werden Sie nun korrekt auf den Ports 
dargestellt.

Beim Start des Controllers geht auch bei diesem Code das Programm zuerst 
in die Datenempfangsschleife, obwohl noch keine Daten gesendet wurden 
aber wie die gelbe LED anzeigt, verlässt es die Schleife nach dem ersten 
Durchlauf und tritt beim nächsten mal wieder in sie ein, obwohl immer 
noch keine Daten gesendet wurden. Das wird immer weiter fortgesetzt, 
solange keine Daten gesendet werden.

Die Schleife wird aber immer noch nicht mehr Durchlaufen, nachdem das 
erste Zeichen gesendet wurde. Ich sehe das auch hier grundsätzlich so 
wie Equinox, dass ein Problem mit dieser Schleife zu besetehen scheint. 
Allerdings kommt der Code hierfür direkt aus dem Datenblatt S. 139.

unsigned char USART_Receive( void )
{
/* Wait for data to be received */
while ( !(UCSRA & (1<<RXC)) )
;
/* Get and return received data from buffer */
return UDR;
}

Jedenfalls sollte die Modifikation mE irrelevant sein. Es scheint also 
aus irgendeinem Grund im Moment ein Problem mit dem RXC Flag (Receive 
Complete) im UCSRA Register zu bestehen, da dieses nicht gesetzt ist, 
wenn der Controller gestartet wird und nachdem es einmal gesetzt wurde, 
nicht mehr gelöscht wird, wenn neue Daten in den Puffer gelangen. Und 
die gelangen in den Puffer. Wenn ich einfach ohne die While Schleife das 
UDR Register immerwieder abfrage, erhalte ich, wenn Daten gesendet 
werden, häufig korrekte Resultate, wenn auch nicht immer.

@Equinox: Du solltest dein Praktikum weiter machen. Es scheint nicht 
schlecht zu sein ;)

[Frank G. (darksban)]

Hallo,

ich habs dann doch noch hinbekommen, nachdem das große schwere 
Eichenbrett von der Stirn gefallen ist.

Ich habe mich darauf versteift, dass in der While-Schleife Daten 
abgerufen werden, obwohl die ja nichts tut außer darauf zu warten, dass 
Daten eintreffen.

Falls es noch mehr Bluetooth-Leute mit Brettern vor den Köpfen gibt, 
hier der Code, der bei mir funktioniert:

#include <avr/io.h>
#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert 
   (z.&nbsp;B. durch Übergabe als Parameter zum Compiler innerhalb 
   des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
   "nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 8000000UL        // Takt 8 MHz
#endif
#include <util/delay.h> 

// Funktion um die Daten aus dem Lesepuffer des Chips abzurufen
unsigned char USART_Receive( void )
{
  while ( !(UCSRA & (1<<RXC)) )
  ;
  return UDR;
}

//Hauptprogramm
int main (void)
{
  //Initialisierung
  DDRB = 0xFF;            // PORTB Ausgang 
  DDRC = 0xFF;            // PORTC Ausgang

  UCSRB |= (1<<RXEN);          // Empfangen aktivieren
  
  UCSRC |= (1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1);  // 8N1
  
  UBRRH = (unsigned char)(51>>8);    // 9600 BAUD s.h. Datenblatt Atmega8 S.155
  UBRRL = 51;              // 9600 BAUD s.h. Datenblatt Atmega8 S.155
  
  unsigned char cWord[255];
  int i = 0;
  int z = 0;
    
  //Programmschleife
  while (1)                       
  {
    cWord[i]=USART_Receive();    // Warteschleife bis Daten empfangen werden
    if (cWord[i]==33) {        // Ein "!" (ASCII 33) als einfaches Steuerzeichen signalisiert das Ende der Zeichenfolge
      for (z=0;z<i;z++){
        PORTB = cWord[z];    // Die vier niedrigen Bits auf den ersten 4 Ausgängen von Port B ausgeben
        PORTC = (cWord[z]>>4);  // Die vier hohen Bits auf den ersten 4 Ausgängen von Port C ausgeben
        long_delay(2000);
      }
      i=0;
    } else {
      i++;
    }      
    
  }
}  

// Delay Funktion, um Pausen in den Programmablauf einzubauen
void long_delay(uint16_t ms)
{
  for(; ms>0; ms--) _delay_ms(1);
}

Sonst hat noch das erste von mir verwendete Android-Terminal-Programm, 
mit dem ich die Daten an den Controller gesendet habe, ein wenig 
Probleme bereitet, weil es eigene Steuerzeichen zum Abschluss der 
Zeichenfolge gesendet hat. Mit "S2 Bluetooth Terminal3" hats dann 
schließlich funktioniert.

[Rufus Τ. F. (rufus)]

Frank G. schrieb:
> #warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
> #define F_CPU 8000000UL        // Takt 8 MHz

Meinst Du, daß das so sinnvoll ist?

[Frank G. (darksban)]

Ich gebe zu, dass ich die Definition des Takts im Code bislang für 
sinnvol gehalten habe. Falls es dir nur um die offensichtlich 
widersprüchlichen Angaben geht, muss ich zugeben, dass mir das beim 
Drüberschauen durch die Lappen gegangen ist. Leider lässt sich das nun 
nicht mehr editieren.

Wenn du das aus irgendeinem anderen Grund für Unsinn hältst, wäre es 
nett, wenn du erklärst warum. Noch netter wäre es, das zu tun bevor du 
Ahnungslose, zu denen ich wie eingangs festgestellt zweifellos zähle, 
spekulieren lässt.