je viens de débuter sur UnoR4.
Mon projet vise à recevoir et transmettre du RF 433Mhz pour réguler une serres.
Mon récepteur était branché sur le port analogique pour Sniffer ou hacker le signal d'une sonde de température. J'avais observé le signal de mes télécommandes et de ma sonde de T° avec le Serial Plotter. J'ai voulu avoir un signal plus précis... Je m’apprêtais à l'enregistrer dans un fichier pour analyse.
Je change la vitesse du port série avec un Serial.begin(48000)... Et patatra !
Je ne suis pus capable de faire des Serial.println() tous bêtes sur le moniteur série !
Je lis toujours le même caractère obscur, sans retour à la ligne, comme ça :
J'ai eu l'idée de re-télécharger l'IDE (sur linux).
Mais surtout après avoir ouvert de nouveau le moniteur série, j'ai vu qu'il était réglé sur 38000 bauds à peu près. Je l'ai remis sur 9600 et j'ai pu lire "toto" !
Par contre j'avais lu qu'on pouvait mettre n'importe quelle vitesse pour le Serial ? Des commentaires ?
On peut mettre n'importe quel débit (dans des limites raisonnable, évidemment).
La seule contrainte c'est d'avoir la même valeur dans le Serial.begin() et dans le moniteur série.
En communication série asynchrone, il n'y a pas de signal explicite indiquant l'arrivée ou la fin d'un bit. La transmission repose donc sur la synchronisation entre l'émetteur et le récepteur via leurs horloges internes. Le bon fonctionnement de cette transmission dépend fortement de la précision de ces horloges, car elles déterminent la vitesse à laquelle les données sont envoyées et reçues.
Les vitesses en bauds, comme 4800, 9600, 19200, etc., sont des multiples de 2400 bauds. Cette norme a émergé en raison des contraintes historiques et techniques des premières technologies de transmission série. Dans les années 1960-1970, les circuits intégrés et les composants électroniques avaient des limitations en termes de fréquence de fonctionnement stable et de précision. Les oscillateurs et les circuits de traitement des signaux n'étaient pas aussi performants qu'aujourd'hui, et il fallait donc s'assurer que la transmission soit fiable tout en restant dans les capacités des équipements de l'époque.
La fréquence de 2400 bauds a été choisie comme une valeur de base, car elle offrait une vitesse de transmission utile tout en étant suffisamment basse pour ne pas dépasser les limites physiques des composants. Cela permettait d'assurer une communication sans trop d'erreurs. Les valeurs comme 4800, 9600 et 19200 bauds, qui sont des multiples de 2400, ont ensuite été adoptées pour offrir des vitesses de transmission plus rapides tout en restant compatibles avec les technologies de l'époque. Ces multiples sont également simples à implémenter dans les circuits électroniques, car ils peuvent être générés en divisant des horloges internes ou en utilisant des générateurs d'horloge multiples.
il y a quelque chose qui reste mystérieux pour moi.
J'ai compris que le port série est lié à un fichier dans /dev que l'on ne peut pas lire directement (car binaire ?).
Je me demande surtout ce qui se passe réellement... L'arduino écrit dessus et le PC le lit... Est-ce qu'il font ça en même temps (synchonisé l'un après l'autre en permanence) ? Est-ce que l'arduino peut écrire plusieurs ligne avant que le PC ne lise le port ? J'ai cru comprendre que ça pouvait se passer dans les deux sens... Comment l'A ou le PC peut faire la différence entre ce qu'il envoie et ce qu'il doit recevoir ?
Et est-ce que ça fait pas beaucoup de consommation inutile si la communication est permanente à haut débit ?
J'allais faire une recherche là-dessus mais j'avoue qu'avec tous les ports qui existent (surtout sur le net) j'ai trouvé peu de choses pertinentes pour commencer... Donc si J-M-L tu es partant pour une synthèse ou si tu as un lien bien fait...
Pour la faire courte, les devices sont des fichiers virtuels, donc ils ne se comportent pas totalement comme un fichier texte, par exemple.
Dans le cas de /dev/ttyUSBx ou /dev/ttyACMx la lecture et l'écriture utilisent des buffers distincts donc, lorsque le PC fait une lecture après avoir fait une écriture, il ne voit pas ce qu'il a envoyé mais ce qui lui à été envoyé par l'équipement à l'autre bout.
La liaison série émulée est bidirectionnelle donc il est parfaitement possible que les 2 équipements envoient des données en même temps mais il n'y a pas carambolage puisque les 2 flux sont complètement distincts.
Si ce sont des buffers ça veut dire que les envois de l'Arduino peuvent s'accumuler dedans, le temps que le PC fasse ce qu'il a à faire d'autre, puis le PC revient et vide le buffer ligne après ligne par exemple ?
Et est-ce que ça consomme bcp de ressources d'envoyer et de recevoir en permanence des données ? A quelle fréquence le font-ils (PC sur Python par exemple en lecture) ? Y a-t-il de "bonnes pratiques" ? (pauses, gestion d'événements...)
Je me pose ces questions car je vais avoir un programme python (ou peut-être C) sur raspberry qui devra écouter l'arduino qui écoute des capteurs (température ou autre) ; et le RPI devra prendre certaines décisions et les envoyer à l'arduino.
Est-ce qu'il vaut mieux tout automatiser du côté arduino (j'ai un R4 wifi) et laisser le PC dans la com et l'enregistrement ? Est-ce qu'un arduino peut gérer à lui tout seul une centrale domotique autoprogramée ?
On va dire plutôt caractères par caractères. Mais c'est l'idée.
C'est la même chose coté Arduino mais les ressource de celui-ci son réduites les buffers sont plus petits.
Ça dépend de ce que tu entends par en permanence, de la quantité de données et du traitement à faire sur les données.
