[SHARP MZ-700] Sortie DVI via le RP2040-PiZero

Placez ici vos trucs et astuces, étalez sans retenue votre savoir-faire et votre science qui va nous permettre de redonner une apparence neuve et fonctionnelle à nos bouzes.

Modérateurs : Papy.G, fneck, Carl

Avatar de l’utilisateur
Bricox
Messages : 1105
Inscription : 25 janv. 2024 10:28
Localisation : Grand-Est

Re: [SHARP MZ-700] Sortie DVI via le RP2040-PiZero

Message par Bricox »

Ha bien, je n'avais pas regardé en détail, le SPI est donc en entrée, pas en sortie comme je l'avais imaginé.

Effectivement, c'est un bon point de départ pour analyser le processus de création.
Le monde a plus besoin de créateurs, d'entrepreneurs, de préventeurs (Napo), de vulgarisateurs que de prédicateurs et de procureurs.
Avatar de l’utilisateur
hlide
Messages : 4104
Inscription : 29 nov. 2017 10:23
Localisation : Yvelines

Re: [SHARP MZ-700] Sortie DVI via le RP2040-PiZero

Message par hlide »

Mais qu'est-ce que je maudis ce forum à la con qui me demande à nouveau le login après que je poste un long pavé !!!! :evil:

Purée je n'ai plus d'énergie à expliquer…

Ce que je souhaitais faire, c'est faire tout le traitement de capture et de remplissage du buffer vidéo par le PIO par le biais de la DMA.

Tout ça est sous réserve que cela soit possible avec la DMA, à savoir pointer la DMA sur les 320x200 pixels (octets) et la possibilité de la remplir en cycle (wrapping en anglais). Le buffer étant alloué, il est forcément aligné sur 4 octets et sa taille est multiple de 4 octets. A chaque fois qu'un octet est écrit, l'adresse est incrémenté de façon à pouvoir remplir le buffer. Et je prie pour que le DMA gère le retour en début d'adresse à la fin.

Je simplifie en omettant le color blending.

Donc le code SM va contenir les différentes étapes :
1) attendre la synchro verticale et ignorer les N lignes non visibles en comptant les synchros horizontaux.
2) compter les pixel clocks pour ignorer les pixels non visibles qui commence la ligne visible.
3) capturer les signaux B, R, G et I, les empiler dans la FIFO puis empiler 4 zeros pour faire un octet à DMA-iser dans le buffer vidéo.
4) compter les pixel clocks pour les 320 pixels visibles en rebouclant en 3)
5) compter les lignes pour les 200 lignes visibles en rebouclant en 4)
6) revenir en 1)

Alors le SM a des limitations :
- 32 instructions maximum,
- deux registres X et Y seulement,
- l'instruction SET accepte d'affecter une valeur 31 au plus en constante,
- l'instruction JMP X--/Y--, target est la seule façon de compter.

Malheureusement, c'est un peu chaud à faire en un seul SM.

Premier SM : gestion des blanks et signale au deuxième SM pour les lignes visibles
SM0 :

Etiquette de sautN° Instruction (PC)Instruction ASM PIOCommentaire
wait_vsync:00WAIT 0 GPIO vsyncattendre le début d'une trame
01WAIT 1 GPIO vsync
02SET Y, V_BLANK_Non présume qu'il y a moins de 32 lignes non visibles
v_blank_loop:03WAIT 0 GPIO hsyncattendre le début d'une ligne non visible
04WAIT 1 GPIO hsyncet que ce signal remonte pour pouvoir détecter le prochain en rebouclant
05JMP Y--, v_blank_loopignore les première lignes non visibles
06SET Y, 10200 lignes -> 10 blocs ...
h_blank_loop_1:07SET X, 20... de 20 lignes
h_blank_loop_2:08IRQ SET hsync_irqdéclenche le remplissage de la ligne visible
09WAIT 0 GPIO hsyncattendre le début de la ligne visible
10WAIT 1 GPIO hsyncet que ce signal soit remonté pour pouvoir détecter le prochain en rebouclant
11JMP X--, h_blank_loop_2
12JMP Y--, h_blank_loop_1on itère sur les 200 lignes visibles
13JMP wait_vsyncon reboucle sur l'attente de la trame suivante


Deuxième SM : gestion de capture des pixels visible pour la ligne en cours
SM1 :

