Bonjour,
 
Voila, juste une petite question (des fois que quelqu'un aurait une idee...)
J'envoie des donnees utiles et des donnees de commande a un periph. Tous les octets sont recevable comme etant des donnees valides.  
Ma question est donc la suivante : comment peut on differencier les data utiles des data de commande ? (envoyer un octet specifique n'est pas suffisant dans ce cas...)
 
Une idee ?

ben c'est le principe d'un scanner, première partie d'un compilateur. cela fonctionne en parallèle avec un parser.
 
Explication: le scanner n'est qu'une sorte de dictionnaire dont les mots sont soit une série d'octet, soit une expression régulière définissant une série de combinaisons d'octets. Le parser, lui, s'occupe de vérifier l'exactitude de la syntaxe.
 
Si tu as besoin de plus de détails...

Bha si je me refere au binaire pure (suite d'octets), c'est ça. Quand il rencontre un octet il sait combien d'octet suivant sont a prendre en compte en tant que data, genre "nop" sur un octet, "jmp" sur 3 ou 4 octets (pffiuuu mon assembleur est pire rouille...).  
Mon probleme est que tout octet peut etre une data, je ne peut donc pas me limiter a mettre 'FE' suivis des octets de commande pas exemple, pareil pour une combinaison (ou alors il faudrait envoyer une longue suite de byte pour etre sur, et c'est pas le top).
Le truc que j'envisage en ce moment serait un octet significatif suivis de 2 ou 4 octets (suivant la longueur de la commande) avec un masque bien specifique...
 
Mais si tu as autre chose a me proposer, je suis preneur !

Genre commandes d'imprimante (à aiguilles (EPSON MX, RX, LX, ..)) où il y avait l'irremplaçable ESCAPE puis le code commande et la longueur de ce qui suit en octets.

Ouais, sauf que pour les imprimantes ils ont designes un caractere special (ESC : 27) comme etant un caractere de commande (caracteres non imprimable).
Dans mon cas l'octet represente des pixels (8) donc *toutes* les valeurs que peut prendre cet octet est potentielement une data, il n'y a pas de caracteres non imprimable ou autre, puisque cela ne se limite pas a la table ascii. Donc je recherche un moyen avec un minimum d'octet pour definir, avec une bonne probabilite, si les derniers octet reçus sont des octets de commande ou des donnees. Ca parait simple, mais en fait, c'est pas si simple que ça...  
 
En attendant merci pour vos reponses

Trracer a écrit a écrit : Bha si je me refere au binaire pure (suite d'octets), c'est ça. Quand il rencontre un octet il sait combien d'octet suivant sont a prendre en compte en tant que data, genre "nop" sur un octet, "jmp" sur 3 ou 4 octets (pffiuuu mon assembleur est pire rouille...).   Mon probleme est que tout octet peut etre une data, je ne peut donc pas me limiter a mettre 'FE' suivis des octets de commande pas exemple, pareil pour une combinaison (ou alors il faudrait envoyer une longue suite de byte pour etre sur, et c'est pas le top). Le truc que j'envisage en ce moment serait un octet significatif suivis de 2 ou 4 octets (suivant la longueur de la commande) avec un masque bien specifique...   Mais si tu as autre chose a me proposer, je suis preneur !

 
ben non, c'est soit avec un dico, et la tous les octets peuvent être utilisés aussi bien pour les donnée que pour les fonctions, mais ca nécessite un analyseur avec un buffer de la taille du nom de la plus longue fonction possible. Soit c'est avec un caractère réservé.

Je saisis peut-être pas bien , mais si y a  
CarComm NbOctet données_de_commande
ou  
CarDonn NbOctet données_de_data,
selon que le premier reçu est CarDonn ou CarComm, on lit NbOctet, puis les NbOctet(s) qui suivent qui seront respectivement des Données ou des Commandes.
Les caractères CarComm et CarDonn sont valides et peuvent se trouver dans les flots de données, mais le fait que ce sont les premiers à lire pour "aiguiller" le reste lève le "doute".
 
Y a des fichiers binaires de spectros qui sont (un peu) comme cela quand on va y mettre son nez (fouineur).

ok, mais dans ce cas, tu dois être sur de tous tes périph a 100% parce que si un bit change dans le NbOctet tout ton système tombe a l'eau. idem si un bit change dans NbOctet ou que tu perds 1 octet. Avec l'autre méthode, tu vas t'apercevoir beaucoup plus rapidement et efficacement de l'erreur (avec correction éventuelle)

oui : revoir ton protocole parce que comme tu nous l'as decrit  
tu vas dans le mur.
 
Caractere escape c'est une bonne solution
et simple si les commandes ne sont pas trop frequentes.
Tu peux aussi rajouter un bit significatif
ou definir une commande d'envoi de donnees:
(tu fonctionnes a l'envers, tu prevois une
commande qui signifie que tu envoies n octets de  
donnees).
Les solutions sont innombrables..
 
A+
LEGREG

La méthode lourdingue est de renvoyer ce qu'on a reçu pour vérification (! ) par l'émetteur...
 
S'il faut un protocole sécurisé, autochecké, je suppose que ça peut passe se faire avec un seul octet (checksum, CRC, ?), mais si erreur prévoir de réclamer à l'émetteur un nouvel envoi, sinon, ça avance pas.
 
Ca revient pas au problème de savoir combien envoyer d'octets en plus pour reconstituer des données altérées ?
 
Ca me reppelle les transmissions Teletex radio-amateurs (Baudot). Commande Majusc/Codes. Si on rate Majus ou Codes (mauvaise transmission), ça devient illisible..

La solution du "caractere ESC" n'est pas suffisante, pour le moment je m'oriente vers un mixe de deux solutions : un octet significatif et les donnees de commande encapsulees dans les deux octets suivant. Par exemple :
11110111b en octet de start
10110010b avec un masque on ne garde que les 4 octets significatifs (ici 0)
01001101b pareil avec un masque complementaire au precedent.
 
Statistiquement il y a peu de chance de trouver cette combinaison dans le flot des donnees, meme si la proba d'avoir l'octet de start dans le donnees est elle relativement elevee...
 
En attendant merci à tous !

Vous en pensez quoi ?

ca dépend, c'est quoi tes impératifs? la rapidité, l'intégrité, le compactage?

La rapidite en premier. Les donnees seront reçu par un pic donc la capacite de traitement est limite donc travailler sur 3 ou quatre octets reste raisonnable (il faut 1250ns pour transferer un byte sur la ligne serie à 9600bps, donc la re-emission effectuee par le pic ne doit pas exceder ce temps...).
C'est la meilleur solution que j'ai trouve jusqu'a present, donc je vais essayer, si ça marche pas je continurais a me creuser les meninges....