Pinball-Man avait soumis l'idée :
Bonjour Pascal
ça c'est constructif. je vais aller voir, comme quoi une explication simple d'un sujet simple reflète mieux la réalité ! merci encorecordialement Guillaume
"Guillaume" a écrit dans le message de news:4aba1f7d$0$420$ snipped-for-privacy@news.free.fr...
En fait pour bien commencer, perso je me fixerais un but, même un truc bateau et pas forcément super compliqué, mais quelque chose qui permet, en fin de projet, d'avoir progressé en douceur sans se prendre la tête tout de suite en se lançant dans quelque chose qui parait insurmontable, je donne un exemple totalement au hasard mais qui permet de montrer comment en partant d'un petit truc, et en le faisant évoluer on peu arriver à faire quelque chose de sympa, sans forcément balancer tout le code d'avant, c'est bien sûr bateau et déjà vu 1000 fois mais ça fait déjà pas mal le tour de la question une fois que tout est fini t'es devenu un expert :-) donc mon exemple:
- commencer par faire un télérupteur tout bête: gestion d'une seule entrée et d'une seule sortie, un coup j'appuie, ça allume, un coup j'appuie ça éteint.
- là tu vas te rendre compte que ça ne marche pas bien à cause des rebonds des fois ça marche, des fois pas, il faudra ajouter un anti-rebonds logique sur l'entrée, il y a plusieurs façons de faire, la plus simple étant de gérer un bete délai avant de valider une action, ou de ne lire l'entrée que toutes les X milisecondes, ou de faire une bascule logicielle, ou une combinaison des 2, etc.
- puis ajouter un timer, le télérupteur se transforme alors en minuterie basique, un appui déclenche un timer qui éteint la sortie au bout de X secondes.
- ensuite ajouter une gestion 'maline': si lampe éteinte et appui bref = minuterie, si lampe éteinte et appui long ça allume la sortie sans minuterie, si lampe allumée et appui bref = ça relance la minuterie, si appui long et lampe allumée alors ça annule la minuterie et ça éteint la sortie. là déjà t'as un télérupteur/minuterie de luxe :)
- puis viendra probablement l'envie de commande un peu plus qu'une seule sortie et un bouton, alors rajouter des boutons de "setup" pour régler la durée, durée que tu stockera bien sur dans la mémoire eeprom et tu feras clignoter lentement une autre sortie correspondant au nombre de minutes réglées, ça fait 3 entrées et 2 sorties.
- puis ajouter un écran lcd, là ça se corse, mais pas tant que ça car il existe des tas de librairies toute faites (comme en basic et en seembleur bien sur) pour commander un lcd, c'est pas très compliqué à gérer. tu pourras alors ajouter l'indication du réglage de durée et lors de l'appui un décompte... (je te passe le détail de comment connecter un lcd il a des milliers d'exemples c'est toujours à peu près pareil en 4 ou 8 fils)
- puis transformer tout ça en horloge, tout en gardant la minuterie, afficher l'heure/minute/seconde, réglable bien sur depuis des boutons.
- ensuite continuer et permettre de programmer un allumage/extinction à une certaine heure
- puis gérer plusieurs plages horaires pour faire un simulateur de présence/programmateur
- ajouter une fonctione random pour faire des allumages "au hasard" dans certaines plages
- puis ajouter un circuit d'extension I2C, par exemple pour permettre de piloter plus de sorties à différentes heures ou récupérer l'heure, puisqu'il y a des composants "horloge" tout faits.
- puis ajouter une gestion usb en émulation rs232, là c'est déjà plus compliqué, il faut la petite interface usb qui va bien, mais pas mal de petites cartes de développement l'ont et avec un bête terminal sous windows tu envoies des ordres à ton système pour allumer/éteindre tel ou tel sortie.
- etc, déjà si t'arrives là, à mon avis, t'auras plus besoin de personne pour programmer en C :-)
Pascal
Après mûre réflexion, Pinball-Man a écrit :
Je te remercie beaucoup. je vais carrément imprimer ton mail et suivre ce dvpt. j'ai été voir les compilateurs et il faut encore comprendre le hard dont j'ai besoin...
On Sep 25, 9:22 am, Guillaume :
En general les kits de developpement sont fournis avec des exemples de code dont la difficulte est tres progressive, permettant justement d'evoluer en programmation de uC, que ce soit en ASM ou en C. Si tu preferes monter toi-meme ton circuit electronique, ces packages d'exemples peuvent etre downloades a part et tu peux utilement t'en inspirer.
On Sep 21, 3:07 pm, "Pierre_Edouard" :
Non : un fichier include est un ".H", pas un ".C"
Non : un fichier include ".H" ne contient pas de code, mais uniquement les prototypages des fonctions, et les definitions des structures de donnees afin de pouvoir ensuite linker l'ensemble des fichiers source et des librairies.
=E9rer le
Non : le travail du preprocesseur n'est pas de compiler, mais de pre-processer le code source avant la compilation, comme par exemple l'interpretation des macros via "#define". La compilation est le job du compilateur, comme son nom l'indique.
k,
Non : la limite de 64Ko due aux 16 bits d'adresses est depassee depuis longtemps.
[ )Non : dans le cas que tu cites, les fichiers d'include ne contiennent que les declarations des fonctions et structures de donnees necessaires au compilateur puis au linker pour generer le code d'appel des fonctions predefinies, et celles-ci ne sont pas "en clair" mais pre-compilees en code machine dans les fichiers objet de la librairie.
On Sep 21, 3:07=A0pm, "Pierre_Edouard" :
pas
Si tu racontes n'importe quoi c'est normal que tu te fasses tailler un costard.
On Sep 21, 9:11=A0am, "Pierre_Edouard" :
ASM ou les
=A0 par le
sseur"
On sait bien sur que "pr=E8s processeur" signifie "pas loin du processeur" et on sait bien sur que cela n'a pas de sens.
On sait bien sur que "pr=E9processeur" signifie "avant le processeur" et on sait bien sur que cela a un sens.
Avant d'ecrire des aneries que d'autres pourraient croire et ainsi faire passer ta propre maladie a des innocents, tu devrais d'abord tenter de comprendre ce que tu lis, au lieu d'adopter ce ton docte qui te ridiculise.
Pas d'accord. Le r=F4le de la directive "include" est de charger un fichier c'est tout. Fichier qui sera analys=E9 avant (d'o=F9 le nom de fichier d'ent=EAte) celu= i o=F9 la directive est invoqu=E9e. Le reste n'est que convention ou habitude, mais dans la norme, c'est son seul r=F4le.
Ils sont m=EAme utiles avant le linkage, ,=E0 la compilation, pour le controle du typage .
--
-Stan
On Sep 25, 11:38=A0am, Stan :
Je suis d'accord, et je ne dis pas le contraire. Ne pas confondre la directive "#include" avec "fichier d'include". Un fichier d'include pourrait tout aussi bien etre une table de donnees.
lui
Agreed.
CQFD
On Sep 18, 8:44 pm, LeLapin :
=EAme
Lui non plus, et c'est d'ailleurs pour ca qu'il a disparu.
Cette phrase est trop compliquee pour notre "ami" : il va donc faire une recherche sur Google & Wikipedia.
Apres avoir confondu (entre autres) les Coulombs avec les Joules, comment esperer qu'il ne confonde pas le circuit integre specialise d'une calculette avec le circuit integre generique qu'est un uP ?
s ;)
Hongrois ce qu'on veut groire ...
============== De quel type de [code] parlez-vous , code source ? code exécutable(machine) ? ...
On Sep 17, 6:35=A0pm, Laurent CLAUDE
La Bible du C : "The C language" by Kernighan & Ritchie.
On Sep 17, 6:35=A0pm, Laurent CLAUDE
"Le langage C" par Kernighan & Ritchie. ( 35 Euros ) ISBN : 2-10-048734-5
A vérifier quand même que l'édition a été mise à jour avec les dernières évolutions du langage, au moins jusqu'au C89 et C99 qui sont quand même moins strict que le C originel de K&R comme par exemple pouvoir déclarer des variables n'importe où dans le code, pouvoir utiliser les commentaires à la C++ avec // le support des inline (C99) qui rendent obsolètes les #define, etc...
Perso j'aime bien les atmel par exemple chez myavr ils ont des kit assez sympa avec plein de périph pour jouer avec:
un truc comme ça
avec des modules plug&play (ou presque...)
parfait pour bidouiller (un lcd, une horloge à pile, capteurs divers etc)
ou pour les plus fortunés avec un afficheur dot matrix et tout:
Pascal
il faudrait renommer cette discussion "formation aux bonnes pratiques du C", il y a 50 façon de faire, des bonnes des pas bonnes, des élégantes, des moches, mais au final, souvent, le résultat est le même, avec le préprocesseur on fait ce qu'on veut, on peut y foutre du code, des header, des types, des commentaires, des data, etc, au final de toute façon en sortie du preprocesseur tout est en vrac dans 1 seul fichier pour chaque .obj / .o généré.
ensuite c'est une question de philosophie et de façon de travailler, souvent les bidouilleurs n'ont que faire de tout le bazar de .h, lib, .c makefiles, etc... alors que dans le monde pro, on en a des centaines, voir des milliers et que ce sont rarement les mêmes personnes qui font les lib de celles qui les utilisent, le .h (proto/contrat d'interface peu importe comment on appelle ça) est le seul lien entre un prog client et une librairie fournie.
Pascal
On Sep 25, 4:42=A0pm, "maior=E9" :
Tsss ...
On Sep 25, 6:49=A0pm, "Pinball-Man" :
C",
Ou plutot faire suive sur un NG adequat, genre:
On Sep 25, 6:38=A0pm, "Pinball-Man" :
"Le langage C" par Kernighan & Ritchie. ( 35 Euros ) ISBN : 2-10-048734-5
s derni=E8res
me
r des
=E0 la
ne,
K&R =3D C "ANSI" !
Jean-Christophe a écrit :
Merci pour cette référence !
Mais j'ai une question stupide ;-) : Ok, le C peut convenir pour tout un tas de µP et µC, mais dans mon cas je souhaite l'apprendre pour du PIC. Ne serait il pas "mieux" (plus simple) de trouver une doc qui ne parlerait du C que pour ce type de composant ? J'ai un peu peur de me perdre dans des apprentissages qui ne me seront pas utiles...
cdlt, Laurent
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.