www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RS232 & Handshake


Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi all,

ich suche einen PAP (Programmablaufplan), wie man eine
RS232-Schnittstelle auf einem µC (8051) mit Handshake (SW + HW)
realisiert.
Alle eigenen Lösungen, zu denen ich bis jetzt gekommen bin, ufern
derart aus, dass ich vermute, dass ich zu kompliziert denke.

Thx

Markus

Autor: Blackbird (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PAP habe ich zwar auch nicht, aber vielleicht hilft Dir der Verweis auf
die IEEE-Standards von RS232 und V.24?

Eine integrierte UART könnte den HW-Handshake vielleicht schon selber
machen? Der SW-Handshake ist eigentlich ganz einfach: Ist der
Empfangspuffer zu 80% voll, so wird ein "Stop" gesendet, wird er
leer(er), wird ein "Go" gesendet (die ASCII-Zeichen hab' ich grad
nicht parat).

Blackbird

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wird Handshake nicht mit Leitungen gemacht (so allgemein)? RTS für
"Request To Send" (will Daten) und CTS "Clear To Send" (habe gerade
nix zu tun, mach mal...) Die Signale sollten dann, wie oben beschrieben,
generiert werden. High, solange alles okay ist, also der jeweilige
Empfänger und Sender nicht ausgelastet sind und Low, falls auf einer
(oder beiden) Seiten ein Überlauf droht. Sollte programmtechnisch kein
Problem darstellen. Solange z.B die Main abgearbeitet wird und der
Prozeß nicht gestört werden darf, wird die CTS-Leitung des
Remote-Controllers heruntergezogen, wenn kein zeitkritischer Vorgang
stattfindet, wird CTS High gelassen. Der PC auf der anderen Seite
verfährt ebenso, so daß der Remote-Controller die RTS-Leitung
kontrollieren sollte, bevor er Daten ´raushaut.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Beiträge.

Mir ist schon klar, wie das zu machen ist, aber meine Lösungen sind wie
gesagt extrem riesig (aufwendig). Dementsprechend auch mein eigens
angelegter PAP.

@Blackbird:

Okay, aber kommt man an die Standards ran? Da muss man doch irgendwie
bezahlen, dass man in das entsprechende Dokument reingucken darf,
oder?!? Falls nicht, wo genau find ich die Spec?

Thx@all

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Travelrec:
Was Du da beschreibt, nennt sich Hardware-Handshake. Den müsste ein µC
aufwendig simulieren, da die darin verbaute UART so etwas in der Regel
nicht unterstützt.
Der von Blackbird beschriebene Software-Handshake verwendet übrigens
die Steuerzeichen XON und XOFF (http://de.wikipedia.org/wiki/Xon).

Mehr Informationen finden sich übrigens auch hier
http://de.wikipedia.org/wiki/RS-232, dort werden unter anderem diverse
Normen mit Namen genannt, was beim Suchen behilflich sein dürfte.

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Rufus: Klar muß der Prozi das simulieren, aber sooo audwändig ist das
nicht - kommt auf´s Programm an. Immer das benötigte Byte in den
Datenstrom einzufummeln, ist auch nicht viel un-umständlicher. Als
alter Elektonik-Freak baue ich dann doch lieber 2 Leitungen mehr ein
und gewinne dadurch mehr Performance und vielleicht auch mehr
Zuverlässigkeit.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daß ein Hardwarehandshake einem Softwarehandshake gegenüber fast nur
Vorteile hat, das wollte ich auch in keiner Weise bestreiten.
Der Programmieraufwand dürfte sich in ähnlicher Größenordnung wie bei
einem Softwarehandshake bewegen; einfacher würde die ganze Chose nur,
wenn die UART selbst Handshake in Hardware implementierte.

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alles klar - jeder macht´s wie er kann ;-). Nichtsdestotrotz sollte sich
der Programmieraufwand gemessen am Nutzen für beide Versionen in Grenzen
halten und dank Timer und Interrupt auch fast unbemerkt neben dem
Hauptprogramm herdaddeln.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das sehe ich auch so.
Nichtsdestotrotz bin ich leider noch nicht weitergekommen :-(

Markus

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was möchtest Du jetzt tun, hast Du schon eine Entscheidung gefällt, ob
Hardware- oder Software-Handshake oder doch beides? Was soll denn am
Ende aller Bemühungen stehen? Wie hoch ist die zu erwartende Baudrate?

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Handshake macht m.E. nur Sinn, wenn man einen Empfangspuffer hat, also:

Ringpuffer anlegen, der aus Interrupt gefüllt und im Programm wenn Zeit
ist gelesen wird. Größe nach Bedarf, Datenrate und Programmauslastung.

Im Interrupt Größe des gefüllten Ringbuffers prüfen (Differenz Schreib-
und Leseposition), bei Überschreitung eines Maxwertes (80% oder so)
Handshake off.

Im Programm beim Auslesen prüfen, ob Ringbuffer wieder leer ((Schreib-
und Leseposition sind gleich), dann Handshake on.

Dann gib es noch etwas, das wohl als Byte-Banging bezeichnet wird: Der
PC darf erst dann das nächste Byte senden, wenn er das vorherige vom
Controller zurückbekommen hat. Braucht keinen Buffer und keinen
Interrupt, ist aber langsam, wie man sich sicher vorstellen kann.

Sven

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, ich würde gerne so viele Möglichkeiten wie möglich erschlagen.
Also 7 und 8 Datenbits, mit/ohne Parität, sowie HW und/oder SW
Handshake. Ringbuffer natürlich. Geschwindigkeit vorzugsweise 115200
oder schneller. Das alles, um möglichst flexibel zu bleiben.

Bevor jetzt jemand das (Aus)lachen anfängt, ich weiss, dass das für
einen 8051 wahrscheinlich nix ist, weil er ja nebenher noch andere
Sachen machen sollte grins

Daher bin ich jetzt nach reiflicher Überlegung sogar am Grübeln, ob ich
es nicht mit einem komplett anderen Ansatz löse:

Ich verzichte auf Handshake sowie Parität und nehme fix 8 Datenbits.
Statt Handshake verwende ich Datenpakete variabler Größe (max.
Buffergröße natürlich ;-) ). Am Ende der Pakete steht noch eine
CRC-Summe. Die µC-Applikation bekommt das Paket nur zu sehen, wenn die
CRC-Prüfung korrekt ist, die Gegenstelle bekommt dann ein ACK,
ansonsten ein NACK.

Das hätte zwar den Nachteil, dass ein Paket komplett abgearbeitet
werden muss, bevor ein neues gesendet werden darf, resultiert aber aus
meiner Sicht in weitaus kürzeren Interrupt-Routinen, was wiederum die
Verarbeitungsgeschwindigkeit der Applikation erhöht. Und es ist aus
meiner Sicht leichter zu implementieren.

Blöd wirds nur, wenn mal eine Peripherie-Einheit an der seriellen
Schnittstelle hängt, die wieder mit Handshake arbeitet, aber bis jetzt
hab ich noch keine wirkliche Verwendung dafür, mir gings nur um
korrekte Kommunikation mit dem Rechner.

Blos, wenn ich es jetzt recht überlege, kommen da (natürlich) wieder
Fragen auf:

1. Wichtigste Frage natürlich, was haltet ihr von dem Lösungsansatz?

2. Ist CRC einigermaßen sicher? Besser als Parität auf alle Fälle, mit
Parität erkennt man ja nur die Hälfte der Fehler.

3. Ich hab über Verwendung von CRC gehört, dass es bei größeren
Datenmengen besser ist, anstatt CRC8 CRC16 zu verwenden. Wie
funktioniert das? Bildet man den CRC16 Wert über 8 oder 16 Bit der
Daten? Wenn 16, was ist bei ungerader Anzahl an Datenbytes?

4. Kann man beliebige Generator-Polynome für CRC verwenden, oder gibt
es welche, die besonders sicher sind?

5. Gibt es andere Verfahren als CRC? Ich meine auch mal Begriffe wie
ERC (nicht Eagle grins) und LRC gehört zu haben (oder ähnlich
lautende). CRC hab ich verstanden, die anderen kenne ich leider nicht.

6. Die Verwendung von ACK/NACK-Zeichen bzw. generell den im
ASCII-Standard spezifizierten Steuerzeichen setzt voraus, dass zur
Datenübertragung die darstellbaren Zeichen verwendet werden (also
"A-Z", "a-z", "0-9" usw.) Wenn ich die rein binäre Übertragung
der Daten implementieren möchte, müsste ich eine feste Paketgröße
verwenden, richtig? Es würde die nötige Zeit für Datenübertragung
nochmals halbieren? Oder gibt es da andere Möglichkeiten, binär mit
variabler Paketgröße zu arbeiten?

7. Hab ich irgendwelche Nachteile des neuen Ansatzes übersehen?

Markus

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.