Mémoire circulaire à l'émission pour un Bus Can

[Patrick75]

Bonjour,
Je pense avoir besoin de mettre en oeuvre une mémoire circulaire pour stocker les messages à envoyer sur le bus CAN à partir d'un Arduino Due et d'un interface Waveshare SN65HVD230
Pour la partie réception, j'ai utilisé votre sketch décrit en partie no2 du Bus Can.

Or, je constate que :
a) je n'ai pas suffisamment "intégré" votre méthode "en réception" pour en déduire un sketch valable en émission
b) je ne trouve vraiment pas d'exemple ni ici ni sur le net d'une telle mémoire ciculaire à l'émission (ça peut signifier aussi que je fais fausse route en cherchant quelque chose qui n'aurait pas lieu d'être ... lol)

Le block system est géré par un Arduino Due traitant 8 cantons avec ses périphériques d'entrée-sortie locaux reliès par un bus I2C. Les différents Arduino Due doivent diffuser aux autres les informations relatives aux cantons que chacun d'entre eux gèrent.
D'autres Arduino "de pupitre" (tableau de contrôle optique) sont aussi à connecter à ce bus Can pour exploiter les informations des cantons qu'ils "surveillent" et envoyer aux Arduino "de block" les positions des leviers de "commande d'aiguille" et de commande des "carrés" et autres "ordres" de ces cantons.

Dans notre réalisation, le temps global de traitement des huit cantons par l'Arduino Due est d'environ 70ms (avec 32 entrées et 32 sorties par GPIO 23017) hors sous-programme de gestion des émissions-réceptions relatives au bus Can.
Le trafic des trains étant intense, j'anticipe un besoin de diffuser sur le bus CAN jusqu'à dix à quinze messages par seconde par Arduino "de block".

Auriez-vous un lien vers un exemple qui me permettrait d'extrapoler le sous-programme de gestion de cette mémoire circulaire à l'émission.
Merci pour tout ce qu'on trouve sur ce site.

[Thierry]

Bonjour.

J'ai mis en place un buffer circulaire dans notre projet LaBox (https://github.com/Locoduino/LaBox/blob/master/src/CircularBuffer.hpp). C'est un buffer basique qui stocke des données binaires. L'utilisateur doit s'arranger pour y stocker des messages de taille constante, ou d'y inclure la taille, puisque le buffer lui même ne contient qu'une liste d'octets sans infos sur son contenu... Il peut servir aussi bien à l'émission qu'à la réception. Il y a un exemple d'utilisation dans la classe ThrottleWifi.

PS : Ne pas se fier au commentaire de description de la classe qui doit être ré-écrit !

[Jean-Luc]

Thierry ne doit pas se souvenir qu’il y a une bibliothèque Locoduino pour ça : RingBuffer

https://github.com/Locoduino/RingBuffer

Elle est disponible via le gestionnaire de l’IDE.

[Thierry]

Oui c'est vrai...

[Patrick75]

Merci Thierry et Jean-Luc,

Je viens d'intégrer la bibliothèque préconisée par Jean-Luc : RingBuf.h v2.0.0
Par curiosité, je jetterai un coup d'oeil à l'autre mentionnée par Thierry.

Bon maintenant, il me "reste" à me familiariser avec sa mise en oeuvre.

Dans notre cas, les messages sont de longueur fixe avec 3 octets de données systématiques, ce qui conviendra donc à la gestion de cette mémoire circulaire, à l'émission.
Pour la réception, vous expliquiez avoir optimisée la bibliothèque du sujet "Bus Can, partie 2" : je la conserverai donc tel que préconisé (je n'ai pas du tout le niveau de compétence pour en juger ni donc m'écarter de vos préconisations).

Nous commençons à obtenir des résultats intéressants dans les essais du block system Arduino "à notre sauce", sur notre réseau de club.
D'ici quelques semaines (... à l'automne), je compléterai la présentation que j'en avais fait.

[simontpellier]

Bonjour Patrick,
Peut-être suis moi aussi bon pour passer à une mémoire circulaire ?
J'ai en effet un arduino qui pousse des données plus vite qu'un de ses clients ne les consomme, ce qui fait que je sature très vite le buffer de réception et que le code se bloque. Je n'ai trouvé aucune solution pour consommer plus... produire moins oui, mais c'est pas vraiment le but !
"RingBuffer" est-il bien la solution à ça ? (gain de temps certain pour moi si vous me le confirmez !)

si oui, la seconde question est plus chère !... en regardant rapidement les méthodes (ainsi que le projet "labox" de Thierry), je ne vois pas comment greffer ça pour gérer des buffers CAN de MCP2515...
si vous l'avez fait et que je puisse avoir ce travail comme exemple, le gain de temps exploserait !

Merci par avance
cordialement
Philippe

[Jean-Luc]

Bonjour,

Si le rythme de production est plus élevé que celui de consommation alors il faut un tampon infini. Un tampon fini ne peut servir qu’à régler des problèmes de producteur / consommateur transitoires 😊

[simontpellier]

Bonsoir Monsieur Jean-Luc,

Moi pas blonde mais j'ai quand même vérifié, même AliBaba n'a pas ça, un tampon infini ! Sans parler du temps qu'il aurait mit à arriver car j'aurais aimé une solution plus rapide...

Il n'y a pas dans ACAN une petite astuce pour moi ? J'ai regardé le pdf en "extras" dans la library mais je n'ai rien vu alors que c'est FORCEMENT un problème que les concepteurs du bus CAN ont eu a résoudre et il y a donc... forcément... une solution ! (Hein ? "Non, un tampon == un tampon" ?)

[Dominique]

Ça n’a rien à voir avec les blondes, ni les concepteurs du Can !
Sinon il n’y aurait ni voitures, ni avions, ni Tesla !

Il faut forcément programmer un contrôle de flux pour réguler l’émetteur, tout simplement.

Sinon revoir forcément la conception de votre projet apparemment inspiré par Buzz l’éclair (« vers l’infini et au delà »).

[simontpellier]

Re bonjour,

Merci pour vos deux réponses, je comprends que le contrôle du flux est impératif... forcément !

Ou en effet revoir la conception, ce qui se traduirait pour moi par un abandon du bus CAN et un retour à l'I2C, du moins sur l'ARDUINO-client problématique.
Qu'il avait fallu ajouter pour pallier le ralentissement, déjà, causé par deux afficheurs OLED 128x32 : avec une connexion I2C - sans "interruptions" donc - le sketch d'affichage se servait avec ce qui venait d'arriver et tout le monde vivait sa vie à son rythme.

Même avec le CAN ça n'est plus la même histoire : des datas qui arrivent à la modeste cadence de 100millis, 6 octets par message, "passent" si la routine d'affichage ne concerne qu'une ligne d'UN écran mais saturent le buffer dès que les deux lignes reçoivent un "oled.print". Avec un taux de rafraichissement dans tous les cas à peu près trois fois moindre qu'avec l'I2C...

Je ne suis pas du tout sûr de bien analyser le problème. Repasser à l'I2C me semblerait une régression mais je ne vois pas d'autre solution : ou peut-être la mémoire circulaire qui continue à me sembler pouvoir un être une ? C'est à dire un buffer FIFO intermédiaire, géré dans l'Arduino ? Si je pouvais avoir une confirmation, je creuserais volontiers.

En tous cas merci par avance pour vos commentaires
cordialement

[Dominique]

1) l’i2c ne gère pas moins de messages que le Can, donc revoir la conception est nécessaire.

2) expliquez votre système et en l’exposant vous trouverez la solution.