[Projet] 10 Compteurs, un affichage du cumul.

[invite4aad5203]

Bonjour à tous,
Avant tout, merci à ceux qui vont prendre le temps de me lire. J'ai essayer de glaner des info par-ci par là, mais rien de probant pour mon projet.

En fait c'est pour le téléthon (pour la bonne cause), et le but, c'est de mettre à disposition des gens 10 vélos en libre service, et qu'on puisse lire le cumul de la distance parcourue sur un afficheur 7 segments (kilomètres ou mètres parcourus, à voir selon la faisabilité).
Ce dont je dispose à priori ce sont dix vélos et leurs support stable (comme des vélo de salle de sport), avec chacun un capteur à effet hall sur la roue arrière ("emprunté" à un compteur de vélo simple).

Ce que je pensait faire, c'est :
- soit d'utiliser un PIC. Dans ce cas j'ai deux "sous-solutions", l'une est d'utiliser 10 entrées, l'autre de tout mettre sur des portes logiques OU (ou faire un OU exclusif) afin d'avoir une seul entrée. Sauf que j'ai peur qu'avec la fréquence d'arrivé des signaux (10 vélos) ça ne passe pas.
- Soit de tout cabler en logique, sachant qu'il faut trouver une solution en local sur chaque capteur pour diviser le nombre d'impulsion (ce que je ne sais pas faire).

Je sais que ça pose pas mal de problèmes techniques, surtout à cause des "chevauchements" possibles, et de la fréquence des signaux (en cumul).

Budget : 100€ max à priori.

Vous pensez que je suis sur la bonne voie ? vous auriez une solution plus simple ? je suis preneur...

Amicalement, Gdmat.
-----

[gcortex]

j'ai peur que tu sois obligé de faire 10 compteurs avec pré-diviseur

pour les 7 segments :

4511 pour cathode commune
ou 4543 qui fait anode ou K commune
précédé d'un compteur 3 digits 4553

ou des 4033 qui comptent et décodent mais pour 1 seul digit

[invitef86a6203]

combien de digit sur le compteur ?

Je suppose qu'il y a qu'un seul compteur général ?

Personnellement je mettrais 2 pic genre Pic16F84 pour le compteur et un pic16F876 pour les capteurs
Un pour faire un compteur simple , l'autre pour faire la saisie.

Il faudrait connaitre le temps minimum de commutation du capteur

Admettons une roue de 700mm 0.7 x 3.14 =~2.2 m
20 km/h fait 20 000/3600 5.55m/s
5.55/2.2 =~ 2 impulsions par seconde soit 500ms
admettons que capteur est en contact sur 1cm
cela nous fait pour 700mm 1/ 700 du temps
soit 500ms /700 = 714 µs.

La boucle de "scrutage" (pooling) devra donc faire 700µs c'est a dire 700 instructions pour un quartz 4MHz et 3500 pour un quartz à 20 Mhz.

Ce qui est très réalisable.

On pourrait pour stabilisé mettre des Ne555 sur chaque entrée afin d'avoir un pulse plus long et bien calibré et bien net.


Pour la logique il faut compter qu'un seul type de front.
Il faudra donc faire une comparaison XOR avec la valeur inversée lu auparavant puis un OR pour masquer les fronts montant et enfin compter les 0 qui donne un changement d'état d'un front descendant.

exemple ;
Nous lisons un port de 8 bits
Il faudrait une partie d'un autre port ou un autre port complet pour faire 16 entrées par exemple.
Nous lisons 00000001 pour commencer puis 00000011 (10) puis 00000001
donc le bit 1 a basculé mais pas les autres
Je met 1 au départ pour ne pas avoir 0 , et le 1 du bit 0 reste à 1 pour l'exemple , il serait comptabilisé sur le front descendant , pour l'exemple je fais qu'un bit.

