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
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
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.
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
@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.
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.
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.
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.
Ja, das sehe ich auch so. Nichtsdestotrotz bin ich leider noch nicht weitergekommen :-( Markus
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?
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
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.