Hi Phineas,
RealView liest den Buffer der seriellen Schnittstelle, worauf es konfiguriert ist.
Es versucht, numerische Werte aus den von Dir gesendeten Zeichen herauszuinterpretieren.
Das bedeutet insbesondere, dass Du den/die Anfragen zum Sensor in einer eigenen Anwendung selbst programieren musst. Geeignet wäre z.B. ProfiLab, oder Du machst was in einer anderen Programmiersprache.
Die Antwort des Sensors passt wohl nicht direkt an RealView, in Deiner Anwendung musst Du das geeignete Format selbst aufbereiten.
Das ganze zusätzliche Teil (diese nötige Anwendung) heisst dann Gateway und benötigt eine Schnittstelle zum Sensor, und eine weitere zum Übertragen an RealView. Das KANN ProfiLab.
Doch dann ist diese zweite Schnittstelle von Deiner Anwendung zum Senden der Daten "besetzt" - somit brauchst Du gar eine weitere Schnittstelle nur für RealView, welche diese selbst öffnet und auf ihr auf geeignete formatierte Daten horcht.
Für die Verbindung zwischen Deiner zweiten und der dritten von RealView brauchst Du typischerweise sog. "virtuelle Schnittstellen", welche nur in Software dasselbe Verhalten einer physikalischen seriellen UART emulieren und ein Werkzeug, welches diese Schnittstellen in Software verbinden kann wie ein Kabel.
Gut geeignet ist VSTE.
Lies zuerst weiter und finde den Link unten.
Wahrscheinlich ist Dir das ja klar.
Zitat aus der Hilfe:
"Programmbefehl im µC-Programm:
Print #1, CH1;"\";CH2;"\";CH3
Beispiel für die Ausgabe:
123\-1.234\1.23E-3
124\-1.235\1.24E-3
...
An diesem Pseudo-Programm erkannt man leicht den Aufbau des Protokolls:
Die numerischen Werte der zu übertragenen Kanäle sind als lesbarer ASCII-Text auf die Schnittstelle auszugeben.
Als Trennzeichen zwischen den Kanälen muss ein ein "\"-Zeichen (umgekehrter Schrägstrich; Backslash) verwendet werden.
Die Übertragung endet typischerweise mit der Zeichenkombination chr(13) chr(10).
Das Protokoll ist von uns fehlertolerant implementiert worden. So kann z.B. auch nur chr(13) oder nur chr(10) am Zeilenende stehen. Ebenso werden sowohl Komma und Punkt als Dezimalzeichen akzeptiert. Die Ausgabe vor- und nachstehender Zeichen, wie z.B. "I =-1,234 mA" liefert einen numerischen Zahlenwert von -1,234. Einheiten werden nicht verarbeitet. Voranstellung dürfen selbst keine numerischen Werte enthalten. So würde beispielsweise die Ausgabe von "Kanal 12 = 13.1 Volt" den numerischen Wert 12 statt 13,1 liefern!
Wenn Du nun einen uC programmiert hast, welcher dieses Format "spricht", und dieser direkt an eine serielle Schnittstelle oder an das USB-IF gesteckt ist als virtuelle Schnittstelle, dann kannst Du RealView auf diese Schnittstelle konfigurieren. RealView "horcht" und versucht zu verstehen
Wenn Du aber den uC über eine Schnittstelle mit einer eigenen Anwendung einliest, und daraus eine Aufbereitung (Umwandlung) der empfangenen Werte programmiert hast, sieht das etwas anders aus.
Hierzu benötige ich mehr Angaben über Deine Umgebung.
Falls das Problem daran liegt, dass der uC an die erste Schnittstelle angeschlossen wurde und Du die aufbereiteten Daten über eine zweite Schnittstelle wegsendest (zu RealView), benötigst Du eine virtuelle Verbindung von dieser (von Deiner Anwendung geöffneten) Schnittstelle zu derjenigen, welche RealView öffnet. Das etspricht deFakto einem Kabel zwischen der zweiten und einer dritten seriellen Schnittstelle. Deine Anwendung für den uC wird Gateway genannt.
Diese Beschreibung entspricht vielleicht nicht Deinem Problem - daher mehr Info nötig.
An anderer Stelle (ProfiLab) in diesem Forum verdankenswerterweise von KAKTUS beschrieben, eigenet sich die Software VSPE
http://www.eterlogic.com/ hierzu bestens und ist zudem noch Freeware.
Viel Glück - RealView ist wie auch ProfiLab ein super Teil !
Viele Grüsse von Thomas