UART Probleme

Morgen,

schau mal den Quarz an, in der Beschreibung von Pollin steht was von 
16MHz.
In deinem Programm benutzt du nur 4MHz.

Die Init scheint so ok zu sein.

Stephan

Nils Elfers schrieb:
> Am PC der die Daten empfangen soll, habe ich auch die Bautrate 9600
> eingestellt.
Teste erst mal, ob der PC überhaupt was über die serielle Schnitstelle 
empfängt: Steck dazu das RS232-Kabel am AVR aus und verbinde die Pins 
2+3. Dann tippst du im Terminalprogramm ein paar Zeichen ein, und 
kontrollierst, ob der die auch wieder empfängt.

Und der nächste Schritt ist, zu kontrollieren, ob du evtl. RX und TX auf 
dem Weg zum AVR irgendwo vertauscht hast.

Lothar Miller schrieb:
> Teste erst mal, ob der PC überhaupt was über die serielle Schnitstelle
> empfängt: Steck dazu das RS232-Kabel am AVR aus und verbinde die Pins
> 2+3. Dann tippst du im Terminalprogramm ein paar Zeichen ein, und
> kontrollierst, ob der die auch wieder empfängt.
>
> Und der nächste Schritt ist, zu kontrollieren, ob du evtl. RX und TX auf
> dem Weg zum AVR irgendwo vertauscht hast.


