Mikrocontroller als Kommunikationsschnittstelle

[Ja D. (jacoie)]

Liebe Forum-Nutzer,
seit meiner letzten uC Programmierung sind mittlerweile gute 12 Jahre 
vergangen. Nun habe ich eine Applikation, die möglichweise am bestens 
von einem uC gelöst werden kann. Hoffentlich bekomme ich von Euch Tipps, 
wie ich das Problem am besten lösen kann. Ich habe zwei Encoder, die 
über RS232 ihre Daten an ein dSPACE DS1104 board schicken. Leider hat 
ein DS1104 board nur eine einzige PHY-Schnittstelle, deshalb brauche ich 
eine Art Multiplexer zwischen den Encodern, der die Daten empfängt und 
sie über eine RS232 ans DS1104 schickt. Dieser Multiplexer muss die 
Position bei einem Encoder explicit anfragen. Ich dacht erstmal an einen 
Raspberry Pi (PRI) mit einem zusätzlichen 2-Channel Isolated RS232 
Expansion HAT 
(https://eckstein-shop.de/WaveShare-2-Channel-Isolated-RS232-Expansion-HAT-for-Raspberry-Pi 
). Die beiden RS232 sind für die Kommunikation mit dem Encoder besetzt. 
Daher wird noch eine dritte RS232 Schnittstelle für die Kommunikation 
mit dem DS1104 benötigt und diese soll mit einem USD-RS232 Adapter 
gelöst werden. Ein Foto von dem ganzen findet Ihr im Anhang. Irgendwie 
gefällt mir die Lösung nicht und finde sie einfach viel zu umständlich. 
Ein Mikrocontroller mit einer RS232 Extension karte soll das Problem 
auch meistern können. Habt ihr Ideen, Tipps von solcher Hardware? Ich 
wäre für jede Antwort sehr dankbar!
Beste Grüße
Jack

[Julian (Gast)]

Ich würde da eins der günstigen Boards mit STM32F103 ("BluePill") 
nehmen. Der Controller hat 3 UART Schnittstellen, somit brauchst du nur 
noch passende Pegelwandler (MAX2323 o.ä.).

[Christopher J. (christopher_j23)]

Was genau hast du denn mit dem dSpace-System vor bzw. wie zeitkritisch 
ist denn die Auswertung der Encoder? Ich Frage, weil ich selbst schon 
mit solcher Hardware und RS232 gearbeitet habe und das war ein 
unendliches Gefrickel, was die Programmierung (mit Matlab/Simulink) 
angeht, vor allem in einem System in dem harte Echtzeit gefordert ist.

Grundsätzlich ist RS232
1. "schnarchlangsam" (kommt natürlich auf die Ansprüche an aber RS422 
wäre grundsätzlich besser)
2. fehleranfällig, da es keine Fehlererkennung auf Hardwareebene gibt 
(da wäre z.B. CAN klar im Vorteil)
3. "kompliziert" auszuwerten (zumindest innerhalb eines 
Simulink-Systems), da wäre eine parallele Schnittstelle - sofern du denn 
eine frei hättest - zu bevorzugen

Aus persönlicher Erfahrung würde ich eine parallele Schnittstelle 
empfehlen, wenn das irgendwie umzusetzen ist. Der Aufwand im dSpace das 
auszuwerten ist einfach am geringsten und eine Encoder zu 
Parallelportumsetzung ist mit einem Mikrocontroller super einfach zu 
machen. Meine Empfehlung dahingehend: Besorg dir einen Mikrocontroller 
mit CAN-PHY, einen CAN- sowie RS422-Transceiver und brutzel das alles 
auf eine Platine. Schau dann womit du am schnellsten zum Ziel kommst. 
Klingt zwar ein bisschen nach "Bruteforce" (und ist es gewissermaßen ja 
auch) aber man kann sich da super schnell verschätzen, was die 
Programmierung von seriellen Schnittstellen innerhalb von Simulink 
angeht. Das ist halt alles andere als intuitiv und vor allem auch 
durchaus anders als in C. Das fängt schon damit an, dass es in Simulink 
nur mit unglaublichen Verrenkungen möglich ist globale Variablen zu 
erstellen, die dann von mehreren Funktionsblöcken aus zugänglich sind.

[Ja D. (jacoie)]

Danke Julian und Christopher für Eure Antworten,
ich brauche dSPACE für eine Regelung, deren Aktuatoren zwei Motoren 
sind, die jeweils Position geregelt sind. Dafür brauche ich die 
Messsignale als Feedback, in dem Fall die zwei Positionen. Mit der 
dSPACE Bibliothek zur Ein- und Auslesung von den RS232/RS422 ist eine 
Auswertung natürlich sehr einfach. Wenn man aber an freien digitalen 
I/Os ohne Bibliothek arbeitet, dann ist die Auswertung bzw. die 
Kommunikation eine ziemlich schmerzhafte Sache, da gebe ich Dir 
vollkommen Recht. In dem uC die seriellen Daten einlesen und dann 
parallel nach dSPACE schicken, scheint womöglich eine gute Lösung zu 
sein. Doch leider ist der parallel port schon belegt ☹. Ursprünglich 
dachte ich, dass ein uC beide Positionen einlesen kann und sie dann 
alternierend an dSPACE schickt. Dort kann man sie auslesen, was mit der 
dSPACE Bibliothek ziemlich einfach ist und dann die Daten wiederum 
alternierend extrahieren. Vlt. reicht ein Arduino 
https://www.arduino.cc/en/Tutorial/MultiSerialMega für diesen Zweck.

