Servus,
ich verzweifle gerade am Ausgeben eines durch UART empfangenen Wertes
auf PORTC.
Ich habe mich in den letzten Tagen schon durch zahlreiche Foren-Beiträge
gelesen, und so auch meinen Code zusammengestellt:
while(!(UCSRA&(1<<RXC)))// warten bis Zeichen verfuegbar
29
;
30
returnUDR;// Zeichen aus UDR an Aufrufer zurueckgeben
31
}
32
33
intmain(void)
34
{
35
uart_init();
36
while(1)
37
{
38
uint8_tc;
39
c=uart_getc();
40
41
// hier etwas mit c machen z.B. auf PORTC ausgeben
42
DDRC=0xFF;// PORTC Ausgang
43
PORTC=c;
44
}
45
return0;// never reached
46
}
Leider weiss ich nicht, wo der Fehler ist.
PORTC ist dauerhaft auf 0x00.
Ich arbeite mit einem ATmega8 und Windows.
Ich hoffe Ihr könnt mir helfen!
Vielen Dank!
Wenn PORTC sonst funktionniert, dann liegt es nicht an JTAG. Wenn JTAG
aktiviert ist, dann kannst du PORTC gar nicht für eigene Aufgaben
verwenden.
DDRC brauchst du nur einmal vor der while-Schleife auf Ausgang setzen.
Die Deklaration von c kannst du auch vor der while-Schleife machen.
Verkabelung richtig (durchpiepsen, nicht nur schauen)? Richtige Leitung
an RX?
Erstmal Danke für die schnellen Antworten!
Ich hab die Deklaration und das einstellen von DDRC umgestell.
Die Kabel sind meiner Meinung nach auch richtig (RXD an PD0 und TXD an
PD1), ich habe auch durchgemessen.
Ist da evtl ein Fehler im Code?
Die Daten sende ich zum Testen mit hterm.
Ber ni schrieb:> Die Kabel sind meiner Meinung nach auch richtig (RXD an PD0 und TXD an> PD1), ich habe auch durchgemessen.
Welches RXD/TXD meinst du hier? Das Paar vom PC RXD(Pin 2)/TXD(Pin 3)
oder die vom µC?
So wie du es schreibst verstehe ich es so:
RXD (PC-Pin 2) - <unbekannte Schaltung> - RXD (µC PD0)
TXD (PC-Pin 3) - <unbekannte Schaltung> - TXD (µC PD1)
Das wäre dann verkehrt. Die Leitungen müssen gekreuzt sein, also so:
RXD (PC-Pin 2) - <unbekannte Schaltung> - TXD (µC PD1)
TXD (PC-Pin 3) - <unbekannte Schaltung> - RXD (µC PD0)
Wie sieht deine Schaltung zwischen PC und µC aus, MAX232, RS232-USB
Baustein?
Dann probier doch erst mal das Echo.
MC rausziehen, RxD und TxD brücken, dann sollten vom Terminal gesendete
Zeichen auch wieder auf dem Schirm erscheinen.
Ok, das funktioniert nicht.
Ich habe einfach den yC aus'm Sockel gezogen und RXD mit TXD verbunden.
Es kommt aber nichts zurück.
Woran kann das liegen?
Benutzt du die spare-Schnittstelle des STK500 oder hast du die
nachgebaut (das gibt dann schon ein paar Fehlerquellen mehr :-) ?
Falls STK500:
-falsches/defektes Kabel
-falscher COM-Port ausgewählt
-falschen SUB-D benutzt (den ganz aussen musst du nehmen)
-echten COM-Port oder USB-RS232-Wandler?
Mess mal das Kabel durch eventuell hast du dein ein falsches erwischt.
interessant sind die Pins 2, 3 und 5 dein Kabel muss 1 zu 1 durch
verbunden sein.
Versuch das ganze analytisch und systematisch einzugrenzen.
1) funktioniert der UART? Kannst Du eine Verbindung mit dem PC
herstellen. Warum verwendest Du nicht einfach eine Funkion UART_putc um
das "vermeintlich" vom PC erhaltene Zeichen wieder als Echo ans
Hyperterminal zurückzusenden? Beispielfunkion gibts hier irgendwo.
Hast Du die Einstellungen im Hyperterminal richtig? COM-Port, Baudrate,
Stopbits und ACHTUNG: Fluß-Steuerung nicht auf Hardware, sondern auf
keine.
Hast Du die Baud-Rate richtig berechnet? Ist der ATmega auf externen
Quarz eingestellt oder auf internen?
2) Liegts an der Ausgabe auf den PortC? DAs kannst Du einfach testen,
indem Du einfach mal dem PORTC nicht die UART-Ausgabe gibst, sondern
einen von Dir gewählten Also einfach PORTC=0xFF. Dann solltest Du an
allen Pins Highpegel messen. Wenn nicht ist da was faul.
Danke für die schnellen Antworten!
Ich hab das Kabel durchgemessen, das passt.
Den SPARE-Anschluss am STK500 benutze ich auch und mein PC hat einen
'echten' COM-Port.
Als Port ist im HTerm COM1 ausgewählt (es gibt nur einen), Baud: 9600,
Data: 8, Stop: 1, Parity: None, CTS Flow Control: nicht ausgewählt.
Sind die Einstellungen richtig?
Jetzt muss ich mal ganz dumm fragen: wo hast du denn Rx und Tx
gebrückt? Die Signale liegen auf der 2poligen Stiftleiste RS232spare,
nicht direkt auf PD0/PD1.
Ber ni schrieb:> Als Port ist im HTerm COM1 ausgewählt (es gibt nur einen), Baud: 9600,> Data: 8, Stop: 1, Parity: None, CTS Flow Control: nicht ausgewählt.>> Sind die Einstellungen richtig?
Auf 'Connect' hast du in HTerm auch geklickt?
Ansonsten wüsste ich jetzt keinen Grund mehr warum das nicht gehen
sollte.
Du kannst mal versuchen direkt am PC in der Buchse die Pins 2 & 3
verbinden, dann solltest du auch ein Echo bekommen.
Die Einstellungen am Hyperterminal stimmen.
Wie siehts mit dem Quarz aus. Bist Du sicher, dass Du ein 3,86MHz-Quarz
hast und der Atmega den auch benutzt?
Wenn Du nämlich den internen Takt oder einen falschen externen
eingestellt hast, gehts auch nicht.
Wenn ich die Pins 2 und 3 am kabel verbinde bekomme ich ein echo. :)
Wenn ich dann das Kabel an den SPARE Anschluss des STK500 anstecke und
die Pins RXD und TXD verbinde passiert nichts. :(
Ber ni schrieb:> Wenn ich die Pins 2 und 3 am kabel verbinde bekomme ich ein echo. :)> Wenn ich dann das Kabel an den SPARE Anschluss des STK500 anstecke und> die Pins RXD und TXD verbinde passiert nichts. :(
Mach doch mal eben ein Foto von deinem STK500 mit den gebrückten RXD/TXD
Pins....
Hier das Foto (sorry für die schlechte Qualität, ich hatte aber gerade
nur ein Handy da).
Ich habe RXD und TXD mit einem Jumper überbrückt.
Das Kabel hängt an RS232 SPARE.
Den Jumper habe ich durchgemessen, der ist OK.
Ber ni schrieb:> Ich habe RXD und TXD mit einem Jumper überbrückt.>> Das Kabel hängt an RS232 SPARE.>> Den Jumper habe ich durchgemessen, der ist OK.
Also wird das Problem wahrscheinlich zwischen Stecker "RS232 Spare" und
dem Jumper sein, da kommt der "Voltage Converter", MAX202CSE oder die
beiden 470R Längswiderstände in Frage. Eventuell ist auch eine
Leiterbahn defekt.
Erst einmal nach sehen ob beide IC's ihre 5V haben bzw. der "Voltage
Converter" seine VTG. (Welchen Wert die auch immer haben mag, kenne das
STK500 nicht)
Sollten die Spannungen vorhanden sein, kannst du entweder die Pegel
messen (Achtung der MAX202CSE invertiert) oder aber vom Stecker
ausgehend die Brücke weiter Richtung Jumper verlagern (vor/hinterm
MAX202/Voltage Converter) und schauen wann du kein Echo mehr bekommst,
Danke für die Antwort!
M. K. schrieb:
> Also wird das Problem wahrscheinlich zwischen Stecker "RS232 Spare" und> dem Jumper sein, da kommt der "Voltage Converter", MAX202CSE oder die> beiden 470R Längswiderstände in Frage. Eventuell ist auch eine> Leiterbahn defekt.
Kann das sein? Das UART senden läuft ja auch über diese Bausteine, und
funktioniert einwandfrei.
crazy horse schrieb:> Dann probier doch erst mal das Echo.> MC rausziehen, RxD und TxD brücken, dann sollten vom Terminal gesendete> Zeichen auch wieder auf dem Schirm erscheinen.Ber ni schrieb:> Ok, das funktioniert nicht.> Ich habe einfach den yC aus'm Sockel gezogen und RXD mit TXD verbunden.> Es kommt aber nichts zurück.Ber ni schrieb:> Wenn ich die Pins 2 und 3 am kabel verbinde bekomme ich ein echo. :)> Wenn ich dann das Kabel an den SPARE Anschluss des STK500 anstecke und> die Pins RXD und TXD verbinde passiert nichts. :(Ber ni schrieb:> Kann das sein? Das UART senden läuft ja auch über diese Bausteine, und> funktioniert einwandfrei.
Habe ich da jetzt was verpasst?
Woher weist du jetzt das senden funktioniert?
Senden in welche Richtung? (µC -> PC oder PC -> µC)
Wenn du den Jumper steckst und das Kabel zum STK500 verbindest, hast du
den µC im Sockel?
M. K. schrieb:
> Woher weist du jetzt das senden funktioniert?
Ich hab ein kleines Programm geschrieben :)
> Senden in welche Richtung? (µC -> PC oder PC -> µC)
yC -> PC
Kabel an RS232-SPARE und RXD/TXD mit PD0/PD1 verbunden
> Wenn du den Jumper steckst und das Kabel zum STK500 verbindest, hast du> den µC im Sockel?
Ja, ist das schlimm?
Ber ni schrieb:>> Wenn du den Jumper steckst und das Kabel zum STK500 verbindest, hast du>> den µC im Sockel?>> Ja, ist das schlimm?
Ja, weil Du dann den TXD-Ausgang des µC mit dem Ausgang des
RS232-Pegelwandlers verbindest und einen Kurzschluss machst.
Wenn Du Glück hast geht nur nichts, wenn Du Pech hast werden ein oder
beide Ausgänge zerstört.
Gruß Dietrich
Hi
>Ja, weil Du dann den TXD-Ausgang des µC mit dem Ausgang des>RS232-Pegelwandlers verbindest und einen Kurzschluss machst.>Wenn Du Glück hast geht nur nichts, wenn Du Pech hast werden ein oder>beide Ausgänge zerstört.
Nein. Der Jumper ist nur mit dem MAX202 verbunden.
MfG Spess
spess53 schrieb:> Nein. Der Jumper ist nur mit dem MAX202 verbunden.
Aber Ber ni schrieb:
> Das UART senden läuft ja auch über diese Bausteine, und> funktioniert einwandfrei.
Also hat er zumindest TXD des µC angeschlossen. Wenn jetzt dieses TXD
High liefert und RXD vom MAX202 über die Transistorschaltung Low, gibt
es einen Kurzschluss. Bei Low des µC geht wegen der Transistorschaltung
zwar nichts kaputt, aber das Echo geht auch nicht.
Gruß Dietrich
Ich glaube wir reden gerade von zwei unterschiedlichen Dingen!
Die Stiftleiste mit RXD und TXD ist NICHT mit dem µC verbunden. Zum
nutzen des RS232-SPARE muss man erst diese Stifte mit den Stiftleisten
für PB0 und PB1 des µC mit einem Flachbendkabel verbinden.
Also dürfte es eigendlich kein Problem sein, außerdem zeigt das STK500
auch keinen Kurzschluss an.
Kann es aber sein, dass nur eine Leitung des UART funkioniert wenn beide
über die gleichen Bauteile laufen?
Übrigens: Ist es normal, dass an RXD und TXD standartmäßig Vcc (+5V)
anliegt?