Hallo Leute, ich versuche gerade, eine UART-Verbindung zwischen 2 µC aufzubauen. Und zwar zwischen einem Atmega644P und einem Atmega168. Der Atmega644P ist mit der seriellen Schnittstelle des PCs verbunden und bekommt Strings geschickt. Strings, die mit einer "2" anfangen, soll er über seine 2. serielle Schnittstelle an den Atmega168 schicken. Dieser soll "168:" vor den String schreiben, damit man weiß daß er ihn bearbeitet hat, und ihn zurückschicken. Die Sache ist, daß solange ich ein Terminalprogramm an beiden Schnittstellen des 644ers habe, er genau macht was er soll. Auch der Weg rückwärts, d.h. in den 2. UART rein und aus dem ersten raus, funktioniert. Auch der 168 macht am Terminalprogramm genau was er soll. Nur sobald ich die beiden zusammenschließe - RxD1 vom 644er an TxD vom 168 und umgekehrt (Crossover), geht nichts mehr. Es ist wirklich reproduzierbar, und ich habe es mehrfach durchgespielt: Wenn ein Terminalprogramm am anderen Ende ist, funktioniert alles. Ist ein µC dran, geht nichts mehr. Hat jemand eine Idee ? Gruß Tilmann
> Hat jemand eine Idee ?
Vermutlich Codezeile 42. Oder Groundverbindung 42.
Wie zeigt sich denn "geht garnichts mehr"? Wird irgendein Quatsch rausgehauen oder passiert garnichts mehr? Hängen die µC an der gleichen Stromquelle? Und probier mal nur eine Leitung also Txd vom 644 zum Rxd vom 168
Ground ist mit allen Beteiligten verbunden. Aber die Idee ist geil, mal nur eine Leitung zu verlegen. Also habe ich die Leitung vom 644er zum 168er verlegt, und die Antwortleitung vom 168 dann nicht zurück an den 644er, sondern an einen Max232, der an einem Terminal hängt. Dort kam dann auch was an, d.h. der 644er schickt an den 168, aber dessen Antwort über den 644er zurück ist das Problem. Also das Problem ist nicht gelöst, aber ich bin einen Erkenntnisschritt weiter. Danke !
Hallo Peter, Dein Vorschlag hat mich auf eine Idee gebracht: Mal eine Zeitverzögerung beim 168er zwischen empfangen und zurückschicken einzubauen. Damit (waitms 500) geht es in dieser Richtung ! Geil, wieder einen Schritt weiter ! Gruß Tilmann
"geht es in dieser Richtung" Quatsch, es geht jetzt in beiden Richtungen, genau wie es soll. Super, danke für den Tip ! Natürlich hätte ich vielleicht auch selbst drauf kommen können, aber vor lauter Kabeln ...
Vielleicht sollte man solche Multiprozessorkommunikationen erst angehen, wenn man EINEN Prozessor SEHR gut beherrscht?
Tilmann schrieb: > es geht jetzt in beiden Richtungen, genau wie es soll. D.h. Du hast einen schweren konzeptionellen Fehler. Vermutlich arbeiten die UARTs blockierend und nicht als Interrupt mit FIFO.
Hallo, sie arbeiten mit "Serial0charmatch()". Das löst doch einen Interrupt aus, oder ? Ich habe gelesen das sei gut. Übrigens habe ich probiert, ob es nicht auch mit einer kürzeren Zeitverzögerung geht als mit 500ms. Bei 1MHz schien mir das sehr lang. Es geht aber nicht kürzer, jedenfalls nicht mit 400ms. Scheinbar braucht der 644 so lange, um sich von den Strapazen des Sendevorgangs zu erholen. > Vielleicht sollte man solche Multiprozessorkommunikationen erst angehen, > wenn man EINEN Prozessor SEHR gut beherrscht? Genau; vor einem halben Jahr wußte ich noch nicht, was ein µC ist ... Gruß Tilmann
@ Tilmann (Gast) >Es geht aber nicht kürzer, jedenfalls nicht mit 400ms. Scheinbar braucht >der 644 so lange, um sich von den Strapazen des Sendevorgangs zu >erholen. Arrrrgggg! Ich brauch die Zeit, um mich von den Strapazen dieses Unsinns zu erholen. >> Vielleicht sollte man solche Multiprozessorkommunikationen erst angehen, >> wenn man EINEN Prozessor SEHR gut beherrscht? >Genau; vor einem halben Jahr wußte ich noch nicht, was ein µC ist ... Dann konzentrier dich mal auf EINEN AVR. Und lern was über RS232 und Programmiertechniken, u.a. Multitasking. Poste Code als Anhang, dann kann man dir helfen. Siehe Netiquette.
Tilmann schrieb: > sie arbeiten mit "Serial0charmatch()". Das löst doch einen Interrupt > aus, oder ? Das kann man nur wissen, wenn man ihren Quelltext kennt. Die Namensgebung klingt verdächtig danach, daß sie blockiert. Ein Standardfunkton der C-Libraries ist das jedenfalls nicht. Woher hast Du sie? Ein MC muß sich nirgends erholen, das ist Quatsch.
Hallo,dir erscheinen 500ms bei 1 MHZ sehr lang. Meinst du 500ms sind bei 8 MHZ schneller vorbei? Das erinnert mich an folgende Frage: Was ist schwerer.1 Tonne Blei oder 1 Tonne Federn? gruss andy
@Peter Dannegger: Serial0charmatch() ist Bascom. Ich blicke es auch nicht so ganz, aber diese Funktion kann man auf ein bestimmtes Zeichen, wie etwa CR als Abbruchbedingung prüfen lassen, löst dann einen Interrupt aus und weist den empfangenen String einer Stringvariablen zu. Es geht auch anders mit Interrupts, aber dann bekommt man alle Zeichen einzeln; ich finde es so praktischer, aber ohne diese Pause wäre es schon besser. Von UARTS blockieren habe ich keine Ahnung. Immerhin ist es geil das schon mal was läuft. Gruß Tilmann @ andy: Die Frage, ob eine Tonne Blei schwerer ist als eine Tonne Federn, kannst Du Dir selbst beantworten, nachdem Dir beides auf den Fuß gefallen ist.
Hallo, übrigens habe ich das mit der Zeitverzögerung noch mal hin- und her probiert. Damit hat es nichts zu tun. Oft schickt er erst beim 2. Mal, besonders nach dem Einschalten. Wenn er aber erstmal weitergeschickt hat, geht es auch die folgenden male auf Anhieb. Und je öfter man es macht, umso zuverlässiger funktioniert es. Es werden sich hier einige aufregen, aber man merkt die Mechanik, die sich erst einschleifen muß; wie ein Motor. Und die Kinder räumen ihr Zimmer auch nicht auf, wenn man es nur 1 x sagt. Gruß Tilmann
Hi >Übrigens habe ich probiert, ob es nicht auch mit einer kürzeren >Zeitverzögerung geht als mit 500ms. Bei 1MHz schien mir das sehr lang. Hört sich nach internen RC-Oszilletor an. Damit ist eine stabile Verbindung reine Glückssache. MfG Spess
> Hört sich nach internen RC-Oszilletor an.
Stimmt, aber 4800 Baud müßte das noch schaffen, oder ? Was gibt es für
Erfahrungswerte ?
Hi
>Stimmt, aber 4800 Baud müßte das noch schaffen, oder ?
Was hat das mit der Baudrate zu tun? Wenn der Oszillator um 5% abweicht
tut er das bei jeder Baudrate.
MfG Spess
@ Tilmann (Gast) >> Hört sich nach internen RC-Oszilletor an. >Stimmt, aber 4800 Baud müßte das noch schaffen, oder ? Oder. http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART
O.k., vielen Dank für den Tip, werde Quarzoszillatoren nachrüsten. Gruß Tilmann
Übrigens, die Kommunikation zwischen dem USB-auf-UART-Baustein "FT232RL" ging bisher prima zuverlässig ohne Quarzoszillator mit 4800 Baud. Aber es scheint, daß wenn sich die Abweichungen von zwei µC begegnen, daß es dann zuviel ist.
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.