mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik UART beim atmega8 - Software-Denkfehler oder Hardwareproblem?


Autor: Matthias (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Meine Schaltung tut in Zusammenhang mit meinem Code nicht das, was ich 
will. Ich hab mit verschiedenen Tutorials gearbeitet und den Code im 
Anhang zusammengestellt. Steckt vielleicht da ein Denkfehler drin oder 
hab ich doch ein Hardwareproblem in der Schaltung?

Am Anfang leuchten beide LEDs -> PD7 und PD4.
Jetzt schicke ich übers Hyperterminal ein Zeichen (z.B. "a"). Erst löst 
der RXC-Interrupt aus und toggelt die eine LED, anschließend soll das 
selbe Zeichen wieder geschickt werden (wird wieder in UDR zurück 
geschrieben) und im TXC-Interrupt die zweite LED getoggelt werden. Das 
passiert so schnell, dass die LEDs scheinbar "gleichzeitig" toggeln. Das 
funktioniert an sich auch.

Nur: es kommt im Hyperterminal nix an. Hin und wieder schiebt er mal ein 
Leerzeichen ein. Zudem kommt es zu unbestimmter Zeit/ nach unbekannt 
vielen Zeichen (Zufall?) dazu, dass die LEDs komplementär leuchten. 
Irgendwo ist eine Fehlerquelle.

Ich verwende einen 16-MHz-Quarz (Atmel Evaluations-Board Version 2.0.1) 
und eine Baudrate von 9600 (vgl. Sourcecode). Das sollte einigermaßen 
fehlerfrei funktionieren: http://www.wormfood.net/avrbaudcalc.php

Die UART-Schnittstelle an sich funktioniert am Rechner: RX und TX 
zusammenschließen an der Leitung geht; auch nach dem MAX232 auf dem 
Board gehts noch. Bleibt also noch der Controller (mit Code) und ein 
bisserl Verkabelung.

Habt ihr Ideen für mich?
Vielen Dank im Voraus!

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kleiner Nachtrag:

http://www.avrfreaks.net/index.php?name=PNphpBB2&f...
Daran hab ich mich unter anderem orientiert.

»Over to it. However, we can now remove the two while loops - since the 
ISR only fires when a byte is received, and only one byte is sent after 
each reception we can guarantee that both checks are now redundant. When 
the ISR fires we know that there is both a byte received in the USART 
input buffer, as well as nothing in the output buffer. Using this 
knowledge, we can simplify our ISR code to the following [...]«

Ist es vielleicht doch diese Annahme, die das ganze etwas wackelig 
dastehen lässt?

Autor: Bill (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tag,


ich bin da jetzt nicht so der crack, aber ich mache das anders, weiss 
also nicht warum es nicht funtktionert.

im RX interrupt würde ich das empfangene in ein volatile char speichern 
und noch ein empfangsflag setzen.
ausserhalb vom INT dann eine funktion aufrufen die den UDRE Interrupt 
einschaltet und das zu sendende zeichen in ein sendepuffer schreibt.
// UDRE Interrupt einschalten
UCSR0B |= (1 << UDRIE0);


// darauf reagieren mit diesem INT:

ISR(USART0_UDRE_vect) {

//sendepuffer in UDR
}

Autor: Bill (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sorry der flag muss volatile sein nicht der emfangspuffer, sry!

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Habt ihr Ideen für mich?
Probiers doch mal so, dass du erst mal die eine Richtung testest 
(uC->PC), dann die andere (PC-uC).

Mach also im uC eine Routine, die immer ein Zeichen (oder eine 
Zeichenkette sendet). Wenn du die am PC empfangen kannst, bist du bereit 
für die nächste Stufe: sende ein Zeichen vom PC und gib das auf 8 LEDs 
aus.

Ein Tipp:
nimm NICHT Hyperterminal für solche Spielereien. Eine Suche hier im 
Forum (+hyperterm* +problem*) zeigt dir mit fast 1000 Treffern auf, 
wieso :-/

Ich verwende OCConsole und HTERM.

Autor: Bill (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stimmt mit HT hatte ich auch mal probleme.

ich nutze python und pyserial.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> #define F_CPU 160000000L
160 000 000

160 MHz? Krass!

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Habt ihr Ideen für mich?

Jeder einzelnen Compilerwarnungen nachgehen (wobei die je nach Optionen 
nicht alle angezeigt werden)
In file included from main.c:3:
c:/programme/winavr/lib/gcc/../../avr/include/util/delay.h:85:3: warning: #warning "F_CPU not defined for <util/delay.h>"
c:/programme/winavr/lib/gcc/../../avr/include/util/delay.h:90:3: warning: #warning "Compiler optimizations disabled; functions from <util/delay.h> won't work as designed"
* main.c, line 5: 1: warning: "F_CPU" redefined
c:/programme/winavr/lib/gcc/../../avr/include/util/delay.h:86:1: warning: this is the location of the previous definition
main.c: In function 'main':
* main.c, line 33:  warning: large integer implicitly truncated to unsigned type

Die haben alle mit deinem Problem zu tun, die letzte hätte dich auf das 
Problem aufmerksam gemacht. Denn das ist ein Fehler, den man selber 
niemals findet.
#define F_CPU 160000000L

Zähl mal die Nullen...

Oliver

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der ATMega8 ist nur bis 16 MHz spezifiziert. Ein 10-faches Übertakten 
mit 160 MHz macht der sicher nicht mit...

EDIT:
Hmmm... Zu spät.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ups.. ja 160 MHz wären dann doch ein bissl viel.
Aber dann hätte meine Blinke-LED (die ich mal in der main-Loop hatte + 
dafür die delay) auch 10mal so schnell blinken müssen. g Und das wäre 
schon aufgefallen. F_CPU war also bei mir auch schon im Makefile 
definiert. Da sollte man dann vielleicht ein wenig mit dem Präprozessor 
arbeiten und Compiler-Warnungen nicht ignorieren, stimmt. Die hatte ich 
gar nicht entdeckt, weil das ziemlich schnell wegscrollt. Werde ich in 
Zukunft drauf schauen, merci.

Auch die weiteren Ideen bringen schon mal Versuchsansätze, die ich 
ausprobieren werde. Danke!

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias wrote:
> Aber dann hätte meine Blinke-LED (die ich mal in der main-Loop hatte +
> dafür die delay) auch 10mal so schnell blinken müssen.
Eher im Gegenteil! Wenn die Baudrate so eingestellt ist, als ob der µC 
mit 160 MHz läuft, er aber in wirklichkeit nur mit 16 MHz tickt, dann 
käme ein 10-mal zu langsames Blinken raus.

Allerdings kommt ja bei der Baudratenberechnung schon Müll raus, d.h. in 
UBRRH/L steht ein unsinniger Wert. Deshalb ist das Verhalten gar nicht 
so trivial.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Aber dann hätte meine Blinke-LED (die ich mal in der main-Loop hatte +
>dafür die delay) auch 10mal so schnell blinken müssen.

Wenn du, wie oben in deinem Programm, F_CPU erst nach delay.h definiert 
hast, nicht.

Oliver

Autor: Matthias (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hey zusammen!

Ein kleines Update von mir. Habe eben wieder Zeit zum "entwickeln" 
gehabt. g Dabei hab ich den Quellcode einfach mal entsprechend auf den 
wichtigen Teil gekürzt. Davor hab ich das alte auf dem µC noch mal im 
Terminal getestet, da kam ziemlicher Buchstabensalat (was ja eigentlich 
auf Unstimmigkeiten mit der Taktfrequenz bzw. der Baudrate schließen 
ließe glaube ich). Mit der aktuellen Version geht's momentan aber (gut, 
ich toggle zwei LEDs auf dem Board). Das Problem, dass die LEDs 
teilweise unterschiedlich leuchten ist dennoch reproduzierbar (beim 
Rollen über die Tastatur z.B.; Anschlag auf einer Taste ist kein 
Problem).

Immerhin etwas.. darauf lässt sich jetzt evtl. wieder Stück für Stück 
dranbauen und schauen, ob es noch funktioniert, wie es soll!

Gruß

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.