Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Sujets - Jean-Luc

Pages: [1] 2 3
2
Les réseaux / DÉPLACÉ: Réseau hivernal en N
« le: mai 29, 2019, 08:55:39 am »

3
Vos projets / Satellite V2
« le: février 04, 2019, 05:42:53 pm »
Bonjour à tous.

Un peu de teasing  :P

La série d'articles sur la carte Satellite V1 est en cours de publication. Pour l'instant 2 articles sont publiés :
Nous peaufinons celui sur la messagerie et le middleware pour le WE prochain.

Il y a déjà eu quelques éléments à propos des évolutions futures : http://forum.locoduino.org/index.php?topic=565.0
L'idée a été creusée et voici donc l'état actuel des reflexions sur la carte Satellite V2.

L'idée est de la rendre plus générale et plus adaptable que la V1 avec une banalisation plus poussée des entrées/sorties. La V1 assigne en dur une entrée ou une sortie à une fonction. La V2 partage certaines broches entre plusieurs fonctions. Une fois le logiciel configuré, une des fonctions est choisie. La V1 est munie d'une détection par consommation, la V2 n'en a pas :) La V1 est monolithique, la V2 peut recevoir des cartes d'extension pour ajouter de l'électronique comme par exemple l'électronique de détection.

La Satellite V2 est plus simple au niveau électronique car il n'y a finalement que:
  • Un Arduino Nano
  • Un contrôleur CAN MCP2517FD
  • Un transceiver CAN
  • Une alimentation plus costaude que sur la V1
  • Optionnellement un second régulateur permettant de l'alimenter avec une tension au delà de 12V
  • Des résistances
  • Des connecteurs

On peut connecter:
  • Jusqu'à 6 servomoteurs avec et sans détection de fin de course;
  • Jusqu'à 15 LED pour la signalisation;
  • Jusqu'à 8 détecteurs;
  • Jusqu'à 4 cartes d'extension.

MAIS PAS TOUT EN MÊME TEMPS

La carte est du même format que la V1 : 100x50mm



Une carte d'extension fait 50x25 ou 75x25 ou 100x25 et se place sous la carte Satellite V2.

4
Vie du forum / UP AND RUNNING !
« le: janvier 29, 2019, 10:03:05 pm »
Bonsoir,

Après quelques avatars et le temps d'avoir une BDD opérationnelle, il semblerait que ça soit bon  :)
Et au niveau vitesse, c'est le jour et la nuit :)

Toutefois, si vous constatez des soucis, réagissez à la suite de ce message.

J'ai profité de l'espace disque plus important pour passer la taille des pièces jointes à 1Mo par message et à 500ko par pièce jointe. Mais n'abusez pas  ;D

5
Discussions ouvertes / Programmation : les closures
« le: janvier 11, 2019, 05:05:40 pm »
Bonjour,

J'ai entrepris une petite mise à niveau des nouveautés apportées par C++ 11.

Je ne vais pas parler de tout car c'est quand même très technique mais je voulais vous présenter les « closures » aussi connues sous le nom de « lambda functions » pour plus simplement « fonctions en ligne » qui sont d'une utilité directe et évidente.

Pour illustrer je vais partir d'une exemple avec une Schedule Table (l'article est ici : https://www.locoduino.org/spip.php?article116)
Supposons que nous voulions reproduire le clignotement d'un feu à éclat : un flash bref, disons 50ms, sur une période de 800ms. Avec une Schedule Table, on peut faire comme ceci :

SchedTable<2> flash(800);

void led13On()
{
    digitalWrite(13, HIGH);
}

void led13Off()
{
    digitalWrite(13, LOW);
}

void setup()
{
    flash.at(200, led13On);
    flash.at(250, led13Off);
    pinMode(13, OUTPUT);
    flash.start();
}

void loop()
{
    ScheduleTable::update();
}

Les closures permettent de remplacer la déclaration séparée qui est faite de led13On et led13Off et de les mettre directement dans le programme lors de l'appel de la méthode at, comme ceci :

