Atmega32 nur über Tx und Rx mit Ft232Rl verbunden, soll Daten aus einem
Terminal empfangen. Eingestellte Baud 9600, genutzt wird ein 12MHZ Oszi.
Wenn ich zB. eine 9 über das Terminal Sende blink eine LED kurz auf das
was empfangen wurde und dann leuchtet wieder die Status LED. Sollte die
Zahl 9 gesendet werden, sollten alle 3 leds aufleuhten, dies passiert
aber nicht. Wer kann mir weiterhelfen?
Peter Naschke schrieb:> Wenn ich zB. eine 9 über das Terminal Sende
Das bedeutet was ganz genau?
Du drückst die Taste, auf der 9 steht?
Dann wird nicht die Zahl 9 versendet, sondern der ASCII Code für diesen
Buchstaben. Und der ist 0x39 und nicht 9
> if (buffer == test)
if (buffer == '9')
Auf dieser Ebene sind alles 'Buchstaben'. Egal ob es wirklich Buchstaben
(klein, groß), oder Ziffern oder Sonderzeichen sind. Wir sagen daher
auch einfach nur 'Zeichen'. Und welcher Code für welches Zeichen steht,
findet sich in den ASCII Tabellen. Muss man aber nicht auswendig wissen,
der Compiler kennt die genauso. Also kann man genausogut auch '9'
schreiben, anstelle des ASCII Codes für das Zeichen '9'.
Wie sendest Du die 9? Durch Druck auf die Taste "9" wird leider 0x39
gesendet. Wie hast Du dich vergewissert, daß Deim µC wirklich mit den 12
MHz läuft?
Das Signal des Ft232 ist kompatible in puncto Spannung und Invertierung
und so?
Ansonsten fällt mir auf, dass bei den Zeichen mit "int" hantiert wird,
sollte das nicht besser uint8_t sein? (8 bit vs. 16 bit)
Sonst sieht's kurz überflogen ganz gut aus.
Ich habe in H_Term die 9 als Dezimal gesendet
Die Schaltung hat die gleiche Spannungsquelle, soll heißen ich benutze
den Busspowered Mode des ft232rl nicht
Peter Naschke schrieb:> Ich habe in H_Term die 9 als Dezimal gesendet
dann sende vom µC aus einfach mal zurück, was der µC empfängt.
Sowas ist immer ein guter Test um festzustellen, ob der Empfänger auch
wirklich das empfängt, was man denkt :-)
Deine Serielle Schnittestelle mit allem drum und drann hast du
hoffentlich vorher schon verifiziert, indem du erst mal nur vom µC aus
sendest, und nachsiehst ob du um HTerm auch das Erwartete empfängst. Man
nimmt immer zuerst diese Richtung in Betrieb, weil man leichter
verifizieren kann, ob alles funktioniert und zb die Baudraten korrekt
sind.
Peter Naschke schrieb:> Mal anders herum gefragt, habe ich die Fuses falsch gewählt?
ganz einfach:
schreib ein Programm, welches auf dem AVR ein paar Zeichen (zb TEST) auf
der seriellen ausgibt.
Steht in deinem HTerm dann auch TEST im Empfnagsfenster, dann ist deine
Serielle Kommunikation fehlerfrei. Steht dort was anderes oder gar
nichts, dann ist irgendwo ein Hund begraben (der in den meisten Fällen
bei einer fehlerhaften Baudrate und/oder Taktfrequenz zu suchen ist).
Aber das Blödeste was du tun kannst, ist dir einen Test auszudenken, bei
dem du ausser 'Funktioniert/funktioniert nicht' keinerlei Aussage
ableiten kannst. Ein Zeichen vom PC zum AVR zu schicken und dann darauf
aufbauend eine LED ein/aus schalten fällt genau in diese Kategorie. Wenn
die Übertragung AVR->PC einwandfrei klappt, dann tut sie das auch in der
anderen Richtung. Um also festzustellen, ob die Übertragung an sich
fehlerfrei funktioniert, testet man die Richtung AVR->PC zuerst. Denn am
PC kann man davon ausgehen, dass sowohl die Serielle als auch die
AUswertung bzw. Anzeige erst mal fehlerfrei ist, wohingegen auf dem AVR
bei diesem Test nur das Senden korrekt funktionieren muss.
Peter Naschke schrieb:> Genau das habe ich grade gemacht, leider kommt nichts beim Terminal> an.
:-)
Also eine nicht getestete Verbindung.
Gut.
Erster Test:
Mega32 aus dem Sockel, den Tx Pin mit dem RX Pin im µC-Sockel mit einem
Drahtstück verbinden. Auf dem PC auf der Tatstatur klimpern. Alles was
du drückst muss über das Kabel und die Drahtbrücke sofort wieder zum PC
zurückkommen. Gegentest: Drahtbrücke raus - das Echo muss aufhören.
Wenn dem nicht so ist, dann ist höchst wahrscheinlich das RS232 Kabel
falsch gekreuzt.
Peter Naschke schrieb:> an.Deswegen war ich grade am überlegen ob die fuses so stimmen.
Unwahrscheinlich.
Wenn die Fuses nicht stimmen hast du eine andere Taktfrequenz. Das zeigt
sich, indem Kauderwelsch ankommt. Aber irgendwas kommt an.
PS:
Man kann sich die Signale auf einer RS232 mit einer LED sichtbar machen.
Einfach eine LED (+330 Ohm Vorwderstand) nach GND schalten und mit dem
anderen Bein auf die unter Verdacht stehende Signalleitung gehen. Bei
diesen Baudraten sieht man die LED noch eindeutig blinken/flackern.
Legst du einen Stein auf die PC Tastatur, dann muss auf der RS232 Seite
vom FT232 es einen Pin geben (weiß die Pinnummer nicht auswendig), an
dem die seriellen Daten rauskommen - dort blinkt dann die LED.
Wenn nicht, dann stimmt mit dem FT232 bzw. dem Treiber im PC was nicht.
Wenn schon, dann nachverfolgen, an welchem µC Pin diese blinkende
Leitung geht. Es muss der Rx Pin vom µC sein.
Als ich den µc raus genommen habe und durch eine Brücke ersetzt habe,
habe ich auch nichts zurück bekommen. An der Brücke liegt aber 5V an und
auch RX ist mit TX und TX mit RX ist richtig verbunden.
Mal ein Paar Bildchen anhängen:
alle 3 Bilder sind von der D+ Leitung hinterm USB-B auf der Platine
gemessen. Bild 4 bei geschlossener Leitung selten mal ein flákern
Bild 1,2 und 3 bei im Terminal geöffneter Leitung, kaum was zu erkennen
ohne das ich was sende.
Die USB Leitungen zu verifizieren dürfte ohne Spezialequipment recht
schwierig sein.
D.h. du musst darauf vertrauen, dass die Kommunikation PC zu FT232
funktioniert.
Mit ordinären Messmitteln kannst du erst am TXD bzw. RXD Pin vom FT232
irgendwelche Aussagen treffen.
D.h. PC auf Dauersenden stellen (zb Stein auf Tastatur) und nachsehen,
ob am FTDI232 an dessen TXD Pin was rauskommt. Wenn möglich alles
abklemmen, was irgendwie die TXD bzw. RXD Leitung blockieren könnte
(daher auch: µC aus dem Sockel nehmen).
Eines ist hoffentlich auch klar. Solange diese einfachen Hardwaretests
nicht erfolgreich absolviert sind, brauchst du dir keine Gedanken um
Software oder dgl. zu machen. Denn diese Tests sind Voraussetzung für
alles andere.
So da bin ich wieder,
also ich habe eine Drahtbrücke zwischen RX und TX auf der Fassung des
Atmega gesteckt. An der Drahtbrücke habe ich mit einem Oszi gemessen.
Mit HTerm habe ich 1sen in 0,2ms und dann nochmal in 0,4ms gesendet und
konnte sie auf dem oszi anhand der flanken deutlich erkennen. Aber bei
HTerm selbst ist nichts angekommen.
Kann das ein Problem mit dem Treibern sein? Sonst irgendwelche ideen
Peter Naschke schrieb:> So da bin ich wieder,>> also ich habe eine Drahtbrücke zwischen RX und TX auf der Fassung des> Atmega gesteckt. An der Drahtbrücke habe ich mit einem Oszi gemessen.>> Mit HTerm habe ich 1sen in 0,2ms und dann nochmal in 0,4ms gesendet und> konnte sie auf dem oszi anhand der flanken deutlich erkennen. Aber bei> HTerm selbst ist nichts angekommen.
OK. Siehst du sie am Eingang des FT232 auch noch?
> Kann das ein Problem mit dem Treibern sein? Sonst irgendwelche ideen
Wenn sie am Eingang des FTD232 auch noch da sind, dann wird das wohl das
Problem sein.
Also mit einer Drahtbrücke Funktioniert das senden und ampfangen, aber
sobald der chip wieder drauf sitzt, kommt nichts an.
Wenn ich etwas vom PC sende und am Pin des Atmega32 messe kann ich es
auch deutlich sehen. Hingegen ich das was ich vom Atmega sende nicht
sehen kann auf den leitungen
1
#define F_CPU 12000000 // Systemtakt in Hz - Definition als unsigned long beachten
> Also mit einer Drahtbrücke Funktioniert das senden und ampfangen,
Gut. Das sollte soweit als Funtionsnachweis für die Verkabelung, die
PC_Seite und den FT232 ausreichend sein.
> aber> sobald der chip wieder drauf sitzt, kommt nichts an.
Sende da mal etwas mehr als nur ein einziges lausiges Zeichen.
1
intmain(void)
2
{
3
uart_init();
4
5
while(1)
6
{
7
usart_putc('x');
8
_delay_ms(500);
9
}
10
}
Und wieder geht das Spielchen los:
Messequipment an den Tx Pin vom Mega und nachsehen, ob da was rauskommt.
Wenn ja, kommt das auch am FT232 an?
Zusätzlich:
Sind die
#define F_CPU 12000000UL
verifiziert worden?
Läuft der µC wirklich mit 12Mhz?
(kann man zb mit einer blinkenden LED und delay_ms leicht verifizieren.
Entwder ein delay_ms(1000) dauert tatsächlich 1 Sekunde oder er dauert
das 12-fache davon, weil der µC noch mit den default-1Mhz statt mit den
angegebenen 12Mhz läuft)
Vielen Dank, das x kommt als x an, also alles super =). Den rest bekomme
ich auch alleine hin.
Fals es von interesse ist, der Fehler war eine Durchkontaktierung der
Platine auf der RX Leitung. Diese hatte nicht richtik Kontakt und die
Daten sind verloren gegangen
liebe grüße