www.mikrocontroller.net

Forum: PC-Programmierung Serial Thread


Autor: Devil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, ich hab da Probleme mit der seriellen Schnittstelle (C++) auf einem 
Embedded-PC.
Ich verstehe nicht warum bzw. wofür diese Code Schnippsel verwendet 
werden?

DWORD dwWhy;
....
if(dwWhy == WAIT_OBJECT_0) // ReceiveFromCOM event
....
WaitForSingleObject
....
if(dwWhy == WAIT_TIMEOUT)

Gibt es eine allgemeine Anleitung für einen serielle Verbindung für 
einen Embedded PC?

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Gibt es eine allgemeine Anleitung für einen serielle Verbindung für
>einen Embedded PC?

ja in der MSDN, oder in diesem Forum mindestens einmal pro Woche

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Devil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab da noch Verständnisprobleme.
Die Kommunikation mit der RS232 funktioniert ja soweit
(Embedded-PC <--> Computer). Ich habe da einen älteren Quellcode.
Da wurden die jeweiligen Threads für die RS232 verwendet.
Kann oder muss oder sollte ich die Threads auch weiterhin benutzen?
Wie funktioniert der Thread genau. Mit der MSDN komm ich nicht so klar. 
Gibt es im Netz eine deutsche Beschreibung über das Thema Threads 
(RS232)?

void SendStringToCOM(char* tstring, BOOL bVerbose)
{
 ....
}

int GetStringFromCOM(char* rstring, BOOL bVerbose)
{
 ....
}

// THREAD
DWORD WINAPI ThreadCOM(void *unused)
{
 ....
}


int Install_ThreadCOM(void)
{
 ....
}

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich hab da noch Verständnisprobleme
Da du nicht sagst , was du nicht verstehst kann dir keiner helfen.

>Die Kommunikation mit der RS232 funktioniert ja soweit
>(Embedded-PC <--> Computer). Ich habe da einen älteren Quellcode.
Du hast also eine funktionierende Vorlage

>Kann oder muss oder sollte ich die Threads auch weiterhin benutzen?
DU bist der Programmierer! Das ist deine Entscheidung, die wird dir 
niemand abnehmen.

>Wie funktioniert der Thread genau.
Da ist keine Frage. Selbst mit "?" ist das nichts was man in einem Forum 
in Kurzform abhandelt. Stelle eine konkrete Frage.

>Mit der MSDN komm ich nicht so klar.
Das ist sehr schlecht, da es deine wichtigste Informationsquelle ist.
Du sagst auch diesmal nicht warum du nicht damit klar kommst.
Tobi hat dir genau den richtigen Link gegeben.

>Gibt es im Netz eine deutsche Beschreibung über das Thema Threads
ja, Suchmaschine oder Wikipedia

Schreib doch einfach erstmal hin was du erreichen willst.

