566 réponses à ce sujet

[Keuronde]

Je commence à avoir un truc fonctionnel...
J'ai la carte de détection (rpi pico) qui envoie les données de ses 12 capteurs (160 caractères) toutes les 20 ms
J'ai un pico "device CDC" qui envoie 60 octets toutes les 3 ms, 100 fois et qui mesure pour chaque emission le temps du "printf()". A la fin de la slave de 100 messages, la carte envoie le temps mis pour chaque message pour être envoyé.
J'ai un pico "host USB" qui récupère les données, avec un tampon pour chacune des cartes, et qui transfert uniquement les données de log au PC par la liaison série.

Le temps d'émission du "device CDC" est stable, entre 55 et 80 µs !
Bref, je suis content !
_Question: à quoi reconnait-on une donnée de log ? Elle commence par ">"_

[Keuronde]

Pa vraiment , c'est la syntaxe de téléplot, pour envoyée une donnée par la liaison série (voir => https://teleplot.fr/)

[Keuronde]

Bon, enfin quelques progrès sur la communication !
Comparé à l'I2C, cette partie là est complexe ! En I2C, le fait de savoir à coup sur quand commence et quand se termine le message simplifie tout une partie du protocole.

Donc, là, nous sommes sur une liaison série sans ces fonctionnalités... Comment nous nous en sortons :
* Une fonction de la lib nous met à disposition les données ainsi que le nombre d'octets reçu *tuh_cdc_read()*
* Nous stockons ces données dans un tampon tournant, avec
* un pointeur sur où écrire les prochaines données
* un pointeur sur où lire les données
* Enfin, nous avons un protocole qui défini différents messages, répartis en 2 familles :
* Les messages ASCII, commencent par '>' et se terminent par '\n'
* Les messages binaires, commencent par 'r', 'w' ou 'd'. leur entête donne leur taille et ils se terminent tous par '\0'
Si on trouve un caractère de début, on vérifie qu'il y a bien le caractère de fin correspondant. Si c'est le cas, on met les données dans une structure message qui sera stockée dans une file (FIFO). Sinon, on passe au caractère suivant.

Ensuite l'applicatif n'a plus qu'à lire les messages les un après les autres et les traiter.
Ça parait pas compliqué, mais j'ai l'impression d'être là-dessus depuis 1 mois et demi

[Keuronde]

J'avais pas le terme "Framing", merci !
C'est ce que j'ai vu, notamment lorsque je me suis penché sur le protocole des servomoteurs Feetech...
Pour les Feetech, il y a 2 octets d'entête, une taille de message et un CRC. J'ai eu la flemme d'implémenter le CRC. J'ai peut-être eu tord...
Je me dis que je ne devrais pas avoir de données parasites sur l'USB (contrairement à un UART) et que l'USB avait déjà un CRC sur les trames.
Mais effectivement, un coup de "pas de chance" et je rate un message (ou je le comprends mal).

[Keuronde]

C'est une astuce intéressante !! Ça m'aurait probablement éviter une grosse partie de mon code !

[Keuronde]

La solution de @madahin [Sharp'Attack] à l'intérêt d'être simple à implémenter.
@Wix [Girafes] (Legend) : je contrôle que mon caractère de fin se trouve au bon endroit, ce qui me permet d'éliminer un message partiel. Mais c'est pas d'une fiabilité absolue... Je note le CRC dans les améliorations à déployer !

[Keuronde]

@Wix [Girafes] (Legend)
Pour l'instant, c'est ce que j'ai (sauf que l'octet de start dépend du type de message)

[Keuronde]

Je viens de lire l'article, c'est en effet plutôt malin. Dans un paquet de 254 octets, il ne peut pas y avoir 255 valeurs différentes. Donc le premier octet indique la valeur par laquelle sera substitué le 0x00 dans le message (s'il est présent)...
L'inconvénient, c'est que le message est limité à 254 octets (mais c'est une limitation qu'on retrouve souvent, dès que la taille est codée sur 1 octets par exemple) !

Va falloir que j'écrive un truc sur le framing, si ça continue...
Merci @nesnes ¯\_([U+30C4])_/¯ [TDS-team-72]

[Keuronde]

Petit point d'avancement :
Avec tous ces tampons à parcourir et à analyser, j'ai accumulé les problèmes de boucles qui n'en finissent pas, de débordement de tableau... J'avais des trucs qui ne marchaient que quelques secondes...
Là, j'ai un échange de messages entre 2 devices (en passant pas l'hôte), avec en théorie 1 message toutes les millisecondes dans un sens et quelques messages qui se baladent en plus.
Je n'ai pas encore mesurer la performance (le temps pour envoyer les messages, et la latence sur un aller-retour de message), mais côté stabilité, ça a tourné 3h30, donc j'ai franchis un cap !

