556
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: avril 21, 2016, 05:20:07 pm »
Je crois que tout est bon :
L'Arduino pour le train miniature
Nouvelles:
Le forum LOCODUINO est consacré aux discussions ayant trait à l'utilisation de l'Arduino dans les automatismes et les animations pour le train miniature. Nous avons eu récemment quelques inscriptions de personnes ayant des projets plus généraux mais surtout inapplicables au train miniature. Si votre projet ou vos questions ne concernent pas le modélisme ferroviaire, ne vous inscrivez pas, vous perdriez votre temps et nous aussi.
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.
557
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: avril 21, 2016, 03:27:02 pm »
Ben, le print je l'ai juste ajouté parce que je ne comprenais pas, et que je voulais savoir si une interruption avait été lancée, mais ça ne marche pas sans non plus !
558
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: avril 21, 2016, 03:13:04 pm »
Après divers essais, je n'arrive à rien. Si maintenant l'initialisation est correctement faite, la carte de réception ne reçoit rien !
J'ai connecté par un câble RJ11 droit (vérifié, au cas où...) les prises côté Nano de chacune des cartes, alimentées toutes deux par l'extérieur, plus des câbles USB en place.
Code émetteur :
Code récepteur :
Les codes ont été adaptés pour coller au matériel : pin 10 pour le SPI, interruption CAN sur la pin 3 pour la lecture et vitesse réduite à 125K... Mais rien n'y fait. Une idée ?
J'ai connecté par un câble RJ11 droit (vérifié, au cas où...) les prises côté Nano de chacune des cartes, alimentées toutes deux par l'extérieur, plus des câbles USB en place.
Code émetteur :
Code: [Sélectionner]
// demo: CAN-BUS Shield, send data
#include <mcp_can.h>
#include <SPI.h>
// the cs pin of the version after v1.1 is default to D9
// v0.9b and v1.0 is default D10
const int SPI_CS_PIN = 10;
MCP_CAN CAN(SPI_CS_PIN); // Set CS pin
void setup()
{
Serial.begin(115200);
while (CAN_OK != CAN.begin(CAN_125KBPS)) // init can bus : baudrate = 500k
{
Serial.println("CAN BUS Shield init fail");
Serial.println(" Init CAN BUS Shield again");
delay(100);
}
Serial.println("CAN BUS Shield init 125K ok!");
}
unsigned char stmp[8] = {0, 1, 2, 3, 4, 5, 6, 7};
void loop()
{
// send data: id = 0x00, standrad frame, data len = 8, stmp: data buf
Serial.println("send data!");
CAN.sendMsgBuf(0x00, 0, 8, stmp);
delay(1000); // send data per 100ms
}Code récepteur :
Code: [Sélectionner]
// demo: CAN-BUS Shield, receive data with interrupt mode
// when in interrupt mode, the data coming can't be too fast, must >20ms, or else you can use check mode
// loovee, 2014-6-13
#include <SPI.h>
#include "mcp_can.h"
// the cs pin of the version after v1.1 is default to D9
// v0.9b and v1.0 is default D10
const int SPI_CS_PIN = 10;
MCP_CAN CAN(SPI_CS_PIN); // Set CS pin
unsigned char flagRecv = 0;
unsigned char len = 0;
unsigned char buf[8];
char str[20];
void setup()
{
Serial.begin(115200);
while (CAN_OK != CAN.begin(CAN_125KBPS)) // init can bus : baudrate = 500k
{
Serial.println("CAN BUS Shield init fail");
Serial.println(" Init CAN BUS Shield again");
delay(100);
}
Serial.println("CAN BUS Shield init ok!");
attachInterrupt(digitalPinToInterrupt(3), MCP2515_ISR, FALLING); // start interrupt
}
void MCP2515_ISR()
{
Serial.println("Exception raised");
flagRecv = 1;
}
void loop()
{
if(flagRecv)
{ // check if get data
flagRecv = 0; // clear flag
// iterate over all pending messages
// If either the bus is saturated or the MCU is busy,
// both RX buffers may be in use and reading a single
// message does not clear the IRQ conditon.
while (CAN_MSGAVAIL == CAN.checkReceive())
{
// read data, len: data length, buf: data buf
CAN.readMsgBuf(&len, buf);
// print the data
for(int i = 0; i<len; i++)
{
Serial.print(buf[i]);Serial.print("\t");
}
Serial.println();
}
}
}
Les codes ont été adaptés pour coller au matériel : pin 10 pour le SPI, interruption CAN sur la pin 3 pour la lecture et vitesse réduite à 125K... Mais rien n'y fait. Une idée ?
559
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: avril 21, 2016, 10:04:19 am »
Merci à tous. Avec le programme de Dominique ça marche. C'est sans doute le numéro de broche SPI que j'avais laissé à 9, sa valeur par défaut dans l'exemple de la biblio... J'y ai repensé dans la nuit, et je pensais bien que c'était ça.
Et effectivement, ça marche aussi pour moi avec seulement l'USB branché... Cela pose t-il un problème d'avoir à la fois l'alimentation extérieure via K1 et un câble USB branché ? Parce que pour vérifier ce qui passe avec la liaison série, c'est quand même plus pratique...
Et effectivement, ça marche aussi pour moi avec seulement l'USB branché... Cela pose t-il un problème d'avoir à la fois l'alimentation extérieure via K1 et un câble USB branché ? Parce que pour vérifier ce qui passe avec la liaison série, c'est quand même plus pratique...
560
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: avril 20, 2016, 08:37:55 pm »
Bon, je continue mes tests... Lorsque je tente d'initialiser le bus Can, rien ne bouge :
void setup()
{
Serial.begin(115200);
while (CAN_OK != CAN.begin(CAN_500KBPS)) // init can bus : baudrate = 500k
{
Serial.println("CAN BUS Shield init fail");
Serial.println(" Init CAN BUS Shield again");
delay(100);
}
Serial.println("CAN BUS Shield init ok!");
}
Le while n'est jamais validé, ni en alim USB, ni en alim externe ! Y aurait-il quelque chose à faire que j'ai oublié du côté matériel, ou un test simple à mettre en oeuvre ? Et dans la même veine, il a deux prises RJ11, a quoi elles correspondent, et est ce que le terminateur est nécessaire ?
void setup()
{
Serial.begin(115200);
while (CAN_OK != CAN.begin(CAN_500KBPS)) // init can bus : baudrate = 500k
{
Serial.println("CAN BUS Shield init fail");
Serial.println(" Init CAN BUS Shield again");
delay(100);
}
Serial.println("CAN BUS Shield init ok!");
}
Le while n'est jamais validé, ni en alim USB, ni en alim externe ! Y aurait-il quelque chose à faire que j'ai oublié du côté matériel, ou un test simple à mettre en oeuvre ? Et dans la même veine, il a deux prises RJ11, a quoi elles correspondent, et est ce que le terminateur est nécessaire ?
561
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: avril 19, 2016, 09:59:12 pm »
Nouvelle question. Si je veux relier deux cartes servos pour faire des essais sur le bus CAN, il faut un cable RJ11 droit ou croisé ?
562
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: avril 17, 2016, 04:42:05 pm »
Oui, il y a pas urgence, c'est juste que je me pose les questions du béotien qui va découvrir la carte... Je viens de tester avec deux servos et une alim externe, ça roule. Yapluka...
563
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: avril 17, 2016, 02:00:41 pm »
Voilà, c'est tout soudé. Après ce marathon de soudure (trois cartes Can, deux cartes Servos, trois Nanos...), je me pose plusieurs questions:
D'abord sur la carte servo :
1) Dans quel sens mettre le Nano ? Je n'ai pas vu de renseignement sur la sérigraphie... J'ai dû me référer à la photo prise en page 4.
2) Quel est le brochage des servos ? Les miens sont, comme beaucoup je crois, livré avec un connecteur trois broches, pas cinq !
Enfin, et de manière plus générale, ne serait-il pas souhaitable d'avoir une section dédiée sur le site Locoduino pour les cartes maison, avec les docs, les listes de composants, les fichiers pour lancer une fabrication, des tutoriaux de montage et/ou une doc d'utilisation ?
D'abord sur la carte servo :
1) Dans quel sens mettre le Nano ? Je n'ai pas vu de renseignement sur la sérigraphie... J'ai dû me référer à la photo prise en page 4.
2) Quel est le brochage des servos ? Les miens sont, comme beaucoup je crois, livré avec un connecteur trois broches, pas cinq !
Enfin, et de manière plus générale, ne serait-il pas souhaitable d'avoir une section dédiée sur le site Locoduino pour les cartes maison, avec les docs, les listes de composants, les fichiers pour lancer une fabrication, des tutoriaux de montage et/ou une doc d'utilisation ?
564
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: avril 16, 2016, 04:34:42 pm »
Ok, c'est soudé sans -trop- de difficultés... Autre question, est-ce que je dois mettre ou pas la Zener livrée (C10PH), en fin de compte ?
565
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: avril 16, 2016, 03:48:51 pm »
Ok, je tente la soudure... Merci.
566
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: avril 16, 2016, 03:21:17 pm »
Non, la question c'est pas sur la soudure, mais bien dans quel sens je dois placer le boitier !
567
Shields et Modules / Re : Carte Servomoteurs DCC + CAN
« le: avril 16, 2016, 03:06:06 pm »
Je m’apprête à assembler la carte, et qu'est ce que je m'aperçois-je ? Des composants CMS ! Jamais soudé ça, mais on va tenter le coup... Avant de m'y mettre je tente un placement manuel des tout petits composants, et je m'aperçois aussi que je ne sais pas dans quel sens mettre RC1 ! Pas moyen de trouver de la doc sur la symbolique inscrite sur la carte pour savoir de quel côté mettre le flanc biseauté du boitier...
Un peu d'aide ?
Un peu d'aide ?
568
Bibliothèques / Stocker des données en mémoire Flash !
« le: avril 12, 2016, 08:48:29 am »
En surfant sur le nouveau site http://create.arduino.cc , je suis tombé sur une bibliothèque qui pourrait rendre de grands services lorsque l'EEPROM est trop petite ou déjà hors service.
D'après le pitch https://github.com/cmaglie/FlashStorage serait capable d'écrire dans la zone programme, la mémoire flash ! D'après le source, une zone mémoire est réservée par le programme via une déclaration de variable, et ensuite le programme va lire et écrire dans cette zone. L'inconvénient est la perte des données lorsque le programme est à nouveau uploadé, mais sinon le principe est des plus intéressants, surtout pour les petites bêtes bien pourvues en mémoire flash, comme le Mega...
D'après le pitch https://github.com/cmaglie/FlashStorage serait capable d'écrire dans la zone programme, la mémoire flash ! D'après le source, une zone mémoire est réservée par le programme via une déclaration de variable, et ensuite le programme va lire et écrire dans cette zone. L'inconvénient est la perte des données lorsque le programme est à nouveau uploadé, mais sinon le principe est des plus intéressants, surtout pour les petites bêtes bien pourvues en mémoire flash, comme le Mega...
569
Bibliothèques / Re : Tuto d'utilisation de Git
« le: mars 29, 2016, 02:05:33 pm »
Après réflexion, peut être qu'il y a une autre cause... Profitons en pour continuer le tuto.
Tuto Partie 4 : Mise à jour du dépôt distant
Si vous avez utilisé le bouton 'Commiter' (et pas le 'Commiter & Pousser'), vous avez poussé vos modifications dans le dépôt local. Mais comment les envoyer ensuite vers le dépôt distant ?
A côté du bouton 'Commiter' dans la barre d'icônes du haut de la fenêtre principale, il y a une flèche bleue vers le bas qui permet de récupérer la version distante, puis une flèche vers le haut pour pousser le dépôt local vers le dépôt distant. C'est cette icône qui va nous aider.
Elle ouvre une fenêtre qui demande vers quelle branche de quel dépôt les modifications doivent être poussées. En général, il suffit de cliquer directement dur le bouton 'Pousser', et pouf, c'est parti !
Ici le dépôt distant s'appelle 'origin' (nom par défaut) et les branches s'appellent 'master' aussi bien sur le dépôt local que le distant.
Mais qu'est ce que c'est que ces branches dont Git parle tout le temps ?
Sommairement, une branche est une version différente du projet sous un nom particulier. A un moment donné, une branche est créée parce que le développement prend une direction parallèle et a besoin de tester des idées, tout en bénéficiant du service de stockage et d'historique de Git. A l'instant t, vous avez donc la branche principale, appelée par défaut 'master', et une ou plusieurs branches annexes. Votre dépôt local est la copie d'une branche particulière, généralement encore 'master', mais il est possible de cloner une autre branche du même dépôt distant dans un autre répertoire, et de travailler dedans sans risque de collision avec la branche principale. Lorsque vous le décidez, il est alors possible de fusionner les branches pour repartir sur seulement la branche principale.
Dans cette vision de ma dernière bibliothèque 'Commanders' dont l'article est en cours d'écriture, sur la fenêtre principale de Git Extension, on voit que depuis le commit 'initial' tout en bas, qui correspond à la création du projet, jusqu'à la version 0.50, les commits se sont succédés sans coup férir. Et puis une branche a été créée, à un moment où j'ai dû ré-écrire une grosse partie du noyau de la bibliothèque. Je voulais alors tester une hypothèse... Entre temps, la version 0.60 est née suite à d'autres corrections sur la branche principale 'master', puis la branche 'serial' a été fermée et fusionnée avec la branche principale qui a repris sa petite vie...
Tuto Partie 4 : Mise à jour du dépôt distant
Si vous avez utilisé le bouton 'Commiter' (et pas le 'Commiter & Pousser'), vous avez poussé vos modifications dans le dépôt local. Mais comment les envoyer ensuite vers le dépôt distant ?
A côté du bouton 'Commiter' dans la barre d'icônes du haut de la fenêtre principale, il y a une flèche bleue vers le bas qui permet de récupérer la version distante, puis une flèche vers le haut pour pousser le dépôt local vers le dépôt distant. C'est cette icône qui va nous aider.
Elle ouvre une fenêtre qui demande vers quelle branche de quel dépôt les modifications doivent être poussées. En général, il suffit de cliquer directement dur le bouton 'Pousser', et pouf, c'est parti !
Ici le dépôt distant s'appelle 'origin' (nom par défaut) et les branches s'appellent 'master' aussi bien sur le dépôt local que le distant.
Mais qu'est ce que c'est que ces branches dont Git parle tout le temps ?
Sommairement, une branche est une version différente du projet sous un nom particulier. A un moment donné, une branche est créée parce que le développement prend une direction parallèle et a besoin de tester des idées, tout en bénéficiant du service de stockage et d'historique de Git. A l'instant t, vous avez donc la branche principale, appelée par défaut 'master', et une ou plusieurs branches annexes. Votre dépôt local est la copie d'une branche particulière, généralement encore 'master', mais il est possible de cloner une autre branche du même dépôt distant dans un autre répertoire, et de travailler dedans sans risque de collision avec la branche principale. Lorsque vous le décidez, il est alors possible de fusionner les branches pour repartir sur seulement la branche principale.
Dans cette vision de ma dernière bibliothèque 'Commanders' dont l'article est en cours d'écriture, sur la fenêtre principale de Git Extension, on voit que depuis le commit 'initial' tout en bas, qui correspond à la création du projet, jusqu'à la version 0.50, les commits se sont succédés sans coup férir. Et puis une branche a été créée, à un moment où j'ai dû ré-écrire une grosse partie du noyau de la bibliothèque. Je voulais alors tester une hypothèse... Entre temps, la version 0.60 est née suite à d'autres corrections sur la branche principale 'master', puis la branche 'serial' a été fermée et fusionnée avec la branche principale qui a repris sa petite vie...
570
Bibliothèques / Re : Tuto d'utilisation de Git
« le: mars 28, 2016, 03:54:55 pm »
Regardes un peu mieux sur Framasoft, y compris en faisant des rafraichissements de la page. L'envoi est rapide (quoique...) mais le rafraichissement par Framasoft par forcément.
Ce que je comprend de ta fenêtre vide, c'est que tout est déjà parti et qu'il n'y a plus de différence !
Ce que je comprend de ta fenêtre vide, c'est que tout est déjà parti et qu'il n'y a plus de différence !