Voilà, je m'interroge (encore !!) dans mon projet en cours, j'utilise softwareSerial pour connecter un GPS à ma carte Uno. J'avais configuré le GPS en 4800bps en me disant que vu que l'arduino fait quand même pas mal d'autres trucs, j'aurais plus de temps pour aller lire ce qui arrive dessus.
Sauf que concrètement, je rate plein de caractères, et ça passe beaucoup mieux en 9600 ?? Pourquoi ? Ça me semble totalement contre-intuitif...
D'autre part, comme je ne lis qu'un caractère par passage dans loop() pour des raisons de réactivité du reste du soft, pour résoudre mon problème, il faudrait pouvoir augmenter la tailler du buffer de réception de softwareSerial, je ne sais pas si c'est possible ? Je viens de regarder rapidement le code de la librairie, je n'ai rien vu qui aille dans ce sens.
Software Serial est connu pour avoir des soucis de timing sous 9600 bauds...
éventuellement essayez avec altSoftSerial
sinon la taille du buffer peut être changée ici, mais c'est juste reculer pour mieux sauter... A mon avis vous devriez lire TOUS les caractères du SoftwareSerial qui sont dans le Rx buffer à chaque tour, comme ils sont en mémoire c'est quasi instantané et ça vous redonnera de la place dans le buffer de Software Serial.
La fonction gps.encode() que vous appellerez est rapide aussi sauf à la fin d'une "phrase" car il décode à ce moment là (à la réception d'un '\r' ou '\n' ou '*')
Avez vous cherché à optimiser les infos retournées par votre GPS (mettre que ce qui est nécessaire dans le flux NMEA)
oui, je n'ai que la trame GPZDA, toutes les deux secondes, que je décode avec la librairie de bricoleau.
Peu importe que la trame soit terminée ou non, à chaque appel le traitement est le même.
Pourtant avec 64b de buffer, ça devrait passer largement en ayant une trame (de 36b) seulement toutes les 2s, donc le soucis ne vient pas de là, c'est bien un soucis de réception pour des vitesses <9600
Bon, à 9600 ça fonctionne, je ne vais pas me prendre la tête plus que ça. Même si de temps en temps je loupe une ou deux trames, c'est juste utilisé pour recaler la RTC si elle dérive de plus de 30s, donc ça passe quand même largement.
vous n'avez pas envie de passer sur les petites MEGA (Mega Pro ou MegaPro mini) qu'on trouve maintenant (5€ en Asie) ?
c'est plus petit qu'une UNO et ça vous donnerait 4 ports série hardware !
si, j'en ai commandé depuis déjà pas mal de temps, mais le virus en a décidé autrement....
cela dit, vu l'application (commander 2 relais en fonctions de températures pour ventiler ou non des combles) l'utilisation d'une mega ne se justifie pas vraiment. En plus j'ai eu des soucis pour écrire sur carte SD avec la méga, ce que je n'ai jamais eu avec la uno, et vu les sujets du forum, ça semble assez récurrent.
Je voulais utiliser un esp32 à la base, pour pouvoir dépouiller les mesures ou changer les consignes sans devoir monter dans les combles, mais mon client ne veut pas entendre parler "d'ondes"...
Ailleurs dans ton programme, tu dois avoir du code qui prend trop de temps ou qui bloque une ressource utilisée par softwareSerial.
C'est peut-être optimisable.
Un suspect?
Et pourquoi ne pas utiliser Serial pour lire le GPS et garder SoftwareSerial pour le debug?
Dans l'application finale tu n'as besoin que d'un lien série?
bricofoy:
D'autre part, comme je ne lis qu'un caractère par passage dans loop() pour des raisons de réactivité du reste du soft, ...
Pardon, mais j'émets quelques doutes sur cette hypothèse de départ.
Le décodeur GPZDA que nous avons mis au point, est très performant. Le traitement d'un caractère ne coûte quasi rien en CPU. Tu devrais traiter tous les caractères disponibles à chaque loop.
Un "while (available()) traiterCar(read());" ne devrait aucunement nuire à la réactivité du reste du programme.
bricoleau:
Le décodeur GPZDA que nous avons mis au point, est très performant. Le traitement d'un caractère ne coûte quasi rien en CPU. Tu devrais traiter tous les caractères disponibles à chaque loop.
oui je suis d'accord — c'était déjà ce que je suggérais en #1 et ça a l'avantage de libérer de la place dans le buffer Rx
Ailleurs dans ton programme, tu dois avoir du code qui prend trop de temps ou qui bloque une ressource utilisée par softwareSerial.
C'est peut-être optimisable.
Un suspect?
Non, rien ne prends du temps dans le programme, c'est étrange. mais je penche plus pour un soucis de SoftwareSerial puisque sans rien changer d'autre juste en passant de 4800bps à 9600 ça fonctionne. Les seules choses qui prennent potentiellement, du temps sont la lectures des 3 capteurs DHT22 et l'écriture sur carte SD, qui ne se font respectivement que toutes les 10s et toutes les 10minutes...
bricoleau:
Pardon, mais j'émets quelques doutes sur cette hypothèse de départ.
Le décodeur GPZDA que nous avons mis au point, est très performant. Le traitement d'un caractère ne coûte quasi rien en CPU. Tu devrais traiter tous les caractères disponibles à chaque loop.
Un "while (available()) traiterCar(read());" ne devrait aucunement nuire à la réactivité du reste du programme.
Oui je pourrais essayer par curiosité, mais maintenant que ça fonctionne j'ai la flemme de redémonter le module GPS pour le connecter au PC pour lui changer ses parametres et le remettre à 4800... Enfin cela dit je peux quand même modifier le traitement, même en restant à 9600.
hbachetti:
Software Serial utilise les PC (pin change) interrupts.
Si quelque part dans le code (ou librairies utilisées) il y a des cli(), gare ...
Non rien. La librairie Time pour gérer l'horloge, et plusieurs machines YASM pour afficher un menu(sur lcd 1602 en i2c), lire des capteurs, enregistrer sur carte SD (mais seulement toutes les 10 minutes) et activer des relais.
fdufnews:
Et pourquoi ne pas utiliser Serial pour lire le GPS et garder SoftwareSerial pour le debug?
Dans l'application finale tu n'as besoin que d'un lien série?
Dans ce cas il faudrait débrancher le GPS pour pouvoir faire la moindre mise à jour, donc ouvrir le boîtier et bidouiller, pas idéal...
Oui mais la finalité du montage ce n'est pas d'être mis à jour quotidiennement mais d'avoir une interface série qui fonctionne sans problème au quotidien.
C'est marrant, ce n'est pas la première fois que je remarque ça sur le forum. Pour faire des petites bidouilles je comprends que l'on veuille conserver Serial car on risque de faire des modifications du programme régulièrement. Mais quand la finalité du montage c'est d'avoir une interface série qui fonctionne bien et d'avoir un programme "performant" je ne vois vraiment pourquoi s'embêter avec softwareSerial avec les limitations que cela impose.
non, la finalité du montage, c'est d'enregistrer des températures sur carte SD, et d'ouvrir ou non des ventilations en fonctions de celles-ci, ce qui à priori fonctionne très bien.
La liaison série avec le gps n'est là que pour permettre le recalage automatique de l'horloge ds1307 au cas où elle dérive trop, ou perde l'heure suite à coupure de jus+pile à plat, et aussi éviter de se taper le codage d'un menu pour le réglage de l'heure. Autant dire que c'est un peu gadget (mais à 3€ le module chinois...pourquoi pas). Donc même si elle merde et que je loupe quelques trames, tant qu'il en reste une de lisible par heure c'est correct...
D'autant que le boîtier sera fixé au mur dans les combles, dans une position fort inconfortable (moins de 1m sous plafond, les pieds dans 40cm de ouate de cellulose... ) pas précisément l'endroit où il sera facile de l'ouvrir pour bidouiller dedans si MAJ il faut faire, alors que juste décoller une étiquette sur le flanc pour raccorder un câble usb ça reste faisable.
Et puis surtout, ce que je dis depuis le début c'est précisément que à 9600bps ça fonctionne. La question était de savoir pourquoi vu que ça ne me semble pas logique, et que ça me le semble encore moins au vu de tout ce qu'on a évoqué. (temps de traitement, taille du buffer, etc) Reste le bug de la librairie.
