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_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler.
8
...
9
10
uint8_tgetc()
11
{
12
while(!(UCSRA&(1<<RXC)))// warten bis Zeichen verfuegbar
13
{
14
}
15
returnUDR;
16
}
17
...
18
19
z3=getc();
20
...
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
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
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.
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...