Etiquette de sautN° Instruction (PC)Instruction ASM PIOCommentaire
capture_pixels:00IRQ WAIT hsync_irqattente de la demande de remplissage de la ligne visible
01WAIT 0 GPIO hsyncattendre le début de la ligne visible
02IRQ CLEAR hsync_irql'IRQ est pris en compte
h_blank_loop:03SET X, H_BLANK_N/2on présume qu'il y a moins de 32 paires des pixel non visibles
04WAIT 0 GPIO colrattendre sur COLR
05WAIT 1 GPIO colret que ce signal remonte pour pouvoir détecter le prochain en rebouclant
06JMP X--, h_blank_loopignore les premiers pixels non visibles
07SET Y, 20une ligne visible = 320 pixels, soit 20 blocs de 16 pixels
capture_320px_loop:08SET X, 88 paires de pixels = 16 pixels
capture_16px_loop:09WAIT 0 GPIO colrattendre sur COLR
10IN PINS 4récupère B, R, G et I et empile dans la FIFO pour la DMA
11IN NULL 4empile 4 zéros pour compléter l'octet dans la FIFO pour la DMA
12WAIT 1 GPIO colrattendre sur COLR
13IN PINS 4récupère B, R, G et I et empile dans la FIFO pour la DMA
14IN NULL 4empile 4 zéros pour compléter l'octet dans la FIFO pour la DMA
15JMP X--, capture_16px_loop
16JMP Y--, capture_320px_loopitère sur les 320 pixels visibles
17JMP capture_pixelson reboucle sur l'attente de la ligne suivante


Je suis dans l'hypothèse que les registres X et Y sont par SM et non juste par PIO. Et bien sûr, rien de codé réellement.
Dernière modification par hlide le 09 nov. 2024 20:55, modifié 7 fois.
Avatar de l’utilisateur
Bricox
Messages : 1105
Inscription : 25 janv. 2024 10:28
Localisation : Grand-Est

Re: [SHARP MZ-700] Sortie DVI via le RP2040-PiZero

Message par Bricox »

Whaou ... belle analyse ... :)

Il faut toujours passer du temps pour l'analyse, c'est un bon investissement.

Quel est le mécanisme de synchro entre SM0 et SM1 ?