1) 00000001 => sauvegarde 00000001 XOR 11111111 => 11111110
--- 
---
2) 00000011 => sauvegarde 00000011 XOR 11111111 => 11111100
-------- 00000011  xor  11111110 = 11111101 
--------------------------------11111101 OR 00000011 = 11111111
00000001 => sauvegarde 00000001 XOR 11111111 => 11111110
----- 00000001  xor  11111100 = 11111101 
--------------------------------11111101 OR 00000001 = 11111101

Il ne reste plus qu'a compter les 0.

[invitef86a6203]

Encore cette limitation du temps de correction stupide....

bon je détail le début

0) la sauvegarde est initialisé à 0  donc inversé 11111111
--- initialisation

1) 00000001 => sauvegarde 00000001 XOR 11111111 => 11111110
-------- 00000001  xor  11111111 = 11111110 
--------------------------------11111110 OR 00000001 = 11111111
-------rien pas de 0

2) 00000011 => sauvegarde 00000011 XOR 11111111 => 11111100
-------- 00000011  xor  11111110 = 11111101 
--------------------------------11111101 OR 00000011 = 11111111
-------rien pas de 0

3) 00000001 => sauvegarde 00000001 XOR 11111111 => 11111110
----- 00000001  xor  11111100 = 11111101 
--------------------------------11111101 OR 00000001 = 11111101
xxx 1 seul 0

[A voir en vidéo sur Futura]

[abracadabra75]

Bonjour.
Tu es en très basse fréquence, avec 10 sources différentes.
Je verrais bien les 10 sources attaquant une porte logique OU (ce peut être un OU câblé) afin d' attaquer (sans le blesser) l' interruption de ton µC.
Celui-ci sait alors qu' une impulsion est arrivée. Chaque source etant branchée sur une entrée, il suffit alors de déterminer laquelle pour faire le comptage du nombre de tours de roue sur le bon compteur.
Le principe est simple. Yapuka faire l' ordinogramme du programme pour écrire le programme....
A+
Ps. la probabilité pour que 2 interruptions arrivent ensemble est calculable, mais me semble assez faible. Et comme la précision de ce genre de comptage n' est pas primordiale, on peut l' ignorer superbement!

Ps2. Freepic basic t' a donné la piste pour calculer cette probabilité.

[invitef86a6203]

résultat;
11111101 ce qui donne 1 seul 0

[invitef86a6203]

Ps2. Freepic basic t' a donné la piste pour calculer cette probabilité.

Il n'y a aucun risque d'erreur ou de collision avec mon algorithme , puisqu'on pool en parallèle les entrées.

Il suffit de déterminer le temps d'exécution qui donnera la vitesse maximum de fonctionnement.

[gcortex]

et un détecteur de parité ?

[invitef86a6203]

et un détecteur de parité ?

Développe ton idée, ça peut être intéressant.

[invite4aad5203]

