www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik fehlerfreie UART-Übertragung?


Autor: moin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Ich bitte um Tipps, wie ich meine Datenübertragung per UART
fehlerfreier gestalten kann.
Ich verwende:ATMega128, 18,432MHz, UART1, 8-bit 1-Stop 0-Parity und die
Leitungen TXT und RXD
Als Terminalprogramm: Terminal v1.9b von Bray

Ich möchte ca. 65000 Messdaten fehlerfrei übertragen (je 24bit)und habe
bisher über das genannte Terminalprogramm immer ein Logfile schreiben
lassen. Auf die Menge der Daten gibt es ca 20 Fehler in der
Übertragung.

Wenn ich das Terminalprogramm in der Standarteinstellung belasse
erhalte ich diese Fehler bei allen Bautraten. Ich vermute, dass der
Fehler nicht auf der Seite des ATMega zu suchen ist. Ich glauge, dass
der Fehler kleiner wird, wenn man das Anzeigefenster des
Terminalprogramms verkleinert. Kann das sein?? Muss ich unter Windows
(Win2000) Prioritäten verändern (oder sowas)?

Ich würde ja gerne mir ein eigenes Programm mit Checksummen schreiben -
hierfür reichen meine Kenntnisse leider nicht aus. Kann man die
restlichen Leitung der Schnittstelle verwenden um mein Problem
hardwaremäßig zu lösen?

Vielen Dank für die Mühe - hoffentlich reichen meine Angaben aus
Euer Moin

Autor: Hubert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das der Mega128 nur bis 16MHz spezifiziert ist ist wohl klar. Wenn man
drübergeht sollte man doch aufpassen das sonst alles stimmt, wie
Betriebsspannung, kleinere C am Quarz und sonstige Entstörmassnahmen.
Die geringsten Frequenzhacker wirken sich aus.
Ansonsten bin ich mir sicher das es hier im Forum etwas zu CRC gibt.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An den 18MHz liegt es höchst warscheinlich nicht.
Ich habe schon öfters einige MByte an einen mit 22MHz laufenden AVR
übertragen, und das ohne Fehler. Auch in der anderen Richtung ging es
fehlerfrei.
Teste mal HTerm (unter PC-Programmierung hier im Forum zu finden).

Autor: müllo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei seriellen Übertragung ist es aufgrund der "integrierten" Taktung
wichtig, das der Abstand zwischen Standardeinstellung am
Terminalprogramm (2400Bd, 4800Bd, 9600Bd, ...) und der programmierten
Taktung am AVR (meist ungleich der Standardeinstellungen). Beim
Empfänger wird immer in Bitmitte abgetastet -> nach der Übertragung des
kompletten Bit-Rahmens muss der Abstand immer noch kleiner als die halbe
Bitbreite sein. bestimmt a bissl Wirre

Zur Erläuterung hatte bei einem 8051er ein ähnliches Problem bei
folgenden Einstellungen wie folgt gelöst:
- DÜ mit 8 Datenbits, je 1 Start- und Stoppbit (=10 Bit als Bitrahmen)
- eingestellte Baudrate am Terminal 4800 Baud
- durch Timing am µC konnte ich eine nur eine Ü-Rate von 4630 Baud
einstellen
- nach 10 Bit muss die Differenz noch kleiner als das halbe Bit sein
  * eingestellt Baudrate: 4800Bd
  * Ü von einem Bit: 480Bd (-> 50%: 240Bd)
  * Differenz: 4800Bd (+-) 240Bd = 4560Bd < Ü(µC) < 5080Bd
  --> die Datenübertragung klappt bei dieser Einstellung

Ich vermute eventuell, dass Du auch dort Problem haben könntest. Also
einfach mal schauen, ob bei Deiner Ü-Rate am Ende Deines 24Bit-Rahmens
noch eine "halbe" Bitrate (lieber ein wenig mehr :)) ).

