Projet

Général

Profil

Actions

Feature #2360

ouvert

Protocoles

Ajouté par Anonyme il y a plus de 12 ans. Mis à jour il y a environ 12 ans.

Statut:
In Progress
Priorité:
Normal
Assigné à:
-
Version cible:
Début:
10/12/2012
Echéance:
% réalisé:

90%

Temps estimé:

Description

Mise en place des protocoles internes et externes au drone (Serial, Wifi)

Mis à jour par Jacques LAFFONT il y a plus de 12 ans

référence page wiki ?

Mis à jour par Anonyme il y a plus de 12 ans

  • % réalisé changé de 0 à 20

Mis à jour par Jacques LAFFONT il y a plus de 12 ans

Endianess Géré par l'encodeur et le décodeur, pas important si les messages sont en ASCII.

Pourquoi ne pas travailler entre 2^(N-1)-1 et -2^(N-1). Utilisation maximale de la dynamique. Rapport 32767 on peut rester centré en zéro, et surtout permet d’éviter une division à chaque envoi / réception de message (utile sur cible µC).

Trame: j'ai un faible pour les trames de taille fixe, mais votre format ne me choque pas.

Le zero des trames de debug est un '0' ascii ou un '\0' binaire ?

Dans le cas de valeurs multiples, un champ indiquant le nombre de valeurs dans le message peut être utile.

Il manque un code de détection d'erreur (checksum) par exemple. Les données sont critiques pour le fonctionnement du système.

Le détail des identifiants serait mieux sur une autre page référencées a partir de la page protocole mais aussi d'un point haut du wiki.

Insister sur le fait que la synchronisation des fsm d’émission et de réception se feront sur les caractère CR/LF (ou un autre à définir). Les autres étant mal placés ou non discriminants.

Étoffer l’échange type qui est une très bonne idée.

Mis à jour par Anonyme il y a plus de 12 ans

Endianess Géré par l'encodeur et le décodeur, pas important si les messages sont en ASCII.

l'encodeur et le décodeur sont des composants des cartes réseau ?

Pourquoi ne pas travailler entre 2^(N-1)-1 et -2^(N-1). Utilisation maximale de la dynamique. Rapport 32767 on peut rester centré en zéro, et surtout permet d’éviter une division à chaque envoi / réception de message (utile sur cible µC).

J'ai peur de n'avoir pas tout compris à cette partie (et c'est un euphémisme)

Trame: j'ai un faible pour les trames de taille fixe, mais votre format ne me choque pas.

Comme je l'indiquais dans les notes, on peut tout à fait envisager de compléter par des octets de bourrage

Le zero des trames de debug est un '0' ascii ou un '\0' binaire ?

Il s'agit d'un zéro ascii (dans le cas contraire je le précise systématiquement)

Dans le cas de valeurs multiples, un champ indiquant le nombre de valeurs dans le message peut être utile.

Normalement le nombre de valeurs est défini par le type de trame

Il manque un code de détection d'erreur (checksum) par exemple. Les données sont critiques pour le fonctionnement du système.

Une détection très simple suffira t'elle ou bien faut il envisager des détections plus complexes et redondantes ?

Insister sur le fait que la synchronisation des fsm d’émission et de réception se feront sur les caractère CR/LF (ou un autre à définir). Les autres étant mal placés ou non discriminants.

Qu'est ce qu'un(e) fsm ?

Mis à jour par Jacques LAFFONT il y a plus de 12 ans

On fait le point lundi.

Mis à jour par Anonyme il y a environ 12 ans

  • Version cible mis à Quadriut Fonctionnel

Mis à jour par Anonyme il y a environ 12 ans

  • % réalisé changé de 20 à 90
Actions

Formats disponibles : Atom PDF