Davidypy/Skills

Explication du code C51 et visualisation pédagogique

Convertit le programme source C51 complet soumis par l'utilisateur en matériel pédagogique destiné aux débutants du cours 'Technologie des applications microcontrôleurs' en lycée professionnel. L'intégrité et la lisibilité du code source priment sur l'esthétique graphique ; l'explication se base sur les instructions réelles du programme, sans prendre les commentaires, noms de fichiers ou circuits conventionnels comme des faits.

Entrée et périmètre de livraison

• Par défaut, livraison d'une infographie PNG en chinois, 1814×867 pixels, paysage, fond blanc, adaptée pour être placée sous le titre d'une diapositive PowerPoint. Par défaut, tentative de création d'une seule image, avec pagination supplémentaire si nécessaire pour la lisibilité ; si l'utilisateur spécifie explicitement le nombre d'images ou la disposition, sa demande est prioritaire.
• Si l'utilisateur demande uniquement une analyse, des prompts ou un plan, seule cette partie est réalisée. La compétence elle-même n'implique pas la génération d'image ; en l'absence de code réel, les exemples ou textes de substitution ne sont pas considérés comme un programme.
• Lecture du code complet, du nom du programme (le cas échéant), du nombre d'images, de la disposition et des conditions connues du circuit. En l'absence de code, celui-ci est demandé explicitement ; pour les autres paramètres raisonnablement déductibles, les valeurs par défaut sont indiquées et le processus se poursuit. Si le niveau actif n'est pas connu, une analyse avec une hypothèse explicite peut être présentée, ou simplement l'état des broches peut être affiché.
• Le nom de fichier est celui donné par l'utilisateur ou explicitement mentionné dans le code source ; s'il n'est pas identifiable, le nom 'programme_non_nommé.c' est utilisé avec une mention qu'il s'agit d'un nom d'affichage, sans usurper le nom de fichier original.
• La sortie est écrite par défaut dans un répertoire de résultats indépendant de la tâche en cours, et non dans le répertoire de la compétence.

Base de référence immuable du code source

1. Le fichier source est sauvegardé octet par octet. Pour le code issu d'une conversation, seul le texte à l'intérieur des blocs de code est extrait, en conservant les lignes vides, les indentations et les sauts de ligne de fin, puis sauvegardé pour établir une référence. Les différents encodages doivent être décodés explicitement ; il est interdit d'utiliser des caractères de remplacement pour masquer des erreurs.
2. Sont enregistrés : le nom du fichier, l'encodage, le SHA-256, le nombre de lignes physiques, le contenu de chaque ligne, et le nombre de caractères de parenthèses. Le nombre de parenthèses inclut les commentaires et les chaînes, servant uniquement d'audit des caractères, non de vérification syntaxique.
3. Il est interdit de réécrire les identificateurs, constantes, commentaires, opérateurs, parenthèses ou instructions répétées ; d'optimiser le code ; d'ajouter automatiquement des parenthèses manquantes ; ou d'insérer des points de suspension dans le code source. Les erreurs détectées sont signalées en dehors de l'image.
4. Par défaut, l'ordre des lignes et l'indentation d'origine sont conservés. Les numéros de ligne et la coloration syntaxique relèvent de la couche d'affichage et ne doivent pas être réécrits dans le texte source. Les tabulations peuvent être développées pour l'affichage selon des tailles de tabulation explicites, mais le caractère original est conservé pour vérification.
5. La pagination ou l'affichage en double colonne doit couvrir chaque ligne du fichier source exactement une fois, avec une numérotation continue dans l'ordre original. La réutilisation d'extraits de code dans la zone d'explication ne constitue pas une répétition de la pagination du code source, mais doit être clairement distinguée.

Établir l'explication pédagogique à partir du programme

Lors de l'analyse, lire references/c51-analysis.md et organiser selon le programme réel :

• Broches d'entrée/sortie, types, valeurs initiales des variables, responsabilités des fonctions.
• Relations réelles entre l'initialisation, la boucle principale, les branches conditionnelles, les boucles bloquantes et les interruptions.
• Ordre d'évaluation des expressions, nombre d'itérations de boucle, décalage/décalage circulaire, valeurs des broches et changements d'état.
• Détection des boutons, anti-rebond, nouvelle confirmation, attente de relâchement effectif, et possibilité de déclenchement multiple par une seule pression.
• Faits connus du circuit, hypothèses nécessaires, parties qui ne peuvent être déterminées par le seul code source.

