mega8 Dip UART != mega8 tqfp UART ?

[Alex G. (alex94)]

Hallo liebe Gemeinde,
ich habe folgendes Problem:

Ich habe ein C programm das ein Int Array über die uart schnittstelle 
einließt. Das ganze läuft auf dem Atmega8 Dip, kompiliert habe ich es 
mit AVR-GCC unter Linux. Auf der Dip version des mega8 funktioniert das 
super.

Als also mein Prototyp fertig war habe ich mir eine Platine mit mega8 in 
smd Bauform und einen FT232 als RS232-TTL Wandler gebaut. Als die 
Platinen ankamen habe ich natürlcih gleich alles zusammen gebaut und 
dann die software auf den mega geladen. Doch dann kam die herbe 
Enttäuschung, es funktionierte genau nichts.

Nach einiger zeit habe ich versucht die Kommunikation mit Bascom 
zutesten.
Also habe ich mir schnell ein kleines Bascom Programm geschrieben das 
die Zeichen einließt und bei einem "a"ein "b" zurück sendet. Das hat 
alles wunderbar funktioniert. Ich kann also ein Hardwarefehler 
ausschließen.

Hier ist der Abschnitt aus meinem Programm mit dem ich ein Zeichen 
einlese:

...
#define BAUD 9600UL          // Baudrate
 
// Berechnungen
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)   // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))     // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler.
...

 uint8_t getc()
{
  while (!(UCSRA & (1<<RXC)))   // warten bis Zeichen verfuegbar
  {
  }
  return UDR;
}
...

z3 = getc();
...

Was mich wie gesagt verwirrt ist das dieses Progeamm auf der Dip version 
des mega8 einwandfrei funktioniert, aber auf der tqfp version nicht.

Ich hoffe ihr könnt mir helfen.
Alex

[Lord Z. (lordziu)]

Was nimmst du als Quarz?

[Alex G. (alex94)]

Ich verwende einen 8mhz Quarz

Der C schnipsel für den Quarz:

#ifndef F_CPU

#define F_CPU 8000000UL    // Systemtakt in Hz - Definition als unsigned long beachten >> Ohne ergeben Fehler in der Berechnung
#endif

Aber ich kann mir nicht vorstellen das es am Quarz liegt denn mit Bascom 
läuft der UART

[Bingo (Gast)]

Ich hätte einer problem vie das , mit einer M168 im DIP und TQFP.

Ich hatte vergesst das die TQFP hat mehrere VCC pins , und du brauchst 
alle mit 100nf zum gnd

mfg
Bingo Dänemark

[Alex G. (alex94)]

Ich habe kurz vor dem µC einen 100n Kodesnator zwischen VCC und GND.
Jedoch kann ich mir schwer vorstellen das es ein Hardwareproblem ist da 
unter Bascom alles wunderbar funktioniert.
Falsche Fusebits kann ich somit auch nicht gesetzt haben.

[Jörg W. (dl8dtl) (Moderator)]

Alex G. schrieb:
> Der C schnipsel für den Quarz:

#ifndef F_CPU

Hmm, wenn dein Makefile nun aus Versehen auch noch ein F_CPU
definiert (mit einem anderen Wert als 8 MHz), dann wird das
nachfolgende nicht benutzt.

[Alex G. (alex94)]

Jörg Wunsch schrieb:
> Hmm, wenn dein Makefile nun aus Versehen auch noch ein F_CPU
> definiert (mit einem anderen Wert als 8 MHz), dann wird das
> nachfolgende nicht benutzt.

Nein das definiert keinen weiteren Quarz.

[Jörg W. (dl8dtl) (Moderator)]

Alex G. schrieb:
> Nein das definiert keinen weiteren Quarz.

Das ist auch kein "Quarz", sondern eine CPU-Frequenz.  Die kann
genauso gut von einem RC-Oszillator kommen.

U. U. ist dein Problem nur ein unkalibrierter RC-Oszillator.

[Alex G. (alex94)]

Jörg Wunsch schrieb:
> U. U. ist dein Problem nur ein unkalibrierter RC-Oszillator.

Ich habe doch eine CPU-Frequenz definiert, oder nicht?

[Stefan B. (stefan)]

Oder nicht!

Du hast dem Compiler gesagt, dein AVR schuftet mit genau x MHz. Der 
reale Oszillator im AVR arbeitet aber mit ungefähr x MHz. Wie groß der 
Abstand ungefähr zu genau ist, hängt von verschiedenem ab u. a. von der 
Art der Taktquelle und Temperatur. Für UART sollte der Abstand nicht 
größer 2% sein. Vergleich das mal mit den Genauigkeitsangaben zum 
internen Oszillator im Atmel Datenbatt.

[Alex G. (alex94)]

