Hallo zusammen, ich bin neu hier im Forum und bin noch nicht lange am Programmieren mit uC. Habe aber schon einige Fortschritte machen können und nun bin ich bei der Kommunikation mit dem PC über RS232 mit dem uC angelangt. Ich muss vorweg sagen, ich habe das myAvr Board MK2 mit dem USB Programmer. Ich habe über diesen Programmer schon eine Datenverbindung zwischen uC und dem PC zustande gebracht (Terminalprogramm HTerm). Ich wollte aber nicht dauernd auf dem Programmer (mySmartUSB MK2) zwischen Daten -und Programmiermodus umschalten. Das geht mit dem kleinen Programm mySmartUSB Terminal Version 1.06. Jetzt habe ich mir von Pollin den RS232-TTL-Wandler-Bausatz (MAX232)gekauft, zusammengelötet und wollte ihn ausprobieren. Ich habe leider auf meinem Laptop keine serielle Schnittstelle mehr und musste mich darum mit einem USB Konverter mit einem seriellen Kabel mit dem MAX232 Bausatz verbinden. Soweit so gut.... Ich bekomme auch tatsächlich meine Zeichen wieder auf HTerm dargestellt (Verbindung jetzt über Max232), allerdings fängt dann irgendwas wir verrückt an zu senden. Wenn ich zwischendurch meine Zeichen sende, werden die nur teilweise in HTerm dargestellt, also dürfte anscheinend ein Empfangsbuffer übergehen. Fazit: -also die Verbindung muss funktionieren, ich bekomme ja die Strings auch dargestellt am PC. -irgendwas muss da dann auf dem Bus herumgeistern -wenn ich ein und ausschalte ist erstmal Ruhe auf der Leitung, erst wenn ich wieder was schicke fängt das Geistern an. -wenn ich mich mit der selben Software im uC über den USB Programmer im Datenmodus verbinde funktioniert es ganz normal. Hätte jemand ein paar Vorschläge was ich dagegen unternehmen kann. Kann es am USB Konverter liegen? Ist irgend so ein noname Ding. Vielen Dank für eure Hilfe im voraus. bg Chris
hallo, was machst du mit dem mySmartUSB während dessen? hast du den abgezogen? nicht das es hier zu Seiteneffekten kommt :/ aber warum nimmst nicht gleich das: http://shop.myavr.de/Bauelemente%20und%20Controller/myUSBtoUART.htm?sp=article.sp.php&artID=200024 von TTL auf RS232 von RS232 auf USB ... das eine Wandlung zu viel ;-)
Hallo danke für deine schnelle Antwort.
Also den mySmartUSB habe ich zumindest vom Board nicht abgezogen. ich
habe nur das USB Kabel zum Laptop entfernt und mit einer externen
Versorgung gearbeitet.
Wenn ich jedesmal den mySmartUSB vom Testboard abziehen muss, ist es ja
noch umständlicher als wenn ich via Programm zwischen Daten und
Programmiermodus umschalte.
>von TTL auf RS232 von RS232 auf USB ... das eine Wandlung zu viel ;-)
Glaubst du das es nicht mit einem USB auf Seriellen Konverter
funktionieren wird.
BG
Chris
Rolf K. schrieb: > von TTL auf RS232 von RS232 auf USB ... das eine Wandlung zu viel ;-) Hab ich auch, das ist nicht das Problem. Interessant wäre aber in diesem Zusammenhang wie der TE sendet. Wie schaut denn der Code dazu aus? Ich geh erstmal von aus, dass die Hardware OK ist. Ich hatte mal ein ähnliches Problem welches darin begründet war, dass ich nicht wartete bis der Sendebuffer leer war bevor ich das nächste Zeichen sendete (bzw. es versuchte)
Also ich bin noch in der Firma und habe leider den Code nicht bei mir. Aber ich mache folgendes, was auch beim Datenmodus über den Programmer funktioniert: Über einen Tastendruck wird ein String auf den Sendebuffer geschrieben. Wenn ich also die Taste nicht gedrückt habe, wird auch nix geschickt. Das funktioniert auch soweit, nur eben mit der Verbindung über den MAX232 nicht. Ich würde also mal vermuten das es mit dem Sendebuffer nix zu tun hat.
Um den RS232-USB und den Max232 Bausatz zu testen, verbinde den Ein- und den Ausgang vom Max232-Bausatz (RX und TX verbinden). Dann öffne dein Terminal, beliebige Baudrate wählen und Tippen. Es muss alles so zurückkommen wie du tippst.
Also direkt auf den eingangsseitigen Anschlüssen des MAX232 (Anschlüsse vom und zum uC) quasi kurzschließen?
So ein Verhalten kenne ich wenn die Masse nen Wackler hat. Irgendwo ne Kalte Lötstelle ? Dann produzieren die Ladungspumpen aus dem MAX232 ne ganze Menge Störungen. Muss natürlich nicht sein aber hab ich schon ab und zu gehabt.
Also direkt auf den eingangsseitigen Anschlüssen des MAX232 (Anschlüsse vom und zum uC) quasi kurzschließen? was du mit Eingangsseitig meinst, ist die Seite, auf der du die 5V Controllerpegel hast. Beim Pollinbausatz hast du da glaube ich 4 Schraubklemmen, 5V, Masse und TX,RX. TX/RX einfach kurzschliessen. So schickst du die Daten vom "Ausgang" vom PC direkt wieder in den Eingang. Vielleicht stimmen die Kondensatoren auch nicht. Schreib mal bitte welche Ausführung vom Max232 du haste (z.B. max232*acpe*) und wieviel µF die Kondesatoren haben. Mehr als 1 sollte es nicht sein. Die meisten max232 kommen mit 10µ klar (habe hier einige Schaltungen so liegen und laufen), aber das ist weit ausserhalb der Spezifikationen.
Also es sind 10uF bei den Elkos. Wie in der Beschreibung angegeben http://www.pollin.de/shop/downloads/D810036B.PDF Ich habe jetzt noch mal probiert mit HTerm und die RX und TX vom Wandler kurzgeschlossen und habe folgendes Ergebnis: Also wenn ich 100 Zeichen auf die Schnittstelle schicke kommen teilweise weniger und teilweise auch mehr Zeichen zurück je nach Baudrate die ich eingestellt habe. Ich habe auch bemerkt, dass es wichtig ist dass ich zwischen dem Senden der einzelnen Zeichen eine Verzögerungszeit von 0.2-0.3s einstelle, und die Baudrate nicht höher als 4800 einstelle. Kann das mit den zu großen Elkos zusammenhängen, dass die Schnittstelle so langsam ist?
christian brunner schrieb: > Über einen Tastendruck wird ein String auf den Sendebuffer geschrieben. Wartest du bei jedem Zeichen, dass du zum Senden schickst, darauf, dass es auch abgeschickt wurde? Wie schaut denn deine Routine dazu aus? Hoffentlich nicht nur so:
1 | while(ZeigeraufSendeString != 0){ |
2 | UDR=ZeigeraufSendeString; |
3 | ZeigeraufSendeString++; |
4 | }
|
Denn, dass du unterwegs Zeichen verlierst (und zwar nicht das erste sondern erst ab dem dritten/vierten) deutet eigentlich schon darauf hin, dass du nicht auf den Sendebuffer wartest (bzw. dass dieser leer ist was bedeutet, dass das vorhergehende Zeichen gesendet wurde). Auf der anderen Seite lese ich grade deinen aktuellen Beitrag der darauf hindeutet, dass an dem Bausatz auch was nicht passt. Ich hab bei meinen MAX232 auch nur 1.0 µF Kondensatoren dran und ich glaub die Empfehlung steht auch im Datasheet dazu aber ich kann mich auch irren.
So ich habe jetzt die Lösung gefunden: also ich habe mal die Spannungspumpen-Kondensatoren von 10uF auf 1uF getauscht. Zum Testen habe ich noch immer die Rx Tx Anschlüsse auf der max232 Platine kurzgeschlossen, um ein Echo im Terminalprogramm zu erzielen. Hat in Summe auch nichts gebracht. Hat nur wieder irgendwelche Zeichen von selber geschickt Vorsichtshalber habe ich mir schon mal einen neuen max232 besorgt und diesen danach eingelötet -> jetzt funktionierte das Echo der Zeichen tadellos. Habe testweise mal einen Zeichenstring von 0123456789876543210 1000 mal geschickt und es sind alle Zeichen wieder angekommen. Aber als ich das Ganze mit dem Testboard und der Verbindung der Rx und Tx Anschlüsse versuchte, ging es in der Form immer noch nicht. Erst als ich dann vom Testboard zur Platine des max232 die Rx Tx Leitungen gekreuzt habe, hat es einwandfrei bei 9600 Baud funktioniert. Ich muss mir noch die genaue Beschaltung des Max232 auf der Platine anschauen. Vielleicht ist die Bezeichnung einfach falsch. Würde mich allerdings sehr wundern, denn das ist ein Standardding, aber nichts ist unmöglich. Ich vermute aber trotzdem mal, das es der max232 war der mir die Probleme bereit hat. bg an alle und Danke für eure Antworten Chris
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.