SchedTable<2> flash(800);

void setup()
{
    flash.at(200, []{ digitalWrite(13, HIGH); } );
    flash.at(250, []{ digitalWrite(13, LOW); } );
    pinMode(13, OUTPUT);
    flash.start();
}

void loop()
{
    ScheduleTable::update();
}

Notez la syntaxe avec les crochets suivis du code entre accolades.

Un autre usage sont les routines d'interruption que l'on attache. Souvent il s'agit juste de mettre à vrai une variable comme par exemple dans cet article : https://www.locoduino.org/spip.php?article148

volatile byte Flag_Recv = 0;   // variable d'échange avec l'interruption IRQ

/*
 *  ISR CAN (Routine de Service d'Interruption)
 *  le flag IRQ monte quand au moins un message est reçu
 *  le flag IRQ ne retombe QUE si tous les messages sont lus
 */
 
void MCP2515_ISR()
{
     Flag_Recv = 1;
}

Et dans setup() :

attachInterrupt(0, MCP2515_ISR, FALLING); // interrupt 0 (pin 2)

Avec les closures on peut écrire directement

attachInterrupt(0, []{ Flag_Recv = 1; }, FALLING); // interrupt 0 (pin 2)

6
Bibliothèques / Bibliothèque KeepMeAlive
« le: décembre 22, 2018, 11:26:26 am »
Bonjour,

Je viens de pousser une bibliothèque pour utiliser le Watchdog Timer des ATMega328 (Arduino Uno, Nano, Pro Mini). Ça marche peut être sur Mega, je n'ai pas testé. Mais l'idée est de l'étendre aux autres Arduino.

Pour savoir à quoi ça sert vous pouvez consulter l'article sur Wikipedia

C'est une fonction importante si vous devez déployer plusieurs Arduino, pas toujours très accessibles, sur votre réseau.

La bibliothèque n'est pour l'instant pas disponible dans le gestionnaire de bibliothèque, il faut la télécharger ici : https://github.com/Locoduino/KeepMeAlive/releases/tag/1.0

 

7
Vie du forum / Problème technique sur l'hébergement
« le: décembre 05, 2018, 09:50:39 am »
Bonjour,

Depuis hier je constate des problèmes d'accès au serveur MySQL chez l'hébergeur. Je n'ai aucune info pour l'instant. J'imagine que ce serveur tourne sur une autre machine et que pour une raison X ou Y, une partie des requêtes échouent.

Les conséquences sont :
  • Côté forum (SMF) des messages apparaissent vides ou incomplets et parfois l'encodage des caractères se fait mal (UTF8 pas interprété en tant que tel)
  • Côté rédactionnel (SPIP) un message explicite s'affiche

Je ne peux rien faire de mon côté pour remédier à cela. Je vais mettre un ticket à l'hébergeur.

MAJ: Le ticket a été ouvert ce matin

8
Bus CAN / Contrôleur CAN MCP2517FD
« le: novembre 19, 2018, 11:31:05 am »
Bonjour,

Actuellement le contrôleur CAN utilisé conjointement avec les Arduino est le MCP2515. Ce composant est sorti en 2003. Il possède 3 buffers d'émission et deux buffers de réception (RXB0 et RXB1). Pour sélectionner uniquement les messages qui sont pertinents, RXB0 possède 1 masque et 2 filtres et RXB1 1 masque et 4 filtres

