Messages

1

Discussions ouvertes / Re : Est il possible de raccourcir la durée du cycle de commande des GPIO PCA9685 ?

« le: février 14, 2022, 10:39:10 am »

Bonjour,

Merci pour ton message:
. je vais effectivement scinder les périphériques I2C esclaves et les répartir sur les 2 bus disponibles du Due
. j'essaierai aussi l'idée de scinder le programme du Due afin qu'il balaye les lignes de code correspondantes aux périphériques esclaves éloignés (... 4 sur 5 des modules PCA9685, modules pilotant l'affichage des feux des signaux) qu'une fois toutes les N boucles du programme principal. En effet, ils doivent pouvoir supporter un certain délai de latence dans leur rafraîchissement tant que ça n'a pas d'impact visuel marqué.
Ceci devrait permettre de retrouver un cycle de boucle d'une dizaine par seconde pour la prise en compte rapide des "événements" (détections, changement d'état des signaux des cantons avals associés)

Je communiquerai les résultats de mes avancées.
Par ailleurs, je reste à l'écoute des remarques que toi et les autres participants du forum voudrez bien m'adresser.

Patrick

2

Discussions ouvertes / Re : Est il possible de raccourcir la durée du cycle de commande des GPIO PCA9685 ?

« le: février 06, 2022, 07:42:43 am »

A défaut d'avoir trouver une solution centrée sur le PCA9685,
j'ai cherché et trouvé une solution de contournement que je souhaite partager avec vous:
"ne transmettre par le bus I2C que les commandes liées à un changement d'état par rapport à l'état mémorisé de la précédente transmission vers le port concerné".
C'est un peu lourd au point de vue programmation mais, c'est efficace et ne prends pas du tout trop de temps à l'Arduino Due qui gére le secteur de 8 cantons.

Process:
. mémoriser sous forme de tableau les états transmis (0 ou 1) la dernière fois
. mémoriser temporairement l'ensemble des 16 états déterminés par le programme
. comparer bit à bit les 2 mémorisation ci-dessus
. enregistrer lesquels des 16 ports font l'objet d'un changement d'état par rapport à la précédente transmission
. conditionner l'envoi vers les ports du PCA9685 à l'indicateur ci-dessus de changement d'état par rapport à la précédente transmission

Comme les trains circulant ne déclenchent qu'un nombre réduit de changements par seconde (... occupations, commandes des sources de traction, commandes des affichages des signaux), on arrive en pratique à une réduction d'un facteur 10 de la durée de cette partie du programme de Block System.
Ceci restorant la viabilité d'un taux de recalcul des situations d'une dizaine de fois par seconde.

Si vous avez des remarques ou des questions sur la parade adoptée, n'hésitez pas à échanger à ce sujet.

3

Discussions ouvertes / Re : Est il possible de raccourcir la durée du cycle de commande des GPIO PCA9685 ?

« le: janvier 27, 2022, 07:30:30 pm »

Re bonsoir,

Je rajoute que j'ai trouvé ces même 15ms en exécutant les fichiers d'exemples simples de la bibliothèque ou trouvez ici ou là.
Ce ne semble donc pas lié à mes lignes de code.

Patrick

4

Discussions ouvertes / Est il possible de raccourcir la durée du cycle de commande des GPIO PCA9685 ?

« le: janvier 27, 2022, 07:01:46 pm »

Bonjour,

Je bute sur la durée (... estimée trop longue à 15ms) du cycle de passation des commandes des états des 16 ports du PCA9685 par le bus I2C:
. Arduino Due
. bus I2C à 400kHz
. modules PCA9685 Adafruit (6 par Arduino Due)
. bibliothèque utilisée: celle sur Github "Adafruit_PWMServoDriver.h"

