mega8 Dip UART != mega8 tqfp UART ?

Was nimmst du als Quarz?

Ich verwende einen 8mhz Quarz

Der C schnipsel für den Quarz:

1

#ifndef F_CPU

2

3

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

4

#endif

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

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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

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.

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.

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...