Also tx und rx sind nicht vertauscht (ist ja auch das fertige Board von 
Polin) das Senden und empfangen am Computer funktioniert auch und die 
Quarz habe ich jetzt auf 16000000UL gestellt. Aber geholfen hat das 
leider alles noch nicht ;-(

Und wenn du auf dem PC mal 600 Baud einstellst?

> Dennoch wird kein Zeichen vom Mikrocontroller gesendet.

Bereits unabhängig vom PC nachgewiesen?
Z.B. mit einer Spion-LED die flackert (AVR sendet) oder nicht (AVR 
sendet nicht oder zu schnell fürs Auge)

AVR-TXD
Pin o-------+------------o MAX232 Eingang
            |
            +--###-->|---o GND
               R    D

D: Low Current LED
R: Vorwiderstand für D (1.5 KOhm o.ä.)

Nils Elfers schrieb:
> Also tx und rx sind nicht vertauscht (ist ja auch das fertige Board von
> Polin)
Seltsame Begründung...

Als Tipp: Kontrollier nochmal auf einem Blatt Papier die Verbindungen 
zwischen dem uC und dem PC. Evtl. brauchst du ein Kabel, bei dem 2x3 
gekreuzt sind. Probier das doch mal aus...

Hi,

war der MC schon in der org. Schaltung oder ist das ein ganz neuer?
Wenn ja, dann prüfe mal die FUSE Einstellungen.

Stephan

Nee, bei dem Pollin-Board braucht man kein Kabel bei dem 2 und 3 
gekreuzt sind.

Beim Pollinboard braucht man ein 1:1 verbundenes RS232 Kabel mit Stecker 
weiblich an der PC-Seite und Stecker männlich an der AVR-Board-Seite.

Auf der AVR-Board-Seite muss man an der richtigen DB9-Buchse anstöpseln. 
Es gibt eine für RS232-Kommunikation und eine zum seriellen 
ISP-Programmieren.

Ah sorry, war nicht beim Pollin NET-IO Board!

Also ich hab mal ein kleines Programm geschrieben um die Verbindung zu 
testen (ist im Anhang) wenn ich an Den pin 2 (TxD) des Mikrocontroller 
ne Led hänge blinkt die jetzt auch. Wenn ich dann das Com Kabel 
anschließe sehe ich habe nichts auf dem Computer davon (das keine 
Zeichen übertragen werden ist mir klar aber irgendein Kauderwelsch 
müsste ich im Terminalprogramm doch sehen oder?). Ich benutze LKTerm auf 
dem Computer. Wenn ich das Uart Programm wieder aufspiele leuchtet die 
LED nur sehr dunkel. Obwohl die ganze zeit gesendet werden soll.
Ist das hilfreich was ich gemacht habe oder nur ne doofe Idee?

spess53 schrieb:
> Das NET-IO hat nur eine Sub-D-Buchse.
Habs gerade nachgeschaut: auch da ist nur ein 1:1 Kabel nötig...

Und das mit der Baudrate ist nicht so schlimm: wenn da wirklich was 
gesendet wird, werden bestenfalls irgendwelche Zeichen angezeigt. Aber 
angezeigt wird sicher was (wenn der Hardwarehandshake am PC 
ausgeschaltet ist)...

Nils Elfers schrieb:
> wenn ich an Den pin 2 (TxD) des Mikrocontroller
> ne Led hänge blinkt die jetzt auch.
Mit welcher Frequenz blinkt die LED mit dem Testprogramm?
Passt das schon: 1s aus, 1s an?

> Wenn ich das Uart Programm wieder aufspiele leuchtet die
> LED nur sehr dunkel. Obwohl die ganze zeit gesendet werden soll.
Dann wird wohl auch was gesendet, denn dunkel heißt:
Startbit und '0'-Bits sind unterwegs...
Sende doch mal 0xff oder 0x00 stat der 0x78 (='x').
Wird die LED dann heller oder dunkler?

Lothar Miller schrieb:
> Sende doch mal 0xff oder 0x00 stat der 0x78 (='x').
> Wird die LED dann heller oder dunkler?

Bei 0x00 dunkler und bei 0xff heller.

Nils Elfers schrieb:

> Wenn ich dann das Com Kabel
> anschließe sehe ich habe nichts auf dem Computer davon (das keine
> Zeichen übertragen werden ist mir klar aber irgendein Kauderwelsch
> müsste ich im Terminalprogramm doch sehen oder?).

Nur wenn der Sender in der Nähe der beim Empfänger eingestellten 
Baudrate (und anderen Einstellungen) ist. Richtig daneben, dann 
synchronisiert sich der Empfänger nicht und schmeisst den empfangenen 
Schrott weg.

Lies mal die AVR Fuses aus und zeige die Werte oder mach den 1s 
Blinktest den Lothar vorgeschlagen hat.

Nils Elfers schrieb:
> Bei 0x00 dunkler und bei 0xff heller.
Dann überträgt das Ding aber was...

Bei 0xFF sollte sie fast schon so hell leuchten wie beim Blink-Programm 
in einer "An"-Phase. Tut sie das?

Stefan B. schrieb:
> Richtig daneben, dann synchronisiert sich der Empfänger nicht und
> schmeisst den empfangenen Schrott weg.
Das habe ich noch bei keinem PC gesehen. Da wird üblicherweise keinerlei 
Framing- oder Parity-Überwachung gemacht. Ich bekomme sogar mit einer 
gebogenen Büroklammer was angezeigt...

Lothar Miller schrieb:
> Nils Elfers schrieb:
>> Bei 0x00 dunkler und bei 0xff heller.
> Dann überträgt das Ding aber was...
>
> Bei 0xFF sollte sie fast schon so hell leuchten wie beim Blink-Programm
> in einer "An"-Phase. Tut sie das?

@TO
Alternativ mit der Baudrate auf 300 Baud runtergehen (auch auf dem PC).
DAS Blinken kann auch ein Blinder nicht übersehen. Obwohl auch bei 9600 
Baud meiner Erinnerung nach es eher ein Geblinke bzw Geflimmer ist, als 
dass die LED schon eine Art PWM sieht und dunkler wird.
Eine LED die ein Beobachter bei 9600 Baud als dunkel beschreibt anstatt 
als flimmernd, macht mich stutzig.


Mach doch bitte endlich den Test. Prozessor aus dem Sockel und im Sockel 
Pin Tx mit Pin Rx brücken. Dann auf dem PC klimpern. Da MUSS dann am 
Terminal was zu sehen sein (Handshake ausschalten nicht vergessen). Wenn 
nicht, dann hast du ein Hardware-Problem und wir brauchen nicht weiter 
Software suchen.

Ihr seid super danke....
Ich hab den Fehler gefunden. Das Kabel zum Computer war defekt und das 
Terminalprogramm hat auch ne Macke (mal funktioniert es und mal 
nicht)...
Mit neuem Kabel und anderem Terminalprogramm funktioniert es...
Danke!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Vielleicht hat einer von euch ja noch zeit und Lust mir einen Tipp für 
das Speichern der Daten auf einer SD Karte zu geben (ein gutes Tutorial 
oder so) ;-)

Nils Elfers schrieb:
> Vielleicht hat einer von euch ja noch zeit und Lust mir einen Tipp für
> das Speichern der Daten auf einer SD Karte zu geben (ein gutes Tutorial
> oder so) ;-)

Beitrag "MMC SD library FAT16 FAT32 read write"

Eine super Lib. Damit arbeite ich sehr gerne. Ist auf jeden fall einen 
Blick wert.

Gruß Skriptkiddy

Nils Elfers schrieb:
> Das Kabel zum Computer war defekt
Genau das wollte ich aber mit dem allerersten Test ausschliessen... :-/
(Beitrag "Re: UART Probleme")
Seis drum, schön dass es jetzt geht. Viel Spass weiterhin... ;-)