Viele Grüße
müllo

Autor: dicky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo müllo. der moin schrieb aber eindeutig dass er 8 bit mit 1 stopbit
benutzt. die 24 bits werden wohl als 3 aufeinanderfolgende bytes
gesendet.

20 fehler auf 65000 ist 20 zuviel.

das parity bit zu benutzen bringt nicht viel.

vielleicht benutzt moin eine zu hohe bitrate. was benutzt du denn ?
bei hohen baudrates wirken sich kleine abweichungen im takt stark aus,
auch wenn alles wieder neu synchron ist mit einem neuen startbit.

neben einer ungenauen bitrate, kann es auch daran liegen dass die
ersten zeichen nicht richtig erkannt werden. müsste moin auch mal
untersuchen ob das so ist. ich muss hier bei mir 32 kbytes mit 57600
baud in wenigen sekunden übertragen, was ohne probleme mit einem msp430
(2,.. MHz takt, takt ist ganzzahliges vielfaches der bitrate) geht, auch
bei starken temperaturschwankungen dank einer temp-kompensation. kenne
aber übertragungsprobleme zu genüge die zu beginn einer übertragung
auftreten wenn der uart des msp zwischenzeitlich "offline" war, also
abgeschaltet war. es darf zu keiner break situation kommen.

ein paar ideen:
1.) eine kleine sequenz von eindeutigen startzeichen erstmal senden,
die der empfänger erkennt und bei deren ende der eigentliche empfang
erst losgeht. wenn du "rohe daten" als werte 0...255 sendest, kann es
etwas heikel sein, da das erste byte zufällig auch diesen wert haben
kann.

2.) ich würde jeweils eine sequenz (paket) von z.b. 32 zeichen senden,
mit startzeichen und einer angehängten prüfsumme. (8 bit quersummee ist
nicht optimal, aber ganz brauchbar - es gibt bessere verfahren) wenn die
quersumme falsch ist, muss der sender die daten sooft wiederholen bis
alles ok ist. etwas aufwendig und langsamer.

3.) das s-record verfahren von motorola vielleicht ? würde die
übertragung erheblich verlangsamen.

Autor: müllo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sorry, habe wohl nicht alles richtig durchgelesen...

Ich wollte auch nur beschreiben, wie sich eine zu starke Abweichung der
programmierten µC-Baudrate zur Standard-Ü-Rate des Terminals auf die
Daten-Ü auswirken kann. Vor allem, wie man relativ einfach (ohne Oszi)
schauen kann, ob es überhaupt funzt.

Bei meiner Erläuterung ging's um eine Fernsteuerung eines Lauflichts
(Schnelligkeit) per Hyperterminal. Wenn ich ein Zeichen zweimal an den
8051er sendete, änderte sich die Geschwindigkeit irrational
-> Fehler der DÜ! (eingestellte Baudrate am µC war etwas zu langsam,
sodass er bei der 8Bit- Übertragung das eigentliche Stopbit als
8.Datenbit erkannte)
--> Baudrate etwas erhöht und es funzte einwandrei

Bei einer anderen Gruppe war es ein Fehler in der Interruptroutine. Die
haben bei Einsprung weitere Interrupts zugelassen, sodass es dort zu
Überläufen kam.

Viele Grüße
müllo

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@müllo

Deine +/-240Baud sind immerhin 5% Fehler, während alle PC üblichen
Baudraten mit den 22,1184MHz die moin verwendet, mit (theoretisch) 0%
Fehler erreichbar sind.
Daran liegt es also nicht.
20 Fehler bei 200kByte sind zwar nur 100ppm, aber bei einer RS232
Verbindung sollten Fehler von <1ppm bei kurzen Leitungen und
ordentlicher MAX232 Schaltung eigentlich kein Problem sein.

Autor: Kupfer Michi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@moin
wertest du RTS vom Host am µP aus?
(RTS=Request to Send / Host Ready to receive)

