ich will mit meinem Pic Daten vom Pc empfangen. aber wenn der pic gerade im sleep mode ist, dann wird er vom dem signal vom pc durch nen interrupt geweckt und springt dann zu der routine die die daten empfängt, aber die kommen immer falsch an. wenn der pic nicht im sleep mode ist dann funktioniert alles. im datenblatt steht dass der pic 1024 tosc braucht bis er wieder im programm anfängt, des hab ich jetzt aber mit einberechnet, funktioniert aber immer noch nicht.
ich warte beim startbit immer 1,5 Bit lang. des wären bei 10mHz oszillatortakt und 9600bps 390 Befehle. jetzt hab ich die warteschleife abgeändert und da werden jetzt nur noch 134 befehle lang gewartet. somit wäre des mit den 1024 tosc / 4 = 256 + 134 = 390 befehle, also müsste es doch gehen. was kann ich noch falsch machen dass es nicht geht.
Hallo Pitt,
sobald der RxD-Interrupt ausgelöst wird, sollte das empfangene Byte komplett da sein. Ich würde die Interrupt-Routine mal überprüfen. Beispiele in Assembler findest Du hier und hier
wie meinst des, dass des byte komplett da ist. also die übertragung wird mit software gemacht, also nicht mit rs232-hardware.
und der pic ist im sleep-modus und das interruptbit gie ist ausgeschaltet, d.h. der pic springt nicht in die interrupt routine sondern macht gleich im programm weiter und geht gleich in die routine in der das byte empfagen wird.
Hallo,
was für einen PIC hast Du ?
Benutzt Du nicht die integrierte USART (sofern 'Dein' PIC eine hat) ?
Wie kommst Du aus dem Sleep-Modus raus, wenn nicht per Interrupt ?
hab den 18F4525. nein benutze nicht die integrierte usart weil da der timer2 mit der verbunden ist und ich brauch den für was anderes. deswegen wird des in der software erledigt.
hier hab ich ein ausschnitt zum thema sleepmode und interrupt.
also ich musste auch einmal sowas realisieren. War damals mit einem 12C509. Das Problem war, dass die ersten Zeichen nicht richtig ankamen. Ich habe dann auf ein Verfahren bei der drahtlosen Kommunikation zurückgeriffen. Dabei werden zuerst einige Trailerbytes geschickt. Die ersten beiden haben den PIC nur aus dem Schlafmodus gerissen, dann kurze Sendepause und anschließend die eigentliche Nachricht senden.
Übrigens: das mit den 1024 Taktzyklen stimmt so schon, aber wer sagt denn, dass der Quarz in 0,nix schwingt. Gerade deshalb wurden diese Zeiten eingebaut, damit ein unbelastetes Anschwingen möglich ist. Wie schnell das allerdings passiert, haängt von verschiedenen Faktoren ab. U.a. Quarzfrequenz (Grundton, Oberwelle), Quarzschliff (Serien- oder Reihen), Temperatur und Spannung. Von daher ist die exakte Startzeit nicht so genau definierbar.
Kannst du die falsch eingelesenen Zeichen auf einer Anzeige sichtbar machen? Oder wenigsten mittels LEDs? Dann kannst du nämlich den IST mit dem SOLL-Zustand vergleichen.
ja des mit dem quarz und anschwingen hab ich auch gelesen, aber da hab ich mir gedacht, des wird schon von den zeiten nix ausmachen. aber so wie es aussieht liegts halt doch am quarz.
ja die zeichen werden empfangen und jetzt wegen der einstellung immer gleich zurück an computer zurückgeschickt aber da kommen ganz andere zahlen an, z.b. bei 00000001 kommt 01101000 und ich hab auch kein bock da alles zu analysieren was ich an der warteschleife umstellen müsst, vor allem weils halt sinnlos ist weil wenn ich des gleiche schicke kommen halt manchmal 11111000 und dann 11111100 an.
dann gabs noch die möglichkeit den pic mit RTS zu wecken aber da bräucht ich noch ne extra leitung.
an die möglichkeit mit dem trailerbyte hab ich auch schon gedacht, aber hab gedacht dass des net so ne schöne lösung ist, aber wenn du des auch schon gemacht hast und es auch noch so in drahtlosen kommunkationen so ist werd ich des auch so machen, dann kann ich mir die ganze arbeit mit analyse oder extraleitung ersparen.
Berechtigungen
Zitieren
Lesezeichen