Delta Island

Bonjour à tous!

Je ne sais pas si vous avez fait un tour sur mon topic "BricoNeo", mais je suis en train de m'amuser avec le l'électronique compliquée pour réaliser une espèce de ROM améliorée et interactive pour NeoGeo.
Après avoir sorti un proto bardé de puces logiques et de circuits programmables, pilotés par un Arduino Nano, je m'intéresse à un moyen de réaliser un projet similaire avec beaucoup moins de composants (donc plus compact, plus simple, plus évolutif, MOINS CHER...). Et le composant de base serait un microcontrôleur RP2040, et en l'occurrence une carte Raspberry Pi Pico (entre 1€ et 5€ la carte).
Après avoir pas mal bossé le sujet, je commence à me dire qu'elle ne sera pas forcément assez rapide pour discuter avec une NeoGeo sur un bus de 2x16 bits, mais elle le serait pour d'autres machines familières sans aucun problème (notamment les machines 8 bits).

Et c'est le moment de la question: qui serait intéressé pour se lancer dans l'aventure de la programmation (un poil avancée, notamment les PIO) sur microcontrôleur RP2040? Je cherche des copains pour me sentir moins seul et sortir des projets sympa à la pelle une fois la technologie maîtrisée.
N'hésitez pas à vous manifester!

Salut Aurélien,

Je suis overbooked (tout comme toi lol), mais je veux bien participer à cette conquête du RP2040.

Je serai de l’aventure

Ce ne sont clairement pas des projets qui vont avancer à fond la caisse .

Pour le moment, après une incursion dans l'assembleur ARM/THUMB du dual CortexM0 qui équipe la carte, je suis arrivé aux limites de temps de réponse (il faut taper sous les 100ns, ce qui ne correspond qu'à une dizaines d'instructions en assembleur pour une horloge à 133MHz).
Je m'intéresse donc aux PIO (programmable I/O), avec 2x4 machines à état qui vivent leur vie à 133MHz aussi, avec leur propre jeu d'instructions spécialisé dans la manipulation de bits et dans l'accès aux GPIO du microcontrôleur.

Concernant la présentation générale de ce qui est possible, j'ai regardé hier le cours en ligne de Uri Shaked, le monsieur derrière l'excellentissime Wokwi. Il connait clairement le matériel sur le bout des doigts, pour avoir programmé son émulateur en Javascript!
Ca se passe par ici...



Il y a 4 autres leçons derrière, dont un cours d'assembleur probablement très intéressant, mais je suis passé directement à la dernière, celle qui concerne les PIO. C'est le seul endroit où j'ai trouvé quelque chose qui ressemble vraiment à des explications concrètes. Malheureusement, tout est fait sur la base du SDK Python. Et on va clairement avoir besoin de maîtriser les temps d'exécution au poil de fesses, donc il faudra trouver autre chose!



Je suis en train de m'exercer, toujours via l'excellent émulateur en ligne Wokwi: https://wokwi.com/
Il propose accessoirement un assembleur en ligne pour les PIO: https://wokwi.com/tools/pioasm

Pour le moment, j'en suis à essayer d'utiliser 16 broches et de les utiliser alternativement comme lignes d'adresse en lecture, et de données en écriture. L'idée étant d'éviter de passer par des registres à décalage comme j'ai fait pour le BricoNeo, et d'utiliser à la place de simples buffers.

A suivre, mais dès que j'aurai avancé un minimum, je pourrai vous partager ma prgression sur mon code en ligne sur Wokwi (parce que tout est partagé sur ce site (sauf si on paie )).

Je me suis amusé "un peu" avec Wokwi, et les machines à état du Pi PICO.

Ma cible est d'utiliser 16 lignes PIO du Pico, en alternance en lecture sur le bus d'adresses et en écriture sur le bus de données via des bascules.
J'ai donc fait un "petit" montage qui me permet de valider ça sur Wokwi.