Wie verteilen sich denn die Fehler über den gesammten Datenstrom. Wird
es schlimmer wenn der PC stark beschäftigt (z.B. mit der Festplatte)
ist? Die Sache mit dem kleineren Anzeigenfenster->weniger Fehler deutet
in die Richtung dass der Host zwischendurch nicht empfangsbereit ist.

Autor: müllo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt:

Und auf welcher Taktrate sendet/ empfängt denn der µC?

In meiner Erläuterung bin ich auch davon ausgegangen, dass der PC mit
4800Bd (==100% konstant) arbeitet. Aber i.d.R. bekommt man keine
100%ige normierte Baudrate hin)

--> Welche Toleranz darf also bei der programmierten Baudrate (im µC)
gerade noch vorhanden sein, damit das vorletzte Bit vom Stop-Bit
unterschieden wird. Durch die Abtastung (optimal auf Bitmitte) draf es
also maximal um eine halbe Bitverschiebung kommen (bei 10 Bit == 5%).

Es ist natürlich okay, wenn es an etwas anderem liegt. Manchmal
addieren sich auf mehrere kleine Fehler zu einem größeren Problem.

Viele Grüße
müllo

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich betreibe die AVRs meistens mit 18,432MHz (=10 fache der UART
Taktrate in einem PC -> 0% Fehler).
Wenn es schnell gehen muss verwende ich 115200Baud, ansonsten
19200Baud.
Damit habe ich schon einige 10MByte am Stück übertragen, und am Ende
kamen genau soviel Bytes an, wie gesendet wurden.

Autor: Kupfer Michi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dito bei mir (115200Baud) auch über 10m Kabel (gestückelt).

Die einzigen Probleme als ich RTS noch nicht auswertete waren Bytedrops
wenn der PC arg beschäftigt war und ich nicht schnell genug die
Eingangspuffer leerte.

Aber ob dieser Fall vorliegt kann moin ja leicht feststellen.

Autor: moin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin begeistert über eure Hilfe. Ich werde heute abend mal über eure
Vorschläge nachdenken. Ich vermute, dass die Fehler entstehen, wenn der
PC zu stark beschäftigt ist. Ich glaube, dass mein Problem fast oder
ganz beseitigt ist, wenn ich das Terminalprogramm 'HTerm' verwende.
Ich werde mal den Rechner stärker belasten und sehen, ob dei Fehler
zunehmen.

@ Kupfer Michi: Was sind Bytedrops? Wie wertet man RTS aus? (Würde ich
gerne machen)

Zur Fehlerverteilung: Zu Anfang habe ich keine Fehler. Bis zum Ende der
Übertragung werden es immer mehr und die Anbstände werden kleiner.

Ich deute 'meine Fehler' so, dass der PC eine Bytes vergisst oder
sich irgend etwas so verschiebt, das Teile falsch gelesen werden. Nach
einer kürzeren Überprüfung habe ich festgestellt,dass ich eine
fehlerfreie Übertragung erhalte, wenn ich nur das Programm 'HTerm'
laufen lasse. (bisher nur zweimal geprüft) Ob das Problem gelöst ist,
kann ich noch nicht sicher sagen.

Euer moin

Autor: Kupfer Michi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@moin

>Bytedrops
Bytes die bei der Übertragung verloren gehen (z.b. weil der
Eingangspuffer voll ist und die HW. nichts mehr annehmen kann).

Schick einfach einen synthetischen Datenstrom (0x00 ... 0xFF repetitiv)
und schau was ankommt bzw wert es mit einem kleinen Program aus. Wenn
bytes fehlen -> RTS Problem, wenn falsche Bytes -> Übertragungsfehler.

>RTS
siehe Anhang. Wird von der Host HW bzw. SW gesetzt um anzuzeigen dass
gesendet werden darf. Schau einfach mit dem Oszi nach ob RTS kurzeitig
ausgeht (angeht? Polarität???)