En 2017 Microchip a sorti un nouveau contrôleur, le MCP2517FD. Ce composant possède une RAM interne de 2ko pour les buffers (hé oui autant que l'Arduino Uno) et permet de configurer 31 FIFO de messages en émission ou en réception, 32 masques ou filtres. L'interêt immédiat est :
  • de libérer la mémoire de l'Arduino qui sert au stockage des messages en réception
  • d'avoir beaucoup de place pour stocker les messages en réception
  • de bénéficier d'une FIFO en émission gratuitement en terme de mémoire pour que l'émission ne soit pas bloquante si le message précédent n'est pas parti

En mode CAN2.0B, il est évidemment compatible avec le 2515

Mon collègue Pierre a écrit un driver pour ce composant : https://github.com/pierremolinaro/acan2517
Cette bibliothèque est téléchargeable via le gestionnaire de bibliothèques de l'IDE

J'ai dessiné une petite carte que je vais bientôt faire fabriquer pour essayer, je vous tiens au courant.

9
Vie du forum / Demandes d'épinglage
« le: juin 05, 2018, 11:18:56 am »
Bonjour,

Epingler un sujet n'est pas un système qui marche utilisateur par utilisateur. C'est un attribut global d'un sujet. Ce n'est pas forcément à la modération de décider quel sujet doit être épinglé.

Ce fil sert poster vos demandes d'épinglage

Et il est lui même épinglé :)

10
Shields et Modules / Mini décodeur à base d'ATTiny 84
« le: juin 02, 2018, 08:36:35 am »
Voici les infos sur cette carte avec le BOM et le schéma

Si vous vous souvenez, cette carte est hybride. Elle peut également être utilisée sans l'ATTiny.

Avec l'ATTiny

Souder S2, S3, S4 et S5 mais pas S1

Le connecteur K2 donne accès aux broches de programmation

Deux sorties peuvent être amplifiées (transistor NPN en collecteur ouvert), la 9 et la 10. Par défaut elles le sont mais vous pouvez avoir une sortie directe en soudant dis 9 (pour la sortie 9) et dis 10 (pour la sortie 10).

Sans l'ATTiny

Souder S1 mais pas les autres. L'ATTiny ne sera pas alimenté. La broche 4 du connecteur K2 donne accès au signal DCC.

11
Bibliothèques / LightDimmer : une bibliothèque pour les feux
« le: mars 29, 2018, 09:40:14 am »
Hier j’ai programmé une bibliothèque pour faire de l’allumage et de l’extinction progressive des ampoules des feux de signalisation. On peut voir ça dans la vidéo de l’article http://www.locoduino.org/spip.php?article47. Le filament des ampoules à incandescence ayant beaucoup d’inertie, il faut 250ms pour qu’ils s’éteignent ou s’allument. Il faut bien sûr une sortie PWM.

La bibliothèque est en bêta, c’est ici :

https://github.com/Locoduino/LightDimmer/releases

Un peu de doc :

https://github.com/Locoduino/LightDimmer/blob/master/README.md

12
Bibliothèques / Hardware packages
« le: février 09, 2018, 05:21:11 pm »
Bonjour,

Je propose de rassembler ici les liens vers les « hardware packages », collections logicielles qui permettent d'ajouter le support d'une carte ou d'un micro-contrôleur à l'IDE Arduino, rendant ce matériel compatible avec le logiciel Arduino.

Au fur et à mesure des contributions, je les ajouterai en tête de fil.



MicroCore https://github.com/MCUdude/MicroCore

Ajoute le support des ATtiny13, ATtiny13A et ATtiny13V.



ATTinyCore https://github.com/SpenceKonde/ATTinyCore

Ajoute le support des ATtiny2313, 4313, ATtiny24, 44, 84, ATtiny25, 45, 85, ATtiny261, 461, 861, ATTiny87, 167 (with or without Optiboot boot loader), ATTiny48, 88, ATTiny441, 841 (With or without Optiboot boot loader), ATTiny1634 (With or without Optiboot boot loader), ATTiny828 (With or without Optiboot bootloader)

13
Bus CAN / Les cartes CAN en 8MHz
« le: septembre 12, 2017, 06:21:10 pm »
Comme je suis en train de faire ma propre bibliothèque pour le 2515, je regarde en détails son fonctionnement ainsi que les normes et recommandations pour la mise en œuvre d'un bus CAN.

Via la configuration on détermine le débit du bus.

