- Akku Tests und Balkonkraftwerk Speicher         
Ergebnis 1 bis 7 von 7

Thema: Serielle Verständnisprobleme

  1. #1
    steffenvogel
    Gast

    Serielle Verständnisprobleme

    Anzeige

    E-Bike
    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

  2. #2
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    17.01.2005
    Ort
    Obertraun
    Alter
    36
    Beiträge
    194
    Hast du schon einmal etwas von Google gehört?

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

  3. #3
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    17.01.2005
    Ort
    Obertraun
    Alter
    36
    Beiträge
    194
    Oh, es sind sogar 3.820.000 Seiten ...
    (177.000, das sind nur die deutschen Seiten)

  4. #4
    steffenvogel
    Gast
    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....

  5. #5
    steffenvogel
    Gast
    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

  6. #6
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    04.01.2005
    Ort
    Bayern
    Alter
    38
    Beiträge
    795
    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
    Gruß,
    Franz

  7. #7
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    04.01.2005
    Ort
    Bayern
    Alter
    38
    Beiträge
    795
    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!
    Gruß,
    Franz

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test