Je travaille sur un système intégré, et je reçois des drames qui l'obtiennent d'envoyer un certain morceau de données sur le port série. Je l'ai réduit et j'ai constaté que si un 0x9b est présent dans le message, il corrompt le message.
Alors je cherche ensuite 0x9b (155) sur http://www.asciditable.com/ , et il manque! N'est-ce pas une coïncidence bizarre!
Des idées, c'est-ce un caractère spécial ou quelque chose?
-edit - ok désolé les gars, ce n'était pas le 0x9b causant ceci, c'était un personnage 0x11. Quel ... Drumroll ... est un personnage XON / XOFFOFF. J'ai tôt eu un contrôle de flux comme XON / XOFF sur l'ordinateur et aucun contrôle de flux sur l'appareil! Merci pour l'aide quand même.
5 Réponses :
Je suppose que ceci est un 0x1b, c'est-à-dire le caractère d'échappement ASCII, avec un bit de parité dans la position 8ème bit (it provenant de la communication série et de tous).
Techniquement, Les caractères de l'ensemble ASCII sont tous plus petits ou égaux à 0x7F , les caractères entre 0x80 sur 0XFF font partie du ascii ascii . La signification des codes ci-dessus varie typiquement, permettant à l'un des multiples caractères d'être traités avec des codes exactement un octet en taille. Cette capacité introduit malheureusement l'ambiguïté pour que l'on a besoin de connaître l'ensemble de caractères supplémentaire en utilisation (la "page de code" si vous voulez). La signification possible du caractère 0x9B pourrait donc dépendre du jeu de caractères [implicite] utilisé avec l'application sous-jacente. Mais comme dit, plus tôt, cela ressemble plus aux caractères sont codés sur 7 bits (par conséquent sont probablement des caractères ASCII "pure") avec un bit de parité.
Par exemple, la table "ASCII" référencée dans la question ne semble avoir aucun caractère associé à 0x9b, tandis que de nombreux autres autres ensemble d'ASCII étendu utilisent ceci pour un caractère "uni" / affichable (ex: A > Personnage à la recherche de ISO-8859-1, le signe de cent (un caractère similaire) avec un autre ensemble, etc.
Hmm, je ne suis pas si sûr: mes paramètres de communication sont 8 n1 - 8 bits, aucune parité, 1 bit d'arrêt
@Chris, il pourrait s'agir d'un bit de parité logique , c'est-à-dire que l'un est géré au niveau du fichier / contenu, et non d'une version ajoutée avec le périphérique de communication série. (Type de "ceinture + bretelles" Configuration si la série Serial comprend également un bit de parité.) Vous pouvez vérifier cela en affirmant que, par exemple, vous n'avez jamais 0x41 ou 0x42 (mais plutôt 0xc1 et 0xc2 respectivement) et que cela conversez-vous toujours. avoir 0x43 (et jamais 0xc3). (Suppositions...)
@Chris: En outre, rappelez-vous que ce n'est pas parce que le côté de la communication série est défini comme 8 bits aucune parité que l'autre côté ne pouvait pas être 7 bits plus la parité ... (sur la deuxième pensée, éventuellement étrange, littéralement car typiquement des comes en série utilise un peu de parité, pas une parité étrange ...)
Cependant, je soupçonne que tu as raison: ce message doit passer par des API de Vendor avant de sortir le port COM, je parierai qu'ils laissent tomber le bit 8 et que ce personnage confondu en quelque sorte ... friguration de la programmation intégrée avec buggy obscure apis!
@Chris, je vois ... je fais juste des suggestions; Des suppositions éduquées de TRES ... Vous devrez peut-être analyser manuellement certains de ces paquets; Qu'est-ce que celles-ci> 0x7f personnage "signifie"? Est-ce que cela est généralement des données textuelles, existe-t-il un peu de mélange binaire? Qu'est-ce que la "corruption des messages" indiquée dans la question signifie effectivement (enfre-t-il le protocole ou fait simplement un paquet qui ne correspond pas au modèle attendu et ne peut pas être analysé, etc.
Ok désolé, c'était une erreur stupide de ma part. J'avais un contrôle de flux sur l'appareil et XON / XOFF sur l'ordinateur, de sorte que l'ordinateur mangeait 0x11. Le 0x9b était un hareng rouge.
Np. Heureux que vous ayez triplé ça!
dans les séquences d'échappement ANSI, 0x9b est le personnage Introducteur de séquence de contrôle < / a> (la version multi-caractères qui est plus familière est ESC - [.
0x9B est l'introducteur CSI ou "Control Séquence introducteur" de l'ensemble de codes de contrôle C1, voir ici: http://www.search.com/reference/c0_and_c1_control_codes
En supposant que les données passent à travers une couche qui traite des codes de contrôle C1 Il n'est pas surprenant qu'il y ait quelques octets manquants après ce caractère car il est utilisé pour indiquer le début d'une séquence d'échappement ANSI. Les octets disparaissent car une couche les frappe dans le cadre d'une instruction. Plus d'infos sur celle-ci ici: http://fr.wikipedia.org/wiki/control_Shance_introducer < / p>
ne peut évidemment pas garantir que c'est votre problème, mais c'est là que je commencerais à creuser dans la documentation de l'API en fonction des symptômes que vous avez décrits.
Si le caractère avant 0x9b est 0x10 (caractère d'échappement de lien DLE - Data Data) qui pourrait expliquer les caractères perdus que vous voyez. Certains appareils utilisent DLE comme indicateur de commande de contrôle et le caractère suivant est la commande. Si les caractères DLE ne sont pas échappés, le signe habituel est une perte de 2 caractères dans le flux ou un comportement étrange de l'appareil. Échappez à des caractères de dle avec DLE. Donc, dans votre cas si votre flux de données comprend:
... 0x10 0x9b ...
Vous devriez écrire
... 0x10 0x10 0x9b ...
Pour quiconque venant à cette question juste à cause du titre: [wiki communautaire parce qu'il ne répond pas réellement à la question, seul le titre.] 0x9b / 155 est absent à partir des tables ASCII car ce n'est pas un caractère ASCII. Les caractères ASCII ne sont que de 7 bits de large, ce qui signifie qu'il n'y en a que 128, il n'ya tout simplement que est aucun caractère 155.
Eh bien, 154 et 156 sont dans la table ASCII que je regardais, juste 155 manquait! Quoi qu'il en soit, j'ai compris le problème, c'était une erreur de configuration XON / XOFFF.
ASCII monte uniquement jusqu'à 127 (0x7f hexagonal).
Eh bien, étendu ASCII si vous voulez.
Quelle est la corruption comme? La connexion se casse-t-elle ou recevez-vous une séquence d'octets qui ne correspond pas à l'entrée? Dans ce cas, à quoi ça ressemble?
C'est comme s'il saute quelques personnages après cet octet.
ASCII était à la fois 7 et 8 bits. La version 8 bits était connue comme étendue ASCII, je crois. Si vous utilisez un produit de développement Microsoft, vous avez juste besoin du codeur correct, Windows-1252, si la mémoire sert.