Bonsoir,
Tout d'abord merci beaucoup de m'avoir lu (comme dit dans le premier message), et ensuite, comme vous pouvez vous en douter par la présence de cette discution, je ne suis pas très calé en éléctronique (ma formation, c'est la mécanique), j'ai juste quelques notions de base (je sais cabler du logique et programmer en C), donc difficile de suivre.
Je vais donc reprendre les points de chacuns, et poser des questions ou répondre aux votre histoire d'y voir clair.

combien de digit sur le compteur ?

Je suppose qu'il y a qu'un seul compteur général ?

Je ne pense pas qu'en deux jours on fasse plus de 10 000km, donc je dirais 4 digits. Et oui c'est un compteur général qui doit afficher le cumul de la distance parcourue par l'ensemble du parc de vélos.

Personnellement je mettrais 2 pic genre Pic16F84 pour le compteur et un pic16F876 pour les capteurs
Un pour faire un compteur simple , l'autre pour faire la saisie.

Si j'ai bien saisi, le premier recoit sur 10 entrées les signaux des capteurs, et renvoi le comptage du nombre d'impulsions reçu, et le second fera les calculs (principalement la division et l'affichage sur les 4 digits à 7 segments.

Il faudrait connaitre le temps minimum de commutation du capteur

Admettons une roue de 700mm 0.7 x 3.14 =~2.2 m
20 km/h fait 20 000/3600 5.55m/s
5.55/2.2 =~ 2 impulsions par seconde soit 500ms
admettons que capteur est en contact sur 1cm
cela nous fait pour 700mm 1/ 700 du temps
soit 500ms /700 = 714 µs.

La boucle de "scrutage" (pooling) devra donc faire 700µs c'est a dire 700 instructions pour un quartz 4MHz et 3500 pour un quartz à 20 Mhz.

Ce qui est très réalisable.

Ok bonne nouvelle. Un quartz, ça doit valoir dans les 10 €si je me trompe pas... On va parler budget plus loins.

On pourrait pour stabilisé mettre des Ne555 sur chaque entrée afin d'avoir un pulse plus long et bien calibré et bien net.

Ca je connais pas du tout, d'après les breves recherches que je viens de faire, ça coute rien du tout, et ça ressemble à de l'anti-rebond. Mais si ça rallonge le pulse, ça peut gener, non ?

Pour la logique il faut compter qu'un seul type de front.
Il faudra donc faire une comparaison XOR avec la valeur inversée lu auparavant puis un OR pour masquer les fronts montant et enfin compter les 0 qui donne un changement d'état d'un front descendant.

exemple ;
Nous lisons un port de 8 bits
Il faudrait une partie d'un autre port ou un autre port complet pour faire 16 entrées par exemple.
Nous lisons 00000001 pour commencer puis 00000011 (10) puis 00000001
donc le bit 1 a basculé mais pas les autres
Je met 1 au départ pour ne pas avoir 0 , et le 1 du bit 0 reste à 1 pour l'exemple , il serait comptabilisé sur le front descendant , pour l'exemple je fais qu'un bit.

1) 00000001 => sauvegarde 00000001 XOR 11111111 => 11111110
--- 
---
2) 00000011 => sauvegarde 00000011 XOR 11111111 => 11111100
-------- 00000011  xor  11111110 = 11111101 
--------------------------------11111101 OR 00000011 = 11111111
00000001 => sauvegarde 00000001 XOR 11111111 => 11111110
----- 00000001  xor  11111100 = 11111101 
--------------------------------11111101 OR 00000001 = 11111101

Il ne reste plus qu'a compter les 0.

Encore cette limitation du temps de correction stupide....

bon je détail le début

0) la sauvegarde est initialisé à 0  donc inversé 11111111
--- initialisation

1) 00000001 => sauvegarde 00000001 XOR 11111111 => 11111110
-------- 00000001  xor  11111111 = 11111110 
--------------------------------11111110 OR 00000001 = 11111111
-------rien pas de 0

2) 00000011 => sauvegarde 00000011 XOR 11111111 => 11111100
-------- 00000011  xor  11111110 = 11111101 
--------------------------------11111101 OR 00000011 = 11111111
-------rien pas de 0

3) 00000001 => sauvegarde 00000001 XOR 11111111 => 11111110
----- 00000001  xor  11111100 = 11111101 
--------------------------------11111101 OR 00000001 = 11111101
xxx 1 seul 0

Là j'avoue avoir eu du mal.
Pourquoi vouloir le front descendant ?
Un µC ne sait-il pas faire la différence entre un front montant et un desccendant ? mes souvenir de lycée me disent que si (mais ça remonte à loin).
Est-ce afin de ne pas surcharger les entrées du µC ?
Je me pencherais sur ce que tu as mis en CODE un tout petit peu plus tard, journée de boulot difficile...

Bonjour.
Tu es en très basse fréquence, avec 10 sources différentes.
Je verrais bien les 10 sources attaquant une porte logique OU (ce peut être un OU câblé) afin d' attaquer (sans le blesser) l' interruption de ton µC.

En effet je comptait mettre des OU pour limiter à une entrée