RTS einfach wie TXD/RXD über einen MAX232 an den µP ranführen und vor
dem UART_Send abfragen und ggf. warten.

Das Host Terminalprogram muss jedoch als Flowcontrol: RTS/CTS
aktivieren. Sonst werden die Signale nicht gesetzt. Es gibt auch noch
XON/XOFF Steuerung über den Datenstrom.

Die Windows API Calls für Serielle I/O kennst du ja um nicht auf ein
Terminal Programm angewiesen zu sein?

Autor: moin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Kupfer Michi
Es fehlen wirklich Bytes, wenn ich Daten von Hex 1100 bis FFFF sende
(aufsteigend). Deine Vermutung war wohl richtig.

@ Kupfer Michi
Was sind Windows API Calls für Serielle I/O??? Von Programmierung auf
dem PC habe ich keine Ahnung - leider.

Ich werde jetzt RTS zusätzlich in meine Routine einbinden: Ich werde
vor jedem Byte dass ich senden möchte abfragen, ob RTS=1 gesetzt ist
(oder nicht-gesetzt=0 ist - ausprobieren) und dann die Übertragung
starten.

Autor: moin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch nach dem Lesen im Internet ist mir die Einbindung von RTS noch
nicht gantz klar:
- RTS leite ich vom PC über den MAX232 zum ATMEGA128
- Im Terminalprogramm schalte ich die Hardwaresteuerung ein
- Ich sende nur dann vom mega128 zum PC, wenn RTS high ist-sonst warte
ich mit dem Senden.

Ist das richtig??

Autor: Kupfer Michi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
richtig.

RTS und CTS zeigen dem jeweiligen Partner an ob man selbst
empfangsbereit ist.
RTS - PC out, sagt µP PC ist bereit für Datenempfang, µP kann senden
CTS - µP out, sagt PC µP ist bereit zum Datenempfang, PC kann senden

Im aller einfachsten Fall ist RTS->CTS am Kabel gebrücked. Wenn der PC
also beim Öffnen der Verbindung RTS setzt wird dies als CTS
zurückgeschickt und der PC denkt der µP/Modem ist Empfangsbereit, was
in den meisten Fällen auch so stimmt.

Also:
µP ist empfangsbereit -> µP setzt sein CTS, PC weis dadurch er kann
senden. wenn der µP gerade beschäftigt ist (d.h. ein USART Interupt
könnte verloren gehen) dann wird CTS zurückgenommen. Das
Terminalprogramm wartet mit senden.

µP will Senden -> RTS prüfen und ggf. warten.

RTS wird von der PC HW/SW gesetzt wenn die COM Verbindung geöffnet ist
und der PC Eingangspuffer nicht mehr als 3/4 voll ist. Ist der Puffer
voller so wird RTS zurückgenommen und erst wieder eingeschaltet wenn er
wieder 1/2 leer ist.
Das PC Terminal Programm muss natürlich RTS/CTS Handshake aktiviert
haben und unterstützen.

Wegen der Invertierung im MAX232 werden die Signale am µP natürlich Low
im Aktivzustand.

>Windows API Calls für Serielle I/O
Das sind die Betriebssystemaufrufe mit denen man von der Seriellen
Schnittstelle bedienen kann.
Wenn du auf der PC Seite nicht selbst programmierst was kannst du den
dann mit den Daten überhaupt anfangen?

Autor: moin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Daten kann ich dann in Excel einlesen und dann weiterverarbeiten,
z.B. Mittelwert bilden, gleitenden Mittelwert bilden, Histogramm
erstellen, ...
An mehr habe ich mich noch nicht gewagt. Auf Dauer werden ich wohl
nicht um VB herumkommen. Ich träume noch von einer automatischen
Schnittstelle vom ATMEGA zu Excel, wo alles automatisch gemacht wird.

