Discussion :

[olibara]

Bonjour j'essaye d'ouvrir le port COM5 en C++ sur mon Device Windows CE

Je suis certain qu'il existe et est opérationnel parce que en cSharp cela fonctionne

Le code ci apres me rends toujours une erreur 2
Est ce que je fais une erreur ?

Merci de votre aide

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
hComm = CreateFile( TEXT("COM5"),  
		GENERIC_READ | GENERIC_WRITE, 
		0, 
		0, 
		OPEN_EXISTING,
		NULL,
		NULL);
	if (hComm == INVALID_HANDLE_VALUE)
	{
    dw=GetLastError();
    int uu=5;
	}

[phi1981]

J'ai trouvé ça ici :
http://msdn.microsoft.com/en-us/library/aa517318.aspx

"When lpFileName points to a COM port to open, you must include a colon after the name. For example, specify COM1: to open that port."

Ce qu'on pourrait traduire par : "Lorsque lpFileName pointe sur un port COM à ouvrir, vous devez inclure les deux points après le nom. Par exemple, specifiez COM1: pour ouvrir ce port.

[olibara]

Merci pour ton aide

Mais ca n'aide helas pas

J'ai déja essayé plein de truc mais sans succes
Le premier problème a contourner est que la fonction CreateFile demande un LPCWSTR
Et comme ca fais lontemps que je n'ai plus fais de C en Windows il a fallu trouver comment déclarer ca

Voici donc ma tentative
Mais ca me rends une erreur 2

NB : j'ai aussi essayé sans succes les assignations suivantes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 wchar_t tt[]=L"COM5";
wchar_t tt[]=L"COM5\0";
wchar_t tt[]=L"COM5:";
wchar_t tt[]=L"COM5:\0";}

Mais toutes produisent l'erreur 2
Or je peux ouvrir ce COM5 sur le meme terminal avec cSharp

Je ne peux pas croire que ce ne soit pas possible en C++
Merci de ton aide

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 wchar_t tt[]=L"COM5";
  int len=0;
  int result=0;
  char *buffer;
  DWORD dw;
 
  hComm = CreateFile( tt,  
		GENERIC_READ | GENERIC_WRITE, 
		0, 
		0, 
		OPEN_EXISTING,
		NULL,
		NULL);
	if (hComm == INVALID_HANDLE_VALUE)
	{
                  dw=GetLastError();
                   int uu=5;
	}

[bacelar]

La Macro W2CT
http://msdn.microsoft.com/fr-fr/library/87zae4a3.aspx

C'est juste un const_cast avec quelque bricoles, donc facilement récupérable dans le .h même si c'est pas sous WinCE.

[olibara]

Merci

J'ai fini par trouver : c'est un LPCTSTR

Et il FAUT les deux points

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
  LPCTSTR portname = L"COM5:";
 
  int len=0;
  int result=0;
  char *buffer;
  DWORD dw;
 
  hComm = CreateFile( portname,  
		GENERIC_READ | GENERIC_WRITE, 
		0, 
		NULL, 
		OPEN_EXISTING,
		NULL,
		NULL);
	if (hComm == INVALID_HANDLE_VALUE)
	{
    dw=GetLastError();
 }

[Médinoc]

Si tu utilises des TCHAR, utilise-les jusqu'au bout: remplace LPCTSTR portname = L"COM5:"; par LPCTSTR portname = TEXT("COM5:");

[olibara]

Merci Medinoc

J'avoue que n'ayant plus fait de C depuis longtemps je suis un peu perdu avec ces différents types et ce qui me semble encore plus énervant c'est que les types ne sont pas uniformisés entre les fonctions

