Bienvenue aux nouveaux arrivants sur FantasPic !
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
Modérateur : Jérémy
Pourquoi utiliser des fichiers sources ?
-
Jérémy
Administrateur du site- Messages : 2722
- Âge : 44
- Enregistré en : juillet 2015
- Localisation : Dans le sud
- Contact :
Bonjour à tous,
J'ai fais un petit Tuto sur les afficheurs 7 segments . Je me suis inspiré du code exemple de MikroC PRo for PIC .
Quand j'ai étudié le fonctionnement de celui-ci, je me suis interrogé sur le fait que la partie de "transformation du chiffre" était dans un fichiers a part nommé Display_Utils.c.
Mais pourquoi ecrire cette partie dans un fichiers a part plutôt que dans le programme lui même comme je l'ai fais dans mon tuto?
Merci de vos éclaircissements ?
J'ai fais un petit Tuto sur les afficheurs 7 segments . Je me suis inspiré du code exemple de MikroC PRo for PIC .
Quand j'ai étudié le fonctionnement de celui-ci, je me suis interrogé sur le fait que la partie de "transformation du chiffre" était dans un fichiers a part nommé Display_Utils.c.
Mais pourquoi ecrire cette partie dans un fichiers a part plutôt que dans le programme lui même comme je l'ai fais dans mon tuto?
Code : Tout sélectionner
//-------------- Returns mask for common cathode 7-seg. display
unsigned short mask(unsigned short num) {
switch (num) {
case 0 : return 0x3F;
case 1 : return 0x06;
case 2 : return 0x5B;
case 3 : return 0x4F;
case 4 : return 0x66;
case 5 : return 0x6D;
case 6 : return 0x7D;
case 7 : return 0x07;
case 8 : return 0x7F;
case 9 : return 0x6F;
} //case end
}
Merci de vos éclaircissements ?
Pourquoi utiliser des fichiers sources ?
Pourquoi utiliser des fichiers sources ?
-
Jérémy
Administrateur du site- Messages : 2722
- Âge : 44
- Enregistré en : juillet 2015
- Localisation : Dans le sud
- Contact :
Ok , donc pas d’intérêt primordiale à part aérer le code !
c'est vrai que ça peut être intéressant de diviser son programme et plusieurs petits programme .
Alors les pointeurs j'ai lus pas mal de truc vite fait dessus, mais je manque de pratique dessus, ils ne sont pas très clairs pour moi encore . Un offset sur une table la tu m'as perdu .
En tout cas merci j'ai la réponse à ma question !
c'est vrai que ça peut être intéressant de diviser son programme et plusieurs petits programme .
tu as aussi la possibilité d'utiliser un pointeur avec un offset sur une table j'aime mieux .
Alors les pointeurs j'ai lus pas mal de truc vite fait dessus, mais je manque de pratique dessus, ils ne sont pas très clairs pour moi encore . Un offset sur une table la tu m'as perdu .
En tout cas merci j'ai la réponse à ma question !
Pourquoi utiliser des fichiers sources ?
Bien sur qu'il y a non pas un mais DES intérêts à pratiquer de la sorte.
D'ailleurs on ne pratique QUE de la sorte dans la vraie vie, le fichier unique est uniquement le reflet d'une (mauvaise) pratique et souvent d'une méconnaissance des techniques propres et efficaces de programmations.
Voici quelques intérêts dans une liste non exhaustive:
1/Lisibilité.
le fichier .c contient les définitions des fonctions, les macros associées (par exemple pour utiliser l'uart ou un capteur quelconque), les variables afférentes etc.
Le fichier associé .h permet de partager les déclarations qui seront nécessaires aux autre modules pour accéder aux différentes fonctions.
On fait appel à #include pour appeler les différents modules logiciels qui seront utiles dans le programme principal, celui qui contient le main().
2/Compréhension
Un développement logiciel n'est pas uniquement un travail individuel, il peut être amené à être partagé et maintenu par de nombreuses personnes dans un cadre professionnel.
Pour cela le choix des noms de variables, les noms d'arguments, de fonctions, etc doivent être clairs et parlants et parfaitement organisés, sans avoir à passer plusieurs heures à jouer à décrypter un hiéroglyphe.
Utiliser une organisation en modules par fonctionnalité apporte une rigueur nécessaire qui s'apprécie quand la taille du programme devient conséquente.
Il n'est pas rare d'avoir plus de 10 modules .c/.h dans une application même relativement simple.
3/ Maintenance
Si une amélioration doit être faite sur par exemple le module I2C (ajout d'une fonction), seul le fichier i2c.c sera retouché, ça va prendre très peu de temps puisque le fichier ne contient que les mécanismes i2c et rien d'autre.
4/ Confidentialité
Possibilité de cette manière de générer des fichiers publics ou non publics, par exemple si vous écrivez une pile CAN Open mais que vous ne voulez pas que votre client ait accès au code source original, il pourra utiliser la pile sans pour autant en connaitre ce qu'il y a sous le capot moteur.
Par exemple sous Mikroc vous avez accès à la fonction ADC_Read() sans pour autant pouvoir visualiser son exact contenu.
D'ailleurs on ne pratique QUE de la sorte dans la vraie vie, le fichier unique est uniquement le reflet d'une (mauvaise) pratique et souvent d'une méconnaissance des techniques propres et efficaces de programmations.
Voici quelques intérêts dans une liste non exhaustive:
1/Lisibilité.
le fichier .c contient les définitions des fonctions, les macros associées (par exemple pour utiliser l'uart ou un capteur quelconque), les variables afférentes etc.
Le fichier associé .h permet de partager les déclarations qui seront nécessaires aux autre modules pour accéder aux différentes fonctions.
On fait appel à #include pour appeler les différents modules logiciels qui seront utiles dans le programme principal, celui qui contient le main().
2/Compréhension
Un développement logiciel n'est pas uniquement un travail individuel, il peut être amené à être partagé et maintenu par de nombreuses personnes dans un cadre professionnel.
Pour cela le choix des noms de variables, les noms d'arguments, de fonctions, etc doivent être clairs et parlants et parfaitement organisés, sans avoir à passer plusieurs heures à jouer à décrypter un hiéroglyphe.
Utiliser une organisation en modules par fonctionnalité apporte une rigueur nécessaire qui s'apprécie quand la taille du programme devient conséquente.
Il n'est pas rare d'avoir plus de 10 modules .c/.h dans une application même relativement simple.
3/ Maintenance
Si une amélioration doit être faite sur par exemple le module I2C (ajout d'une fonction), seul le fichier i2c.c sera retouché, ça va prendre très peu de temps puisque le fichier ne contient que les mécanismes i2c et rien d'autre.
4/ Confidentialité
Possibilité de cette manière de générer des fichiers publics ou non publics, par exemple si vous écrivez une pile CAN Open mais que vous ne voulez pas que votre client ait accès au code source original, il pourra utiliser la pile sans pour autant en connaitre ce qu'il y a sous le capot moteur.
Par exemple sous Mikroc vous avez accès à la fonction ADC_Read() sans pour autant pouvoir visualiser son exact contenu.
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 47 invités