Die Übertrgung ist Teil eines Messwerterfassungssystems wo du mir auch
schon mit Verbesserungsvorschlägen geholfen hast:
http://www.mikrocontroller.net/forum/read-1-161803.html

Autor: Kupfer Michi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich träume noch von einer automatischen Schnittstelle

Mach doch eine Programmier AG auf und stell es als Projektziel :)

In der Oberstufe hats doch sicher den ein oder anderen für den sowas
schon im Bereich des mögliche liegt und so hat jeder was davon... oder?

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier scheint einiges durcheinander zu kommen...

Zur Kärung:

RTS + TxD sind ausgehende Signale.
CTS + RxD sind eingehende Signale.

(Eselsbrücke: Die es gibt auf jeder Seite ein R.)

Eine Verbindung zwischen Sendersignal und Empfängersignal
  =  TxD -> RxD
 und RTS -> CTS

Man muss also den Zustand des CTS Eingangs (verbunden mit dem RTS
Ausgang der Gegenstelle) prüfen bevor man sendet.

Autor: Kupfer Michi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, normalerweise wird für Signal und Anschlusspunkt der selbe Name
verwendet. Beides wird dann umgangssprachlich als synonym verwendet.

RS-232 geht da einen anderen Weg und benennt die beiden Endpunkte einer
Leitung unterschiedlich und zu allem Überfluss überkreuz gleich. Dies
ist zwar wegen der Symetrie der Situation sinnvoll und logisch, führt
jedoch trotzdem schnell zur Verwirrung (zumindestens bei mir, wenn man
vereinfachend von RTS spricht, was meint man damit, das Eigene, das der
Gegenstelle oder das RTS das auf der Gegenstelle CTS heisst?)

Ich hoffte dadurch dass ich mich primär auf die PC
Ausgangsignale/Pinbezeichnungen bezog dieser verwirrung aus dem Weg zu
gehen. Scheinbar mit mässigem Erfolg...

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> RS-232 geht da einen anderen Weg und benennt die beiden
> Endpunkte einer Leitung unterschiedlich

Die Verwirrung entsteht nur, wenn an beiden Enden der Verbindung
Endgeräte sitzen, wie PCs, Controller, Programmer, etc. Freilich ist
RS232 dafür garnicht konzipiert worden. Sondern für Modems.

> RTS + TxD sind ausgehende Signale.

Nur bei Anschlusstyp DTE (Data Terminal Equipment = PC/µC). Beim
Anschlusstyp DCE (Data Communication Equipment = Modems) sind es
Eingänge.

Es ist also immer wichtig, den Anschlusstyp zu kennen. Der STK500
beispielsweise kommt als DCE daher, damit keine Nullmodemkabel
notwendig sind.

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich beziehe mich bei meinem obigen Beitrag bei RxD und TxD auf die
Bezeichnung bzw. Funktion der Pins am AVR. Synonym dazu werden von mir
CTS als IN und RTS als OUT bezeichnet (obwohl die Pins dazu nicht
vorgeben sind).

Autor: müllo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt:

Ich muss jetzt nochmal nachhaken, weil ich entweder auf dem Schlauch
stehe oder etwas falsch verstanden habe.

Ich bin davon ausgegangen, das ein ATMega128 mit f_osz=18,432MHz
betrieben wird und die DÜ an der UART1, 8-bit 1-Stop 0-Parity gewünscht
wird.

Mich würde jetzt mal interessieren, welche Baudrate über das
Atmel-Register eingestellt ist und auf welcher rü das Terminal läuft.

Autor: moin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Müllo
ATMega128: f_osz=18,432MHz; UART1; 8-bit 1-Stop 0-Parity
     .equ CLOCK = 18432000               ;d.h. 0% Fehler
     .equ BAUD = 115200
     .equ UBRRVAL = CLOCK/(BAUD*16)-1    ; UBRRVAL = 9 (exakt)
     ldi   t0,Low(UBRRVAL)  ;Low-Byte für Baudrate
     ldi   t1,High(UBRRVAL)  ;High-Byte für Baudrate
     sts   UBRR1L,t0;out
     sts   UBRR1H,t1;out  ;Baudrate setzen
