Apres plusieurs tentative

Quelles tentatives.
Bernardino t'avais proposé une solution.

Maintenant est-ce que le problème c'est la comparaison de chaines ou est-ce autre chose?
Parce que le bout de code que tu montres donnes à penser que tu ne gères peut être pas bien la réception de ta chaine.
As-tu fait imprimer la chaine reçue pour voir si tu stockes et compares bien la chaine complète?

En plus comme le fait remarquer skywodd il faut se méfier de String qui n'est pas très économe en ressources et peut jouer des tours en bouffant ta mémoire.

je viens de m’apercevoir que le serial lit le code ASCII

Petite erreur d'interprétation.
Le Serial lit ce qu'on lui envoi.
Un terminal (le Serial Monitor est un terminal) envoie le code ASCII des caractères que l'on entre au clavier.
Si tu utilises un programme coté PC pour piloter ton arduino rien ne t'empêche d'envoyer des valeurs directement sous forme d'octets signés. Ou bien en utilisant un codage qui t'arrange.
Il faut adapter le programme dans ton Arduino en fonction de ce qu'il y a en face et aussi de ce que tu veux faire. Ne jamais oublier que lorsqu'on développe un application qui utilise un moyen de communication il est toujours bon de connaitre le fonctionnement des 2 extrémités pour ne pas se tromper.

Rien n'empêche d'utiliser un module bluetooth pour assurer la liaison série.
D'ailleurs il existe une carte qui le fait nativement: http://arduino.cc/en/Main/ArduinoBoardBluetooth
Maintenant sur une carte standard le module bluetooth étant connecté sur RX TX va poser des problèmes lors du téléchargement du code. Il faut soit le retirer pour faire le chargement du code par les voies naturelles (USB), soit adapter le bootloader en partant de ce qui est fait dans la carte citée plus haut.

Ce qui me dérange par contre c'est qu'il n'y a rien dans ton programme pour lire ce que tu envoies sur le port série par le biais du serial monitor....  

Si il y a ce code

Code:

   {Deplacement = Serial.read();}
FaireUnPas(Deplacement);

Le problème je crois c'est qu'il y a un amalgame entre le code ascii du caractère reçu et sa valeur.
Ou alors les valeurs envoyées ne le sont pas à partir du serial monitor.

@tazzzbass
Qu'est-ce que tu envoies et qu'est-ce que tu t'attends à recevoir?
J'ai l'impression que tu confonds caractère et valeur

splitter le signal au sortir du MAX485 ? si oui combien d'arduino peut on mettre en sortie d un même signal ? y a t il des protections à faire, une amplification éventuelle ?

Si tu dois dupliquer le signal du MAX485, autant dupliquer l'entrée plutôt que la sortie. Au moins du bénéficie du fait que le RS485 c'est un bus et qu'il supporte plusieurs charge et en plus il est robuste aux perturbations.

Franchement on commence un peu à se perdre dans ton installation. Tu pourrais pas nous faire un synoptique?

Mais voilà, pour des raison de place, de température, d'isolation, d'humidité et d'accessibilité je voudrais que l'arduino soit placé sous la selle.

