- LiFePO4 Speicher Test         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 17

Thema: Kommunikationsparameter

  1. #1
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    22.09.2009
    Beiträge
    164

    Kommunikationsparameter

    Anzeige

    Praxistest und DIY Projekte
    Hallo zusammen,

    passen die Kommunikationsparameter aus meinem C++ -Programm

    Code:
        dcbSerialParams.BaudRate= CBR_128000; //CBR_57600;
        dcbSerialParams.ByteSize=8;
        dcbSerialParams.StopBits=ONESTOPBIT;
        dcbSerialParams.Parity=NOPARITY;
    zu denen des Bascom-Programms?
    Code:
    Config Com1 = 128000 , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0
    Bisher kommen die Daten um ca. 10 Sekunden verzögert vom Controller zum PC an.

    Als Anhang auch die Einstellungen des Terminal von Bascom.

    Vielen Dank und Grüße

    datatom
    Angehängte Dateien Angehängte Dateien

  2. #2
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.842
    Auf jeden Fall solltest du
    "Handshake none"
    einstellen.
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  3. #3
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    22.09.2009
    Beiträge
    164
    Meinst du die Einstellung bei den Terminal settings oder im C++ -Programm?

    Bei den Terminal settings habe ich umgestellt, wie es im C++ -Programm geht weiß ich leider nicht genau?

  4. #4
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.842
    Das wären die Terminal Settings. Vielleicht macht es aber eh nix aus, weil sich Xon/Xoff ja nicht in der Hardware abspielt.
    Ob COM4 richtig ist, kann ich natürlich nicht sagen.
    Ansonsten sollten die Konfigurationen eigentlich passen, denn wenn nicht, käme nur effektiver Müll raus.

    128000 ist aber schon flott, probier doch erst einmal (auf beiden) 19200 oder sowas
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  5. #5
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.842
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  6. #6
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.652
    Hi datatom,

    es kommt auch darauf an, welchen Quarz Du hast (und welchen Controller - beide Angaben wären hier sinnvoll). 1) Der interne Oszillator wird für 128kBd sicher nicht mehr taugen. 2) Unterschiedliche Quarze haben unterschiedliche Baudratenfehler, da der Teiler für den Bittakt eine ganze Zahl ist und irgendwie zum Quarztakt und der gewünschten Baudrate passt oder eben auch nicht. Siehe diese Beispiel für 20MHz oder diesen Beitrag.

    ......Bild hier  

    Aber aus den hier skizzierten Abweichungen kann ich keine Pause von 10 sec ableiten.
    Ciao sagt der JoeamBerg

  7. #7
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    61
    Beiträge
    5.799
    Blog-Einträge
    8
    16000000 / 128000 = 125

    Das passt doch optimal, oder übersehe ich da etwas?

    Aha: https://www.roboternetz.de/community...C3%BCck-zum-PC
    Bild hier  
    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

  8. #8
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.652
    Zitat Zitat von radbruch
    16000000 / 128000 = 125 ... übersehe ich da etwas? ...
    Diesen anderen Thread kannte ich nicht, der ist hier auch nicht genannt :( :( :(
    Ciao sagt der JoeamBerg

  9. #9
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.842
    Das Problem ist hier, dass die Daten zwar korrekt ankommen (ist das so ?), aber eben mit 10 Sek Delay.
    D.h. das mit der Baudrate und den anderen Config-Sachen ist NICHT das Problem.
    Dann kann es nur ein Problem in der Software sein. Ich vermute PC-Seitig, will aber keinem Unrecht tun.
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  10. #10
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    22.09.2009
    Beiträge
    164
    Zitat Zitat von PicNick Beitrag anzeigen
    Das Problem ist hier, dass die Daten zwar korrekt ankommen (ist das so ?), aber eben mit 10 Sek Delay.
    D.h. das mit der Baudrate und den anderen Config-Sachen ist NICHT das Problem.
    Dann kann es nur ein Problem in der Software sein. Ich vermute PC-Seitig, will aber keinem Unrecht tun.
    Richtig die Daten kommen korrekt. Die Verzögerung ist das Problem.

    Ich habe jetzt die Parameter im C++ -Programm folgendermaßen belegt:
    Code:
        dcbSerialParams.BaudRate= CBR_128000; //CBR_57600;
        dcbSerialParams.ByteSize=8;
        dcbSerialParams.StopBits=ONESTOPBIT;
        dcbSerialParams.Parity=NOPARITY;
        dcbSerialParams.fOutxCtsFlow=0;
        dcbSerialParams.fOutxDsrFlow=0;
    Die Kommunikation mit dem Bascom-Programm und der Konsole klappt ohne Probleme und ohne Verzögerung. Deswegen sehe ich das Problem, ebenfalls wie PicNick, PC-seitig. Ich kann mir das aber nicht erklären. Hier mal mein ReadFile und WriteFile:

    Code:
    char *write_pointer = write_char;
            DWORD len = write_pointer ? (DWORD)strlen(write_pointer) : 0;
            DWORD dwBytesWritten;
            while(len)
            {
                if(!WriteFile(hSerial, write_pointer, len, &dwBytesWritten, NULL)) 
                {
                    //error occurred. Report to user
                    return TB_ERROR; //-1;
                }
                len -= dwBytesWritten;
                write_pointer += dwBytesWritten;
            }
            write_pointer = "\r";
            len = (DWORD)strlen(write_pointer);
            while(len)
            {
                if(!WriteFile(hSerial, write_pointer, len, &dwBytesWritten, NULL)) 
                {
                    //error occurred. Report to user
                    return TB_ERROR; //-1;
                }
                len -= dwBytesWritten;
                write_pointer += dwBytesWritten;
            }
        }
    
        Sleep(200);
        
        DWORD dwBytesRead;
        char read_buffer[256];
        int read_index = 0;
        while(read_index < sizeof(read_buffer)) 
        {
            if(!ReadFile(hSerial, &read_buffer[read_index], 1, &dwBytesRead, NULL)) 
            {
                //error occurred. Report to user
                return TB_ERROR; //-1;
            }
            if(dwBytesRead != 1) 
            {
                //error occurred. Report to user
                return TB_ERROR; //-1;
            }
            if(read_buffer[read_index] == '\n') 
            {
                // ignore
                continue;
            }
            if(read_buffer[read_index] == '\r') 
            {
                // end of message
                break;
            }
            read_index++;
        }
        if(read_index == sizeof(read_buffer)) 
        {
            //error occurred (buffer overflow). Report to user
            return TB_ERROR; //-1;
        }
        read_buffer[read_index] = '\0';
    
        if(read_index > 0)
        {
            wchar_t print_buffer[sizeof(read_buffer)];
            mbtowc(print_buffer, read_buffer, MB_CUR_MAX);
        }
        else
        {
            //error occurred. Report to user
            return TB_ERROR; //-1;
        }
        //MessageBox(hwnd, print_buffer, L"ReadFile", MB_OK | MB_ICONINFORMATION);
    
        int string_read_laenge = 3;
        if(read_index < 3)
        {
            // Sollte read_index < 3 sein, gibt es einen Fehler, weil der substr nicht klappt. Bei dem substr wird erst ab Feld 3 gearbeitet
            return TB_ERROR; //-1;
        }
        string_parameter_read = read_buffer;
    Ich sende Daten vom Joystick zum Controller und der sendet sie wieder zurück zum PC. Die Daten die ich sende sind immer die aktuellen Daten der Joystickachsen. Dann empfange ich z.B. 10 mal den gleichen Wert der Achsen, obwohl ich mehrfach schon aktuellere Daten zum Controller gesendet habe. Erst nach ca. 10 Sekunden erhalte ich mit ReadFile die Daten die ich 10 Sekunden vorher zum Controller gesendet habe. Zwischen WriteFile und ReadFile empfängt der Controller nur einmal Daten und sendet auch nur einmal Daten zurück. Das habe ich mit LED-blinken getestet.

    Ich verzweifle

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

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

Solar Speicher und Akkus Tests