PC: Terminalprogramm HTerm 0.5.7 115200 Baud; Com1 (höhere Bautraten
lässt der PC nicht zu)

@ AN ALLE
Dies ganze hin und her hat mich doch verwirrt  ;-(
Könnt ihr bitte überprüfen, ob ich alles richtig verstanden habe?

Wenn ich auf den Stecker des PCs (oder einer 1:1 Verlängerung) sehe
habe ich folgende Pins:
1            2            3            4            5
DCD         RxD          TxD          DTR          GND
      6            7            8            9
     DSR           RTS         CTS          RI

Ist das richtig, dass ich die RTS-Leitung des PCs abtasten muss?
Wenn alles OK ist, muss sie auf low sein (hinter dem MAX232 auf Seiten
des AVR). Wenn der Puffer des PCs zu voll wird, wird die RTS-Leitung
high und der AVR muss mit dem Senden von Daten warten.     Ist das
richtig???

Nun zu meinem ursprünglichen Problem:
-Seit ich das Terminalprogramm gewechselt habe (von Terminal v1.9b
(Bray) nach HTerm 0.5.7)kann ich selbst bei 115200 Baud und über
500000 übertragenen Bytes KEINE Fehler mehr erzeugen. :-)))))
Ich kann immer noch nicht glauben, dass all meine Probleme nur vom
'falschen' Terminalprogramm verursacht worden sind.
-Da ich mich von dem ganzen hin und her habe verwirren lassen, habe ich
nacheinander die RTS und die CTS Leitungen abgetastet. Während der
Übertragungen konnte ich keine Pegeländerungen durch eine zu hohe
Rechnerlast feststellen (egal wie ich den Rechner belastet habe -
Rechner läuft unter win2000).
Bevor jemand nachfragt: Ja, ich habe das Handshaking eingeschaltet ;-)
Auch bei dem fehlerhaften Programm habe ich auf beiden Leitunge keine
Fehler feststellen können. (Es produziert noch immer seine Fehler -
auch bei recht niedrigen Baudraten)
Wie könnt ihr eine Pegeländerung durch eine zu hohe Rechnerlast
hervorrufen???

Vielen Dank für eure Mühe
moin

Autor: müllo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
alles klar...bei der 8051er Kiste konnte man die serielle Schnittstelle
nur über einen Timer synchronisieren und da konnte man keine
"genormte" Baudrate (in deinem Falle 115200) einstellen.

aber jetzt läuft's ja...viel Freunde und viele Grüße
müllo

Autor: Kupfer Michi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Pin Belegung am DB9 PC Ausgang
Stimmt, und diese Bezeichnungen sind für dich allein entscheidend.
Und um nicht noch mehr Verwirrung durch die verscheidenen
Signalpolaritäten auf dem Weg bis zu deinem AVR zu stiften Mess einfach
nach:
Vor dem Start des Terminal Programms sollte RTS "nicht
Empfangsbereit" anzeigen, nach dem Start/Öffnen des COM Ports sollte
dann die Leitung umschalten. Daran erkennst du auch ob RTS/CTS
Handshake aktiviert ist.***

Wie misst du ob RTS kurzzeitig umschaltet?

Im PC gibt es 2 Eingangspuffer: den FIFO Puffer des UART,der dürfte
vielleicht so 16-64 Byte grosse sein, von dort schafft das BS die Daten
in den COM API Puffer, der ist vielleicht so 2-3KB gross.
Holt die Applikation z.B. durch falsches Design (Multithreading und
Asynchrone I/O) die Daten nicht schnell genug ab so gehen sie verloren
(d.h. wenn das Handshake nicht befolgt wird).

