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.
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!
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.
