www.mikrocontroller.net

Forum: Compiler & IDEs mega8 Dip UART != mega8 tqfp UART ?


Autor: Alex G. (alex94) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lord Ziu (lordziu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was nimmst du als Quarz?

Autor: Alex G. (alex94) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex G. (alex94) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex G. (alex94) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex G. (alex94) Benutzerseite
Datum:

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

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

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex G. (alex94) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex G. (alex94) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan B. (stefan) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ... ... (docean) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.