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
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 ...
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
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
Ü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.
