Je sais pas ya un soucis avec les nano chinois en ce moment, mais ça fais 2 commandes que je reçois, et qu’il est brické à chaque fois => impossible de les faire causer avec l’IDE… (aucun soucis avec les mega…)
Ca a été rapide, trop cool que ce soit une boîte française qui vende ça !
Une petite photo avec de gauche à droite :
- DevKit32 BSFrance.fr
- ESPio 32 BSFrance.fr
- Adafruit Feather 32u4 BLE
- Arduino nano 328 (copie chinoise)
Génial ! Est-ce que tu arriverais à tester les pins ADC (bruit / précision) de l’ESPio et du Devkit ? En général c’est mieux d’avoir une amplification séparée mais si l’ampli intégré est suffisamment précis je pourrai essayer de brancher directement mes capteurs dessus au lieu de passer par un HX711. Le HX est 24-bit et celui embarqué 12 bit je crois mais si ça peut suffire, pourquoi pas?
Tu as vraiment besoin d’une grande précision ?
24-bit c’est énorme !!
J’avoue que je me sers pas trop des analog input, et je vois pas trop comment faire les tests que tu me demandes.
(eh oui, je suis pas aussi calé que tu le penses :mrgreen: )
Sinon je me penche un peu sur les pins déjà équipés pour du touch capacitif.
Je pourrais créer un bouton invisible sur le boitier de la PirCac. 
De ce que je comprends de la différence entre 12 et 24 bit au niveau des pins ADC, dans le premier cas j’aurai une précision de l’ordre de 0.105v et le second une précision de l’ordre de 0.052v ; encore que la ESP tourne en 3.3v donc ce serait plutôt du 0.07V en 12 bit et 0.034v en 24 bit ?
Je n’ai pas encore mesuré la réactivité et la précision du signal de mes capteurs en “lecture” par rapport à la déformation que je vais exercer dessus donc je suis pas sûr encore de mon besoin en précision 
je peux déjà commencer avec ça quitte à rajouter des HX711 sur le branchement plus tard!
Edit : En gros pour pouvoir mesurer le bruit / précision, admettons qu’il y ait une pression constante appliquée sur le capteur, normalement la mesure devrait rester précise vu que ça s’update en continu ; si déjà pour la même mesure il y a une différence trop conséquente (ex ± 0.2v) c’est qu’il y a du bruit qui parasite le signal ; si ça dérive au lieu de rester constant, c’est également qu’il y a du bruit parasite.
Ma première étape c’est d’aboutir à un signal réactif et progressif, comme pour la course du trigger sur une radiocommande. Je vais charger le firmware d’Ackmaniac pour essayer le “Watt control” donc il faut que j’ai une course de 100% (et je dois aussi prévoir la course des freins)… je vais acheter un vrai casque je crois haha après il me semble qu’il y a aussi des pins dédiés pour les accéléro/gyro sur la PCB?
Tu veux faire un bouton capacitif ? Je suis toujours intrigué par le fonctionnement de ce type de bouton, c’est un peu du tactile mais sans écran ! C’est le même principe que sur les balances ou les plaques à induction non ? Est-ce que c’est le contact avec un type de matériau donné, la secousse ou la température qui déclenche le capteur ?
C’est exactement la même chose que nos écrans de smartphone… mais sans l’écran en dessous 
Voilà ce que dit Wikipedia :
Dans les systèmes capacitifs3, une couche qui accumule les charges, à base d’indium, métal de plus en plus rare, est placée sur la plaque de verre du moniteur. Lorsque l’utilisateur touche la plaque avec son doigt, certaines de ces charges lui sont transférées. Les charges qui quittent la plaque capacitive créent un déficit quantifiable. Avec un capteur dans chacun des coins de la plaque, il est possible en tout temps de mesurer et de déterminer les coordonnées du point de contact. Le traitement de cette information demeure le même que pour les circuits résistifs.
Un avantage majeur des systèmes capacitifs, par rapport aux résistifs, est leur capacité à laisser passer la lumière avec un meilleur rendement. En effet, jusqu’à 90 % de la lumière traversera une surface capacitive par rapport à un maximum de 75 % pour les systèmes résistifs, ce qui donne une clarté d’image supérieure pour les systèmes capacitifs.
Malheureusement ces systèmes ne sont pas facilement extensibles aux écrans plus grands qu’une vingtaine de pouces. Ils sont par contre très compétitifs aux petites tailles et on les retrouve ainsi dans de nombreux smartphones et tablettes de milieu et haut de gamme, plus rarement dans le bas de gamme.
Un sujet Instructables plutôt complet : http://www.instructables.com/id/How-To- … h-Arduino/
J’y avais pas pens’'e au départ mais comme les pins sont déjà équipés sur l’ESPio, autant en profiter !
Juste 2 fils en plus à mettre
Merci pour l’explication ! Ça a l’air carrément fun, je trouvais pas d’interrupteur à mon goût (problème de compacité etc) ça m’intéresse !
Il y a moyen de faire soit un interrupteur invisible soit un anti-spark switch ultra plat avec ça (en fait les deux ne sont pas incompatibles, invisible et antispark en même temps )
Mais genre … sur un boitier full closed carbone par exemple, je pourrais avoir un on-off derrière :idea: ?!
:ugeek:
comme si 
ça avec le doigt !? :shock:
Vazy Pimousse, allez y les gars :mrgreen: je veux voir ça !!!
Pour un antispark, je vois plusieurs points négatifs :
- Il faut un Arduino pour gérer ce touch et piloter ensuite un relais pour l’antispark (car il faut un NC et NO).
- Le capactif c’est pas super super fiable donc si quelque chose venait frotter la partie en question, ça te couperait d’un coup ton système
@Riako, La deuxième photo c’est un RFID. Avec un Arduino ça peut le faire aussi, mais c’est plus la même techno (mais le principe est cool et ça fait clé anti-démarrage :mrgreen: ).
Le capacitif, dans la vie de tous les jours, c’est ce genre d’objet (lampe tactile) :
Mais on en trouve partout (tous les écrans tactiles, boutons tactiles sur les tableaux de bord de voiture…).
Et oui, il est possible de faire une “zone” sur ton boitier full closed qui serve d’interrupteur.
Mais là encore on rejoint les 2 points soulignés avant.
Et en augmentant le temps de contact nécessaire ?
C’est vrai qu’un contact “instantané” comme sur la lampe que tu as montré c’est dangereux mais si on “exige” au niveau de l’arduino un délai de contact d’au moins 2 secondes ça filtrerait déjà les frottements accidentels des contacts prolongés. Ça reste encore un délai d’allumage acceptable durant lequel l’arduino peut lancer l’ordre de “précharger” l’ESC
Tout-à-fait !
Reste que l’Arduino doit rester allumer en permanence pour gérer cet allumage ?
Qui allume l’Arduino ?
Le serpent se mord la queue
ha yes … ben ils font comment sur la stary alors !?..
J’aime plus l’idée de la p’tite carte (plus safe) incrusté dans le manche de la remote ! Et comme eux quand t’allume la telco ça déclenche le système une fois poser 2 seconde sur le top de ma trappe par exemple … ?
enfin c’est beau de rêver :mrgreen: de toute façon je change de deck !..
Après avec un microcontrôleur qui entre hibernation, ça doit pouvoir se faire (consomme toujours un peu mais vraiment pas grand chose).
Rien d’impossible à faire au final.
Vedder avait commencé à regarder pour faire un mode de très faible consommation avec le VESC quand tu arrivais au cutoff end.
Mais ça n’avait pas été plus loin.
@Vanarian : je galère un peu pas mal avec l’ESP32.
Disons que c’est bien plus complet qu’un Arduino et permet de faire beaucoup plus de choses, MAIS il faut mettre bien plus les mains dans le cambouis.
Par exemple, sur Arduino Mega, pour utiliser le 2e serial, tu câbles sur le port dédié et tu fais
Serial1.begin(9600)
Sur l’ESP32, presque tous les pins peuvent être utilisés pour faire un des 3 ports UART.
Sauf qu’il faut le déclarer au préalable. Rien de compliqué.
SAUF que ma librairie VESCUart utilise ce Serial1 donc il faut le déclarer en publique, et là mes connaissances en C++ sont limitées…
J’ai passé des heures à essayer plusieurs emplacements dans le code, impossible.
Ah mince, attends je regarde si j’arrive à te trouver une solution. Je suis également débutant donc peut-être que ce que je vais te proposer c’est déjà une évidence pour toi ^^"
Dans un premier temps, as-tu essayé de câbler sur les ports TX0 / RX0 qui correspondent au Serial1 par défaut de l’ESP32?
Je prends l’exemple d’un shield HydraBUS raccordé à l’ESP : https://hydrabus.com/2016/10/22/hydraes … ith-esp32/
Il est câblé sur les pins RX0 et TX0 ; si tu regardes le code (il y a une vidéo) pour le connecter il appelle « sudo » etc => il rentre le password du Hydra puis il a le menu des commandes qui s’affiche après ; la connexion devrait être faite, si tu entres « uart » dans l’invite de commande avec la vitesse du baudrate tu devrais avoir la connexion établie pour utiliser ta librairie VESCUart non ?
Ça ne résout pas le problème de déterminer n’importe quel pin en Serial1 mais ça pourrait te permettre d’utiliser tout de suite le pin par défaut en Serial 1 en attendant qu’on trouve la solution 
Edit :
Tiens je viens aussi de trouver ça @a2retro You can attach all 3 UARTs to any pins you like (almost). Pins 9 and 10 are tied to your flash chip, so I would not use them for Serial. You can check esp32-hal-uart.h if you want C style api to the serial or just use HardwareSerial Serial1(1); and then Serial1.begin(baudrate, SERIAL_8N1, rxPin, txPin); to start and use it like any other Arduino Serial
Je ne sais pas si tu as déjà essayé la fonction HardwareSerial Serial1 ?
Edit² : pinMode(9,FUNCTION_4) # U1RXD
pinMode(10,FUNCTION_4) # U1TXD N’utilise pas les pins 9 et 10 de préférence, mais normalement cette fonction en choisissant les GPIO qui t’intéressent (ex: 13 et 14) devrait définir aussi les pins correspondants en serial par défaut pour utiliser rxPin et txPin.
Pour les deux citations, tu as la page complète ici : « https://www.esp32.com/viewtopic.php?t=303 »
Là tu as un exemple où un chip GPS est relié en serial sur les pins sélectionnés en UART1 ; l’auteur du post a un autre souci mais la connexion est bien établie : https://github.com/espressif/arduino-esp32/issues/437
Edit 3 : Tiens tu as un exemple de référence serial1 et serial2 en librairie externe ici : https://github.com/espressif/arduino-esp32/issues/407 en utilisant la fonction HardwareSerial
Ouai j’ai trouvé et me suis inspiré des liens que tu donnes.
Si je fais HardwareSerial puis Serial1.begin(…) dans un sketch vide ça compile.
Le soucis c’est pour déclarer HardwareSerial publique pour que mon main ET ma librairie puisse l’utiliser.
Je n’y arrive pas, il me dit que c’est pas déclarer dans mon scope librairie.
J’ai essayé en mettant “extern” devant pour le rendre publique : marche pas mieux…
Je n’utilise pas le RX0 et TX0 car ils sont communs avec l’USB (comme l’Arduino) et je m’en sers comme console de débogage. J’utilise 16 et 17 pour le Serial1 (prévu comme ça par défaut dans la librairie même si on peut personnalisé et prendre presque tous les pins).
Développeur C++ depuis un peu plus de 15 ans, si je peux aider, n’hésitez pas
Par contre, je ne comprends pas trop le pb d’après les infos données là. Je regarderai ça sur ordi à la maison.
Alleluia !!!
Je peux uploader le code sur Github ou Arduino Create si tu veux. 
@Vanarian, j’ai pas fait gaffe à ton EDIT 3 ! Très intéressant, je vais regarder ça de plus près.
Merci !!
EDIT : CA COMPIIIIIIIIIILE !!!
Merci mille fois Vanarian, il suffisait que je fasse un “extern HardwareSerial Serial1” dans le HardwareSerial.h
Pour l’instant j’en suis qu’au portage du programme qui tourne sur le Nano.
Ensuite j’investiguerai sur le BT, Wifi, Touch etc.
De ce que je comprends de la différence entre 12 et 24 bit au niveau des pins ADC, dans le premier cas j’aurai une précision de l’ordre de 0.105v et le second une précision de l’ordre de 0.052v ; encore que la ESP tourne en 3.3v donc ce serait plutôt du 0.07V en 12 bit et 0.034v en 24 bit ?
Je n’ai pas encore mesuré la réactivité et la précision du signal de mes capteurs en “lecture” par rapport à la déformation que je vais exercer dessus donc je suis pas sûr encore de mon besoin en précision je peux déjà commencer avec ça quitte à rajouter des HX711 sur le branchement plus tard!
Edit : En gros pour pouvoir mesurer le bruit / précision, admettons qu’il y ait une pression constante appliquée sur le capteur, normalement la mesure devrait rester précise vu que ça s’update en continu ; si déjà pour la même mesure il y a une différence trop conséquente (ex ± 0.2v) c’est qu’il y a du bruit qui parasite le signal ; si ça dérive au lieu de rester constant, c’est également qu’il y a du bruit parasite.
Ma première étape c’est d’aboutir à un signal réactif et progressif, comme pour la course du trigger sur une radiocommande. Je vais charger le firmware d’Ackmaniac pour essayer le “Watt control” donc il faut que j’ai une course de 100% (et je dois aussi prévoir la course des freins)… je vais acheter un vrai casque je crois haha après il me semble qu’il y a aussi des pins dédiés pour les accéléro/gyro sur la PCB?
Tu veux faire un bouton capacitif ? Je suis toujours intrigué par le fonctionnement de ce type de bouton, c’est un peu du tactile mais sans écran ! C’est le même principe que sur les balances ou les plaques à induction non ? Est-ce que c’est le contact avec un type de matériau donné, la secousse ou la température qui déclenche le capteur ?
@Vanarian, pour ameliorer significativement le rapport S/bruit sur un système fluctuant , si tu possedes 2 capteurs identiques, tu connectes les 2, l un servant de ref et tu soustrais la valeur retournee à celle de ton capteur de mesure, ainsi les fluctuations (pour autant qu elles soient semblables) seront annulees et tu n auras “theoriquement” que le signal sans le bruit[emoji6]