Au programme:
- Le montage, avec les entrées à gauche (les 2 banques de DIP) et les sorties à droite (avec les 2 barres de LED)
- Des buffers que j'ai dû programmer pour l'occasion avec le SDK de Wokwi parce qu'ils n'avaient pas le composant dans la liste...
- Du code C pour le core 1 du Pico, qui initialise une machine à états, attend des demandes d'adresses, et crache des données en échange
- Du code assembleur PIO pour la machine à état, qui supervise le bus d'adresses, renvoie les changements au core 1, attend les données à transmettre, et les envoie sur les bascules

J'ai l'impression qu'il y a un souci avec l'émulation des sidesets. J'ai peut-être fait une bêtise dans mon code (mais je viens de passer la soirée à chercher la quelle). En mode debug de la machine à états, le code désassemblé du PIO m'affiche les sidesets décalés d'1 bit par rapport au code assemblé. Quand je passe le sideset en mode optionnel, je retrouve bien le bon code. Ca me parait bien étrange, et ça sent le bug côté Wokwi.
A ce stade, et dans l'environnement Wokwi, le sideset ne fonctionen pas du tout, les broches ne changent pas d'état et je ne peux pas couper le buffer d'entrée et envoyer l'impulsion d'horloge sur les bascules.
Je vais donc devoir passer à l'acte et faire un petit montage pour valider ce bout de code (et le timing qui va avec) à coups d'oscillo sur les broches d'horloge et d'activation du buffer.

Je n'ai pas fait ici d'assembleur ARM pour le core 1, parce que je voulais juste tester la machine à état. Un problème à la fois .

Si vous voulez jeter un oeil, j'ai un projet ici (tout est public). Je l'ai locké pour qu'on ne me pourrisse pas, mais vous pouvez faire des modifs et les enregistrer sous un autre nom si vous voulez...
C'est ici: https://wokwi.com/projects/380555206283084801

Et pour les curieux relatifs, ça a cette tête:

C'est vraiment bien wokwi !
Merci pour le partage !

Bon, la première bonne nouvelle, c'est que Wokwi n'est peut-être pas aussi buggé que je le pense (mais un peu quand même).

La seconde, c'est que j'ai réussi à configurer l'environnement VS Code pour assembler le code PIO. Ca va être plus simple qu'avec le PIOASM en ligne de Wokwi pour travailler!

La mauvaise, c'est que ça ne marche pas non plus sur le vrai matériel! (la LED est supposée s'éteindre)

Eh ben je galère bien avec la gestion des sidesets, que je n'arrive pas à faire marcher pour le moment. Mais vu que certains y arrivent, je vais y aller par étapes et je finirai par y arriver .

@Xrider, tu penses qu'il est possible de souder un RP2040 à la main sur un PCB? Ca m'a l'air bien petit!

Souder un rp2040 à la main c’est possible, mais je te recommande d’utiliser un stencil.

Mais la meilleure solution pour ne pas te poser de question quand les choses ne fonctionneront pas comme tu veux (soft vs hard), c’est de commander des pcb prototype assemblés

Petit raccrochage de wagons sur mes expérimentations...

J'ai réglé mes problèmes de sidesets et je maîtrise pas trop mal la partie programmation des PIO.

J'ai donc fait la chaîne suivante (à peu près dans cet ordre, mais mieux optimisé):
- Le code PIO attend un changement de valeur sur le bus d'adresses
- Quand il détecte une modif, il la pousse dans le FIFO du Core 1 du RP2040 et se met en attente de la valeur correspondante.
- Le Core 1 est codé en assembleur ARM/THUMB pour ne pas perdre de temps
- Il boucle (en assembleur, donc) sur l'état du FIFO en attendant une valeur
- Quand il trouve une valeur, il va chercher dans la pseudo ROM la valeur à cette adresse (en RAM, donc)
- Il la pousse dans l'autre FIFO
- Le PIO récupère la valeur
- Il coupe l'arrivée du bus d'adresses en pilotant le buffer d'entrée
- Il change le sens des 16 broches du RP2040
- Il pousse la valeur sur les broches
- Il actionne les 16 bascules D pour mettre les valeurs à dispo sur le bus de data en attendant qu'on les lui demande
- Il repasse les 16 broches en mode lecture
- Il attend une nouvelle adresse