Pour mémoire, notre réseau de club en analogique est actuellement cantonné par 8 Arduino Due pilotant chacun 8 cantons.
Les PCA9685 servent d'interface tout ou rien avec des relais pour commuter les sources de traction et, à piloter pour l'instant en tout ou rien les feux des signaux et des pupitres (... les fonctions de clignotement et de "fading": ... allumage et extinction progressive viendront se rajouter ultérieurement).

Je n'ai rien trouvé sur internet comme "truc", comme bibliothèque plus rapide, comme commande particulière à envoyer aux PCA9685 pour les forcer ni, aucun sujet sur ces 15ms (... ce qui est étonnant vu qu'on peut théoriquement chaîner en I2C jusqu'à 62 PCA9685 ce qui prendrait donc environ 1s de cycle, ce qui est énorme et occupe abusivement l'Arduino Due).

Auriez-vous déjà rencontré ce problème et comment l'avez vous résolu ?

On ne va quand même pas doubler chacun des 8 Arduino Due de Block System par un autre (... Due ou Teensy) pour prendre en charge ces PCA9685 en dehors du programme du Due de Block System. Si ?

J'ai regardé s'il y avait moyen de transmettre les commandes par Bytes vers des registres des PCA9685 (... comme je le fais depuis les modules GPIO 23017 pour les entrées d'information: 3 modules I2C 23017 par Arduino Due de Block System).

J'ai regardé s'il existait un "sous programme en Python" qui pourrait être plus "efficace" mais, je n'ai pas trouvé.

Pour mémoire, il est prévu de relier les Arduino de Block System par un Bus CAN.

Question accessoire: devrait on utiliser la possibilité des Arduino Due d'avoir un second Bus Can qui transférerait à fort débit les tableaux de bits à envoyer vers l'Arduino d'interface I2C ? (pour décharger le Due de cette tâche afin de revenir à un temps total de traitement permettant un rafraîchisement des entrées-sorties au moins 10 fois par seconde).

Pour info, voici les lignes de code concernant les ordres envoyés aux PCA9685:

Code: [Sélectionner]

...

PCA9685_11.begin();
// PORT A
if (tabOutputsPortS11A[0]==0) {
    PCA9685_11.setPWM(1, 0, 4096);   }
  else   {
    PCA9685_11.setPWM(1, 4096, 0);   } 

if (tabOutputsPortS11A[1]==0) {
    PCA9685_11.setPWM(2, 0, 4096);   }
  else   {
    PCA9685_11.setPWM(2, 4096, 0);   }   

if (tabOutputsPortS11A[2]==0) {
    PCA9685_11.setPWM(3, 0, 4096);   }
  else   {
    PCA9685_11.setPWM(3, 4096, 0);   } 

if (tabOutputsPortS11A[3]==0) {
    PCA9685_11.setPWM(4, 0, 4096);   }
  else   {
    PCA9685_11.setPWM(4, 4096, 0);   }   

if (tabOutputsPortS11A[4]==0) {
    PCA9685_11.setPWM(5, 0, 4096);   }
  else   {
    PCA9685_11.setPWM(5, 4096, 0);   } 

if (tabOutputsPortS11A[5]==0) {
    PCA9685_11.setPWM(6, 0, 4096);   }
  else   {
    PCA9685_11.setPWM(6, 4096, 0);   }   

if (tabOutputsPortS11A[6]==0) {
    PCA9685_11.setPWM(7, 0, 4096);   }
  else   {
    PCA9685_11.setPWM(7, 4096, 0);   } 

if (tabOutputsPortS11A[7]==0) {
    PCA9685_11.setPWM(8, 0, 4096);   }
  else   {
    PCA9685_11.setPWM(8, 4096, 0);   }       

// PORT B

...

Bon, je suis dans la panade et j'espère que l'un d'entre vous pourra m'indiquer "une piste" pour diminuer le temps "processeur" pris pour gérer ces sorties. 

Enfin:
. l'objectif est de gagner un facteur 10, pas 10% !
. je ne tiens pas à passer le bus I2C en 1MHz (longueur physique du bus, sensibilité aux parasites, alimentation des PCA9685 en 3,3V l'interdisant)

On pourrait discuter d'une autre architecture ou toutes les liaisons s'opérent par l'intermédiaire de bus CAN (... ce que vous faîtes, je crois: ce n'a pas été retenu parce que ça oblige dès le départ à prévoir un Arduino supplémentaire en tête de tout interface). Quoi que s'il fallait rajouter un Arduino accessoire à chaque Due, on en serait là.

Bonne soirée,
Patrick

5

Bus CAN / Re : ACAN ESP32

« le: septembre 05, 2021, 12:48:37 pm »

Bonjour,
Un grand merci à msport et surtout Dominique pour leurs réponses précises et très rapides.

J'utilise déjà effectivement la bibliothèque due_can et je suis aussi déjà informé du piège de la permutation des bits de poids fort et faible en fonction du type d'Arduino utilisé, une piqûre de rappel ne fait pas de mal de toute façon.

Merci pour les fichiers joints et les explications sur la manipulation de données (je suis dans le cas de 4 blocs de 8 bits, chaque bit portant une donnée spécifique à gérer une par une).

Le testeur sera très utile, j'en suivrai les annonces.

Je regarde tout ça et reviendrai ici pour vous dire le résultat.
Patrick

6

Bus CAN / Re : ACAN ESP32

« le: septembre 04, 2021, 12:02:58 pm »

Bonjour,
Ce message n'est pas vraiment sur le sujet mais, je n'ai pas trouvé où le raccrocher.
Question:
A ce que j'ai compris, les bibliothèques ACAN ne sont pas compatible avec l'Arduino Due or les fonctionnalités de ACAN sont très intéressantes pour manipuler les data.
Qu'elle bibliothèque conseillerez-vous pour le Due ?
Merci.

7

Bus CAN / Re : Mémoire circulaire à l'émission pour un Bus Can

« le: juillet 20, 2020, 05:31:35 pm »

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.

8

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

« le: juillet 19, 2020, 04:33:08 pm »

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.

9

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau - le système de Denis

« le: septembre 21, 2016, 09:03:01 pm »

Je serai tenté par une description du réseau dans une matrice bien que ça diverge de la programmation C++ objet orthodoxe,  si je comprends bien.

Notre projet de réseau est complexe :
. 80 cantons à 2 zones environ plus une 20aîné de  zones d'aiguilles et une 10aine de zones d'arrêt supplémentaires pour les  cantons banalisés
. une 50aine d'aiguilles
. 5 à 8 pupitres de commande d'aiguilles et de carré de protection et la répétition des signaux de Bal Sncf
. pas d'itinéraires automatiques
. détection par consommation de courant à partir d'une source 24V continu
. 2 sources de courant traction Vnormal, Valentino
. un Arduino Due par canton, pupitre, zone complexe d'aiguilles

Le réseau sera construit en plusieures phases.

Je préférerais que la programmation de tous les Due de cantons soit identique et aussi definitive que possible.

La référence à une matrice unique centrale avec si possible une procédure de distribution automatique au démarrage me plairait bien.

Qu en pensez vous ?

Merci pour tous vos messages et articles qui nous aident beaucoup.

10

Présentez vous ! / Bonjour de Patrick75

« le: septembre 07, 2016, 01:04:37 pm »

Bonjour à tous,

Après avoir conçu et mis en place il y a 20 ans un block électronique qui permet la circulation d'une vingtaine de trains dans un club, nous nous lançons à quelques un dans un remplaçant basé sur l' Arduino Due et le Bus Can.

J'ai lu, relu et digéré à peu près tout sur le sujet, ici ou ailleurs et maintenant, nous nous lançons dans les expérimentations. Cependant à n'en pas douter, des points demanderons des éclaircissements ! 

Merci à tous d'avoir apporté ici toutes vos connaissances et expériences et, merci de m'accueillir parmi vous.

Patrick