Serielle Verständnisprobleme

Hi,
so seit langem melde ich mich hier nun mal auch wieder zu Wort...
und zwar bin ich dabei mal ein bisschen mit meinem Asuro rumzuprogramieren. Dabei ist mir aufgefallen das ich so gut wie keine Ahnung vom Aufbau der seriellen Schnittstelle, U(S)ART, RS232 hab.
Wers nicht weis der Asuro komuniziert per Infrarot mit dem PC. Ich benutz C auf der Bot Seite und VB6 auf der Rechner Seite. Nun will ich mit einem VB Programm meinen Asuro kontrollieren. Das ganze so ungefähr so ablaufen:
Alles bis auf die Ereignisse von den Tastern geht vom PC aus.
Also ich schicke mit dem PC per MSComm (VB Steuerelement) eine bestimmte Zeichenfolge. Und der Bot antwortet drauf mit OK oder dem Messwert.
Das senden ist ja noch leicht zu bewerkstelligen. Nur wie empfängt der Bot das dann?
Wozu ist der Buffer?
Liest man den immer komplett aus oder nur zeichenweise?
Wie groß ist der Buffer?
Brauch ich sowas wie ein Handshaking?
Ich hab mir mal die Asuro Lib 2.6 von Sourceforge runtergeladen und hab schon ein bisschen mit der SerWrite und SerRead Funktion rumgespielt.
Nur ohne jeglich ahnung über UART bzw serielle Komunikation bringt das nicht so viel...
Also alles in Allem ich wäre sehr froh wenn mir jemand eine kleine Einführung in die Serielle Komunikation geben könnte..

vielen Dank Steffen

Hast du schon einmal etwas von Google gehört?

Wenn du bei Google nur UART eingibst findest du ca. 177.000 Seiten.

Oh, es sind sogar 3.820.000 Seiten ...
(177.000, das sind nur die deutschen Seiten)

mhm vieleicht lags daran, dass ich nur nach "serielle programmierung" gesucht habe. Ich werds mal mit UART probieren. Sonst habe ich immer nicht das gefunden was ich gesucht habe....

Ok ich werd mich hüten noch ma so eine Frage hier im Forum zu stellen.
Hier http://www.mikrocontroller.net/articles/RS-232
und hier http://www.beyondlogic.org/serial/serial.htm
gibts ne brauchbare Beschreibung.

Steffen

Hallo Steffen,

Sieh dir mal meinen Vorschlag zur Pufferung an:

Zweite Antwort:
https://www.roboternetz.de/phpBB2/ze...090&highlight=

Wenn du dir für deine Befehle ein Protokoll ausdengst, tust du dich viel leichter.

Du überlegst dir ein Startzeichen und ein Endzeichen. Damit du Übertragungsfehler ausgleichen kannst schickst du noch die Länge und eine Prüfsumme mit. Das SMART-Protokoll habe ich in meinem Beispiel. Dieses Braucht man wenn man mit dem"intelligenten" LC-Display von Electronik-Assembly spielt . Schau dir doch mal das Datenblatt an, da ist das Protokoll beschrieben. dann brauchst fast keine Abänderungen an meinem Programm vornehmen. http://www.lcd-module.de/deu/dip/edip.htm

Hier der Beitrag, den ich oben als LINK angeführt habe. Ist Übersichtlicher:
-----------------------------------------------------------------------------------

Hallo,

Zum Thema USART Befehle Empfangen habe ich mir Folgendes Ausgedacht:

Man überlegt sich zunächst wie man seine Befehle Sendet.
Also eine art Protokoll.

Bei mir ist das Folgendermaßen:

1. Ein Zeichen, welches für den Beginn eines neuen Befehlspaketes symbolisiert
2. die länge der Nachfolgenden Bytes
4. X-Bytes

Als Startzeichen habe ich mit ESC ausgesucht. Hat den ASCII-Code 0x1B.