Autor: Devil (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Im Anhang befindet sich der THREAD Aufruf sowie die 
Initialisierungsroutine für den THREAD.
Die folgenden Funktionen:

void SendStringToCOM(char* tstring, BOOL bVerbose)
{
 ....
}

int GetStringFromCOM(char* rstring, BOOL bVerbose)
{
 ....
}

verwende ich in dem THREAD.
Die Install_ThreadCOMGps() Funktion für ich in meinen gesamten Quellcode 
nur einmal auf. So wie es aussieht funktioniert das ganze auch.
Aber wie könnte ich eindeutig feststellen ob der THREAD auch zu 100% 
funktioniert. Ein THREAD läuft ja parallel zu einem anderen Prozess!



Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Aber wie könnte ich eindeutig feststellen ob der THREAD auch zu 100%
>funktioniert.
In dem du an Hand des Programmcodes verifizierst, ob das Programm für 
alle möglichen Fälle richtig läuft.

>Ein THREAD läuft ja parallel zu einem anderen Prozess!
richtig, aber das hindert dich nicht einen Breakpoint reinzusetzen, wenn 
du etwas nicht verstehst.

Sind die Antworten Dir zu allgemein?
Das Problem ist folgendes:
Du hast ein Programm, daß du irgendwoher (kopiert?) hast. Du verstehst 
es nicht?. Du sagst nicht wozu du es benutzen willst aber erwartest daß 
andere dir sagen ob du es richtig benutzt.
So nach dem Motto "Ich habe hier einen Schraubenzieher, verwende ich den 
richtig?" Da weiß ich auch nicht ob du gerade versuchst eine Schraube 
rauszudrehen oder ob du versuchst dein Auto damit zu knacken.

Autor: Devil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok sorry! Mit dem Embedded-PC steuere ich verschiedene Motoren, LED`s
und führe gewisse Berechnungen durch. Nun möchte ich ein externes Gerät 
an den Embedded-PC anschließen. Von diesem externen Gerät möchte ich 
Strings empfangen bzw. senden. Jetzt habe ich für die serielle 
Kommunikationen THREAD aufgesetzt. Dieser soll z.B. bei Eintreffen von 
Daten(strings) die anderen Prozesse vom Embbed-PC nicht blockieren.
Desshalb habe ich gedac ht ich verwende dazu einen THREAD für die 
COM-Verbindung.

Autor: Devil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie könnte ich WaitForSingleObject sinnvoll im THREAD einsetzen?
Ist der Code so in Ordnung?

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Dieser soll z.B. bei Eintreffen von Daten(strings) die anderen Prozesse vom 
>Embbed-PC nicht blockieren. Desshalb habe ich gedac ht ich verwende dazu >einen 
THREAD für die COM-Verbindung.
Das ist eine logische Herangehensweise. Ich gehe mal davon aus an der 
Schnittstelle hängt nur das Gerät mit dem du kommunizierst.

Du hast erst mal etwas was funktioniert, ob es vollkommen richtig in 
allen Fällen funktioniert ist nicht sicher. Die meißten 
(hobby)Programmierer sind dann glücklich und machen sich keine weiteren 
Gedanken, warum du nicht?
Was willst du ein (in den meißten Fällen) funktionierendes Programm oder 
ein Programm, welches du verstanden hast?

>Wie könnte ich WaitForSingleObject sinnvoll im THREAD einsetzen?
warum willst du unbedingt WaitForSingleObject einsetzen?

>Ist der Code so in Ordnung?
Das kann ich dir nicht sagen, da ich weder das Protokoll zum Gerät 
kenne, noch den ganzen Programmcode.

Was mit auffällt ist folgende Zeile
>InitUART(0x3F8, 4);
Wie alt ist der Code? Kein Windowsprogramm hat es nötig direkt auf die 
Schnittstelle mit Portadresse 0x3f8 und Interrupt) zuzugreifen.


Autor: Devil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja der Code ist schon etwas älter. So ungefähr 8 Jahre. Weiss nicht 
genau.
Wahrscheinlich ist es besser das ganze nochmals neu auf zu ziehen.
Woher könnte ich Infos erhalten, wie ich die RS232 Verbindung auf meinem 
Embedded-PC zum laufen bringen könnte?

Autor: Devil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab da ein Fehler festgestellt:
int CGPSMOUSE::GetStringFromCOM(BOOL bVerbose)

{
   DWORD dwWhy;
   int i,ch;
   int length=0;
   length = rxcom_que.que_contents();
   char rxstring[10];
   rxstring[length];
   i=0;
   int iExitCode = 3;                    // returned value
   
   dwWhy = WaitForSingleObject(hReceivedFromCOMGpsEvent, 200);      
   pMsgHandler->PrLog("dwWhy <<%d\n", dwWhy);

   if(dwWhy == WAIT_OBJECT_0)            // ReceiveFromCOM event

   {
  while(rxcom_que.que_contents() > 0)
  {
    while(i < length) // read all from que
      {
            rxcom_que.read_que_int(&ch);     
            rxstring[i] = (char)(ch & 0xFF); // convert to string
            i++;
      } 
    rxstring[length] = (char)'\0';
      if( bVerbose )
      {
            pMsgHandler->PrLog("COM1<<%s\n", rxstring);

      }
  }
      iExitCode = 0;
   }
   else
   {
    if(dwWhy == WAIT_TIMEOUT)           
      {
         rxcom_que.Clear();                // clear receive queue contents
         iExitCode = 1;                    // return with timeout error

      }
   }
   return(iExitCode);
}

DWORD WINAPI ThreadCOMGps(void *unused)  // COM1-Thread
{
 char rstring[21];
 
 while(TRUE)
 {
  pMsgHandler->PrLog("1<<%d\n", pGpsMouse->GetStringFromCOM(TRUE));
  pMsgHandler->PrLog("2<<%d\n",rxcom_que.que_contents());
 }
 return 0;
}

Wenn ich dies so ausführe, dann wird die if Bedingung
if(dwWhy == WAIT_OBJECT_0) übersprungen. Die Funktion kann dann keine 
Dtaen von der RS232 sammeln.

pMsgHandler->PrLog("1<<%d\n", pGpsMouse->GetStringFromCOM(TRUE));
Hier lese ich immer 1 aus.
Kann mir dazu jemand helfen?

Autor: Devil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Event für das Empfangen wird so initialisiert:
hReceivedFromCOMGpsEvent = CreateEvent(NULL, FALSE, FALSE, ReceivedFromCOMEvent)

Autor: Devil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das verstehe ich immer noch nicht warum dwWhy nicht gleich WAIT_OBJECT_0 
ist!

if(dwWhy == WAIT_OBJECT_0) // ReceiveFromCOM event

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier nochmal ein Link (diesmal in Deutsch)
http://www.microsoft.com/germany/msdn/library/wind...
was da drin steht bezieht sich nicht nur auf Vista sondern zeigt den 
Umgang mit Overlapped IO sehr anschaulich.
Lies dir endlich das ganze in der MSDN durch, die Links hast du.

>Das verstehe ich immer noch nicht warum dwWhy nicht gleich WAIT_OBJECT_0
>ist!

Ich auch nicht da du weder sagst was dwWhy für einen Wert hat, noch 
Codeteile postest die auf irgendeine Weise erhellen würden, was du mit 
der Schnittstelle treibst.
Oder um es mal anders zu formulieren (siehe oben) HÜBSCHER 
SCHRAUBENZIEHER DEN
DU DA HAST.

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.