Au moins pour les points température, isolation et humidité l'afficheur est aussi sensible voir plus que l'arduino.
Le registre à décalage c'est une solution satisfaisante pour l'esprit, mais d'un point de vue technique c'est pas génial. Le principe même rend le système sensible. La moindre perturbation (et c'est pas ce qui manque sur un véhicule) crée des fronts d'horloge parasites qui entraînent des perturbations d'affichage comme c'est une solution sans intelligence locale (près de l'afficheur) il n'y a aucune chance que les erreurs soient vues et corrigées.
Tout ça pour dire qu'il y a peut être d'autres solutions plus robustes.
  - utiliser une arduino mini logée sous l'afficheur à la place d'une uno.
  - utiliser un afficheur intelligent avec une liaison série (de type UART). C'est moins sensible qu'un registre à décalage.

Pour ce qui concerne la température prévoir un réglage du contraste de l'afficheur par ce que entre l'hiver et l'été la température sur un tableau de bord peut facilement s'étaler de -15°C à +50°C autant dire que l'afficheur va souffrir. La réponse des cristaux liquides est assez dépendante de la température. Certaines familles de cristaux liquides n'aiment d'ailleurs pas du tout les températures négatives.

j'aimerais qui ne tienne compte que du changement d'état ( comme un front montant ou front descendant )

Pour détecter un front, il faut tester l'état de l'entrée à 2 instants différents. Par exemple l'état à l'instant présent et l'état lors du passage précédent dans la boucle. Ensuite on compare si l'état actuel est l'état précéddent sont différents. Si c'est le cas alors il y a eu un front.

Code:

byte monEntree=2;

byte actuel;
byte precedent;

void setup(void){
  Serial.begin(9600);
  pinMode(monEntree, INPUT);
  precedent=digitalRead(monEntree);  // pour initialiser la variable dans un état connu
}

void loop(void){
  actuel=digitalRead(monEntree);    // Lit l'état de l'entrée
  if (actuel!=precedent){           // Si différent il y a eu changement d'état
    Serial.print("il y a eu une transition "); // Cette condition teste toutes les transitions
  }
  
  if ((actuel==0) && (precedent==1)){ // si precedent à 1 et actuel à 0 front descendant
    Serial.println("descendante");         // Cette condition teste les fronts descendants
  }
  if ((actuel==1) && (precedent==0)){ // si precedent à 0 et actuel à 1 front descendant
    Serial.println("montante");         // Cette condition teste les fronts montants
  }
  precedent = actuel;                // mémorise l'état actuel pour la prochaine itération
  delay(500);                          // pour les besoins de la démonstration mettre ici le reste du code
}

Les constantes en float s'écrivent avec le point décimal sinon elles sont prises pour des entiers.

vitesse = (100000.0 / 3000000.0)

cette tram comprend 64 bytes. Et les 4 premier bytes son réservé au start et les 2 suivant pour une action et enfin le suivant qui m'intérésse est réservé au action du moteur.

Bytes ou bits?

Je suis un peu perdu

On voit pas la peine de poster 3 fois ton message les secours n'arriveront pas plus vite.

Support natif des drivers FTDI ... c'est utopique ça par contre sur une tablette non-rooté.

Peut être que ma tablette Archos vient de Mars en tout cas j'ai déjà branché des dongles FTDI et prolific pour utiliser une appli de terminal sans aucun problème et elle n'est pas rootée.

* upload sketches (FTDI-based board and Arduino Uno are supported at this time only, android devices with USB-host support required)

En fait j'ai écrit une bêtise. Il n'est demandé que le support USB-Host natif.

Dans la série j'ai testé pour vous, hier j'ai chargé sur ma tablette l'IDE Arduino sous Android.
L'application est fonctionnelle, l'édition et la compilation se passent bien. Pour le chargement il y a quelques fois des problèmes et j'ai du une ou 2 fois faire un reset manuel pour que le chargement se passe bien.
A l'installation de l'appli un répertoire est créé sur la carte SD pour héberger les librairies et le code.
L'article qui m'a mis sur la piste de cette appli:
http://blog.makezine.com/2013/04/15/developing-for-arduino-on-android/

A noter: il n'est pas nécessaire d'avoir rooté la tablette pour utiliser cette IDE. Par contre elle devra avoir nativement le support FTDI USB-Host pour pouvoir assurer le téléchargement.

Le fabricant c'est SGS-thomson mais la maison n'existe plus depuis 1998. Maintenant c'est STmicroelectronique.
Autant dire que ton composant il commence à dater pas mal.
Es-tu certain de ton interprétation de l'inscription sur le composant?
A mon sens il y a trop de chiffres. N'aurais-tu pas pris une lettre pour un chiffre style 5 pour un S par exemple

On a pas dit que ça ne le faisait pas, mais stein dit qu'il ne veut pas modifier sa carte.
En même temps du 115200 bauds par soft faut pas rêver même avec un quartz à 20MHz cela ne doit pas laisser beaucoup de ressource pour faire autre chose.

(j'ai du mal à comprendre l’intérêt de cette librairie en faite)

Pourquoi l'avoir choisie alors?
As-tu cherché pour voir s'il en existait d'autres?

Pour piloter un afficheur 7 segments il n'y a pas besoin d'avoir des pins PWM.

Code:

if (balance[i] >= 0x48 && balance[i] >= 0x57)

Il y a mal donne
  0x48 = H
  0x57 = W

Je crois que tu voulais mettre
  48 = 0
  57 = 9

Maintenant, une bonne habitude pour éviter ce genre de bévue. Utiliser des constantes du même type que la variable que l'on teste. Tu veux tester un caractères pourquoi ne pas utiliser des constantes caractères.

Code:

if (balance[i] >= '0' && balance[i] <= '9')

en plus le code est plus lisible car on sait tout de suite ce que l'on teste.