Hello,
Sans ouvrir de polémique hein ... je crois que vous ne parlez pas de la même chose, Temps-X si je me réfère à l'image que tu as postée tu parles du fonctionnement normal (et idéal) d'un encodeur, on n'y voit aucun rebond. Antoine parle du traitement des rebonds parasites occasionnés par les encodeurs mécaniques bas-prix chinois. Il existe des encodeurs idéaux, j'en ai deux ou trois mais ce n'est pas le même prix.
Sans vouloir prendre parti pour un discours ou pour l'autre, Bigonoff dans ses cours va au fond des choses sur les PIC, c'est la référence. Mais il ne donne pas de conseils d'algorithmique qui est la base de la programmation, il part du principe que c'est acquis quand on ouvre son cours.
Allez papy raconte..
Quand j'ai commencé la programmation (hier en 14 au temps du ZX81) c'était une science nouvelle pour le grand public et comme il fallait se former on trouvait pas mal de bouquins qui n'existent plus aujourd'hui, notamment sur la bonne façon de programmer, c'était un peu le passage obligé si on voulait apprendre à bien travailler. Pour programmer des routines simples on peut faire çà de tête, il en va tout autrement pour un processus très complexe, à moins d'être un rare génie il faut mettre les idées à plat sur papier. On appelle çà un ordinogramme, un algorigramme ou encore un logigramme.
Pour des trucs simples on y va gaiement directement au clavier mais imaginez un peu programmer un Master-Mind sur PIC sans passer par le papier/crayon...
Ces bouquins expliquaient comment le faire, les symboles normalisés représentant une saisie au clavier, sortie sur écran, sortie sur imprimante, des choix, choix multiples, etc. etc.
https://openclassrooms.com/courses/intr ... origrammesIls expliquaient aussi qu'il faut une seule entrée et une seule fin, tout doit se passer entre ces ceux issues, sinon c'est générateur de bugs sournois qui surviendront forcément un jour ou l'autre.
Pareil pour une sous-procédure: une entrée et une fin.
Il y a aussi le pseudo code mais perso je n'ai jamais trop accroché à cette manière de poser le problème.
C'était aussi la grande époque du Basic (
des Basics) et tout le monde utilisait les goto à tout va, l'instruction la plus grande génératrice de bugs qui n'ait jamais existé car en en abusant on crée des programmes non structurés. Ces bouquins apprenaient à programmer avec rigueur sans utiliser cette instruction (c'est possible) en utilisant un tronc de programme général qui appelle des sous-procédures et des conditions judicieusement placées, (comme en C avec le main et les appels de fonctions). Et il n'y a qu'en faisant un ordinogramme bien ficelé qu'on pouvait se passer des goto. A l'époque utiliser un goto était synonyme de mauvais programmeur. J'ai été surpris de retrouver cette fonction sur l'assembleur PIC mais c'est la seule dispo en 16F
.
Ces bouquins expliquaient aussi que pour des programmes complexes il faut toujours terminer en les testant par "le test du con", aujourd'hui à notre époque aseptisée on parle plutôt de "test du singe", c'est à dire faire essayer le programme par quelqu'un qui n'y connait rien et qui le plantera forcément, façon de dénicher les bugs. Depuis que je lui en ai parlé ma femme ne veut plus m'aider