Avec cette présentation, cela met en évidence l'absence de l'instruction 07 :
(Si cela est juste un décalage, je te le fais. C'est facile pour moi avec Excel.)
tabat_asmpio
SM0 :

Etiquette N° Instruction Instruction ASM PIO Commentaire
wait_vsync: 00 WAIT 0 GPIO vsync attendre le début d'une trame
01 WAIT 1 GPIO vsync
02 SET Y, V_BLANK_N on présume qu'il y a moins de 32 lignes non visibles
v_blank_loop: 03 WAIT 0 GPIO hsync attendre le début d'une ligne non visible
04 WAIT 1 GPIO hsync
05 JMP Y--, v_blank_loop ignore les première lignes non visibles
06 SET Y, 10 200 lignes -> 10 blocs ...
h_blank_loop_1: 08 SET X, 20 ... de 20 lignes
h_blank_loop_2: 09 IRQ SET hsync_irq déclenche le remplissage de la ligne visible
10 WAIT 0 GPIO hsync attendre le début de la ligne visible
11 WAIT 1 GPIO hsync
12 JMP X--, h_blank_loop_2
13 JMP Y--, h_blank_loop_1 on itère sur les 200 lignes visibles
14 JMP wait_vsync on reboucle sur l'attente de la trame suivante


SM1 :

Etiquette N° Instruction Instruction ASM PIO Commentaire
capture_pixels: 00 IRQ WAIT hsync_irq attente de la demande de remplissage de la ligne visible
01 WAIT 0 GPIO hsync attendre le début de la ligne visible
02 IRQ CLEAR hsync_irq l'IRQ est pris en compte
h_blank_loop: 03 SET X, H_BLANK_N/2 on présume qu'il y a moins de 32 paires des pixel non visibles
04 WAIT 0 GPIO colr attendre sur COLR
05 WAIT 1 GPIO colr
06 JMP X--, h_blank_loop ignore les premiers pixels non visibles
07 SET Y, 20 Un ligne visible = 320 pixels, soit 20 blocs de 16 pixels
capture_200px_loop: 08 SET X, 8 8 paires de pixels = 16 pixels
capture_16px_loop: 09 WAIT 0 GPIO colr attendre sur COLR
10 IN PINS 4 récupère B, R, G et I et empile dans la FIFO pour la DMA
11 IN NULL 4 empile 4 zéros pour compléter l'octet dans la FIFO pour la DMA
12 WAIT 1 GPIO colr attendre sur COLR
13 IN PINS 4 récupère B, R, G et I et empile dans la FIFO pour la DMA
14 IN NULL 4 empile 4 zéros pour compléter l'octet dans la FIFO pour la DMA
15 JMP X--, capture_16px_loop
16 JMP Y--, capture_200px_loop itère sur les 320 pixels visibles
17 JMP capture_pixels on reboucle sur l'attente de la ligne suivante


Autopush is enabled, threshold 8 : Transmission automatique quand 8 octets sont constituées
Dernière modification par Bricox le 11 nov. 2024 10:35, modifié 3 fois.
Le monde a plus besoin de créateurs, d'entrepreneurs, de préventeurs (Napo), de vulgarisateurs que de prédicateurs et de procureurs.
Avatar de l’utilisateur
hlide
Messages : 4104
Inscription : 29 nov. 2017 10:23
Localisation : Yvelines

Re: [SHARP MZ-700] Sortie DVI via le RP2040-PiZero

Message par hlide »

Les SM du même PIO peuvent utiliser jusqu'à 4 IRQ pour se signaler entre eux. Donc j'ai le SM0 qui signale au SM1 quand il doit traiter une ligne visible.

Grosso modo, SM0 lève un IRQ dès que l'on a passé la dernière ligne non visible avant d'entrer dans les lignes visible. Le SM1 attend que cet IRQ soit levé pour commencer à traiter la ligne. Il désactive ensuite le flag de l'IRQ et commence à traiter les pixels invisibles puis celle visibles. Les deux SM continuent de leur côté à traiter la ligne. Le SM0 va lever 200 fois l'IRQ puis passera à la trame suivante sous le feu des synchros /VSYNC et /HSYNC.

Je vais regarder comment t'a fait pour le tableau… et corrigé le mien.

Après, je n'ai pas fait attention au fait que les deux SM ne pourraient pas s'exécuter en même temps. Si c'est le cas, il faut signaler et attendre que l'IRQ soit traité par le SM1 (IRQ libéré à la fin dans ce cas) et le SM0 n'aura plus qu'à boucler 200 fois sans attendre sur le /HSYNC juste en signalant l'IRQ et en attendant qu'il est fini.
Avatar de l’utilisateur
Bricox
Messages : 1105
Inscription : 25 janv. 2024 10:28
Localisation : Grand-Est

Re: [SHARP MZ-700] Sortie DVI via le RP2040-PiZero

Message par Bricox »

Si tu réponds au post du tableau, tu peux récupérer le BBcode.

J'ai remplacé "Nom fonction" par "Etiquette".

Je suppose que WAIT 0 GPIO puis WAIT 1 GPIO attendent un front montant.

Je suppose également que GPIO vsync fait partie d'un bloc de déclarations préalable.

capture_200px_loop devrait s'appeler capture_320px_loop

Si cela fonctionne sans modif, tu pourrais mettre les 2 SMs dans une seule et là, plus de doute sur le fonctionnement // des SMs.

Je suppose qu'à l'autre bout du DMA PIO1/ARM1 , les quartets de 4 pixels sont traités, par le Core1.
Un DMA pur ARM1 peut ventiler les quartets vers des buffers, qui seront transmis par DMA ARM1/PIO0, au PIO0 de sortie HDMI.
Dernière modification par Bricox le 09 nov. 2024 20:51, modifié 1 fois.
Le monde a plus besoin de créateurs, d'entrepreneurs, de préventeurs (Napo), de vulgarisateurs que de prédicateurs et de procureurs.
Avatar de l’utilisateur
hlide
Messages : 4104
Inscription : 29 nov. 2017 10:23
Localisation : Yvelines

Re: [SHARP MZ-700] Sortie DVI via le RP2040-PiZero

Message par hlide »

Non, un "WAIT 0 <source>" attend juste que le signal passe à 0 si ce n'est pas déjà le cas.

Le "WAIT 0 hsync" puis le "WAIT 1 hsync" c'est pour m'assurer que quand je reboucle N fois, je passe bien N hsync, car le signal hsync peut durer bien plus longtemps que les cycles nécessaires au rebouclage.
Avatar de l’utilisateur
hlide
Messages : 4104
Inscription : 29 nov. 2017 10:23
Localisation : Yvelines

Re: [SHARP MZ-700] Sortie DVI via le RP2040-PiZero

Message par hlide »

Bricox a écrit : 09 nov. 2024 20:03 Si cela fonctionne sans modif, tu pourrais mettre les 2 SMs dans une seule et là, plus de doute sur le fonctionnement // des SMs.

Je suppose qu'à l'autre bout du DMA PIO1/ARM1 , les quartets de 4 pixels sont traités, par le Core1.
Un DMA pur ARM1 peut ventiler les quartets vers des buffers, qui seront transmis par DMA ARM1/PIO0, au PIO0 de sortie HDMI.
1) Non, j'ai tenté avec un seul SM et ce n'est pas possible : je n'ai que deux registres X et Y et il m'en faudrait 4 pour pouvoir traiter les 200 lignes et les 320 pixels.