[Keuronde]

Bon alors, ça marche, j'ai amélioré le performance d'un point de vue "temps de traitement". Je consomme 75µs pour envoyer un message et 80 µs pour les recevoir.
Mais je garde une bande passante très limitée, sachant qu'avec 1 seul _device_, le maximum que j'atteignais c'était 1 message de 64 octets par 1 ms.
Là, j'ai une carte de détection qui envoie un message toutes les 5 ms (en théorie, j'ai pas vérifié) et j'arrive à recevoir 1 message de donnée sur mon récepteur toutes les 6 ms. Sachant que l'hôte fait office de tampon et stock les valeurs reçues de la carte du capteurs. Peut importe qu'un nouveau message des capteurs soit arrivé ou non, l'hôte transmet la dernière valeur reçue. La carte des capteurs est surtout là pour charger le bus et voir comment l'ensemble se comporte avec un peu de charge.
La conclusion c'est qu'on tourne à 146 messages par secondes. Ce serait un peu juste pour de l'asservissement de moteurs mais pour le reste, (évitement, actionneurs) ça parait OK

[Keuronde]

Précédemment, j'avais réglé mes soucis en débogant mon programme avec VS Code. J'avais réussi à tout installer tout seul, comme un grand, sauf l'interface entre `gdb` et `VS Code`. Pour cela, je me suis résigné à installer le plugin Raspberry Pico de VS Code (raspberry-pi.raspberry-pi-pico).
J'ai été bluffé, parce que ça a marché !

Donc, oui, pour un débutant, maintenant, je pense que je recommanderai le plugin de VS Code qui installe plein de choses.

Ça ne m'a pas empêché d'essayer de comprendre comment finir mon installation. Après avoir obtenu un truc fonctionnel une fois le plugin désinstallé, je mets mes notes en ligne. Je ne suis pas encore fier de la config, j'ai des trucs à peaufiner, mais ça me parait presque publiable.

Bref, ma prose est ici : https://poivron-robo...o-Le-debug.html

[Keuronde]

Je viens de d'avoir une réunion avec Aisler, ils vont soutenir #poivron-robotique et #riombotique

[Keuronde]

Je pense que c'est la carte la plus inintéressante que j'ai pu faire :
- Un convertisseur de tension
- Un microcontrôleur
- Un lecteur de carte SD
- Une liaison UART convertie en USB
- Des LED RGB pour les statu des organes du robot.

Cette carte sera le c[U+0153]ur de la communication interne du potentiel robot et sa mémoire avec une carte SD pour les LOG. Bref, c'est la conclusion du travail fait cet été.

[Keuronde]

J'avais bon espoir de le souder @kmikaz [Evo/Coffee/PS] @DanLo' [7Robot] Vous pensez que ça va être chaud ?
https://www.molex.co...etail/472192001

[Keuronde]

Il a l'air pas mal ! Je pense sérieusement à modifier ma carte, à l'usage ça doit être plus simple... @kmikaz [Evo/Coffee/PS]

[Keuronde]

@kmikaz [Evo/Coffee/PS] Tu mets un pull down à "card detcion switch 1" et tu forces ta sortie de microcontrôleur à 1 sur DATA3/carteDetection ?
La pull down ne pose pas de soucis pour le fonctionnement de la carte ?
Changement du lecteur de carte SD

[Keuronde]

Oui, J'ai un petit stock qui trainait...

[Keuronde]

Tu mettrais quoi ? 100 nF ?
J'en ai 12 en série sur ma carte de détection, et j'ai pas remarqué de soucis lié à ça ... Tu as déjà eu des soucis ?

[Keuronde]

Tu mets du CMS pour ces condos ? J'ai le reflexede tout mettre en traversant...

[Keuronde]

C'est une ligne de plus dans la BOM...