Hallo, folgendes mir nicht erklärbares Problem. Mein Programm sendet jede Sekunde ein J zu einem anderen Controller, der das empfangende Zeichen auf einem Display ausgibt.Funktioniert super. Wenn ich VOR der for(;;) Schleife den Max auf senden schalte klappt es. Problem : Wenn ich Ihn in der for Schleife auf senden schalte, klappt es NICHT !! Ich verstehe es einfach nicht !? Danke im vorraus ! Gruß Thorsten
So glaube ich habe es gefunden. Aber verstehen tue ich es noch immer nicht !? Es ist die Delay Routine. Wenn ich diese NACH dem umschalten aktiviere, dann sendet er nix.Warum auch immer !? Ohne die Delay Routine klappt es wunderbar. Was ist an der Delay Routine so schlecht, das diese den Programmablauf so stört !? Probiere es einmal per Timer, aber da es ein RS485 Protokoll werden soll, dachte ich das die Delay Routine ok wäre.Nummer 1 sendet und wartet ein paar Sekunden.Dann gibt Nummer 2 Antwort. naja..... Nutze diese Delay Routine auch bei anderen Sachen 1-Wire mit DS18S20, serielles Display u.s.w. nur in diesem Fall ist sie wohl nicht ok. Warum auch immer. Irgendjemand vielleicht eine Idee ? Danke im vorraus ! Gruß Thorsten *gähn
Gast
#318474
Du solltest das TXC-Bit auswerten, wenn du mit rs485 arbeitest. Guck mal ins Datenblatt, was es damit auf sich hat. (ich weiß es...)
DDRD = (1 << DDD2); // Datenrichtung als Ausgang Was isn DDD2 ?
@Kriki DDD2 bedeutet DataDirection Port D Bit 2 im Tutorial ist es mit Port B. Da es bei mir Port D ist, sieht es etwas komisch aus, aber das funktioniert einwandfrei.Darf nach dem umschalten nur keine Delay Schleife aus meinem Programm benutzen, da sonst das umschalten zwar funktioniert ( Nachgemessen ), aber das senden klappt nicht. Thorsten
@Rahul
Meintest Du das deswegen, da ich auch halbduplex beim RS485 habe,das
ich dieses TXC Bit auswerten sollte.
Zitat :
Dieses Bit wird vom AVR gesetzt, wenn das im Sende-Schieberegister
befindliche Zeichen vollständig ausgegeben wurde und kein weiteres
Zeichen im Sendedatenregister ansteht. Dies bedeutet also, wenn die
Kommunikation vollumfänglich abgeschlossen ist.
Dieses Bit ist wichtig bei Halbduplex-Verbindungen, wenn das
Programm nach dem Senden von Daten auf Empfang schalten muss. Im
Vollduplexbetrieb brauchen wir dieses Bit nicht zu beachten.
Das Bit wird nur dann automatisch gelöscht, wenn der entsprechende
Interrupthandler aufgerufen wird, ansonsten müssen wir das Bit selber
löschen.
Gruß
Thorsten
So mit der TXC Änderung klappt es jetzt. Danke !
Gast
#318479
Nennt man sowas nicht "Hilfe zur Selbsthilfe?"
Wenn man noch nie mit dem Max485 gearbeitet hat , finde ich den Ausdruck Hilfe zur Selbsthilfe doch ok. Habe immerhin nicht gesagt weiß nicht , kann mir das mal einer machen. Etwas Denkanstoß braucht der Mensch ab und zu :-) Gruß Thorsten
Gast
#318481
So verstehe ich die "Arbeit" im Forum...
Gast
#318482
Sers, @ engineer Etwas prinzipielles. Wenn du Daten periodisch austauschen möchtest würde ich dir empfehlen die Anfrage des Masters über nen Timer zu steuern. Im Slave und Master wertest du die empfangenen Daten über den UART-Interrupt aus. Habe mit dieser Methode schon ein Netzwerk mit ATMega8515 als Master und bis zu 8 ATMega16 als Slave in einem Netzwerk betrieben. Delay Funktion ist nix gut für diese Anwendung. Ergo: Mit Timern und Interrupts arbeiten!
Sicherlich, ich war auch schon weiter, da es aber plötzlich das Problem des umschalten gab, habe ich alles wieder bis auf ganz simpel zurückgebaut im Programm, um den Fehler des umschaltens heraus zu bekommen. Trotzdem Danke für den Tip. Gruß Thorsten
abo
@Methi Sehe gerade das Du abo hast. Womit kann ich Dir helfen ? Umschaltung und Ping Pong der Daten mit RS-485 Protokoll ist fast laufähig. Gruß Thorsten
http://www.mikrocontroller.net/forum/read-1-307453.html#326835 schaun sie da, ähnliches problem... für das projekt sammle ich halt alle infos, die ich finde... und da ich mit MC noch wenig Erfahrung habe, verschlinge ich solch ein material natürlich :)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.