Schnittstelle zu langsam?!

Hallo MCoder!

Ich sitze gerade dran und probiere deine Funktion zum laufen zu bekommen. Ist mir über das WE leider nicht gelungen. Zwar geht es jetzt drum die entsprechenden Daten als Binärdaten vom Comport zu holen. Dabei habe ich festgestellt, das dieses nicht wirklich zum erfolg führt!

Das auswerte Proramm findet in der Datei keinerlei Infomrationen.

Was mache ich da falsch! Ich denke mal das ich anstatt der

Code:
 pBuffer[iIN++] = byte;

mit memcpy arbeiten muss oder

Schon mal besten dank für infos
 
Das weitere Problem, was ich habe ist, das ich vorher nicht weis wieviele Zeichen vom Comport kommen. Das kann unterschiedlich sein!

Bitte um Hilfe
 
Das auswerte Proramm findet in der Datei keinerlei Infomrationen.
Das bedeutet, dass keine Daten in "pBuffer" geschrieben werden? Memcpy brauchst du nicht, da ja immer nur ein einzelnes Byte gelesen wird, das du direkt zuweisen kannst. Prüfe doch mal (Debugger) ob die Zuweisung "pBuffer[iIN++] = byte;" überhaupt aufgerufen wird.

Das weitere Problem, was ich habe ist, das ich vorher nicht weis wieviele Zeichen vom Comport kommen. Das kann unterschiedlich sein!
Solange der übergebene Puffer genügend Reserven hat, sollte das kein Problem sein. Du liest eben solange die Bytes ein, bis das Ende eines Datensatzes erreicht wurde, übergibst die Daten zur Weiterverabeitung und startest den nächsten Lesezyklus.

Gruß
MCoder
 
Das bedeutet, dass keine Daten in "pBuffer" geschrieben werden? Memcpy brauchst du nicht, da ja immer nur ein einzelnes Byte gelesen wird, das du direkt zuweisen kannst. Prüfe doch mal (Debugger) ob die Zuweisung "pBuffer[iIN++] = byte;" überhaupt aufgerufen wird.

Das habe ich bereits getan! Es wird ja sogar die Ausgabedatei angelegt, in der die Daten drin stehen.

Aber noch was anders! Mit der Zuweisung über den gleichoperator, kann es ja auch vorkommen, das aus dem Comport das Zeichen für die schließende Null kommt. Das würde ja dann bedeuten, das das Array geschlossen ist! Deswegen muss ich doch dann memcpy benutzen.

Solange der übergebene Puffer genügend Reserven hat, sollte das kein Problem sein. Du liest

ok dies ist mir doch jetzt klar geworden.

Vielleicht ist hier was falsch!
Also so schrebe ich die Daten in meine Datei
Code:
FILE *fp_binaer;
                fp_binaer = fopen("ausgabe.log", "a+b");                 if(fp_binaer != NULL)
                {
                    fwrite(pBuffer,myCharAnz,sizeof(CHAR),fp_binaer);
                    fclose(fp_binaer);
                }
                else
                {
                    fclose(fp_binaer);
                }
            }

Dabei entsprciht dann myCharAnz der durchläufe in der while schleife bis die break Bedingung erreicht wird!

Ist doch korrekt oder
 
Aber noch was anders! Mit der Zuweisung über den gleichoperator, kann es ja auch vorkommen, das aus dem Comport das Zeichen für die schließende Null kommt. Das würde ja dann bedeuten, das das Array geschlossen ist! Deswegen muss ich doch dann memcpy benutzen.
Die Null wird ja bereits durch die Abbruchbedingung vor der Zuweisung abgefangen und damit das Lesen eines Datensatzes beendet, d.h. im Puffer steht (außer am Ende) keine Null.

Beim Schreiben der Datei musst du bei "fwrite" die beiden mittleren Parameter tauschen:
Code:
fwrite(pBuffer, sizeof(CHAR), myCharAnz, fp_binaer);
Gruß
MCoder
 
Vielen dank MCoder!

Der Fehler ist mir auch aufgefallen! Ich habe es jetzt ein bisschen Modifiert. Aber ich habe es das Gerät zum Testen wieder. Und siehe da es sind immer noch die Datenlücken da! Zwar weniger aber immer noch vorhanden. Jetzt werde ich probieren nicht die ReadFile sondern die ReadChar Methode zu benutzen! Vielleicht ist diese ja schneller!

Also im moment sieht es so aus bei mir:

Code:
int CComPort::ReadPort(char *pBuffer, int nSize)
{ 
char  byte;
    char *pB;
    DWORD dwBytesRead;
    int   iIN = 0; // Variable die festlegt wieviel Zeichen eingesen wurden
    
    pB = pBuffer; //

    while( ReadFile(m_hPort, &byte, 1, &dwBytesRead, NULL) && dwBytesRead == 1 )
    

    
    {
        if( byte == (-52) ||     // Endezeichen            
           // byte == 0     ||     // leeres Zeichen            
            //iIN  == (nSize - 1)  // Ende des Buffers          
            iIN  == (nSize)
            )        
        {             
            break;
        }         
        
                       
        
        *pB = byte;
        pB++;
        iIN++;

    
    }     

    
    
    return iIN;

}

ich hoffe das ich das irgenwie zuum laufenbekomme, damit ich die daten vollsänig vom comport holen werde.

Bitte um Hilfe
 
Hallo MCoder! Leider ist es mir nicht gelunge eine readChar methode zu implemetieren, anscheind bin ich zu blöd dafßür!

Aber dann noch eine andere Sache. Das rumspielen an den Parameter mit den COMMTIMEOUTS bringt bei mir auch keinen erfolg.

Naja ich weis da jetzut wirkloich nicht weiter! Hast du vielleicht noch ien tipp parat
 
Hallo Winner,

was du mit der ReadChar-Methode gemeint hast ist mir nicht klar, so gibt s bei der WinAPI nicht.

Die Datenverluste kommen mir schon sehr seltsam vor, zumal die Daten des seriellen Ports ja von Windows auch gepuffert werden. Bist du sicher, dass die Abbruchbedingungen usw. stimmen? Ich vermute, dass die Daten dann verloren gehen, wenn du gerade nicht innerhalb von ReadPort bist. Evt. solltest du ReadFile innerhalb des Threads ständig laufen lassen. Mit folgenden Code solltest du feststellen können, ob die verlorenen Daten tatsächlich vom Port verursacht werden. Damit müsstest du nämlich jetzt alles kriegen.
C++:
char pbBuffer[1024];
int  nPos = 0;

while( bRunning ) // bRunning steht für die Abbruchbedingung deines Threads
{
    DWORD dwBytesRead;
    BYTE  byteRead;
    
    if( ReadFile(m_hPort, &byteRead, 1, &dwBytesRead, NULL) && dwBytesRead == 1 )
    {
        pbBuffer[nPos++] = byte;   // Wegschreiben, egal was da kommt
    }
    
    if( nPos == sizeof(pbBuffer) ) // Buffer ist voll --> in Datei sichern
    {
        FILE *fp = fopen("ausgabe.log", "a+b");
        
        if( fp != NULL )
        {
            fwrite(pbBuffer, sizeof(CHAR), sizeof(pbBuffer), fp);
            fclose(fp);
        }   
        
        nPos = 0; 
    }
}
Gruß
MCoder
 
Vielen dank! Ich werde es gleich mal ausprobieren. Die Methode readChar habe ich hier in einem buch gelesen, wo stand das es damit die Daten einzelen vom comport holt.

Aber schon mal vielen lieben dank für deine Mühe! Ich werde es gleich mal ausprobieren und rückmeldund geben!

Gruß Winner
 
Hallo MCoder!

Ich habe das jetzt getestet. Auf den ersten Blick scheint es sehr gut zu laufen.

Ich habe nur hier eine Lücke immer zu Beginn der Aufzeichnung, womit aber letztenendlich gelebt werden kann, da die Geräte schon lang vor dem eigentlichen messbeginn aktiv sind!

Aber um dir mal solch eine lücke zu zeigen habe ich mal die daten die ich erhalten habe hier reingeschrieben.
Code:
56878350	-0.305222	-0.040654	49.175.069	3.846.092.924.723	659.521.739.560	5.028.361.171.242	1	10
56878410	-0.135244	0.077062	49.177.866	3.846.092.920.664	659.521.741.133	5.028.361.172.099	1	60
56878420	-0.128428	0.077920	49.178.928	3.846.092.920.585	659.521.741.201	5.028.361.172.273	1	10

Die erste Splate stellt die Zeitmarke da! Sie zählt immer hoch. Die Ausgabe erfolgt 100 mal diue Sekune. Und wie du hier selbst sehen kannst, sind die Daten nicht vollständig. Nach 56898350 müsste 86898360 folgen. Hier ist es aber 56878410, was dann die entsprechende lücke ist. Es ist zwar noch nicht malk eine sekunde aber es sind für mich 6 fehelende Datensätze! Sowas hatte ich aber durchaus auch mitten in den messungen was durch dich aber behoben wurde!

Schon mal vielen dank!

Weist du da sonst noch wieter?
 
Zurück