le main d'une programme demande un _TCHAR*

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
int _tmain(int argc, _TCHAR* argv[])
{
  LPCTSTR portname = L"COM5:";
  int len=0;
  DWORD result=0;
  char *buffer;
  DWORD dw;

Mais le WriteFile demande la longueur de la chaine passée dans le LPCVOID *

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
    len=strlen(argv[0]);
    WriteFile(hComm, argv[0], len, &result, NULL);

le strlen ci dessus me donne une erreur

error c2440 '=' cannot convert from 'const char *' to 'tchar *'

Quelle methode ou cast puis-je employer pour connaitre la longueur de la chaine d'un TCHAR *
Merci de ton aide

[Médinoc]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
int _tmain(int argc, _TCHAR* argv[])
{
  LPCTSTR portname = TEXT("COM5:");
  size_t len=0;
  DWORD result=0;
  char *buffer; //TCHAR* buffer?
  DWORD dw;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
    len=_tcslen(argv[0]);
    WriteFile(hComm, argv[0], len*sizeof(TCHAR), &result, NULL);

Note que ceci va directement transmettre des TCHAR sur le port de communication, ce qui n'est généralement pas ce que tu veux. C'est peut-être là que tu vas devoir mettre du code conditionnel pour transmettre systématiquement des char (quel encodage?) ou des wchar_t, selon les besoins du protocole.

[olibara]

Merci medinoc

Comme tu l'a vu sur un autre post plus spécifique a cette conversion de TCHAR, je me suis débrouillé en écrivant une petite methode simple de conversion de TCHAR[] en char[]
Elle fait l'affaire dans le contexte

N.B. : entretemps j'ai vu que MultiByteToWideChar() aurait peut etre pu faire l'affaire, mais quand on est pressé on est souvent mieux servi par soi meme car ca semble quand meme etre un peu la jungle ces conversions en C++

Bien sur la methode ci dessous ne traite que l'Unicode WORD mais c'est ce dont j'ai besoin

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
char *ConvertToCharPtr(_TCHAR* tc)
{
  int ltc=_tcslen(tc);
  char *buf=(char *)calloc(ltc+2,1);
  char *p;
  char c;
  p=buf;
  int i=0;
  for (i=0;i<ltc;i++)
  {
    c=(char)tc[i];
    *p=c;
    p++;
 
  }
  return buf;
}

[Médinoc]

Ça ne convertit rien du tout, ça, ça caste tout. C'est comme faire rentrer un morceau de bois cylindrique dans un trou carré avec un marteau.
D'un autre côté, toute conversion de UTF-16 en autre chose qu'UTF-8 fait un peu la même chose...

Et tu n'as toujours pas précisé quel encodage était attendu par ce qui est à l'autre bout du port COM.

[olibara]

Salut
Ce que ca fait c'est effectivement caster chaque WORD unicode (16 bit) en char 8 bit

Ce que j'attends sur le terminal c'est du bete Ascii 8 bit (voir map ci joint)

[bacelar]

L'ASCII 8 bits, ça n'existe pas.
Des tables de codes étendues de l'ASCII sur 8 bits, c'est pas une norme.
La vache, celle-là, de table, je l'avais pas vu depuis un Commodore64, avec ces trèfles. LOL

[Médinoc]

C'est du CP437, ça. Même pour les Consoles, on n'utilise pas ça en France normalement.
Pour ça, tu DOIS utiliser WideCharToMultiByte() avec 437 comme page de codes. Ton truc à base de cast donnera des données incorrectes, et wcstombs() aussi.

[olibara]

Bonjour

Salut Bacelar je trouve ton assertion un peu bornée et l'ASCII 8 bit ca existe bien
Ce n'est pas parce que tu n'a jamais vu de dinosaure que ca n'a pas existé

http://www.ascii-code.com/

Merci Medinoc tu vraissemblablement raison mais pour le besoin actuel ma boucle a base de cast suffit largement et offre l'avantage de pouvoir le cas échéant facilement filtrer certains caractéres (blancs)

Le fait est que pour des raisons technique sur un PDA Win CE je reçois une chaine de caractére emise par un Serveur SAP et que je dois envoyer cette chaine a un autre terminal mobile (Opticon vendu en France) avec un processeur Toshiba
Pour cela je dois passer par un petit exe dont le seul role est de recevoir une chaine entrante et la transmettre sur le port com

La chaine envoyée par SAP est une chaine de caracteres 8 bit purement alphanumerique majuscule sans accent
Le souci c'est que quand je passe la chaine originale en parametre a un EXE Windows CE la chaine est castée automatiquement en Unicode, je ne fais donc que l'oprération inverse de ce que Win CE a fait derriere mon dos.

[Médinoc]

Non, l'ASCII 8 bits n'existe pas.

L'ASCII fait toujours 7 bits, les ASCII Étendus font 8 bits. En en plus, l'auteur du website se contredit: La table étendue qu'il affiche correspond en fait à l'encodage Windows-1252 (qui correspond à ISO 8859-1 avec les codes de contrôles C1 remplacés par des glyphes).

Attention, cette table est différente de l'autre table postée (CP1252 contre CP437).

[olibara]

Merci Medidoc

Bon soit : disons ASCII etendu pour les puriste

Il n'empeche que 8 bit ca reste 8 bit

Disons donc un Byte
On peut meme appeller cela un TinyInt en SQL

Et si Windows s'amuse a intercaller un deuxieme null byte dans ma chaine de Byte pour en faire un WORD
Ma boucle ne sert qu'a retirer ce Byte clandestin pour reconstituer ma chaine originale !

[Médinoc]

Attention, UTF-16 ne correspond pas à "Windows-1252 plus un octet nul": Tout ce qui est dans la zone C1 (Symbole Euro, E dans l'O, etc.) possède une valeur supérieure à 255 une fois en unicode.

[Médinoc]

PS: Donc finalement, tu veux du 437 ou du 1252? Tu nous as dit une chose et l'autre...

[olibara]

Salut Medinoc

Oui je sais que UTF8 c'est pas de l'Unicode en WORD
Oui Le code page original est vraissemblablement 437 comme tu l'a identifié

Mais cela a peu d'importance

Car
1- Mon EXE compilé en VC ++ sur WinCE reçoit une chaine pouvant contenir des byte ayant une valeur décimale de 32 à 95 ou ' ' à '_' ou 0x20 à 0x5F
2- Cet cette chaine de byte passé a l'EXE à été vraissemblablement convertie par l'OS en chaine de Word (en tout cas j'espère qu'il ne fait pas aussi de l'UTF8 sur les accentués bien que dans mon cas ca n'aurait pas d'impact )
3- Donc je n'ai qu'a retirer le null byte qui est venu s'ajouter intempersivement pour reconstituer la chaine de byte originale

Vois-tu une erreur dans ce raisonnement !

[foetus]

Pas de chance Source: Unicode in Microsoft Windows

In Windows CE UTF-16 was used almost exclusively, with the "A" api mostly missing.

En gros, Microsoft a retiré toutes les fonctions et bibliothèques finissant avec un "A" (pour ANSI)
Donc il faudra gérer dans ton projet que de l'UTF-16, avec des conversions vers la sortie.
Et tu peux rien n'y faire.

Si je ne dis pas de bêtises , c'est pour cela que tu as des caractères '\0' entre les caractères ASCII.
Parce que c'est de l'UTF-16 et non pas de l'UTF-8 ou de l'ASCII (il n'y aura pas ces caractères) ni de l'UTF-32 (je ne sais pas trop mais tu aurais 4 octets)