C win32 api Daten Übertragung

>    printf("%d\n",buf[0]);

1

   printf("%c",buf[0]);

Dein Messgerät schickt dir Text.
Du betrachtest gerade die ASCII Codes dieses Textes. Als Dezimalzahlen 
ausgegeben können die ganz schön verwirrend sein

Sieht aus als ob die Baudrate nicht stimmt.

Apropos: Wo stellst du die eigentlich ein?
Du befüllst zwar einen DCB, machst aber nichts damit .-)

Skaos schrieb:
> mhh die Baudrate stimmt 9600. 9600 stelle ich in dem Hyperterminal.
> Wenn ich mit dem DCB nichts mache :S, wie kann ich dann etwas machen??

BuildCommDCB(...)
SetCommState(...)

Hallo danke für die schnelle Antwort, ich habe mein Programm so geändert 
leider bekomme ich immer noch eine falsche Ausgabe... Ich nuetze ich 
BuildCommDCB(...) SetCommState(...)  falsch, ich habe aber auf die msndn 
Seite nicht wirklich vrstanden :(

1

#include <stdio.h>

2

#include <stdlib.h>

3

#include <windows.h>

4

#include <conio.h>

5

int main(void) {

6

7

  DCB dcb;

8

  HANDLE hPort;

9

        COMMTIMEOUTS cto;

10

  DWORD dw;

11

  unsigned char buf[0x100];

12

  cto.ReadIntervalTimeout=50;

13

        cto.ReadTotalTimeoutConstant=50;

14

  cto.WriteTotalTimeoutMultiplier=10;

15

  cto.WriteTotalTimeoutConstant=40;

16

  hPort=CreateFile( "COM1",GENERIC_READ | GENERIC_WRITE,0,   NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);

17

18

  if (hPort==INVALID_HANDLE_VALUE)

19

        {

20

            printf("CreateFile\n"); return 1;

21

22

        }

23

24

    GetCommState(hPort, &dcb);

25

    BuildCommDCB("9600,n,8,1", &dcb);

26

    while(1)

27

    {

28

    if(ReadFile(hPort, buf, 1, &dw,NULL))

29

        {

30

            //error occurred. Report to user.

31

        }

32

    printf("%s",buf);

33

    }

34

35

CloseHandle(hPort);

36

return 0;

37

}

Edwar Yupanqui schrieb:
> Hallo danke für die schnelle Antwort, ich habe mein Programm so geändert
> leider bekomme ich immer noch eine falsche Ausgabe... Ich nuetze ich
> BuildCommDCB(...) SetCommState(...)  falsch, ich habe aber auf die msndn
> Seite nicht wirklich vrstanden :(


Entschuldige, aber:
Wie wäre es mit Gehirn einschalten?

In der MSDN ist sogar ein vollständiges Beispiel!


>     GetCommState(hPort, &dcb);
>     BuildCommDCB("9600,n,8,1", &dcb);

Und wo ist der SetCommState?

Set Comm State

so wie "Setzen der Kommunikationsparameter"

Du machst:
   Hole die momentan eingestellten    Get Comm State
   Erzeuge die Werte für ...          Build Comm DCB

aber du setzt sie nirgends. Du aktivierst sie nicht! Nur dadurch, dass 
du einer Variabeln bei dir einen Wert zuweist, stellt sich doch nicht 
die serielle Schnittstelle auf einen neuen Baudratenwert ein. Du musst 
dem Betriebssystem schon sagen: "Schau her. So möchte ich das Ding 
eingestellt haben" - Set Comm State

Ok danke für deine Hilfe.
Ich habe aber gerade entdeckt, dass das Programm ohne SetCommState 
funkrtioniert. Ich muss es so ausgeben:  printf("%c",buf[0]);

Warum geht das ohne SetCommState??

Wenn ich SetCommState nutze, wäre es so?
    GetCommState(hPort, &dcb);
    BuildCommDCB("9600,n,8,1", &dcb);
    SetCommState(hPort, &dcb);

danke und tut mir leid für meine dummen Fragen

Edwar Yupanqui schrieb:

> Warum geht das ohne SetCommState??


Weil 9600, 8N1 zufällig die Standard-Einstellung ist. Kannst du auch 
im Gerätemanager umstellen.

Hier gibts übrigens super Beispiel-Code:
http://www.codeguru.com/Cpp/I-N/network/serialcommunications/article.php/c2483

Dieser Code beschreibt eine MFC-Klasse. Einerseits ist das C++ (und kein 
C), andererseits ist die MFC nicht mit der kostenlosen Visual Studio 
Express-Variante nutzbar.

Richtig, aber die paar MFC-spezifischen Sachen kann man leicht ersetzen. 
Es ging mir eher ums Prinzip, damit dem TE klar wird, die man die DCB 
anwendet, die commstates setzt usw. und in welcher Reihenfolge das 
passiert.

Hältst Du das für wirklich wahrscheinlich?

Hmm....stimmt, er gab sich sehr lernresistent. Naja, man soll die 
Hoffnung nie aufgeben.

Christian R. schrieb:
> Hmm....stimmt, er gab sich sehr lernresistent. Naja, man soll die
> Hoffnung nie aufgeben.

Danke für das Beispiel. Jetzt funktioniert mein Programm auch.

Na ja.
Was stellst du dir den vor, wann hPort jemals NULL werden soll?

hPort wird nie von alleine NULL! Du hast den Port in Beschlag und 
solange dein Programm läuft und du den seriellen Port nicht schliesst, 
ist er deinem Programm zugeordnet.

Wenn deine Schleife laufen soll, solange ein Sender sendet, musst du mit 
dem sendenden Programm etwas vereinbaren, woraus der Empfänger erkennen 
kann: Das wars, ab jetzt kommen keine Daten mehr.

Wie du das machst: lass deine Phantasie spielen. Das kann sein, dass die 
Gegenstelle ein bestimmtes Zeichen sendet. Das kann sein, dass die 
Übertragung überhaupt nach einem Protokoll abgewickelt wird, das kann 
sein, dass dein Programm in einen Timeout läuft. Irgendwas. Denk dir was 
aus.

Peter schrieb:
> Gibts eventuell Verbesserungsvorschläge???

Naja, da du sämtliche Fehler-Behandlung einfach mal weggelassen hast, 
würde ich da mal ansetzen....

Den Schwachsinn

    while (hPort!=0)
        {

hast du immer noch drinnen

hPort ist ein Handle! Das ist eine Art Kennung, die dir vom 
Betriebssystem gegeben wird und der dir exklusiven Zugang zum Gerät 
'serielle Schnittstelle' gewährt. Mit dem Handle hast du das Gerät in 
Beschlag, solange bis du CloseHandle aufrufst.
hPort KANN in deinem Programm niemals 0 werden!
Damit suggeriert diese Schleife etwas, was einfach nicht stimmt, weil 
der Fall gar nicht eintreten kann!


> ja der gleiche wie oben schon einmal, nicht ständig die Datei
> "Messung.txt" öffenen und schließen.

Das kann sogar sinnvoll sein. Wenn von der seriellen die Daten nur 
tröpfchenweise kommen und man sicher gehen möchte, dass jedes 
einkommende Datum sofort tatsächlich am File landet und nicht erst 
vorher noch in einem Cache rumlungert. Sicher ein flush hätte es 
wahrscheinlich auch getan aber im Falle eines Absturzes möchte ich mich 
nicht unbedint darauf verlassen, das das Filesystem hinter mir 
zusammenräumt.


Das komplette Fehlen jeglicher Fehlerbehandlung wiegt da sehr viel 
schwerer. Und natürlich, dass der Code vor der Veröffentlichung erst mal 
aufgeräumt werden sollte. Was da Includes und Variablen rumlungern, die 
kein Mensch braucht ....

Peter schrieb:
> Karl heinz Buchegger schrieb:
>> Sicher ein flush hätte es
>> wahrscheinlich auch getan aber im Falle eines Absturzes möchte ich mich
>> nicht unbedint darauf verlassen, das das Filesystem hinter mir
>> zusammenräumt.
>
> aber beim öffnen und schliesen müssen mehr Änderrungen am Dateisystem
> gemacht werden als beim flush, damit ist das risiko sogar höher das bei
> einem Abstuzt etwas verloren geht.
> Außerdem sollte man heute davon ausgehen das die Hardware und das
> Betriebsystem richtig arbeiten. Wenn nur die Anwendung abstützt bleibt
> das Dateisystem auf jeden fall ganz. Man müsste ja auch sonst eventuell
> beachten das der Speicher defekt ist und eine Variable den Inhalt ändert
> ohne das man etaws dafür kann.

ICh hab's schon lang nicht mehr ausprobiert. Aber wie ist das mit 
heutigen Windows-en. Früher war es so, das man eine Datei, die ein 
Programm zu schreiben offen hatte, nicht auch noch gleichzeitig lesend 
öffnen konnte. Existiert diese Restriktion noch?

(Von daher unter anderem auch die Angewohnheit eine Datei nur solange 
wie unbedingt notwendig offen halten)

> Früher war es so, das man eine Datei, die ein
> Programm zu schreiben offen hatte, nicht auch noch gleichzeitig lesend
> öffnen konnte. Existiert diese Restriktion noch?

Unter den 32-Bit-Versionen von Windows war das noch nie so, da konnte 
das Verhalten durch die Flags gesteuert werden, die der Funktion 
CreateFile übergeben werden.