VisualBasic + Bascom + ComPort

Hallo, ich weiß nicht ob ich hier jetzt richtig bin weil die frage sich eigentlich mehr mit VB und nicht mit Bascom befasst aber ich versuchs mal. Mein Robbi kommuniziert mit einem VB-Prog auf meinem rechner über die serielle schnittstelle. Funktioniert auch so weit ganz gut. Im VB-Prog wird anscheinend immer ein interrupt ausgelöst wenn ein komplettes Datenpaket oder was auch immer angekommen ist. Wenn dieser interrupt auslöst starte ich eine funktion die guckt was angekommen ist und das auswertet. Nun wäre es verdammt praktisch wenn pro interrupt nur ein wert ankommen würde. Das funktioniert aber nur wenn ich zwischen dem senden lange genug abwarte. Ansonsten werden mir mehrere Werte in ein "paket" gemüllt die dann irgendwann abreißen um im nächsten pakt fortgesetzt zu werden. Ist es möglich dem AVR zu sagen das er das paket sofort losschicken soll oder kann ich den rest irgendwie mit müll auffüllen damit pro wert genau ein pakt ankommt? Ich frage mich warum von euch noch keiner auf dieses Problem gestoßen ist oder macht ihr das grundsätzlich anders?
Danke schonmal und Gruß, Markus

was verschickst du für datenpakete.
schildere mal dein projekt.
in visualbasic kannst du sleber festlegen, wie gross die datenmenge ist um diese dann entgen zu nehmen.
mfg pebisoft

ich verschicke die werte vom kompass, dem ultraschallmodul usw. mit dem bascom befehl "print var". in der variable steht dann sowas wie "k360" dafür das der der kompas jetzt 360grad hat. oder u10 fürn ultraschall usw. Und für jeden dieser blöcke hätt ich gern nen einzelnen OnRxd Interrupt im Basic dass ich nicht sowas wie k123u oder so reinbekomme.

da du am pc sowieso alle werte zum bearbeiten brauchst um dann den robby zu steuern schick doch die werte in einem einzigen string und werte den dann in visualbasic aus. so mache ich es. ich habe auch werte vom kompasmodul vom srf04 3x und 2x sharpsensor.
ich habe für alle zahlen je 4byte und die kennzeichnung.
"ul0234um2345ur1200sr0123sl0345ko1290"
ul=srf04 links, um=srf04 mitte, ur=srf04 rechts, sr=sharp rechts, sl=sharp links, ko=compasmodul.
geht ausgezeichnet.
mfg pebisoft

genau so hab ich mir das auch vorgestellt. Aber mein problem ist das ein string in dieser größe mehr als einen interrupt erzeugt. Vielleicht weil er von der hardware irgendwie in pakete aufgeteilt wird. Ich hätte gern das mein basic einen interrupt macht sobald alles da ist. Wie machst du das denn?

in visualbasic kannst du buffer einrichten und mit inputlen festlegen wie lang der string sein soll wenn er ausgegeben wird.
mfg pebisoft

also löst der interupt im basic immer dann aus wenn der puffer voll ist? das mit inputlen probier ich mal, danke.

Wenn man zwischen den einzelnen Informationen ein bekanntes Trenzeichen einfügt, so kann man unabhängig vom Buffer solange die empfangenen Daten aneinander ketten, bis das Trennzeichen kommt und erst dann ein eine Aktion auslösen.
So hat man immer genau ein Datenpaket zur weiteren Verarbeitung.
Als Trennzeichen bieten sich z.B. Chr(13) oder auch ";" an.

Ich habe auf meinem BOT sogar eine Art XML-Protokoll eingeführt.
Der AVR sendet also z.B.: <Kompass>360</Kompass><US>100</US>
An Hand der Steuerzeichen "<" "</" und ">" kann man dann nicht nur die Einzelinformationen mit total unterschiedlichen Längen filtern, sondern auch noch Verschachtelungen machen:
<Motorlinks>
<Geschwindigkeit>100</Geschwindigkeit>
<Entfernung>1000</Entfernung>
<Richtung>Vor</Richtung>
</Motorlinks>
<Motorrechts>
<Geschwindigkeit>100</Geschwindigkeit>
<Entfernung>...

Diese ganzen Blöcke sind dann natürlich auch mit dem Microsoft XMLDOM-Objekten lad- und bearbeitbar:

XMLDOM.load(Buffer)
Print "Kompasswert:" & XMLDOM.selectsinglenode("Kompass").text

hm... das mit dem xml ist nicht schlecht. aber dann bist du ja interrupt-unabhängig. Das heißt du müsstest über einen timer immer mal wieder nachgucken wie viele werte inzwischen angekommen sind. Oder wie machst du das?

Nein, nein.
Der AVR sendet in regelmäßigen Abständen Sensorwerte (US,Kompass, Batteriespannung,...) und bei speziellen Ereignissen (z.B. Motorendposition erreicht)
Auf der PC-Seite wird der Buffer in der Interruptbehandlung (Com_OnReceive) zusammengesetzt und analysiert.
Ist zu einem geöffneten TAG ein End-TAG gefunden, ist das Informationspaket komplett und kann verarbeitet werden.
Bei mir sende ich dann diese "Paket" über TCP an ein entsprechendes Programm, bei dem wieder ein Interupt ausgelößt wird, welcher dort zur Weiterverarbeitung führt (Anzeigen einer Kompassnadel, Prüfung auf Entfernungsunterschreitung, senden eines weiteren Motorsteuerungspackets per TCP an das RS232-Gatwayprogramm und dadurch Weiterleitung an den AVR,...)

Ich hoffe, das Prinzip ist einigermaßen verständlich.

AVR <-RS232-> Gatwayprogramm <-TCP-> mehrere Anwendungen
Und das Ganze mit aufgesetzer XML-Protokoll-Schicht.
Ich kann durch diese Technik sogar im Gatwayprogramm die TCP-Adresse konfigurieren.
Also z.B. Spannungsüberwachung auf "localhost" und Motorsteuerung per WLan an einen externen Steuer-PC mit IP 192.168.0.1 zur "Weiterverarbeitung" senden.