[Algo] Faire la part entre des data et des command...

Recherche :

Dernière réponse
Sujet : [Algo] Faire la part entre des data et des command...
Trracer	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....

Dernière réponse

Sujet : [Algo] Faire la part entre des data et des command...

Trracer

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

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

Trracer

gizmo

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

Trracer

Vous en pensez quoi ?

Trracer

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 !

Carbon_14

La méthode lourdingue est de renvoyer ce qu'on a reçu pour vérification (! :lol:) 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..

LeGreg

Trracer a écrit a écrit :

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 ?

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

gizmo

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)

Carbon_14

Je saisis peut-être pas bien :D , 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).

gizmo

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

Trracer

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

Carbon_14

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.

Trracer

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 ! :)

gizmo

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

Trracer

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 ?