Serial Thread

>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

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)
{
 ....
}

>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.

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!

>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.

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.

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

>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.

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?

Hab da ein Fehler festgestellt:

1

int CGPSMOUSE::GetStringFromCOM(BOOL bVerbose)

2

3

{

4

   DWORD dwWhy;

5

   int i,ch;

6

   int length=0;

7

   length = rxcom_que.que_contents();

8

   char rxstring[10];

9

   rxstring[length];

10

   i=0;

11

   int iExitCode = 3;                    // returned value

12

13

   dwWhy = WaitForSingleObject(hReceivedFromCOMGpsEvent, 200);      

14

   pMsgHandler->PrLog("dwWhy <<%d\n", dwWhy);

15

16

   if(dwWhy == WAIT_OBJECT_0)            // ReceiveFromCOM event

17

18

   {

19

  while(rxcom_que.que_contents() > 0)

20

  {

21

    while(i < length) // read all from que

22

      {

23

            rxcom_que.read_que_int(&ch);     

24

            rxstring[i] = (char)(ch & 0xFF); // convert to string

25

            i++;

26

      } 

27

    rxstring[length] = (char)'\0';

28

      if( bVerbose )

29

      {

30

            pMsgHandler->PrLog("COM1<<%s\n", rxstring);

31

32

      }

33

  }

34

      iExitCode = 0;

35

   }

36

   else

37

   {

38

    if(dwWhy == WAIT_TIMEOUT)           

39

      {

40

         rxcom_que.Clear();                // clear receive queue contents

41

         iExitCode = 1;                    // return with timeout error

42

43

      }

44

   }

45

   return(iExitCode);

46

}

47

48

DWORD WINAPI ThreadCOMGps(void *unused)  // COM1-Thread

49

{

50

 char rstring[21];

51

52

 while(TRUE)

53

 {

54

  pMsgHandler->PrLog("1<<%d\n", pGpsMouse->GetStringFromCOM(TRUE));

55

  pMsgHandler->PrLog("2<<%d\n",rxcom_que.que_contents());

56

 }

57

 return 0;

58

}

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?

Den Event für das Empfangen wird so initialisiert:

1

hReceivedFromCOMGpsEvent = CreateEvent(NULL, FALSE, FALSE, ReceivedFromCOMEvent)

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

if(dwWhy == WAIT_OBJECT_0) // ReceiveFromCOM event

Hier nochmal ein Link (diesmal in Deutsch)
http://www.microsoft.com/germany/msdn/library/windows/windowsvista/UnterstuetzungFuerDenAbbruchVonWin32EAVorgaengenInWindowsVista.mspx?mfr=true
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.