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 ---
Forum général sur l'Assembleur !

Modérateur : mazertoc

Programmation modulaire à usage personnel
JJE
Passioné
Passioné
Messages : 399
Âge : 83
Enregistré en : novembre 2017
Localisation : Picardie

#1 Message par JJE » mar. 31 mars 2020 18:56

Bonjour à tous,

Pourquoi
L’essentiel a été dit ici et plus particulièrement
Cette méthode de regroupement permet de réaliser une encapsulation comparable par certains aspects à celle de la programmation objet, et permet l'organisation du code source en unités de travail logiques.

Ceci est le pourquoi.

Comment
Code folding
L’éditeur de MPLAB fournit un mécanisme qui permet de développer et réduire l’affichage du code :
Menu : Edit/Properties
Dans la boîte de dialogue qui s’ouvre sélectionner l’onglet Asm File types et cocher la case Enable code folding. Use ;{ and ;}
Une fois cochée, vous pouvez dans votre source définir des blocs par les deux indicateurs donnés ( ;{ est le début, ;} la fin. Apparaît alors, en marge gauche le symbole « - »pour réduire l’affichage du bloc de lignes, « + » pour le développer.
Ceci permet de faire disparaître l’affichage du code ne correspondant pas à l’intérêt de l’instant, encore faut-il que le source ait été bien organisé pour que les lignes correspondant à un centre d’intérêt soient dans un même bloc
Cette méthode présente plusieurs inconvénients
 Elle est dépendante de l’éditeur utilisé. Il n’est pas sûr qu’elle existe sur celui que vous utilisez.
 Il n’est pas rare qu’en plus du code, un bloc de programme correspondant à un centre d’intérêt particulier, nécessite des données. Les lignes de code sont écrites dans un segment ORG du source, les lignes de données dans un segment CBLOCK, ou même définies par des EQU. Aucun mécanisme n’est donné pour lier ces différents blocs.
 Des blocs peuvent être imbriqués, mais, quand on développe le plus externe, tous les internes se trouvent aussi développés. Imaginons que vous mettiez toutes les macros à la suite les une des autres dans votre source et que vous fassiez un bloc du code de chaque macro et un sur-bloc de l’ensemble. Si vous voulez lire et/ou modifier le code de l’une d’elle, vous développez le bloc externe, et elles sont toutes développées, c’est dommage car ça complique la recherche de la macro sur laquelle vous voulez travailler
 Cette méthode ne règle pas la question du réemploi du code écrit qui passera nécessairement par des opérations de copier/coller où souvent on ne recopie pas ce qu’il faut, ou pas tout ce qu’il faut.
Fichier à inclure
Bien connu de chacun car utilisé dans chaque application pour introduire les symboles décrivant le processeur, ils peuvent être mis en œuvre dans la programmation modulaire.
Je n’ai pas le sentiment qu’ils soient fort utilisés.
L’idée est d’écrire dans un fichier séparé d’extension .inc tout ce qui concerne un centre d’intérêt donné et d’utiliser la directive include pour l’incorporer dans son fichier principal.
Un exemple sera donné ci-dessous.
Au final, le programme principal est réduit à peau de chagrin, juste les lignes de programme concernant l’application elle-même dans lequel, il est certainement beaucoup plus facile de se retrouver. Et quelle facilité pour du réemploi !
Exemple
Je vais me baser sur le source de Temps-X relatif à l’algorithme de Bresenham, je suis d’ailleurs très mal à l’aise ne connaissant ni la gestion du spi ni la gestion de cet écran OLED, mais le source est très clair, bravo Temps-X :bravo:
On pourrait envisager le découpage suivant :

    Un module spi chargé de la gestion spi qui contiendrait
      le sous-programme spi
      probablement les lignes 59 et 60 qui définissent les symboles utilisés
    Un module OLED chargé de la gestion de l’écran Oled qui contiendrait
      command_ssd1306 qui devrait être cachée, n’étant utile qu’aux fonctionnalités plus générales décrites après
      donner_ssd1306 ssd1306 qui devrait être cachée, n’étant utile qu’aux fonctionnalités plus générales décrites après
      position_ssd1306
      pset_ssd1306
      lettre_ssd1306
      La table acii définie aux lignes 1099 à 1179, d’ailleurs pourquoi ne contient-elle que 80 caractères ?
      affiche_ssd1306, en fait, je ne suis pas sûr qu’elle soit nécessaire à ce niveau
      cls_ssd1306
      graphique_ssd1306, en fait, je ne suis pas sûr qu’elle soit nécessaire à ce niveau
      les lignes 488 à 502, regroupées dans un sous-programme Init_ssdl306. Il est probable que le tableau configuration défini aux lignes 1080 à 1085 ne doive pas rester dans le programme appelant et passé en paramètre à Init_ssdl306
      Et une directive include le précédent
    Un module biblig bibliothèque graphique qui contiendrait
      affiche_ssd1306 si on ne l’a pas mis au dessus
      graphique_ssd1306 si on ne l’a pas mis au dessus
      ligne
      Et une directive include le précédent
      et dont il n’est pas difficile d’imaginer des extensions.
Ce faisant, dans le programme principal, on gagne plus de 500 lignes et sur les 570 restant, les 500 premières sont des initialisations, bien embêtantes d’ailleurs lais malheureusement indispensables. On doit pouvoir les rassembler dans une macro ce qui ferait un programme réduit à guère plus de 50 lignes. Facile à lire.
Les procédures de tempo, dont on a aussi assez souvent besoin gagneraient elles aussi à être rédigées dans un module indépendant.
Si, un nouveau développement utilise le même écran OLED, il suffit d’écrire en début de fichier
Include <chemin>/biblig et on peut utilise toutes des possibilités décrites précédemment.
Si, dans un nouveau développement, on a besoin d’utiliser un autre type d’écran, il suffit de réécrire le fichier OLED adapté au nouvel écran. Penser alors à gérer leur différences avec un n° de version par exemple

Le sujet Programmation modulaire à usage de bibliothèque donnera quelques idées sur ce sujet dont chacun pourra prendre et adapter celles qui l'intéressent.
Modifié en dernier par JJE le mer. 1 avr. 2020 11:46, modifié 2 fois.
Cordialement

JJE

C'est pas parcequ'on n'a rien à dire qu'il faut fermer sa G....e

Programmation modulaire à usage personnel
Temps-x
Avatar de l’utilisateur
Expert
Expert
Messages : 2595
Enregistré en : juillet 2016
Localisation : Terre

#2 Message par Temps-x » jeu. 2 avr. 2020 00:21

Bonsoir JJE, et tout le forum,

Ce que je veux faire pour moi ou le forum, c'est créer des macros pour différent module, pour que tout le monde puisse s'en servir, comme pour un Arduino ou il existe une panoplie de bibliothèque.

Tu pourras retrouver beaucoup de macro dans divers tutoriel que j'ai fais, donc voici les liens, pour t'éviter de chercher.

Algorithme de Bresenham

Écran OLED 0.96 128x64

Écran Nokia 5110

Led RGB 5050 WS2812B

Matrice et afficheur avec MAX7219

Potentiomètre numérique et Rhéostat

Il y en a d'autre qui son en préparation, mais je n'ai pas le temps pour les mettre sur le forum, le pire dans cette histoire c'est qu'ils sont déjà écrit.

JJE a écrit :Source du message La table acii définie aux lignes 1099 à 1179, d’ailleurs pourquoi ne contient-elle que 80 caractères ?


Ma table ASCII contient 255 caractères, certain son vide, car pas le temps de tout faire, sur ce type d'écran c'est a toi de créer tes propre caractère.

JJE a écrit :Source du message affiche_ssd1306, en fait, je ne suis pas sûr qu’elle soit nécessaire à ce niveau


Affiche soit un caractère, avec lettre_ssd1306 ou un texte entier avec affiche_ssd1306 avec un maximum de 255 lettres.

En faite, quand tu affiches un caractère pour cette écran, tu lis 5 octets, le nombre d’octets dépends de la grosseur de la Fonts utilisé.

JJE a écrit :Source du message graphique_ssd1306, en fait, je ne suis pas sûr qu’elle soit nécessaire à ce niveau


Il faudrait modifier cette fonction pour charger une image de n'importe quelle taille ne dépassant pas la capacité de l'écran

ça donnerais : graphique image,début, fin

Je vais surement modifier le code, pour que cette option soit présente avant fin de semaine, de plus je vais revenir sur la multiplication 16 bits par 16 bits pour en faire une macro comme tu me l'a suggéré. :wink:

Pour les versions de Pic16Fxxxx il faut créer les instructions qui existe dans les Pic18Fxxxx avec des macros

Ce qu'il faudrait c'est reprendre les macros une par une pour en faire des macro sans faille.

==> A+
Modifié en dernier par Temps-x le jeu. 2 avr. 2020 12:51, modifié 1 fois.
:roll: Les requins, c'est comme le langage ASM, c'est le sommet de la chaîne alimentaire. :wink:

Programmation modulaire à usage personnel
JJE
Passioné
Passioné
Messages : 399
Âge : 83
Enregistré en : novembre 2017
Localisation : Picardie

#3 Message par JJE » jeu. 2 avr. 2020 12:22

Bonjour temps-X, merci de ces infos.
Cordialement

JJE

C'est pas parcequ'on n'a rien à dire qu'il faut fermer sa G....e


Retourner vers « Langage ASM »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 39 invités