[Christopher J. (christopher_j23)]

Ja D. schrieb:
> Dort kann man sie auslesen, was mit der dSPACE Bibliothek ziemlich
> einfach ist und dann die Daten wiederum alternierend extrahieren.

Ja, es ist durchaus einfach eine Sequenz von Bytes zu empfangen, die das 
dSpace-System empfängt aber damit ist es leider nicht getan. Du musst ja 
auch irgendwie die Informationen daraus extrahieren, d.h. welcher 
Encoder jetzt welchen Wert hat und das heißt eben automatisch, dass du 
irgendeine Art von Frame benötigst, damit du weißt wo jetzt die 
Information anfängt und wo sie aufhört. Das wiederum in Matlab bzw. 
Simulink zu programmieren ist eben meiner Meinung nach durchaus etwas 
"gewöhnungsbedürftig". Mit der CAN-Schnittstelle habe ich mit dSpace 
persönlich keine Erfahrung aber zumindest in der Theorie sparst du dir 
schonmal das framing und die Fehlerkorrektur, weil das vom Protokoll 
selbst übernommen wird und deine Nutzdaten problemlos in einen Frame 
passen sollten.

Was RS232 angeht musst du mal ins Datenblatt von deinem ds1104 schauen 
wegen maximaler Baudrate. Wenn ich mich recht erinnere hat das ds1103 
mit dem ich gearbeitet hatte max. 115200 Baud/s mit RS232 und max 
2Mbaud/s mit RS422. Für Motorregelungen könnten 115200 Baud/s schon 
ziemlich langsam sein. Geh mal von mindestens 30% (eher 50%) Overhead 
für Start- und Stoppbit, sowie dein "Protokoll" aus, dann bleiben dir 
unterm Strich weniger als 10 kByte/s für deine Nutzdaten, d.h. 5 kByte/s 
pro Kanal. Musst du halt wissen ob das für deine Anwendung reicht.

[A. S. (Gast)]

Ja D. schrieb:
> muss die Position bei einem Encoder explicit anfragen.

Was bedeutet das?

Bei einem anfragen, beim anderen nicht?
Wann sendet der andere?
Vielleicht reicht ein Oder.

[Ja D. (jacoie)]

Christopher J. schrieb:

> Ja, es ist durchaus einfach eine Sequenz von Bytes zu empfangen, die das
> dSpace-System empfängt aber damit ist es leider nicht getan. Du musst ja
> auch irgendwie die Informationen daraus extrahieren, d.h. welcher
> Encoder jetzt welchen Wert hat und das heißt eben automatisch, dass du
> irgendeine Art von Frame benötigst, damit du weißt wo jetzt die
> Information anfängt und wo sie aufhört. Das wiederum in Matlab bzw.
> Simulink zu programmieren ist eben meiner Meinung nach durchaus etwas
> "gewöhnungsbedürftig". Mit der CAN-Schnittstelle habe ich mit dSpace
> persönlich keine Erfahrung aber zumindest in der Theorie sparst du dir
> schonmal das framing und die Fehlerkorrektur, weil das vom Protokoll
> selbst übernommen wird und deine Nutzdaten problemlos in einen Frame
> passen sollten.

vielen lieben Dank. Ich würde eine Lösung mit CAN in erwägung bringen. 
Danke nochmal!

[Ja D. (jacoie)]

A. S. schrieb:

> Was bedeutet das?

der MC von der Fa. Faulhaber agiert nicht nur als Low-Level Controller 
sondern auch als Datenlogger. Eine der vielen Daten ist die Position, 
daher muss man eben diese eine Information anfragen und dies geschieht 
mit einer Adressierung eines Registers.

> Bei einem anfragen, beim anderen nicht?
Der andere ist einfach ein Encoder, der keine aktive Senke braucht. Er 
schickt auch ungefragt die Position.

> Wann sendet der andere?
Beide Encoder und MC wissen nichts voneinander, daher ist eine 
Sende-Synchronisierung gar nicht möglich

[A. S. (Gast)]

Ja D. schrieb:
> Er schickt auch ungefragt die Position.

Ja D. schrieb:
> Beide Encoder und MC wissen nichts voneinander, daher ist eine
> Sende-Synchronisierung gar nicht möglich

Das wird doch trotzdem irgendwo angegeben sein, wann oder wie oft das 
passiert, oder?