2) L'objectif c'est 0 CPU. Il faut deux DMA de ce que j'ai lu, la première pointe sur le buffer à remplir. La deuxième DMA va remettre l'adresse de début dans l'adresse d'écriture de la première DMA quand elle atteint la fin. Donc SM1 devrait remplir directement ce buffer qui sera lu en parallèle par le core 1 pour sortir en DVI (code que je ne touche pas !). Ca permettrait de libérer le core 0 pour d'autre tâche.

J'ajoute que si je veux faire le color blending, ça présume que j'utilise la DMA à la fois en lecture et en écriture (chacun leur adresse) : le SM1 devrait lire la partie MSB de l'octet depuis le DMA en lecture, le placer en LSB combiné au B, R, G et I capturés et placés en MSB puis écrire le résultat dans la DMA en écriture. Je ne sais pas si c'est faisable, si oui, on aura notre 27/81 couleurs sans opérations CPU.

Au cas où tu n'aurais pas deviné, voici comment en pseudo code, je calcule le color blending :

Code : Tout sélectionner

    // attend un changement de front de COLR.
    wait upon GPIO[15] == 0;
    // on effectue le blending par le jeu de la palette.
    vram[pos++] = (vram[pos] >> 4) | (GPIO[4-7]<<4);
    // attend un changement de l'autre front de COLR 
    wait upon GPIO[15] == 1;
    // on effectue le blending par le jeu de la palette.
    vram[pos++] = (vram[pos] >> 4) | (GPIO[4-7]<<4);
Avatar de l’utilisateur
Bricox
Messages : 1105
Inscription : 25 janv. 2024 10:28
Localisation : Grand-Est

Re: [SHARP MZ-700] Sortie DVI via le RP2040-PiZero

Message par Bricox »

N'ayant pas la structure des bits de vram, je ne comprends pas.

Il faudrait également que je me remémore les positions des couleurs utiles de la palette 16x16.
Le monde a plus besoin de créateurs, d'entrepreneurs, de préventeurs (Napo), de vulgarisateurs que de prédicateurs et de procureurs.
Avatar de l’utilisateur
hlide
Messages : 4104
Inscription : 29 nov. 2017 10:23
Localisation : Yvelines

Re: [SHARP MZ-700] Sortie DVI via le RP2040-PiZero

Message par hlide »

La palette de 256 couleur est découpée comme suit :
index = (couleur du pixel de la trame précédente) + 16*(couleur du pixel de la trame en cours)

J'ignore I pour la suite.

ainsi un noir c'est index = 0.
ainsi un bleu foncé c'est index = 1 ou 16.
ainsi un bleu normal c'est index = 1+16 = 17.
ainsi un rouge foncé c'est index = 2 ou 32.
ainsi un rouge normal c'est index = 2+32 = 34.
ainsi un vert foncé c'est index = 4 ou 64.
ainsi un vert normal c'est index = 4+64 = 68.

J'ai donc deux quartets pour l'index et à chaque capture du pixel je recalcule son index = (quartet du pixel de la trame précédente) | ((quartet du pixel de la trame en cours) << 4).

