COM-Port per C-Konsolenprogramm mit Parameter ansprechen

Paddre

Moinmoin.

Ich bin gerade dabei über die serielle Schnittstelle Daten vom PC an einen Microcontroller zu senden.

Dafür habe ich mir ein Programm in C geschrieben, welches dieses ermöglicht. Dieses Programm soll hinterher per Konsole aufgerufen werden, mit den Parametern

argv[1] : COM-Port (z.B.: COM1)
argv[2] : Dateipfad (z.B.: D:\bytes.txt)

Ein Beispielaufruf soll dann so aussehen:

Terminal COM1 D:\Bytes.txt

Als Vorgehensweise habe ich mich im Groben an der MSWindows-Version orientiert (http://msdn.microsoft.com/en-us/library/ms810467.aspx)

Das Problem ist, dass ich Probleme mit den komischen Windows-Datentypen (TCHAR*) bekomme.

Ich bekomme es nicht hin diese Zeile:

TCHAR *pcCommPort = TEXT("COM1");

so zu ersetzen, dass ich als Port den, mit dem Aufruf, übergebenen nehme.

Die betreffenden wichtigsten Zeilen im Code sind folgende:

TCHAR *pcCommPort = TEXT("COM1");
HANDLE hCom = CreateFile( pcCommPort,
                    GENERIC_READ | GENERIC_WRITE,
                    0,    // must be opened with exclusive-access
                    0, // default security attributes
                    OPEN_EXISTING, // must use OPEN_EXISTING
                    0,    // not overlapped I/O
                    0  // hTemplate must be NULL for comm devices
                    );

Hoffe ihr hattet schonmal ähnliche Probleme

Gruß
Patrick

P.S.: Bitte fangt nicht an mir von der Windows-Variante abzuraten und mir irgendwelche abenteuerlichen vielleicht auch besseren Möglichkeiten anzuschnacken
Das jetzt noch umzumodeln dauert Zeit, und die habe momentan nicht übrig.

In der Datei WinNT steht irgendwo folgende Zeilen:

typedef char CHAR;
typedef wchar_t WCHAR;
typedef WCHAR TCHAR;

Ich denke einmal, mit CHAR (nicht TCHAR) kannst du etwas anfangen und es ist klar, dass *CHAR string identisch mit *char string ist. Wieso aber will die Windows-Funktion einen String vom Typen TCHAR *? Nun, der Grund ist der, dass deine CreateFile-Funktion mit UNICODE-Strings arbeitet. Da der Umfang von UNICODE bedeutend grösser ist als der ASCII-Code, reichen die 256
Bite die ein Char zur Verfügung stellt nicht mehr und man nimmt deshalb einen grösseren Datentypen wie wchar_t um das Problem zu lösen.
Wenn du jetzt keine Lust hast dich mit UNICODE zu beschäftigen kannst du aber auch einfach CreateFileA verwenden - das ASCII-Pendant.

RealC++ schrieb:

In der Datei WinNT steht irgendwo folgende Zeilen:
typedef char CHAR;
typedef wchar_t WCHAR;
typedef WCHAR TCHAR;
Ich denke einmal, mit CHAR (nicht TCHAR) kannst du etwas anfangen und es ist klar, dass *CHAR string identisch mit *char string ist. Wieso aber will die Windows-Funktion einen String vom Typen TCHAR *? Nun, der Grund ist der, dass deine CreateFile-Funktion mit UNICODE-Strings arbeitet. Da der Umfang von UNICODE bedeutend grösser ist als der ASCII-Code, reichen die 256
Bite die ein Char zur Verfügung stellt nicht mehr und man nimmt deshalb einen grösseren Datentypen wie wchar_t um das Problem zu lösen.
Wenn du jetzt keine Lust hast dich mit UNICODE zu beschäftigen kannst du aber auch einfach CreateFileA verwenden - das ASCII-Pendant.

Ein Char sind natürlich 8Bit und nicht 256Bit.-Sorry Aber mit 8Bit sind 256 unterschiedliche Kombinationen (in diesem Fall Zeichen) möglich.

Paddre

Klingt logisch!

Läuft nun!!

Vielen Dank!!!

Gruß
Patrick