Ouvrir le port COM sur Windows CE

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:

---

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; }

---

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.

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:

---

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:

---

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; }

---

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.

Merci

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

Et il FAUT les deux points

Code:

---

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(); }

---

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

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:

---

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:

---

1 2 3

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

---

le strlen ci dessus me donne une erreur

Citation:

---

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

Code:

---

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:

---

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.

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:

---

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; }

---

�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.

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)

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 :ptdr:

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.

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.

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).

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 !

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.

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

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 !

Pas de chance :langue2: Source: Unicode in Microsoft Windows

Citation:

---

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 :wow:, 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)

Citation:

---

Envoy� par olibara

re�oit une chaine pouvant contenir des byte ayant une valeur d�cimale de 32 � 95 ou ' ' � '_' ou 0x20 � 0x5F

---

Dans ce cas, ce n'est ni du 1252 ni du 437, mais bien de l'ASCII pur 7 bits que tu peux recevoir en entr�e. Donc oui, l� tu peux tout simplement caster chaque wchar_t en char, en boucle, puis rejeter (violemment ou non) toute valeur qui ne rentre pas dans le moule.

Merci foetus

Tu a assebien r�sum� et document� la difficult�
Et aussi la raison pour laquelle ma solution de caster en boucle la chaine de WORD produite par WINCE en chaine de char fonctinne bie et offre une cerataine souplesses

Tout en admettant (pour les puriste) la limite de la m�thode si j'avais a traiter du cyrillique, de l'arabe, l'h�breu du chinois ou meme des simples accentu�s