La vram est juste un tableau d'octet représentant des index de la palette, soit 256 couleurs. J'ai défini la palette de sorte à obtenir le mixage de couleur tenant compte dans un quartet sa valeur dans la trame précédente et un autre quartet sa valeur en cours. Et magiquement, j'obtiens la couleur mixée.
Dernière modification par hlide le 09 nov. 2024 22:41, modifié 1 fois.
Avatar de l’utilisateur
Bricox
Messages : 1105
Inscription : 25 janv. 2024 10:28
Localisation : Grand-Est

Re: [SHARP MZ-700] Sortie DVI via le RP2040-PiZero

Message par Bricox »

Super ... le mystère s'éclaircit ... :D

Merci pour ta pédagogie.
Le monde a plus besoin de créateurs, d'entrepreneurs, de préventeurs (Napo), de vulgarisateurs que de prédicateurs et de procureurs.
Avatar de l’utilisateur
Bricox
Messages : 1105
Inscription : 25 janv. 2024 10:28
Localisation : Grand-Est

Re: [SHARP MZ-700] Sortie DVI via le RP2040-PiZero

Message par Bricox »

Exemple d'initialisation de l'encapsulation du programme PIO d'écoute SPI TFT, en C :
sm_config_set_wrap(&c, offset + fourwire_wrap_target, offset + fourwire_wrap);

Programme d'écoute SPI TFT, en ASM PIO RP2040 :tabat_asmpio

Directives Etiquette de saut Instruction ASM PIO N°Inst.PC Commentaire
.program fourwire flush: mov isr, null 00 Clear ISR and input shift counter
jmp check_chip_select 01 Poll chip select again
.wrap_target do_bit: wait 0 pin 2 02 Detect rising edge and sample input data
wait 1 pin 2 03 (autopush takes care of moving each
in pins, 2 04 complete data word to the FIFO)
check_chip_select: jmp pin, flush 05 Bail out if we see chip select high
.wrap
Dernière modification par Bricox le 13 nov. 2024 08:13, modifié 2 fois.
Le monde a plus besoin de créateurs, d'entrepreneurs, de préventeurs (Napo), de vulgarisateurs que de prédicateurs et de procureurs.
Avatar de l’utilisateur
Bricox
Messages : 1105
Inscription : 25 janv. 2024 10:28
Localisation : Grand-Est

Re: [SHARP MZ-700] Sortie DVI via le RP2040-PiZero

Message par Bricox »

hlide a écrit : 09 nov. 2024 22:00 La palette de 256 couleur est découpée comme suit :
index = (couleur du pixel de la trame précédente) + 16*(couleur du pixel de la trame en cours)

J'ai donc deux quartets pour l'index et à chaque capture du pixel je recalcule son index = (quartet du pixel de la trame précédente) | ((quartet du pixel de la trame en cours) << 4).
couleur du pixel de la trame précédente et couleur du pixel de la trame précédente sont commutatifs.

Je pense que :

Code : Tout sélectionner

vram[pos++] = (vram[pos] >> 4) | (GPIO[4-7]<<4)
est équivalent à :

Code : Tout sélectionner

vram[pos++] = (vram[pos] & F0) | GPIO[4-7]
Cela devrait être plus rapide
Le monde a plus besoin de créateurs, d'entrepreneurs, de préventeurs (Napo), de vulgarisateurs que de prédicateurs et de procureurs.
Avatar de l’utilisateur
hlide
Messages : 4104
Inscription : 29 nov. 2017 10:23
Localisation : Yvelines

Re: [SHARP MZ-700] Sortie DVI via le RP2040-PiZero

Message par hlide »

C'est du pseudo code.

le vrai code, si c'était en C par le CPU : vram[pos] = (vram[pos] >> 4) | (gpio & 0xF0); ++pos;

Par le PIO, il faut jongler par décalage car il n'y a pas de AND.
Avatar de l’utilisateur
Bricox
Messages : 1105
Inscription : 25 janv. 2024 10:28
Localisation : Grand-Est

Re: [SHARP MZ-700] Sortie DVI via le RP2040-PiZero

Message par Bricox »

Table de référence, des 9 instructions ASM PIO :tabat_asmpioref