Allgemein ist bekannt, dass es nicht so hinhaut die einkommenden Befehle direkt zu bearbeiten. also schreibe ich die empfangenen Zeichen in einen Puffer.
Da das Befehlspaket ein Startzeichen hat ( ESC hier ), und mir dann gleich die Länge übermittelt ist das ja ein Kinderspiel, die Daten in einen Puffer zu schreiben.

Hier der Code. Ich verwende 5 Puffer:

Code:

uint8_t UART_buffer0[8]; uint8_t UART_buffer1[8]; uint8_t UART_buffer2[8]; uint8_t UART_buffer3[8]; uint8_t UART_buffer4[8]; uint8_t *UART_pointer; void UART_receive( uint8_t data ){ if ( data == ESC ){ uint8_t gotone = 0; UART_buffer0[1] = 0; // Unvollständige verwerfen UART_buffer1[1] = 0; // Unvollständige verwerfen UART_buffer2[1] = 0; // Unvollständige verwerfen UART_buffer3[1] = 0; // Unvollständige verwerfen UART_buffer4[1] = 0; // Unvollständige verwerfen if( ! UART_buffer4[0] ){ UART_pointer = UART_buffer4; gotone = 1; } // Nimm Puffer 4 wenn er frei ist if( ! UART_buffer3[0] ){ UART_pointer = UART_buffer3; gotone = 1; } // Nimm Puffer 3 wenn er frei ist if( ! UART_buffer2[0] ){ UART_pointer = UART_buffer2; gotone = 1; } // Nimm Puffer 2 wenn er frei ist if( ! UART_buffer1[0] ){ UART_pointer = UART_buffer1; gotone = 1; } // Nimm Puffer 1 wenn er frei ist if( ! UART_buffer0[0] ){ UART_pointer = UART_buffer0; gotone = 1; } // Nimm Puffer 0 wenn er frei ist if( gotone ){ UART_pointer[1] = 1; // Markiere den gewählten Puffer UART_pointer[2] = 0; // Leeren UART_pointer[3] = 0; // Leeren UART_pointer[4] = 0; // Leeren UART_pointer[5] = 0; // Leeren UART_pointer[6] = 0; // Leeren UART_pointer[7] = 0; // Leeren } } else { if( UART_pointer[1] ){ // Nur in Puffer schreiben, wenn er in Bearbeitung ist! UART_pointer[ UART_pointer[2] + 3 ] = data; UART_pointer[2]++; // Füllzähler hochaddieren if( UART_pointer[3] && (UART_pointer[2] > (UART_pointer[3]+1)) ){ UART_pointer[1] = 0; // Puffer aus Bearbeitung entfernen UART_pointer[0] = 1; // Puffer als VOLL markieren } } } }

[0] = Puffer ist Volol
[1] = Puffer in Arbeit
[2] = Selbstgezählte
[3] = Empfangene Längenangabe
[4] = Databyte 1
[5] = Databyte 2
[6] = Databyte 3
[7] = Databyte 4

Die routine wird mit UART-Interrupt ausgeführt.

Als erstes wird nach einem Freien bzw. schon gelesenen Puffer gesucht
( schaun ob BufferXXX[0] = 0 ist. )

Wurde einer gefunden, dann wird einen zeiger Drauf!

Dann wird dieser als "in Bearbeitung markiert." und eventuell vorher fehlerhafte IN BEARBEITUNG werden verworfen.
demnach gibt es immer nur EINEN Puffer, der in bearbeitung ist.

sind so viele Bytes empfangen wie es das Längenbyte angab, so wird der pufer aus der Bearbeitung entfernt BufferXX[1]=0 und als VOLL markiert: BuufferXX[0] = 1.

Dieser kann dann bequem von einer anderen Funktion Verarbeitet werden. Das ganze verschafft mehr zeit zum verarbeiten!
Funktioniert bei mir einwandfrei. Hab diesen code ein wenig zugeschnitten, da ich selbst ein bisschen ein anderes "Protokoll"habe, aber dieses ist das beste meiner meinung nach.

Ich hoffe jemand findet Gebrauch dafür!