La durée d'un bit est quantifiée en TQ (Time Quantum). Cette durée est divisées en 4 segments successifs dans le temps :
1 - Le segment de synchronisation (SyncSeg) qui est de durée fixe : 1 TQ
2 - Le segment de propagation (PropSeg) qui permet de tenir compte du temps de propagation du signal dans le bus. Il peut être programmé de 1 à 8 TQ
3 - Le segment de phase 1 (PS1), également programmable entre 1 et 8 TQ
4 - Le segment de phase 2 (PS2), programmable entre 2 et 8 TQ (plus loin dans la datasheet, c'est de 1 à 8, enfin passons)

Par ailleurs il y a des contraintes :
a - PropSeg + PS1 ≥ PS2
b - PropSeg + PS1 ≥ 2

l'échantillonnage du bit présent sur le bus est réalisé à la fin de PS1 et doit se situé entre 60 et 70% de la durée du bit d'après Microchip mais pour CANOpen et DeviceNet c'est 87,5 et la norme ARINC dit 75%.

TQ est dérivé de l'oscillateur dédié au 2515 (Fosc = 16MHz habituellement, 8MHz sur les cartes chinoises) via un Baud Rate Prescaler (BRP) sur 6 bits et qui peut donc avoir une valeur comprise entre 0 et 63 :

TQ = 2 x (BRP + 1) / Fosc

Donc avec Fosc = 16MHz et BRP = 0 (division minimum), on a TQ = 125µs et pour faire un bit, il faut 8 x TQ

Par exemple, la bibliothèque mcp_can utilise les valeurs suivantes pour un bus à 1Mbits :

BRP = 0 (TQ = 125µs)
PropSeg =  1 TQ (0)
PS1 = 3 TQ (2)
PS2 = 3 TQ (2)

Avec le SyncSeg qui dure 1 TQ, on a bien 8 TQ. L'échantillonnage est à 5/8 = 62,5%

Avec un carte à 8MHz, on a 4 x TQ de 250µs pour faire la durée du bit. Comme le SyncSeg prend 1 TQ, il en reste 3 (PropSeg = 1, PS1 = 1 et PS2 = 1) et ça coince car à priori PS2 est au mini à 2 TQ. Je ne suis pas persuadé qu'on puisse atteindre 1Mb avec un quartz à 8MHz.

14
Bus CAN / Composants : transceivers et contrôleurs
« le: juin 17, 2017, 12:01:31 pm »
Bonjour,

J'attire votre attention sur deux composants :

Le premier est un transceiver CAN de Microchip, le 2562. Il est similaire au et compatible avec le 2551. La différence est qu'il dispose de deux alimentations. La première est destinée à l'interface avec le microcontrôleur et la seconde pour le bus CAN. Ceci permet de connecter un microcontrôleur alimenté en 3,3V au réseau CAN qui lui est alimenté en 5V sans composants supplémentaires pour adapter les niveau logiques.



http://www.tme.eu/fr/details/mcp2562-e_p/circuits-integres-interface-can/microchip-technology/

Le second, le 25625, est un 2515 et un 2562 dans le même boîtier. Il permet donc d'économiser aussi des composants.



http://www.tme.eu/fr/details/mcp25625-e_ss/circuits-integres-interface-can/microchip-technology/

Le défaut est que le boîtier le plus accessible pour nous est le SSOP 28 broches, boîtier CMS avec un pas de 0,65mm. Ça se soude mais c'est un peu délicat :)

15
Vos projets / Tablette de commande du réseau
« le: juin 16, 2017, 12:08:14 pm »
Bonjour,

J'ouvre ce fil pour exposer le projet que nous avons de développer une tablette à base d'Arduino. Il s'agit d'un projet collectif mené avec deux camarades, Pierre et Philippe, dans lequel je ne suis pas le programmeur principal et ma part y est pour l'instant extrêmement faible. Je vais donc présenter un travail qui n'est pas le mien car ni Pierre ni Philippe ne participent au forum.

Pour commencer je vais présenter rapidement le système d'exploitation de réseau que nous avons conçu. Il s'agit d'un système de pilotage analogique. Le réseau est donc divisé en zones alimentées séparément. On distingue deux types de zones :
1 - les cantons dans lesquels un convoi peut être à l'arrêt. Le plus petit canton du réseau en longueur de rails définit la longueur maximum d'une rame. les cantons ont une zone de pleine voie et une zone d'arrêt dans chaque sens
2 - les zones d'aiguille

Chaque zone alimentée est gérée par un microcontrôleur et de l'électronique associée : l'alimentation traction.
Une alimentation traction remplit les fonctions suivantes :
* détection en zone de pleine voie et en zone d'arrêt
* mesure du courant (détection des court circuits)
* mesure de la vitesse du convoi (toutes les 10ms)
* calcul de la PWM par un asservissement proportionnel intégral
* alimentation du convoi
* éclairage permanent du convoi

Les alimentations traction sont reliées par un bus CAN à 727Kbits/s à un contrôleur central qui
- diffuse deux signaux de synchronisation pour la synchronisation des PWM (à 32kHz) et la mesure de vitesse (à100Hz)
- reçoit des alimentations traction les informations de détection de présence, de mesure de courant, etc
- envoie aux alimentations traction des ordres d'affection de convoi (gains de l'asservissement), les consignes de vitesse