Celui-ci sait alors qu' une impulsion est arrivée. Chaque source etant branchée sur une entrée, il suffit alors de déterminer laquelle pour faire le comptage du nombre de tours de roue sur le bon compteur.

Heu, tu viens pas de dire à l'instant qu'on attaquait qu'une entrée du µC en rassemblant tout avec des OU ?
Pas besoin de savoir de quel vélo les impulsions viennent, il faut juste affiché le cumul distance des 10, et rien que ça (c'est déjà assez compliqué comme ça pour moi ).

Ps. la probabilité pour que 2 interruptions arrivent ensemble est calculable, mais me semble assez faible. Et comme la précision de ce genre de comptage n' est pas primordiale, on peut l' ignorer superbement!

Ps2. Freepic basic t' a donné la piste pour calculer cette probabilité.

Le fait que la proba soit faible me suffi bein largement oui, on ne sera pas à 50km près.

et un détecteur de parité ?

Ca j'ai rien trouvé dessus...
-------------------------------------------------------------------------

Pour conclure, vous me redonnez un peu de courage, car avec mes cours de SI de lycée, je ne serais arrivé à rien. Par contre il me faudra un tout petit peu d'aide pour le circuit électrique (notement pour l'intégration des PIC et des afficheurs).

Amicalement, Gdmat.

[invitef86a6203]

Je ne pense pas qu'en deux jours on fasse plus de 10 000km, donc je dirais 4 digits. Et oui c'est un compteur général qui doit afficher le cumul de la distance parcourue par l'ensemble du parc de vélos.

On doit trouver ça tout fait sur le net.

