Re: [Pdmtl] Communication sérielle

[Thomas Ouellet Fredericks]

Voci un genre de code plus intuitif selon moi pour l'utilisateur:
tu gardes plus de la moitié des valeurs possibles (156 sur 256) pour
des codes de contrôle (genre break, feed, setasinput, setasoutput,
getadc, etc...) et en soustrayant aux autres (156 à 256) 100, tu peux
avoir une résolution de dizaines. Tu peux donc faire qqch du genre
pd à arduino: 32 -> GetAdc
arduino à pd: 158 -> 158 -156 = 2
arduino à pd: 255 -> 255 - 156 = 99
arduino à pd: 0 -> Done
lorsque pd reçoit le Done il calcule la valeur, soit 9902 (2*1+99*100)

Les codes contrôle ne rentreront jamais en conflit avec les valeurs et
les valeurs peuvent être lues à l'oeil.

Une idée de même.
Encore plus intuitif, c'est de garder les chiffres 0 à 99 pour les
valeurs numériques et les autres (100-255) pour des codes de contrôle.

Tom

On 4/4/06, Mathieu Bouchard <matju at artengine.ca> wrote:
> On Tue, 4 Apr 2006, Alexandre Quessy wrote:
>
> > Donc, un bon protocole pour transmettre des nombres plus grands que
> > 256 serait de le transmettre en ASCII. Super. Merci.
>
> Aussi, le BER permet cela. Le BER est un encodage auto-délimitant pour des
> nombres de taille variable. C'est facile: tu écris ton nombre en base 128
> et tu rajoutes 128 à chaque chiffre qui n'est pas le dernier (ou
> alternativement tu rajoutes 128 juste au dernier).
>
> exemple:
>  1000000 = 7812 reste 64
>     7812 =   61 reste  4
>       61 =    0 reste 61
>
> alors tu écris 61+128=189 suivi de 4+128=132 suivi de 64.
>
> L'avantage de cette méthode c'est que ça prend 2 fois moins bytes que
> ASCII.
>
>  _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
> | Freelance Digital Arts Engineer, Montréal QC Canada
>