Stefan B. schrieb:
> Du hast dem Compiler gesagt, dein AVR schuftet mit genau x MHz. Der
> reale Oszillator im AVR arbeitet aber mit ungefähr x MHz. Wie groß der
> Abstand ungefähr zu genau ist, hängt von verschiedenem ab u. a. von der
> Art der Taktquelle und Temperatur. Für UART sollte der Abstand nicht
> größer 2% sein. Vergleich das mal mit den Genauigkeitsangaben zum
> internen Oszillator im Atmel Datenbatt.

Ok angenommen mein Quarz schwingt bei 7mhz und nicht bei 8 wie im 
Programm angegeben. Aber warum funktioniert dann mit Bascom der Uart 
einwandfrei? Achso in dem Bascom Programm habe ich auch eine CPU 
Frequenz von 8mhz definiert, wie im C Programm.

[Stefan B. (stefan)]

Sorry, ich habe nicht zurückgescollt, als ich die Antwort geschrieben 
habe, sondern nur auf 
Beitrag "Re: mega8 Dip UART != mega8 tqfp UART ?" "RC-Oszillator" + 
"habe doch eine CPU-Frequenz definiert" geachtet.

Bei der Originalfrage bin ich ratlos. Ich würde es wie bei dem BASCOM 
Versuch machen: Ein abgespecktes C Programm schreiben (und zeigen).

Vielleicht stören andere Features im Projekt in Verbindung mit der neuen 
Platine. Z.B. ein Pin der jetzt anders belegt ist als im Prototypen und 
einen IRQ oder eine Warteschleife im Restprogram auslöst. Vielleicht ist 
die störrische RS232 nur ein Feature eines anderen Bugs.

[Jörg W. (dl8dtl) (Moderator)]

Du wirst das wohl leider nur selbst debuggen können.  Der nächste
Schritt wäre das Anklemmen eines Oszis, um die generierten RS-232-
Signale zu überprüfen.

[Alex G. (alex94)]

Jörg Wunsch schrieb:
> Du wirst das wohl leider nur selbst debuggen können.  Der nächste
> Schritt wäre das Anklemmen eines Oszis, um die generierten RS-232-
> Signale zu überprüfen.
Das habe ich schon getestet, einen Hardwarefehler kann ich 100% 
auschließen denn die Kommunkation funktioniert in beide Richtungen mit 
Bascom.

Da ich leider nicht weiter komme habe ich mal mein Programm und das 
Makefile anghängt.
Wie schon gesagt das Programm läuft auf meinem Prototyp Board (das Board 
mit dem mega8 in der DIP version) einwandfrei. Auf meinem final Board 
(das Board mit dem mega8 als SMD version) läuft es nicht. Wobei ich 
einen Hardwarefehler auf dem final Board komplett auschließen kann. 
Alles ist genauso wie auf dem Prototyp Board verbunden und 
angeschlossen. Und unter Bascom kann ich auch alles richtig ansteuern.

Meine Frage ist ob es zwischen dem mega8 smd und dem DIP Unterschiede 
gibt. Und wenn ja ob mein Programm davon betroffen ist, denn anders kann 
ich mir das nicht funktionieren nicht erklären.

Alex

[Jörg W. (dl8dtl) (Moderator)]

Alex G. schrieb:
> Meine Frage ist ob es zwischen dem mega8 smd und dem DIP Unterschiede
> gibt.

Nein (wenn man davon absieht, dass die QFP-Version ein paar Pins mehr
hat, die dem ADC als Eingänge zugeschlagen worden sind).

Du sollst nicht die Kommunikation unter Bascom testen und musst
auch nicht erzählen, was alles ganz toll funktioniert.  Ich hatte
dich gebeten, die nicht funktionierende Implementierung mit dem
Oszi zu testen und zu schauen, was genau dort passiert.  Wenn
du's dann noch nicht selbst findest, dann schildere einfach hier,
was du in diesem Falle den gemessen hast.

[Stefan B. (stefan)]

Vielleicht hilft die aufgeräumte Version im Anhang weiter.

Es ist ein einfaches UARTDEBUG eingebaut:

Wenn während des Einlesens die LED flackert oder aus ist (aus: Zeichen
kommen in sehr geringem Abstand), empfängt die UART Zeichen. Das wäre
der Normalfall.

Wenn während des Einlesens die LED dauerleuchtet, wartet die UART auf
Zeichen (while in getc). Dauerleuchten wäre verdächtig.

Wenn die Emulation 10s lang läuft (Senden von data[]), leuchtet die LED
10s lang dauernd. Längeres Dauerleuchten als 10s (80s?) wäre verdächtig.

[... .. (docean)]

erstell mal ein Programm das exakt das macht was dein Bascom Programm 
macht.
Also 'a' ampfangen 'b' senden.

Am besten in einem neuen Ordner, und dann hängst du hier .c und Makefile 
an.

Kaum einer wühlt sich hier durch dein Code...