Chaque explication clé utilise le format : 'instruction directement citée du code source → fonction de l'instruction → effet réel'. Ne sélectionner que 3 à 6 points de connaissance pertinents pour la page en cours ; les résumés fonctionnels comportent généralement 2 à 4 points. Ne pas ajouter de points de connaissance non présents dans le code source pour faire du nombre.

Disposition et génération

Avant de générer l'image, lire references/rendering.md, qui contient les commandes de l'outil de rendu, le format JSON pédagogique et les règles de pagination.

• Fond blanc, bordure fine, cartes arrondies, marges de sécurité de 20 à 30 px autour. Code en thème bleu ; explications clés en vert ; effets d'exécution en orange ; flux en cyan. En l'absence d'images historiques, créer selon ces spécifications, sans prétendre correspondre à des créations antérieures non vues.
• Pas de titre de cours supplémentaire. Le titre de la carte de code affiche le nom réel du fichier, avec la mention 'C Langage (51 microcontrôleur)' et le numéro de page à droite.
• La zone de code à gauche occupe généralement 55 à 65 %, avec une police à chasse fixe et une police de secours pour le chinois ; commentaires en vert, mots-clés en bleu/violet, valeurs numériques en orange. Le code et les commentaires ne doivent pas déborder, être rognés ou compressés via une taille de police trop petite.
• À droite, placer selon le contenu : fonctionnalité du programme, instructions clés, effets matériels, flux réel ; en cas de plusieurs pages, répartir sur les pages associées, sans répéter tous les modules sur chaque page. Si le code est trop long, utiliser une page dédiée au code et une page dédiée à l'explication.
• Privilégier l'exécution du script scripts/render_infographic.py de la compétence pour un rendu déterministe complet du PNG. Ce script lit le code source ligne par ligne, gère la pagination, les numéros de ligne, la coloration syntaxique, les cartes pédagogiques, les LED de broches et les nœuds de flux avec lignes de connexion ; le contenu pédagogique est écrit par vous dans un JSON après analyse, l'outil n'infère pas la sémantique.
• Si le script rejette en raison de contraintes de largeur de ligne, de capacité de texte ou de disposition, ajuster la pagination ou la mise en page, ou utiliser des outils programmatiques SVG/HTML pour atteindre la même référence de code source et la même vérification de couverture. Ne pas tronquer ou réduire subtilement le texte pour contourner l'échec.
• Les cartes ordinaires, broches, LED, afficheurs 7 segments, flèches doivent être dessinés de manière programmatique, sans modèle d'image. Utiliser la compétence imagegen disponible uniquement si l'utilisateur le souhaite ou si le contenu nécessite réellement des illustrations bitmap ; il ne doit pas confier au modèle d'image la redessin du code source en prétendant être précis.
• Si le nombre d'images fixé par l'utilisateur ne peut satisfaire à la fois l'intégrité et la lisibilité, expliquer le nombre de pages nécessaires et les raisons, et proposer une mise en page claire ; ne pas supprimer arbitrairement du code source. En mode automatique, choisir directement une pagination claire et lisible.

Vérification et livraison

1. Reconstruire le texte de toutes les pages de code source, le comparer caractère par caractère avec la référence, vérifier la numérotation continue des lignes, l'absence de doublons ou d'omissions, la parenthèse fermante d'origine et le saut de ligne de fin. Conserver la liste des résultats.
2. Vérifier l'interprétation du programme, les conditions des branches, le comportement des boutons et l'état du matériel ; le niveau des LED, l'ordre des bits et la direction doivent correspondre au câblage connu ou aux hypothèses indiquées.
3. Ouvrir chaque PNG final, vérifier que le code, les commentaires chinois, les nœuds de flux et le texte explicatif sont clairs, sans chevauchement, texte manquant, rognage ou décalage ; confirmer les dimensions réelles de chaque image.
4. Distinguer le périmètre de vérification : la comparaison du code source prouve la cohérence de l'entrée de mise en page ; la lisibilité finale des pixels nécessite une inspection visuelle. Ne pas utiliser le hachage du code source ou du PNG comme preuve de reconnaissance optique ou d'exactitude sémantique.
5. Livrer les images avec une brève description : nombre d'images, plages de lignes de code source et contenu d'explication principal sur chaque page, dimensions réelles, périmètre de vérification effectué, problèmes détectés dans le programme source, et hypothèses matérielles. Fournir le lien vers la référence du code source et manifest.json pour faciliter la revue.
6. Si vous ne recevez que des prompts, des panneaux de code ou des esquisses non vérifiées, indiquer clairement l'état de la livraison, sans l'appeler infographie pédagogique complète. En cas de limitations des outils, expliquer les limitations réelles et ce qui a été accompli.