μC -> RS232 -> Visual Basic 6.0 Datenauswertung

[Rush (Gast)]

Hallo Fachleute ;-)

Ich habe mein Problem schon im μC-Forum gepostet. Vielleicht kann mir 
ein VB-Progger aber etwas besser dabei helfen.

Einen Thread zu diesem Thema gibt es schon, der hat mir aber nicht
weitergeholfen. Also hier nochmal etwas detailierter.

Ich versuche nun seit einigen Tagen mit Visual Basic 6.0 einen über den
UART übertragenen Wert ordentlich zu empfangen bzw. anzuzeigen.
Vergebens!

Bei dem Wert handelt es sich um einen Rückgabewert (Integer) einer
Funktion welche das Temperatur-IC MAX6675 ausliest. Über den UART
verschicke ich zwei Byte hintereinander.

int main(void)
{
  unsigned int temperature;

  initavr();
  USART_Init(UBRR_VAL);
  

while(1)
{
  long_delay(3000);
  temperature = gettemp();  // Temperatur holen
  USART_Transmit(temperature >> 8);
  USART_Transmit(temperature);


}
}

Meine Idee war jetzt, ich versende diese zwei Bytes, lese sie in VB
einzeln aus. Zuerst das erste Byte, schiebe es 8 Bit nach links und dann
zweite Byte.


Das Problem:
Der Paramter RThreshold gibt an, nach wievielen empfangenen Zeichen das
ComReceive-Ereignis ausgelöst wird, InputLen gibt an wieviele Zeichen
aus dem Empfangspuffer eingelesen werden sollen.

Wenn in dem ersten Byte eine NULL drin steht, wird diese ,trotz des
Parameter NullDiscar = False, von VB aber ignoriert.

Setzte ich nun den Parameter InputLen = 2, wird nie ein Wert eingelesen
wenn das erste Byte eine NULL enthält, setzte ich InputLen = 1 wird
immer nur ein Byte eingelesen, sprich, wenn in dem ersten Byte keine
NULL drin steht, wird trotzdem nur eins eingelesen...
Setze ich InputLen = 0, wird zwar der ganze Eingangsbuffer eingelesen
(so kommts mir zumindest vor) allerdings kommt das VB nach einiger Zeit
aus dem Rythmus.
Das ist das erste Problem.

Das zweite Problem:
Ich versende die Temperatur direkt als String. Dann stehen je nach
gemessener Temperatur unterschiedlich viele Zeichen im Empfangspuffer.
Hier kann ich also auch keine feste InputLen setzen da die Zeichen ja je
nach Temperatur variieren. Somit kommt das VB wieder aus dem Rythmus.

Hier mal die Konfiguration des COM-Controls:

MSComm1.CommPort = 1
MSComm1.Settings = "9600,N,8,1"
MSComm1.RThreshold = 1
MSComm1.SThreshold = 1
MSComm1.InputLen = 0
MSComm1.NullDiscard = False
MSComm1.PortOpen = True



Weiss jemand von euch wie man sowas am einfachsten proggen kann?

Danke schonmal im Voraus.

[Rush (Gast)]

Super...

"Ich habe mein Problem schon im μC-Forum gepostet. Vielleicht kann mir
ein VB-Progger aber etwas besser dabei helfen."

Schlau gemeint, aber das ist MEIN Thread !

[Stefan B. (stefan)]

Na dann lösche ich meinen Hinweis auf das Crossposting und meine 
vorherige Antwort halt weg.

[Huhn (Gast)]

Brooooooooooooooooooooooooooooooock pock pock pock..

[Rush (Gast)]

Das ist eine ernst gemeinte Frage und kein Spaßposting!!

[Rufus Τ. F. (rufus)]

> Setze ich InputLen = 0, wird zwar der ganze Eingangsbuffer
> eingelesen (so kommts mir zumindest vor) allerdings kommt
> das VB nach einiger Zeit aus dem Rythmus.

Deswegen verwendet man für derartige Übertragungen auch ein Protokoll, 
das es ermöglicht, herauszufinden, welches Datenbyte welche Bedeutung 
hat. Das ist bei Deinem Ansatz kaum möglich; Du verlässt Dich darauf, 
daß die Wartezeit ausreicht, die Du zwischen Deinen "Datensätzen" 
einlegst.

Besser ist die Verwendung zusätzlicher Bytes, die eindeutig 
kennzeichnen, daß jetzt ein neuer Datensatz beginnt bzw. aufhört; eine 
Variante wäre die Verwendung der Steuerzeichen STX und ETX (0x02 und 
0x03).

Da diese aber auch als Nutzdaten übertragen werden könnten, müsstest Du 
beim Empfang diesen Umstand erkennen; gültig sind Pakete, die mit STX 
anfangen, auf die zwei Bytes beliebigen Inhalte und dann ETX folgen.

Einfacher (und auch mit 'nem doofen Terminalprogramm wie Hyperterminal 
nachvollziehbar) ist allerdings eine Klartextübertragung - Du wandelst 
den numerischen Wert in eine Klartextrepräsentation als Dezimal- oder 
Hexadezimalzahl um, und sendest jeden Wert als Zeichenfolge. Als 
Pakettrennzeichen bietet sich hier CR (0x0d) an.

Somit wird jeder Wert als Textzeile übertragen, die Du mit VB auch 
leicht wieder auswerten kannst, ohne Dir Gedanken um das korrekte 
Auseinanderpflücken und Wiederzusammensetzen von 16-Bit-Werten machen zu 
müssen (-> endianness ).