USART von PIC18Fxx2 bei fehlerhafter Datenübertragung

Jan 25, 2005 3 Replies

Hallo, mit einem PIC18F452 soll eine serielle Übertragungsstrecke (115,2 kBaud) realisiert werden. Es ist damit zu rechnen, dass es bei der Übertragung häufig zu Datenfehlern kommt, da die Übertragungsstrecke massiv gestört wird. Das Framing-Error-Bit und das Overrun-Error-Bit dürften öfters gesetzt sein, auch kann es häufig zu Synchronisationsschwierigkeiten des Controllers kommen. Mittels Interrupt werden die seriell eintreffenden Daten in der Software abgeholt. Das Übertragungsprotokoll sortiert fehlerhafte Signale recht zuverlässig aus. Es ist nicht möglich, die Übertragungsstrecke zu verbessern.



Über erprobte Tipps, wie zum Beispiel mit den Fehlerbits in der Software umgegangen wird, würde ich mich sehr freuen. Die Beschreibungen von Microchip beziehen sich eher auf einen relativ ungestörten Empfang. Es scheint so, dass zum Beispiel bei gesetztem Overrun-Error-Bit kein Interrupt ausgelöst wird, so dass es außerhalb der Interrupt-Service-Routine bearbeitet werden muß.

MfG Martin


Martin Konopka schrieb:

ud)=20

ng=20

t=F6rt=20

s gesetzt=20

rollers=20

=20

nale=20

cke zu=20

Hallo,

da k=F6nnte ein Missverst=E4ndnis vorliegen. Durch St=F6rungen auf der=20 =DCbertragungsstrecke k=F6nnten Framing-Error und Parity-Error entstehen.=

Der Overrun-Error entsteht dadurch wenn im Empf=E4nger die Zeichen nicht =

schnell genug abgeholt werden, aber daf=FCr k=F6nnen die St=F6rungen nich= ts.

Bye

Theoretisch stimmt das! Overrun-Errors treten dann auf, wenn der Controller nach einem Absturz wieder startet und seine Arbeit aufnimmt wenn gleichzeitig schon Daten reinkommen. Das ganze System reagiert auch tolerant auf Controllerabstürze und anschließendem Neustart: In diesem Fall muß auch ein Overrun-Error sicher beherrscht werden.

Trotzdem möchte ich bei den PICs nicht darauf wetten, ob vielleicht nicht doch ein Setzen des Overrun-Error-Flags durch absolut krumme Daten hervorgerufen werden kann.

Ich suche halt nach guten Lösungsansätzen für die Arbeit in extremen Umgebungen.

MfG Martin

Hi Martin,

Martin Konopka schrieb:

men=20

Wenns denn nicht anders geht, kannst Du ja noch eine Pr=FCfsumme o.=E4. blockweise mitsenden lassen (CRC16 z.b.) Damit kannst Du =DCbertragungsfehler sehr sicher erkennen. Zus=E4tzlich w=FCrde ich versuchen, mit der Baudrate so weit wie m=F6glic= h=20 runtergehen und die Signalleitungen RC-filtern.

Auf das sichere Erkennen von =DCbertragungsfehler durch Parity/Framing- Errors w=FCrde ich mich nicht verlassen wollen.

HTH Wolfgang

--=20 From-address is Spam trap Use: wolfgang (dot) mahringer (at) sbg (dot) at

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required