USART zwischen Arduino und externem Atmega328p

[Sepp (Gast)]

Morgen...

Habe hier einen Arduino und einen externen Atmega328P-AU

Ich habe ein Programm geschrieben in welchem ich UART testen möchte. Die 
Ini sieht folgendermaßen aus:

Micro:

#define F_CPU 16000000UL
#define USART_BAUDRATE 9600
#define BAUD_PRESCALE F_CPU/16/USART_BAUDRATE-1

------- Alles hier dazwischen in der Ini;
  UCSR0B |= (1 << RXEN0) | (1 << TXEN0) | (1 << RXCIE0);  // UART RX, TX und RX-Interrupt einschalten
  UCSR0C = (1<<UCSZ00) | (1<<UCSZ01);            // 8 Daten  und 1 Stopbits
  UCSR0A = (1<<UDRE0);

  UBRR0H = (BAUD_PRESCALE >> 8);
  UBRR0L = BAUD_PRESCALE;
--------

ISR(USART_RX_vect)                      // ISR UART RX
{
  ui8_UART_In = UDR0;
  if (ui8_UART_In == 48) 
  {
    PORTD = (1<<LED_3);
    ui_TimerUART = 0;
    UART = true;
  }
} Mein Interrupt zur Überprüfung

Arduino bis auf den Interrupt das gleiche...

Sende ich nun per Arduino

UDR0 = 48;

erhalte ich nichts auf dem Mikro... Ich habe schonmal getestet ob er 
überhaupt den Interrupt erkennt, das scheint zu funktionieren. 
Allerdings erhält er komische Werte wenn ich Debugge... So ist es bei 
einer gesendeten 48 zB der Wert 255 was nicht sein kann.

Massen sind verbunden, RX sowie TX richtig angeschlossen -> Anhand 
Interrupt und LED getestet, Baudraten jeweils auf 9600...

Jemand eine Idee woran das liegen kann?

Achja... Habe auch mal ohne meine Mikro-Ini das senden vom Arduino 
getestet mit einfachstem

Serial.begin(9600);
Serial.println(48);

allerdings selbiges Problem.

Wäre um Rat dankbar :)

[Sepp (Gast)]