Ca donne ça en termes de chronologie:
Je mets en entrée un signal carré de 1MHz (on a environ 3MHz sur une NegGeo, typiquement). On en voit un bout en bas en jaune.
On est à l'échelle 50 nanosecondes par division horizontale.

En rose, c'est la coupure du bus d'adresses

En blue, c'est l'impulsion pour pousser les données sur les bascules. Elles sont alors dispo pour la machine qui veut les lire.

Sur NeoGeo, un cycle de lecture s'étire sur de l'ordre de 100ns (en fait, il se passe un peu plus de temps parce que les adresses sont mises sur le bus un peu avant que la broche d'activation ne reçoive son impulsion).

Dans mon cas, j'observe un délai d'environ 400ns entre le changement d'adresse et le push sur leur mise à disposition.
C'est probablement très utilisable pour certaines machines 8 bits de la belle époque (il faudra que je fasse des mesures!), mais pour de la NeoGeo, il va falloir aller 4 fois plus vite. => Il faut que je change complètement de stratégie!

Il est assez rapide de pousser de la données séquentielle sur les GPIO via les PIO et le DMA. Mais là, c'est vraiment du transfert mot à mot, et je ne peux pas utiliser le DMA (ou alors je n'ai pas encore tout saisi ).

OK, alors il reste clairement des points d'ombre dans ma connaissance des PIO
Si je bourrine comme un âne et je balance des adresses au Core 1, qu'elles aient changé ou non...
Ca va beaucoup plus vite et je sors les données en maximum 170ns! (la capture laisse penser que les pics sont synchronisés, ce n'est pas le cas, ils tombent n'importe quand.
=> J'ai dû louper un truc, au boulot!

Et un peu plus tard...

J'a trouvé pourquoi je me prenais 200ns de délai après un changement d'état... la faute (à moi, déjà), et au fait que j'utilise les mêmes broches en entrée et en sortie.
Pour ne pas tout exploser, j'ai relié mes broches à la masse via des résistances de 10kOhms.
Et je fais varier la première broche en injectant un signal carré avec mon générateur de fonctions via une résistance de 10kOhms.
Résultat: le générateur est en concurrence avec le Pico qui pousse sur sa sortie, et le signal met du temps à s'établir. J'ai vu ça tout simplement en observant le signal à la sortie du générateur et à l'entrée du Pico (de l'autre côté de la résistance).

Du coup, j'ai fait quelque chose qui ressemble au montage final, et j'ai mis un buffer sur cette ligne 0, piloté par les PIO...
Maintenant, le Pico ne lit les adresses que quand ça lui chante, et il ne crache plus dans le générateur!

Amélioration suppémentaire: j'ai passé l'horloge du Pico de 133MHz à 250MHz! Ce n'est pas supporté, mais tout le monde dit que ça marche très bien (on peut même aller plus haut).

Avec tout ça, j'arrive à un délai maxi de 162ns.
Et devinez qui nous indique que le timing maxi sur NeoGeo est de 150ns... https://wiki.neogeodev.org/index.php?title=Memory_speed

Je vais essayer de gagner encore un peu de temps, mais ça commence à sentir bon pour utiliser cette technique pour d'autres supports!

Gagner du temps va commencer à être compliqué. L'incertitude vient du fait que je fais des boucle sur les PIO et en assembleur pour détecter les changements. Ces deux mécaniques injectent chacune une incertitude, et les 2 se combinent.

Réfléchir......................

Note, là, ça tourne à 3MHz, la courbe verte est celle qui correspond à la sortie du buffer (je mange donc un décalage de 10ns dès le départ et il faudra s'attendre à la même chose derrière les bascules).