-
        

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 15

Thema: serielle Schnittstelle vom PC unter C++

  1. #1
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    17.08.2005
    Alter
    33
    Beiträge
    685

    serielle Schnittstelle vom PC unter C++

    Anzeige

    Hallo,

    um meinen Bot zu kontrollieren und die Messergebnisse auf dem PC darstellen zu können, benötige ich eine funktionierende Kommunikationsgrundlage.

    Auf der Bot-Seite ist alles klar. Die Daten vom Terminal-Programm werden alle richtig erkannt und richtig zerlegt (verwende nur Zeichenketten).
    Nur will ich halt nicht ein fertiges Terminal-Programm verwenden, sondern mein Eigenes. Dazu habe ich mir mühsam eins unter Borland 6.0 gebastelt ( ich habe noch mit C zu tun, da will ich mich nicht noch Hals über Kopf in C++ reinsteigern).

    Was ich jetzt nur bräuchte, wäre eine ganz simple Funktion zum Aufrufen der Schnittstellen-Parameter (Com-Port, Baudrate ,...) und eine SendData/ReadData Funktion. Diese ReadData Funktion müsste an ein Event gekoppelt sein (wenn ein Zeichen im Buffer des PC's vorliegt).

    Nun habe ich wirklich nichts richtiges im Internet gefunden (auch nicht hier im Forum). Immer wenn ich solche Beispiele adaptieren will, haut nichts hin:
    http://www.winapi.net/index.php?inhalt=t3
    http://msdn2.microsoft.com/en-us/library/ms810467.aspx
    http://www.codeproject.com/system/serial.asp
    (um nur wenige aufzuzählen)
    Auch 2 Bücher habe ich mir dazu ausgeliehen.

    Was ich benötige ist wirklich nur eine Integration einer fertigen Komponente. Ich stell mit das wie beim Controller vor. Man hat zB. zig Dateien für den DS18S20 und per Hauptprogramm wird nur eine einzige Funktion (wie ein Makro) aufgerufen und fertig (also nur die Header-Datei einbinden).

    Bin wirklich am ausrasten, nur wegen dem blöden *Piep* sucht man ewig im Netz, probiert und sucht weiter...
    Um am Ende nichts ordentliches heraus zu bekommen. Na gut, etwas gutes war dabei: Timer unter C++ bekomme ich nun hin (aber keine Ahnung von Events - für Controller ist die Interrupt-Programmierung und die UART-Schnittstelle eigentlich so simpel zu programmieren ).

    Euer deprimierter Reeper

  2. #2
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    Das hab ich mir aus einem alten Artikel gerettet, schau mal, vielleicht hilft es dir

    8-Bit,
    ohne Parity,
    ohne Flußkontrolle (3 Draht)
    Ich verwende übrigens das MS VisualC++. Bei diesen Calls ist aber nix davon zu sehen, da es die üblichen Standard-Calls sind.
    Keine Klassen, kein nix.



    Windows-Interface
    Code:
    Open
    Get Handle 
    char	cName[]="\\\\.\\COM1";  
    HANDLE	hFile;
    
        hFile= CreateFile(cName,GENERIC_READ|GENERIC_WRITE,0,0,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0);
    
        if(hFile==INVALID_HANDLE_VALUE)    // Das war nix, eventuell anderes "COM" versuchen
    
    Das Handle "hFile" wird nun für alle Calls angegeben, wie halt bei Windows üblich. 
    
    Set State 
    Mit diesem Handle kann (muß) man die Eigenschaften festlegen. Ich sag's ehrlich, mit den Time-Out Argumenten hab' ich nicht weiter 'rumprobiert, mir war nur wichtig, daß es funktioniert. Das letzte Mal hab ich noch "*.SYS" Treiber für das Steinzeit-DOS geschrieben. Also eventuell bitte um Nachsicht. 
    
    COMMTIMEOUTS	sTo;
    DCB		sDcb;
    
    	memset(&sDcb,0,sizeof(sDcb));
    	sDcb.DCBlength          = sizeof(sDcb);
    	sDcb.BaudRate     	= Baud;            // 9600 oder eine andere Baudrate
    	sDcb.fParity      	= FALSE;
    	sDcb.fBinary      	= TRUE;
    	sDcb.Parity       	= NOPARITY;
    	sDcb.StopBits     	= ONESTOPBIT;
    	sDcb.fOutxCtsFlow 	= FALSE;
    	sDcb.fOutxDsrFlow 	= FALSE; 
    	sDcb.fDtrControl	= DTR_CONTROL_ENABLE;
    	sDcb.fRtsControl	= RTS_CONTROL_ENABLE;
    	sDcb.fDsrSensitivity    = FALSE;
    	sDcb.fAbortOnError	= FALSE;
    	sDcb.ByteSize     	= 8;
    	
    	if(SetCommState(hFile,&sDcb)) 
     	{
    	  sTo.ReadIntervalTimeout	   = MAXDWORD; 		// 0 ms Read-Timeout
    	  sTo.ReadTotalTimeoutMultiplier   = 0; 
    	  sTo.ReadTotalTimeoutConstant     = 0; 
    	  sTo.WriteTotalTimeoutMultiplier  = 1;			// 1*2 ms Write Timeout
    	  sTo.WriteTotalTimeoutConstant    = 2;
      	  if(SetCommTimeouts((HANDLE)hFile,&sTo))
    		return 1;  // O.K. return
            }
          	CloseHandle(hFile);
            return 0;          // Im Fehlerfall
    }
    Read
    Fragen, ob Daten da sind 
    COMSTAT	sComStat;
    DWORD	dwErrorFlags = 0;
    
    	ClearCommError(hFile, &dwErrorFlags, &sComStat);
    
            sComStat.cbInQue;     // Die Anzahl der Bytes im Buffer
    Daten abholen 
    DWORD	dwCount;
    	ReadFile(hFile, Buffer, Max, &dwCount, 0);
    Buffer ein Bereich für die Daten 
    Max die Anzahl der gewünschten Bytes 
    dwCount die Anzahl der tatsächlich bekommenen Bytes 
    Write
    	WriteFile(hFile, Buffer, Count, &dwCount, 0);
    Buffer die zu sendenden Daten 
    Max die Anzahl der Bytes 
    dwCount die Anzahl der tatsächlich gesendeten Bytes 
    Close
         	CloseHandle(hFile);
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  3. #3
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    17.08.2005
    Alter
    33
    Beiträge
    685
    Geht leider nicht, aber danke Picknick

    Borland kennt viele Befehle nicht (Get, Set, ...).

    Ich konnte vor einiger Zeit mit einem Beispiel aus einem Buch auch etwas senden, jedoch unzuverlässig und nach kurzer Zeit war die Verbindung unterbrochen (Controller war immernoch mit einem anderen Terminal-Programm "erreichbar" -> hat sich also nicht aufgehangen).

  4. #4
    Erfahrener Benutzer Begeisterter Techniker Avatar von just4fun
    Registriert seit
    06.09.2004
    Ort
    Hannover
    Alter
    46
    Beiträge
    314
    Open Source, bitte sehr: http://sourceforge.net/projects/qextserialport bzw. http://qextserialport.sourceforge.net/
    Funktioniert unter Windows und Linux! Ich nutze es selbst mit dem Qt-Framework.

    Kann allerdings sein, dass Qt Voraussetzung ist; da bin ich mir grad nicht mehr so sicher. Dann hast du mit dem Borland-Kram natürlich ein Problem.

    Wäre vielleicht ne gute Gelegenheit auf Open Source (Qt für nicht kommerzielle Zwecke) umzusteigen... Möchte aber jetzt hier keine Diskusion lostreten. Nur als Anregung!!
    www.robotiklabor.de - Der Podcast rund um Robotikthemen
    www.direcs.de - Meine Robotik-Seite mit Videos, Fotos, Screenshots, Source-Codes und mehr.

  5. #5
    Erfahrener Benutzer Roboter Genie Avatar von robocat
    Registriert seit
    18.07.2006
    Beiträge
    935
    ich würde gerne helfen, aber mir ist nicht ganz klar, was du mit borland und events genau meinst. hast du eine windoof fensteranwendung, die man sich zusammenklickt, indem man zB die timerkomponente aufs formular klatscht und dann code in die timerfunktion einfügt? oder verwechsel ich das,..?

    gruesse

  6. #6
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.05.2005
    Ort
    Issum
    Alter
    45
    Beiträge
    2.236
    Hallo just4fun,
    Ich habe eine Frage,
    wird bei dieser lib auch ein Event ausgelöst, wenn Daten über die Serielle Schnittstelle angekommen sind ?

    Das war bis jetzt mein Problem, sowas umzusetzen.
    Gelöst habe ich es so, daß
    1. Der µC nichts sendet, wenn er nicht gefragt wird.
    2. Ich schaue jede Sekunde nach, ob was im Puffer liegt.

    Also keine "saubere" Lösung, ich arbeite auf Linux mit Gtk+ und selbstgestrickten Systemaufrufen und bin bis jetzt glücklich, wenn aber die von Dir genannte lib beim Empfang ein Event generiert, würde ich mir das überlegen, ob Qt doch nicht besser ist.

    Gruß Sebastian
    Software is like s e x: its better when its free.
    Linus Torvald

  7. #7
    Erfahrener Benutzer Begeisterter Techniker Avatar von just4fun
    Registriert seit
    06.09.2004
    Ort
    Hannover
    Alter
    46
    Beiträge
    314
    Zitat Zitat von izaseba
    Hallo just4fun,
    Ich habe eine Frage,
    wird bei dieser lib auch ein Event ausgelöst, wenn Daten über die Serielle Schnittstelle angekommen sind ?

    Das war bis jetzt mein Problem, sowas umzusetzen.
    Gelöst habe ich es so, daß
    1. Der µC nichts sendet, wenn er nicht gefragt wird.
    2. Ich schaue jede Sekunde nach, ob was im Puffer liegt.

    Also keine "saubere" Lösung, ich arbeite auf Linux mit Gtk+ und selbstgestrickten Systemaufrufen und bin bis jetzt glücklich, wenn aber die von Dir genannte lib beim Empfang ein Event generiert, würde ich mir das überlegen, ob Qt doch nicht besser ist.

    Gruß Sebastian
    Hi Sebastian,

    nein von selbst nicht. Habe das auch so ähnlich wie du geregelt. Wobei Events und Threads etc. unter Qt extrem easy und sehr leicht und schnell umzusetzen sind: http://doc.trolltech.com/4.3/signalsandslots.html
    www.robotiklabor.de - Der Podcast rund um Robotikthemen
    www.direcs.de - Meine Robotik-Seite mit Videos, Fotos, Screenshots, Source-Codes und mehr.

  8. #8
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    17.08.2005
    Alter
    33
    Beiträge
    685
    Hallo just4fun,

    danke für die Links, steht sehr viel drinnen. Werde es mal mir zu Gemüte führen. Das Blöde an der ganzen Sache ist ja, dass ich es nicht verstehen muss/unbedingt will. Denn es dient ausschließlich als Mittel zum Zweck und das Hauptaugenmerk liegt auf der Controller-Seite (C) und nicht auf dem PC (C++). Eine fertige Lösung wäre schon cool.

    Hallo robocat,

    Soweit mir bis jetzt bekannt, heißen Interrupts in C++ quasi Events (wenn man es vergleichen kann/will).
    Ja, die Timerlösung ist wie du geschrieben hast. Einfach Icon suchen, drauf klatschen und Code einsetzen (letztes so wie beim Controller).

    Hallo izaseba,

    Timer ist zwar eine Lösung, jedoch wie du selber geschrieben hast: "keine saubere Lösung". Es kann ja zwischenzeitlich passieren, dass der Buffer überschrieben wird (wenn man unkontrolliert senden lässt).


    Was auch auf der PC Seite komisch, bzw. für mein Vorhaben suboptimal ist, dass man den buffer jedesmal bestimmen muss (also immer zu erwartende Bytes dazu übermitteln).
    Bei mir ist die Kommunikation so aufgebaut, dass am Ende der Zeichenkette ein '#' steht, somit ist dies das Ende und der String wird zerlegt und verglichen ...
    Ich müsste demnach den buffer vorsichtshalber sehr groß machen. Jedoch wird meistens nur eine Zeichenkette mit 5-6 Zeichen übermittelt. Aber später soll ab und zu mal ein mehrdimensionales Array gesendet werden ...

    Gruß Stefan

  9. #9
    Erfahrener Benutzer Roboter Genie Avatar von robocat
    Registriert seit
    18.07.2006
    Beiträge
    935
    ich glaube, wirklich event-driven ist das alles nicht. zumindest habe ich noch nichts dergleichen gefunden. meistens wird ein thread verwendet, der ständig den port abfragt, also im grunde dein (2.)

    http://www.tetraedre.com/advanced/serial2.php

    gruesse

  10. #10
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.05.2005
    Ort
    Issum
    Alter
    45
    Beiträge
    2.236
    Hallo Just4fun,
    danke für die Antwort, dann werde ich vorerst bei Gtk bleiben, Qt habe ich auch schon programmiert, es war aber noch die 3.* Version gewesen, irgendwas gefiel mir nicht mehr an 4.* (weiß selber nicht mehr, was es war ) und habe mich dann mit Gtk angefreundet...
    Im Endeffekt, ist die vorgehensweise doch fast gleich.
    @Reeper,
    deswegen komuniziere ich mit den µC und nicht andersrum, wenn ich ihm sage, was ich haben will, weiß ich wohl dann am besten, mit welchen Daten ich zu rechnen habe.
    Allerdings verschicke ich keine Strings sondern binäre Form (Es ging mir auf den Senkel von bin nach ascii zu wandeln, verschicken, String auswerten, Zahlen wieder in bin wandern usw. )

    Gruß Sebastian

    EDIT:
    @robocat, dann bin ich beruhigt, daß die anderen auch nur mit Wasser kochen
    Habe mir Dein Link angeguckt, ich glaube es ist das, was Reeper braucht
    Software is like s e x: its better when its free.
    Linus Torvald

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

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