www.mikrocontroller.net

Forum: PC-Programmierung μC -> RS232 -> Visual Basic 6.0 Datenauswertung


Autor: Rush (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rush (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 !

Autor: Stefan B. (stefan) Benutzerseite
Datum:

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

Autor: Huhn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brooooooooooooooooooooooooooooooock pock pock pock..

Autor: Rush (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist eine ernst gemeinte Frage und kein Spaßposting!!

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.