Guten Tag, ich habe ein recht aufwendiges Lampenprojekt realisiert, welches ich jetzt noch mit einem anspruchsvollen Bedienteil ausrüsten möchte. Da bietet sich natürlich heute ein TFT-Touch-Display an. Diese lassen sich nur sehr sehr aufwendig grafisch anspruchsvoll ansteuern, wenn man das mit einem Mikrocontroller machen möchte. Sehr viel leichter sollte das in einer Windows- oder Linux-Umgebung sein, weil dort ja bereits Dateisystem und Grafik-Datei-Formate bekannt sind (und ich also Bilddateien verwenden kann). Aus diesem Grund möchte ich mein Bedienteil mit RaspBerry Pi 2 Model B, einem noch zu findenden TFT-Touch-Display und einer Schnittstelle zum schon bestehenden RS485 Netzwerk ausrüsten. Da ich mich mit Linux nicht wirklich auskenne, dafür aber schon Jahre lang VB programmiere, möchte ich die Programmierung des Raspberry mit Windows VS (VB oder C) realiseren. Daher sollte auf dem Raspberry Win10 ToT laufen. Jetzt endlich meine Frage: Wie kann ich am RaspBerry das RS485 Netz anschließen? Verfügt der Prozessor auf dem RaspBerry über die UART-Schnittstelle, oder muss ich das UART Protokoll selber implementieren? Wenn ich das selbst mache, dann handelt es sich ja um eine zeitkritische Anwendung, kann man dem Win10 auf dem RaspBerry sagen, dass er den Prozeß des Zeichensendens über die eigene UART-Schnittstelle nicht unterbrechen darf? Danke für Eure Hilfe!
Irgendwie versteh ich Deine Frage nicht. Eine UART-Schnittstelle ist letztlich (fast) nichts anderes als ein Schieberegister. Du schreibst ein Byte ins Ausgaberegister und das Byte wird aus der UART rausgeschoben. Wenn Du das meinst, dies läuft komplett in Hardware. Also innerhalb eines Zeichens ohne Unterbrechung. Ansonsten versteh ich Dein "zeitkritisch" nicht. Übrigens bei RS485 musst Du noch bedenken, dass es "Vollduplex" und "Halbduplex" gibt. Halbduplex wird bei RS485 sehr gern verwendet.
Zwar kannst Du einen RS485-Treiber an der UART des Raspberry Pi anschließen, dann aber musst Du Dich immer noch um die Sender-/Empfänger-Umschaltung kümmern. Das ist insbesondere bei knappem Timing auf dem RS485-Bus alles andere als trivial; Du willst nicht zu früh umschalten (bevor der Pi sein Telegramm komplett abgeschickt hat), aber auch auf keinen Fall zu spät (nachdem ein anderer Busteilnehmer begonnen hat, zu antworten). Einfacher bist Du mit einem USB-RS485-Adapter, sofern dieser z.B. mit einem FT232 und der RS485-Beschaltung nach dessen Datenblatt aufgebaut ist. Das übernimmt die Sender-/Empfänger-Umschaltung nämlich selbst, und Du musst Dich mit Deiner Software nicht mehr darum kümmern.
Rufus Τ. F. schrieb: > Einfacher bist Du mit einem USB-RS485-Adapter Und unter Windows sprichst Du den USB-RS485 dann einfach als COM an, oder?
Ich geb's zu, es ist ziemlich schwierig zu verstehen, ich habe versucht weit auszuholen um zu verstehen worauf ich hinaus will. Ich möchte mein Bedienteil über RS485 mit den Lampen verbinden. Den MAX485 werde ich an den Mikrocontrollern an TxD und RxD anschließen und mittels UART ansteuern. Beim RaspBerry gibt es meines Wissens keine UART-Hardware, dass heißt, ich muss das über Software machen. UART ist zeitkritisch weil es eine asynchrone Schnittstelle ist. Dass heißt: wenn ich Daten sende, darf Windows auf dem Raspberry nicht gerade anfangen, das Dateisystem aufzuräumen und erstmal 10 sec. lang meinen Prozess stören. Bei einem Mikrocontroller keine Frage, bei einem Windows-basierten System ein Riesen-Problem!
Danke an rufus und Pepe! Natürlich hat der USB! Damit kann ich das über USB realisieren. Danke!
Pepe schrieb: > Und unter Windows sprichst Du den USB-RS485 dann einfach als COM an, > oder? Sofern es einen Devicetreiber gibt: Ja, natürlich. Allerdings ist zu prüfen, ob es überhaupt passende Devicetreiber für auf ARM laufende Windows-Versionen gibt. Explizit erwähnt wird es von FTDI nicht, was kein gutes Zeichen ist.
ArduStemmi schrieb: > Beim RaspBerry gibt es meines Wissens keine > UART-Hardware, dass heißt, ich muss das über Software machen. UART wäre aber auch beim RaspBerry vorhanden: Auf dem GPIO Stecker. Pin 8 & 10.
Die Hardware-UART des Pi hat aber keine Hardwareunterstützung für die von mir angesprochene Sender-/Empfänger-Umschaltung des RS485-Treibers - und damit wird die Sache ziemlich unpraktisch. Im übrigen scheint es mit dem Treibersupport für diese Hardware-UART auch nicht besonders gut auszusehen: https://www.raspberrypi.org/forums/viewtopic.php?f=105&t=109047
Schön ist was anders. Richtig. Aber wenn der RS485-Treiber nur auf TX geschalten wird, wenn ich was rausschicken möchte und in der anderen Zeit auf RX, müsste es doch funktionieren. Ok, ohne Hardware-Unterstützung ist es natürlich nicht ganz einfach "rechtzeitig" auf RX zu schalten.
Ob es funktioniert, hängt davon ab, wie knapp das Timing ist, das die anderen Busteilnehmer verwenden. Und nicht jede UART liefert die Information, daß das Sende-Schieberegister leer ist (daß also das Senden tatsächlich abgeschlossen ist), in so einem Fall muss man mit einem Timer arbeiten, der beim Beschreiben des UART-Datenregisters mit dem letzten Byte aufgezogen wird und im Timerinterrupt nach Ablauf die Sender-/Empfänger-Umschaltung "von Hand" durchführen. Unter Windows kann das aber schon zu spät sein (Für niedrige Interruptlatenzen ist das nicht berühmt, und an einen echten Timerinterrupt kommt man unter Windows eh' nicht ran, da steckt viel Betriebssystemoverhead dazwischen). Wenn man Glück hat, geht's trotzdem, klar.
Genau in diese Richtung ging meine ursprüngliche Frage: Ist Windows in der Lage, einen "Stream" über UART ungestört ohne es zu unterbrechen zu senden, oder kann es sein, dass es durch eigene Prozesse daran gehindert wird. Die Frage des Timing bei Senden und Empfangen ist bei mir unkritisch, ich werde es halten wie beim Funken auf See! Jeder kriegt seine Zeit, die liegen ausreichend weit auseinander. Die Sendezeiten dienen zugleich der "Synchronisation". Damit gibt es kein: Ich habe gesendet und jetzt aber flott um die Antwort nicht zu verpassen. Also zum Beispiel sendet der Sender bei -5ms (Das Ende der Sendung ist T=0!). Empfänger 1 sendet nach 10 ms, Empfänger 2 sendet bei 20 ms und so weiter!
Prinzipiell ist Windows in der Lage, einen "Stream" unterbrechungsfrei zu senden (sofern die verwendete Baudrate in einem vernünftigen Rahmen liegt, d.h. bei 1 MBaud kann das anders aussehen). Das bekommt der Gerätetreiberunterbau und auch die API hin, sofern nicht für jedes einzelne zu sendende Byte ein separates WriteFile durchgeführt wird. Problematisch wird es erst dann, wenn sehr kleine Häppchen im Ping-Pong-Verfahren ausgetauscht werden sollen. Wie das ganze auf einem eher leistungsschwachen ARM aussieht, entzieht sich meiner Kenntnis. > Also zum Beispiel sendet der Sender bei -5ms (Das Ende der Sendung ist > T=0!). Empfänger 1 sendet nach 10 ms, Empfänger 2 sendet bei 20 ms und > so weiter! Das ist schon recht knapp -- jedenfalls in Abhängigkeit von Baudrate und Paketgröße. Angenommen, Du würdest mit "nur" 9600 Baud arbeiten, dürfte eine Antwort der Empfänger keine 10 Zeichen lang sein. Ob die softwaremäßige Sender-/Empfänger-Umschaltung (durch Wackeln an einem I/O-Pin) ausreichend schnell ist, um binnen 10 msec garantiert umzuschalten, hängt von der Schedulergranularität des Windows-Kerns ab, und davon, wie die effektive Erkennung des Übertragungsendes erfolgt. Wenn Du mit der Windows-API mit der seriellen Schnittstelle kommunizierst, gibt es keine exakte Signalisierung für "übertragung abgeschlossen, letztes Byte gesendet", Du wirst also mit einer Timerfunktion (Callback oder wie auch immer) beim Start der Übertragung für Paketlänge * Zeichendauer warten müssen und nach Ablauf des Timers die Sender-/Empfängerumschaltung durchführen. Da all' diese Dinge mit Taskwechseln einhergehen, kommt hier die bereits erwähnte Schedulergranularität ins Spiel - auf normalen x86-Windows-Systemen beträgt diese üblicherweise 10 msec, d.h. Du kannst, ohne weitere Maßnahmen zu ergreifen, effektiv nur in ganzen 10msec-Intervallen auf etwas warten. Das "normale" Windows bietet die Möglichkeit, diese Granularität auf 1msec zu reduzieren. Alles, was knapperes Timing erfordert, muss auf Devicetreiberebene erfordern, was man aufgrund der Komplexität der Programmierung sich sehr gut überlegen sollte. Wie das bei Windows 10/ARM aussieht, weiß ich nicht, aber ohne vorhandene Treiberunterstützung für USB-Seriell-Bridges oder die Onboard-UART des Raspberry Pi ist es auch eher müßig, sich darüber Gedanken zu machen. Und was auf jeden Fall komplett ausscheidet, ist jede Überlegung, per "Bit-Banging" die UART-Funktionalität in Software nachzubilden. Das ist ganz erheblich zu langsam, wenn es unter einem Betriebssystem läuft und jeder I/O-Zugriff durch diverse Treiber- und Taskwechselschichten hindurch muss.
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.