Un second bus CAN dédié aux accessoires (aiguillages, signaux, ponts tournants, portes de remises, ...) permet de communiquer entre le contrôleur central et les cartes de pilotage des accessoires.

Le contrôleur central contrôle le déplacement des convois et assure la sécurité : block system habituel. Il contrôle également la signalisation. Il reçoit des souhaits de positionnement des aiguillages. Ces derniers sont effectivement positionnés lorsque par le contrôleur central lorsque les contraintes de sécurité le permettent.Le logiciel de suivi de convois, Caniche, a été développé par Pierre.

Toute cette électronique n'est pas entièrement Arduino. Pour ma part, j'ai deux cartes construites autour d'un Arduino Nano : la carte pont tournant et une carte servo pour les portes de remises. Toutefois, pour des évolutions futures, nous pensons remplacer le contrôleur central (actuellement une carte Olimex avec un ARM 7 TDMI à ~60MHz) par un Teensy 3.6 qui dispose de deux contrôleur CAN.

Comme nous ne souhaitons pas avoir un ordinateur de bureau ou portable dans la boucle, l'interface homme-machine pour piloter le réseau choisi est une tablette (entre autre).

Pour répondre à une question qui ne manquera pas d'arriver, pourquoi ne pas avoir utilisé une tablette existante fonctionnant sous iOS ou Android ? Effectivement nous réalisons une tablette qui est plus épaisse et moins performante sans être pour autant vraiment moins chère. Mais un critère essentiel à nos yeux est de ne pas être dépendant d'une infrastructure logicielle complexe et de politique de développement et déploiement évolutives, casse pieds et imprévisibles.

Le hard

Pour l'instant Pierre a développé un prototype composé de :
- Un écran tactile 7" avec interface parallèle :



- Un Teensy 3.6



- Une connectique CAN
- Un ampli audio LM386 (pour faire des blip)
- Un encodeur rotatif (qui n'est pas monté et qui je pense ne le sera pas)

le tout intégré sur une carte.

À l'étude :

- Intégration dans un boîtier
- Alimentation sur batterie LiPo
- Lien radio avec un NRF24

Le soft

Le logiciel Arduino bien sûr,
UTFT, bibliothèque de gestion des écrans LCD
Une bibliothèque de gestion du tactile, URTouch étant mal écrite et buggée
AW (Arduino Widgets), bibliothèque développée par Pierre qui affiche des widgets, gère leur superposition et l'interaction avec l'écran tactile et qui sera disponible bientôt.

Des photos vont suivre :)

Pages: [1] 2 3