***mist, hab gerade nochmal nachgeprüft: selbst bei deaktivierten
RTS/CTS Handshake wird beim COM Port öffnen RTS aktiviert, dann aber in
der Pufferüberlaufsituation nicht mehr zurückgenommen. Ob der COM port
von deinem Terminalprogramm richtig konfiguriert ist kriegt man also so
nicht direkt heraus.

Autor: Steffen Brüssel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe  nicht jedes einelne Wort hier gelesen aber was hälst du von
ner CRC Prüfsumme. Ich tausche zwischen PC und MC Daten in Byte
orientierten Telegrammen (Modbus RTU) aus.
Darin enthalten ist ne CRC 16 Prüsumme die wird über die Daten des
Einzelnen Telegrammes erzeugt auf beiden Seiten. Beim Senden und
Empfangen. Die Summe wird mitgesendet. Du kannst dann prüfen ob die
Übertrgung fehlerfrei abgelaufen ist.
Die CRC 16 Berechnung kann glaub ich dasWinAVR schon selbst. Ansonsten
stell ich dir gern entsprechenden Code zur Verfügung.

Gruß

Steffen

Autor: moin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Steffen
Da ich noch keine Programme für den PC schreiben kann, lade ich die
Daten mit einem Terminalprogramm herunter und kopiere sie dann nach
Excel. Excel macht dann alles weitere. (Ich träume noch von einem
kleinen Programm, dass auf dem PC die Daten direkt nach Excel kopiert)
Eine Prüfsummenberechnung kann also leider noch nicht stattfinden. Da
ich in Assembler programmiere, hilft mir dein Angebot leider nicht
weiter

Wenn die Daten wahlweise an einen graphischen Taschenrechner TI83/TI84
gesendet werden, findet eine Prüfsummenkontrolle statt, da das
Übertragungsprotokoll dies zwingent vorschreibt.

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt

> An den 18MHz liegt es höchst warscheinlich nicht.
> Ich habe schon öfters einige MByte an einen mit 22MHz laufenden AVR
> übertragen, und das ohne Fehler. Auch in der anderen Richtung ging
es
> fehlerfrei.

Das ist schön. Da "moin" aber von einer fehlerfreien Übertragung
sprach, ist es sicher der flasche Weg, ein Bauteil außerhalb seiner
Spezifikation zu betreiben.

Autor: Steffen Brüssel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicht Träumen.  ;)
Wenn du dichn Bissel mit Visual Basic beschäftigst, hast du ruck zuck
ne Verbindung zwischen Excel und AVR zurechtgebastelt.
Die serielle Kommunikation geht recht einfach. Nach den ersten
obligatorischen Rückschlägen zumindest.

Ich kann nur sagen, dass sich bei mir die CRC Geschichte richtig
gelohnt hat.
Bei dir müsste allerdings auch das Terminal damit klar kommen...

Aber vielleicht magst dus ja mal mit Telegrammen und CRC Prüfung
probieren, wenn du anfängst kleine PC Programme zu schreiben. ;)

Viel Erfolg

Steffen

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn genügend Leitungskapazität vorhanden ist, kann man einfach die
Daten dreimal schicken und dann die 2-von-3-Funktion bilden, die jedes
einzelne gekippte Bit korrigiert:

#define mc_two_of_three(a, b, c) (((a) bitand (b)) bitor ((a) bitand
(c)) bitor ((b) bitand (c)))

Das Makro hat den Vorteil daß man wahlweise chars, ints ... übergeben
kann.
Für die Fehler-Detektion nimmt man einfach das EXOR von a, b und c mit
anschließendem Bitcount.
Ansonsten gibt's auch kompliziertere ECC Codes, die weniger
Leitungskapazität benötigen.

Autor: Sascha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

@Steffen,
Könnstet Du mir den Source für Modbus zusenden??

Grüße
Sascha

Autor: linda (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
busco una amistad, sincera, y si se puede hasta una relacion

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.