Keiner eine Idee? :(

[Stefan F. (Gast)]

Alle Rückfragen, die ich in so einem Fall stellen würde, hast du bereits 
positiv beantwortet. An deinem obigen Text kann ich keinen Fehler 
erkennen.

Ich nehme an, dass du keinen Logikanalyzer oder Oszilloskop hast. Aber 
eventuell gelingt es Dir, die seriellen Signale mit den Audio-Eingang 
deines Computer aufzuzeichnen. Mit Programmen wie Audacity kannst du 
dann das Signal als Grafik anzeigen lassen. Das wäre sehr hilfreich.

          100k
Tx o-----[===]-----+--------o Audio Eingang
                   |
                  |~|
                  | | 1k
                  |_|
                   |
GND o--------------+--------o GND

[Marc V. (Firma: Vescomp) (logarithmus)]

Sepp schrieb:
> Keiner eine Idee? :(

 Ich glaube beim Arduino heisst die Routine SerialEvent.
 Rx und Tx verbinden, Zeichen senden, 1 sec warten, loop.

void serialEvent() {
   while (Serial.available())
  {
     PORTB ^= (1<<PB5);
  }
}

 Beim Micro dasselbe, nur:

ISR (USART_RX_vect)
{
    PORTD ^= (1<<LED_3);
}

 und das Ergebnis posten.

[Stefan K. (stefan64)]

Sind die Clocks der beiden ATmega beide auf externen Quarz eingestellt 
und wird bei beiden 16Mhz verwendet?
Ein falsch empfangenes Zeichen deutet auf eine falsche Baudrate hin - da 
Du die bei beiden Controllern auf 9600 stehen hast, kann es ev. an 
unterschiedlichen System-Clocks hängen.

Viele Grüße, Stefan

[Stefan E. (sternst)]

Sepp schrieb:
> So ist es bei
> einer gesendeten 48 zB der Wert 255

CKDIV8-Fuse im Empfänger gesetzt?

[Marc V. (Firma: Vescomp) (logarithmus)]

Stefan K. schrieb:
> Ein falsch empfangenes Zeichen deutet auf eine falsche Baudrate hin - da
> Du die bei beiden Controllern auf 9600 stehen hast, kann es ev. an
> unterschiedlichen System-Clocks hängen.

 Kaum.
 Eine gesendete 0x30 kann niemals als 0xFF empfangen werden, egal
 was für Baudraten und Clocks bei beiden laufen.

 Allerdings kann die Gegenseite die bits 6 und 7 als Startbit deuten
 und deswegen 0xFF als neues Zeichen empfangen - vorheriges Zeichen
 hat Frame Error.
 Dafür muss aber die Baudrate beim Empfänger == Senderbaudrate/2 sein.

 Also Arduino auf 9600B und Micro auf 4800B.
 Oder bei Micro steht 16MHz, aber der Micro läuft mit 8MHz.

[Stefan E. (sternst)]

Marc V. schrieb:
> Eine gesendete 0x30 kann niemals als 0xFF empfangen werden, egal
>  was für Baudraten und Clocks bei beiden laufen.

Klar kann es das. Wenn der Empfänger z.B. wegen der CKDIV8-Fuse um den 
Faktor 8 zu langsam ist, dann fällt das Datenbyte fast komplett in das 
Startbit beim Empfänger. Der kurze High-"Impuls" innerhalb des Startbits 
wird ihn kaum stören, ebenso wenig die Tatsache, dass dann sein erstes 
Datenbit im ersten Achtel Low ist.

Marc V. schrieb:
> Allerdings kann die Gegenseite die bits 6 und 7 als Startbit

Schon die allererste fallende Flanke (also das Sender-Startbit) startet 
auch im Empfänger das Startbit.

[Sepp (Gast)]

Marc V. schrieb:
> Sepp schrieb:
>> Keiner eine Idee? :(
>
>  Ich glaube beim Arduino heisst die Routine SerialEvent.
>  Rx und Tx verbinden, Zeichen senden, 1 sec warten, loop.void
> serialEvent() {
>    while (Serial.available())
>   {
>      PORTB ^= (1<<PB5);
>   }
> }
>
>  Beim Micro dasselbe, nur:ISR (USART_RX_vect)
> {
>     PORTD ^= (1<<LED_3);
> }
>
>  und das Ergebnis posten.

Das ist nicht das wonach ich suchte, da ich nur testen wollte ob das 
Gesendete vom Arduino auch so auf meiner Platine ankommt, aber Danke :)

Stefan K. schrieb:
> Sind die Clocks der beiden ATmega beide auf externen Quarz eingestellt
> und wird bei beiden 16Mhz verwendet?
> Ein falsch empfangenes Zeichen deutet auf eine falsche Baudrate hin - da
> Du die bei beiden Controllern auf 9600 stehen hast, kann es ev. an
> unterschiedlichen System-Clocks hängen.
>
> Viele Grüße, Stefan

Beide Controller werden mit 16MHz versorgt... Arduino sowieso und meine 
Platine mit einem 16MHz Quarzoszi. Fuses alle richtig eingestellt.

Marc V. schrieb:
> Allerdings kann die Gegenseite die bits 6 und 7 als Startbit deuten
>  und deswegen 0xFF als neues Zeichen empfangen - vorheriges Zeichen
>  hat Frame Error.
>  Dafür muss aber die Baudrate beim Empfänger == Senderbaudrate/2 sein.
>
>  Also Arduino auf 9600B und Micro auf 4800B.
>  Oder bei Micro steht 16MHz, aber der Micro läuft mit 8MHz.

Damit hab ich auch schon gerechnet, dass der Arduino andere 
Grundeinstellungen hat, deswegen hab ich die Register neu gesetzt um dem 
vorzubeugen. Leider kein Erfolg...

[Marc V. (Firma: Vescomp) (logarithmus)]

Stefan E. schrieb:
> Klar kann es das. Wenn der Empfänger z.B. wegen der CKDIV8-Fuse um den
> Faktor 8 zu langsam ist, dann fällt das Datenbyte fast komplett in das
> Startbit beim Empfänger. Der kurze High-"Impuls" innerhalb des Startbits
> wird ihn kaum stören, ebenso wenig die Tatsache, dass dann sein erstes
> Datenbit im ersten Achtel Low ist.

 Kann natürlich auch sein, ist sogar wahrscheinlicher, vor allem, da
 ich oben Sender und Empfänger vertauscht habe.
 Allerdings ist das Startbit beim Empfänger im letzten Viertel High und
 das erste Datenbit ist im ersten Viertel Low.
 Passt aber trotzdem.

[Marc V. (Firma: Vescomp) (logarithmus)]

Sepp schrieb:
> Das ist nicht das wonach ich suchte, da ich nur testen wollte ob das
> Gesendete vom Arduino auch so auf meiner Platine ankommt, aber Danke :)

 Das weiss ich, du solltest es nur ausprobieren und Ergebnisse
 zurückposten.
 Wenn es geht, ist mit beiden alles in Ordnung, dann kann man weiter
 suchen, z.B. man setzt Tx-Pin abwechselnd auf Log.0 und dann auf Log.1
 und beim Empfänger fragt man den Rx-Pin ab und schaltet eine LED an
 und aus (Loop, nicht ISR).

 Und so Schritt für Schritt.

[Sepp (Gast)]

Leute ich hab einfach noch eine zweite Platine aufgebaut mit dem 
Mikro...

Da funktioniert alles, es tut das was es soll, Register, Baudrate, 
Masse, alles identisch und es läuft...

Ka was da Arduino verbockt hat oder ich einfach nicht kapiert habe bei 
dem Teil, muss aber immer mehr feststellen dass das Teil einfach **** 
ist.

Hab das Teil nur gekauft um Programme und Register zu testen bevor ich 
mir einen Mikro zerschieße aber naja...

Ich bedanke mich für die Hilfe. :)

Fazit: Fehler nicht gefunden, Arduino für diesen Testzweck nicht 
geeignet aufgrund eines nicht gefundenen Fehlers.

Folgende Probleme wurden angesprochen und überprüft:

-Register, in Ordnung
-Baudraten, in Ordnung
-Masse, gemeinsame Masse, in Ordnung
-Fuses, in Ordnung

[Antwort schreiben (Gast)]

>Ka was da Arduino verbockt hat oder ich einfach
>nicht kapiert habe bei

Das Problem liegt bei Dir.

Ich glaube der Fehler ist:

#define BAUD_PRESCALE F_CPU/16/USART_BAUDRATE-1

[Sepp (Gast)]

Antwort schreiben schrieb:
>>Ka was da Arduino verbockt hat oder ich einfach
>>nicht kapiert habe bei
>
> Das Problem liegt bei Dir.
>
> Ich glaube der Fehler ist:
>
> #define BAUD_PRESCALE F_CPU/16/USART_BAUDRATE-1

Das glaube ich nicht, sonst würde der Fehler auch auf meiner Platine 
auftauchen was er nicht tut.