Salut à tous
Un petit cadeau de Noël pour les frapadingues de montages alimentés par batterie :
Cette petite carte permet de tester un montage en remplaçant vos batteries préférées pour faire varier leur tension au doigt et à l’œil.
Bonnes LI-IONs et LIPOs
Fidèle à toi même. 
On peux, pour simplifier le circuit, utiliser un potentiomètre multi-tours accouplé avec son pommeau.
Oui, c'était ma première idée ;D
Pour ceux qui seraient intéressés par l'exécution de commandes envoyées par un PC à un ARDUINO par la ligne série, j'ai écrit un script PYTHON pour tester cette carte :
import unittest
import time
import serial
class Test(unittest.TestCase):
def sendReply(self, request):
global ser
ser.write(request+'\r\n')
answer = ser.read_until('\n')
print answer,
return answer.strip('\r\n')
def setUp(self):
pass
def tearDown(self):
pass
def test_power(self):
print 'setting voltage to 3V'
answer = self.sendReply('VOUT=3')
voltage = float(answer)
self.assertTrue(voltage > 2.97 and voltage < 3.03)
print 'setting voltage to 3.7V'
answer = self.sendReply('VOUT=3.7')
voltage = float(answer)
self.assertTrue(voltage > 3.67 and voltage < 3.73)
print 'setting voltage to 4.2V'
answer = self.sendReply('VOUT=4.2')
voltage = float(answer)
self.assertTrue(voltage > 4.17 and voltage < 4.23)
def test_GPIO(self):
print 'setting GPIO9 to OUTPUT'
answer = self.sendReply('OUT 9')
self.assertEqual(answer, 'OK')
print 'setting GPIO9 to 1'
answer = self.sendReply('SET 9')
self.assertEqual(answer, 'OK')
print 'getting GPIO9'
answer = self.sendReply('GET 9')
self.assertEqual(answer, '1')
print 'setting GPIO9 to 0'
answer = self.sendReply('RESET 9')
self.assertEqual(answer, 'OK')
print 'getting GPIO9'
answer = self.sendReply('GET 9')
self.assertEqual(answer, '0')
def test_ANALOG(self):
print 'setting voltage to 3.7V'
answer = self.sendReply('VOUT=3.7')
voltage = float(answer)
self.assertTrue(voltage > 3.67 and voltage < 3.73)
print 'reading ANALOG1'
answer = self.sendReply('READ 1')
voltage = float(answer)
self.assertTrue(voltage > 3.6 and voltage < 3.8)
print 'reading ANALOG2'
answer = self.sendReply('READ 2')
voltage = float(answer)
self.assertTrue(voltage > 3.6 and voltage < 3.8)
print 'reading ANALOG3'
answer = self.sendReply('READ 4')
voltage = float(answer)
self.assertTrue(voltage > 3.6 and voltage < 3.8)
print 'reading ANALOG4'
answer = self.sendReply('READ 5')
voltage = float(answer)
self.assertTrue(voltage > 3.6 and voltage < 3.8)
print 'reading ANALOG5'
answer = self.sendReply('READ 5')
voltage = float(answer)
self.assertTrue(voltage > 3.6 and voltage < 3.8)
print 'reading ANALOG6'
answer = self.sendReply('READ 6')
voltage = float(answer)
self.assertTrue(voltage > 3.6 and voltage < 3.8)
if __name__ == "__main__":
global ser
ser = serial.Serial('/dev/ttyUSB1', baudrate=115200)
ser.timeout = 3
time.sleep(1)
ser.read_until('\n') # read boot message
unittest.main()
Les modules unittest et pyserial sont nécessaires.
'/dev/ttyUSB1' peut être remplacé par 'COMX' sur une machine Windows.
Le résultat :
riton@alpha:/mnt/sdc1/riton/projects/3.7v-power-supply/test$ python test.py
setting voltage to 3.7V
3.70
reading ANALOG1
3.69
reading ANALOG2
3.64
reading ANALOG3
3.67
reading ANALOG4
3.67
reading ANALOG5
3.67
reading ANALOG6
3.71
.setting GPIO9 to OUTPUT
OK
setting GPIO9 to 1
OK
getting GPIO9
1
setting GPIO9 to 0
OK
getting GPIO9
0
.setting voltage to 3V
3.01
setting voltage to 3.7V
3.69
setting voltage to 4.2V
4.21
.
----------------------------------------------------------------------
Ran 3 tests in 2.130s
OK
riton@alpha:/mnt/sdc1/riton/projects/3.7v-power-supply/test$
La fonction commandShell qui reçoit les commandes côté ARDUINO se trouve ici :
3.7v-power-supply.ino
Hello Henri
Comment tu trouves le temps de faire tout ça? 
La retraite ...
hbachetti:
La retraite ...
Et c'est ... une bonne réponse ! 
Sympa la réalisation avec le DAC
Merci Artouste.
hbachetti:
Merci Artouste.
Je pose la question ici , plutot que sur ton blog
tu évoque des difficultés/impossibilité d'utiliser ton encoder "asia" avec la lib encoder de PaulStoffregen
c'etait quoi les symptomes ?
perso c'est une lib que j'utilise depuis des années avec toutes sorte d'encoder A/B, du plus cheap (genre asia) au plus sophistiqué sans soucis.
Okazou , ce n'est pas du à une de ses qualité (qui n'est pas un défaut 8) ) mais qui selon config renvoi 4 états distincts par "click de detente complet" ?
Okazou
Oui, j'ai déjà vu ça.
Je viens de refaire un essai avec une NANO.
Avec un vrai Bourns PEC11R :
La librairie PaulStoffregen produit 2 événements par click.
La librairie BrianLow produit 0 ou 1 événement par click.
Avec un encodeur chinois :
La librairie de PaulStoffregen produit 4 événements par click, quelques fois 6.
La librairie BrianLow produit 1 événement par click mais c'est très lent.
C'est assez inconstant et difficile à gérer.
Mais mon code, qui marche bien avec un encodeur chinois, loupe des clicks avec un vrai Bourns 
Je me suis inspiré de ceci : Improved-Arduino-Rotary-Encoder-Reading
Existe t-il une solution universelle ? ? ?
hbachetti:
Oui, j'ai déjà vu ça.Je viens de refaire un essai avec une NANO.
Avec un vrai Bourns PEC11R :
La librairie PaulStoffregen produit 2 événements par click.
La librairie BrianLow produit 0 ou 1 événement par click.
Avec un encodeur chinois :
La librairie de PaulStoffregen produit 4 événements par click, quelques fois 6.
La librairie BrianLow produit 1 événement par click mais c'est très lent.
C'est assez inconstant et difficile à gérer.
C'est un... peu un probleme de debounce
la lib travaille selon config soit en double interrupt, soit en interrupt simple, soit en polling
Avec la qualité toute relative des encodeurs cheap en encodeur D'IHM : qq detentes par tours = 1 detente = 4 etats distincts relevables , je passe la config en "polling"
Pas besoin de sortir "l'artillerie" lourde des interrupts ;D comme par exemple avec des encodeurs de suivi de motorisation ( RPM élevé)
NB : je ne connais pas l'autre lib 
C'est un... peu un probleme de debounce
Je ne suis pas sûr.
A partir du moment où la pin A a été vue, il n'y a aucune raison de la prendre en compte une deuxième fois avant de voir la pin B.
Je pense plutôt a un bug mais son code en assembleur me donne la migraine.
Le polling n'est pas toujours possible, tout dépend de ce que l'on a à faire par ailleurs.
C'est dommage car j'aime bien l'interface de la librairie de PaulStoffregen.
Je l'ai d'ailleurs adoptée pour mon propre code, avec une notion supplémentaire : le click peut avoir une valeur X, c'est à dire incrémenter ou décrémenter la position de 5, 10 points ou 100 points pour 1 click.
hbachetti:
Je ne suis pas sûr.
A partir du moment où la pin A a été vue, il n'y a aucune raison de la prendre en compte une deuxième fois avant de voir la pin B.
Je pense plutôt a un bug mais son code en assembleur me donne la migraine.Le polling n'est pas toujours possible, tout dépend de ce que l'on a à faire par ailleurs.
C'est dommage car j'aime bien l'interface de la librairie de PaulStoffregen.
Je l'ai d'ailleurs adoptée pour mon propre code, avec une notion supplémentaire : le click peut avoir une valeur X, c'est à dire incrémenter ou décrémenter la position de 5, 10 points ou 100 points pour 1 click.
Bonjour Henri
Oui , elle est qqfois assez pointue , mais quand même bien "foutue"
J'ai un code trés minimal (pas de lib) utilisé pour gérer plusieurs "encodeurs asia cheap 24 clicks " en polling pour faire de l'interface MIDI , j'ai testé de mémoire jusqu'à 5 A/B sur une base 328P, je me souviens que j'avais aussi fais un test de stress de vitesse sur les encodeurs avec une simple "perceuse/vicieuse" 8)
Je n'ai pas le code sous la main ce WE, je le mettrais ASAP
Ne pas oublier aussi qu'en polling de A/B , le temps de boucle est un paramètre trés "sensible" pour les actualisation
Mon code marche très bien, pas de problème.
J'utilise les interruptions.
Je voulais dire simplement que gérer les rebonds ne sert à rien.
A partie du moment où on a vu A, il suffit de s'en souvenir et d'ignorer les fronts suivants sur A, en attendant qu'un front sur B arrive, et vice-versa.