__________Instr. binaire
Bit: 15 14 13 12|11|10|9|8 7_|_ 6 _|_ 5 4 | 3 | 2 | 1 | 0
JMP 0 0 0 Delay/side-set Condition
(nc)
!X scratch X zero
X-- scratch X !zero, prior decrement
!Y scratch Y zero
Y-- scratch Y !zero, prior decrement
X!=Y scratch X != Y
PIN branch on input pin
!OSRE output shift reg notEmpty
Address
WAIT 0 0 1 Delay/side-set
Polarité Source Source
1 GPIO Syst.GPIO input select by Index
0 PINS Input pin selected by Index
IRQ PIO IRQ flag selected by Index
Index
IN 0 1 0 Delay/side-set Source
PINS
X scratch register X
Y scratch register Y
NULL all zeroes
ISR
OSR
BitCount
OUT 0 1 1 Delay/side-set Destination
PINS
X scratch register X
Y scratch register Y
NULL discard data
PINDIRS
PC
ISR also sets ISR shift cuntr to BitCount
EXEC Exec. OSR shift data as instruction
BitCount
PUSH 1 0 0 Delay/side-set
block Push ISR=>Rx FIFO, wait space available
noblock Push ISR=>Rx FIFO, if noSpace free, no-op
iffull block Push ISR=>Rx FIFO, if enough bits & space free
iffull noblock Push ISR=>Rx FIFO, as on top + else no-op
0 | 0 | 0 | 0 | 0
PULL 1 0 0 Delay/side-set
block Pull Tx FIFO => 32bit => OSR
noblock Pull Tx FIFO =>if notData, X => OSR
iffull block Blocking pull, only if OSR is sufficiently empty
iffull noblock Nonblocking pull, but only if OSR is empty
0 | 0 | 0 | 0 | 0
MOV 1 0 1 Delay/side-set Destination
PINS Uses same pin mapping as OUT
X scratch register X
Y scratch register Y
PC
ISR Input shift counter is reset
OSR Output shift counter is reset
EXEC Execute data as instruction
Operation Source
None PINS
Invert X
Bit-reverse Y
PC
ISR
OSR
EXEC
IRQ 1 1 0 Delay/side-set
Int 0–3 to the ARM CPU
Int 4–7 to appropriate PIO in the same bank.
SET 2 set int 2, won't wait for interrupt to be handled
CLEAR 2 clear interrupt 2
WAIT 2 set int 2 and wait for int handler to clear it
SET 2 REL int nbr will be adjusted by adding PIO nbr
Index
SET 1 1 1 Delay/side-set Destination
PINS
X scratch register X
Y scratch register Y
PINDIRS
Data


Remarque : PUSH et PULL ont le même code binaire d'instruction, c'est le bit 7 qui fait la distinction.
Dernière modification par Bricox le 13 nov. 2024 08:12, modifié 3 fois.
Le monde a plus besoin de créateurs, d'entrepreneurs, de préventeurs (Napo), de vulgarisateurs que de prédicateurs et de procureurs.
Avatar de l’utilisateur
hlide
Messages : 4104
Inscription : 29 nov. 2017 10:23
Localisation : Yvelines

Re: [SHARP MZ-700] Sortie DVI via le RP2040-PiZero

Message par hlide »

Ah enfin, j'ai retrouvé mon LA5032. Vu que j'ai démonté complétement mon MZ-700, ça ne va pas être pour tout de suite.

1) Mon MZ-700 étant malade, je compte l'examiner plus en détail et donc mettre en pause la sortie DVI le temps que je trouve ce qui ne va pas.

2) j'ai examiné d'autres exemples et je commence à deviner comment on peut affecter les valeurs de X et Y plus grandes que 31. En fait, quand on démarre le SM et que ce dernier ne joue pas avec le FIFO dans son noyau (code en boucle), on peut utiliser OSR dans le prologue pour mettre initialement des valeurs constantes.

DirectivesEtiquette de sautInstruction ASM PION°Inst.PCCommentaire
.program syncspull block00Dépile du FIFO la première constante dans OSR
mov isr,osr01Et copie dans le registre ISR
pull block02Dépile du FIFO la dernière constante dans OSR
.wrap_targetwait_vsync:wait 1 gpio 903Détecte un front descendant sur /VSYNC
...xxLà le code avec des boucles utilisant OSR ou ISR affecté à X ou Y...
.wrap


Ce qui veut dire que OSR, ISR peuvent contenir nos constantes tandis que X et Y seront utilisés comme compteurs de boucle.

En revanche, pour le SM1 qui gère la DMA, ça ne sera pas vraiment possible.
Répondre