Si j'ai bien saisi, le premier recoit sur 10 entrées les signaux des capteurs, et renvoi le comptage du nombre d'impulsions reçu, et le second fera les calculs (principalement la division et l'affichage sur les 4 digits à 7 segments.

OK

Ok bonne nouvelle. Un quartz, ça doit valoir dans les 10 €si je me trompe pas... On va parler budget plus loins.

1€ =>
http://www.selectronic.fr/article.as...r=90.0837-9999

Ca je connais pas du tout, d'après les breves recherches que je viens de faire, ça coute rien du tout, et ça ressemble à de l'anti-rebond. Mais si ça rallonge le pulse, ça peut gener, non ?

2 tours par seconde à 20km/h ça fait 10 à 100km/h on peut mettre un créneau de 100ms à chaque impulsion. Comme un anti rebond effectivement.
ça gène pas ça permet de faire bien plus de chose entre 2 lectures.
à 20mhz 500 000 instructions , le luxe !

Pourquoi vouloir le front descendant ?
Un µC ne sait-il pas faire la différence entre un front montant et un desccendant ? mes souvenir de lycée me disent que si (mais ça remonte à loin).
Est-ce afin de ne pas surcharger les entrées du µC ?

Le µc a une interruption pour un seul fil par pour 10 ou 16 , on peut faire la différence pour cette interruption unique.
Dans notre cas on a besoin de 10 interruptions qu'on a pas , alors on lit périodiquement plus vite que le plus rapide des événements pour faire une image a un instant t , il suffit alors de comparer à la dernière lecture enregistré pour avoir les variations.
Un front descendant , bah il fallait bien choisir l'un ou l'autre...
dans le cas ou l'on utilisera pas une entrée il faudra la câbler à la masse ou au plus.

Heu, tu viens pas de dire à l'instant qu'on attaquait qu'une entrée du µC en rassemblant tout avec des OU ?
Pas besoin de savoir de quel vélo les impulsions viennent, il faut juste affiché le cumul distance des 10, et rien que ça (c'est déjà assez compliqué comme ça pour moi ).

dans ce cas on raisonne autrement en disant qu'on génère un pulse très court qu'on envoie sur interruption du compteur int0 du pic , cela nécessite aussi une mise en forme avec un NE555 sur chaque entrée mais ce coup ci très court.
Si l'on en met plusieurs on met une fonction logique OR qui va mettre les impulsions à la queue leu leu sur un seul fil.
Il ya dans ce cas un risque de collisions , dans notre exemple 2 impulsions par seconde fait ~700µs avec un pulse de 10µs de large on aurait 1/70 perte de signal.
bon 1/100 de perte c'est acceptable.
ça nécessitera plus de composants et ne sera pas juste à 100%.
Par contre on pourrait envisager un seul pic , l'interruption se passant en "bakground".

[invitef86a6203]

correction

la probalité serait de 10µs / 500 ms (20km/h)
1/50 000 donc vraiment faible.

Et il faudra faire un programme complet avec 1 seul pic.

Le OR de 10 entrées necessite 3 CI logique

[invitef86a6203]

la probalité dépend aussi de la vitesse de traitement de l'int , admettons 100 instructions a 4mhz , ça fait 100µs
1/5000 toujours acceptable.

Pour le OR un OR a diodes est suffisant en sortie des NE555.

[abracadabra75]

Mille excuses, j' ai lu un peu rapidement, et loupé que tu voulais faire la totalisation des distances de tes vélos.
Ton problème est encore plus simple:
-les capteurs à effet Hall produisent 1 impulsion par tour de roue;
-tes n impulsions sont regroupées avec un OU logique;
-ce OU déclenche l' interruption de ton µc;
-tu fais +1 dans un compteur à chaque interruption;
-pour faire 1 km il te faut p tours de roues(p=1000 / circonférence de la roue). -Chaque fois que le compteur atteint p, tu incrémentes un 2ème compteur qui te servira à afficher la distance parcourue, (sans oublier de remettre le premier compteur à 0!).

Il te faudra décoder ce 2ème compteur pour attaquer les 3 (ou 4 ou 5,...) afficheurs qui donneront la réponse.

Ton 1er compteur n' est pas bien gros: si une circonférence de roue fait 2,20m (dixit freepic), cela fait 454,5454.... impulsions au km, arrondi à 455.
Un compteur sur 2 octets suffit.
Quant au second, je ne crois pas que les 10 vélos atteindront 65536 (2^16) kilomètres, sauf si les participants ont pris beaucoup d'EPO (hélas classique dans ce sport, mais qui ferait désordre pour le téléthon). 2 octets suffisent encore pour le 2 ème compteur.

A+

[invitef86a6203]

acabracadabra75;

Si j'ai bien compris, il veut qu'un seul compteur qui totalise tout.
Sinon un affichage par vélo on explose le budget de 100€.
Et si on met tout les pulses sur 1 seule int on ne sait plus quel vélo envoie le pulse.

Dans la version que je propose on pourrait évoluer vers un compteur par vélo en voyant une commande sur un bus série , mais ce n'est pas ce qui est demandé.

Pour le moment je reconnais que ton idée est plus économique donc,
Tu devrais proposer un schéma.

[abracadabra75]

Tu m' as mal compris, parce qu' on emploie les termes de façon inexacte: le mot 'compteur' est employé dans le sens 'affichage du compteur kilométrique', d' où le quiproquo.
Les compteurs dont je parle sont internes au logiciel et ne peuvent bien sûr pas être vus.
Relis bien: je ne parle que d' un seul affichage (sur plusieurs afficheurs) quelque soit le nombre de vélos.
Et je n' ai rien dit de la façon dont sera réalisé cet affichage, qui sera sans doute le côté le plus cher de la réalisation suivant la technologie utilisée et la taille demandée (dont notre ami ne dit rien).

Et comme on fait une totalisation globale, on n' a pas à se préoccuper de quel vélo vient l' impulsion détectée par le capteur.

A+

Ps. je vais essayer de concocter le schéma, mais il ne sera à adapter car je ne fréquente pas les pics (ils me donnent des boutons, mais c' est hors sujet).

[abracadabra75]

Pour compter, encore une fois le µcontrôleur me semble un marteau pilon.
Aussi voici un projet de compteur à base de CD4XXX dont voici le fonctionnement:
-les capteurs hall produisent des impulsions positives. Un simple 'OU' câblé au moyen de diodes 1N4148 attaque un compteur à 12 digits dont seuls 9 sont utilisés puisque 455 (base 10) fait 111000111 (base 2).
-les 6 digits à 1 sont réunis en un seul au moyen de 2 AND à 4 entrés (CD4082 a 2 x 4 entrées).
-Ce AND commande alors des CD4026 qui sont à la fois des compteurs décimaux et des drivers d' afficheurs 7 segments montés en cascade.

Pour compter, il suffit de 2 simples CI qui ne rélameront aucune programmation pour fonctionner.

J' ai mis en plus un projet à base de µc. Il est fait à base de 68HC11, car je n' ai pas de schéma à base d' autre µC facilement adaptable dans mes bibliothèques.
Mais pour moi, comme le comptage sera logiciel, tout reste à faire.

A+

[invitef86a6203]

il manque le ne555 sur chaque entrée.
La probabilté monté comme ça n'est plus négligeable.
10 mm de contact sur 700mm x par 10 vélos ça fait 100mm soit 1/7 d'erreur

Je ne pense pas que le µC ai assez de courant pour piloter correctement les 7seg
il faut un ULN2803 et un transistor sur chaque commun de 7 seg


Perso je mettrait un pic ...
Mais si tu propose un soft met le µC que tu veux

[invitef86a6203]

le montage en composants logiques et peut être plus facile...
Manque les NE555 aussi.
Mais comment convertir en km chaque impulsion fait ~2,2m on indique donc une distance en unité 2.2m pas des km
il faut un diviseur genre 4020 ou autre

Ps)il a dit 4 digits

perso je mettrait 3 en km et un en 100m avec un point (led) entre les digits 3 et le 1

[abracadabra75]

455 x 2,2 = 1001
donc 1 km avec une bonne approximation,( si on admet d' autre part que la circonférence a été bien mesurée).
Le 4040 compte toutes les impulsions venant des capteurs Hall.
Le 4082 (AND) est configuré de façon à compter 455 ce qui indique que 1 kilomètre (cumulé des n vélos) a été parcouru.
A ce moment on incrémente de 1 le compteur/driver d' affichage, et on remet à 0 le compteur 4040.
On a bien l' affichage du kilométrage cumulé.
Il n' a donc pas besoin d' un diviseur supplémentaire.
En en montant plusieurs en cascade, on obtient l' affichage du kilométrage parcouru. Pour 4 digits, on monte 4 CD4026 : la retenue des unités sert de clock au 4026 des dizaines et ainsi de suite.

Si on veut afficher en centaines de mètres, on change le facteur de division, mais on perd en précision (ce qui dans le projet de notre ami n' est pas mortel, mais il ne faut pas faire cependant n' importe quoi).

L' affichage d' un point décimal est un élément fixe, et n' intervient pas dans le comptage.

La façon d' afficher n' est que l' élément final et dépend de ce que veut indiquer notre ami: à lui de la déterminer.

Je m'aperçois que sur le schéma envoyé le condensateur C1 qui provoque la remise à 0 a disparu. Je mets donc en PJ le schéma corrigé.

Quant à utiliser d' autres composants, pourquoi pas? Je ne suis pas intégriste, et n' ai rien contre (sauf leur consommation que je trouve exagérée, montrant ainsi leur ancienneté). Tu m' as suggéré de faire un schéma. Je l' ai fait à ma manière et suis prêt à affirmer qu' il fonctionnerait en cas de réalisation. Si tu en as un autre en tête, vas y: à tes crayons.
C'est en confrontant diverses solutions qu' on trouvera la meilleure, l' union faisant la force.
A+

[invitef86a6203]

Ok pour le 4040 la référence est tellement petite que je l'avais pas vu.

manque toujours 2 digits.
et l'erreur est de 14 % sans les NE55 d'entrée

[invitef86a6203]

la remise à zéro /454 est fausse
454 = 111000110 soit 5 diodes sur les 1 pour reseter