Le but de cette expérimentation est de créer un dispositif de base pour Maple Bus à partir d'un micro-contrôleur SX28, autrement dit de réaliser la circuiterie électronique d'une pseudo manette DreamCast.
Le site du constructeur (http://www.parallax.com/) permet de télécharger toutes les notices (http://www.parallax.com/tabid/460/Default.aspx) ainsi que les logiciels (http://www.parallax.com/tabid/460/Default.aspx) nécessaires à cette expérimentation.
Il est aussi possible d'acheter individuellement sur ce site (http://www.parallax.com/tabid/138/List/0/CategoryID/15/Level/a/SortField/0/Default.aspx) les fournitures et les composants nécessaires à un développement pour un coût modique :
La carte de développement
SX Tech Board
(http://www.parallax.com/DesktopModules/CATALooKStore/MakeThumbImage.aspx?ID=%2fPortals%2f0%2fImages%2fProd%2f4%2f452%2f45205-M.jpg&PORTALID=0&W=120&H=120) (http://www.parallax.com/Store/Microcontrollers/SXProducts/tabid/138/CategoryID/15/List/0/SortField/0/Level/a/ProductID/366/Default.aspx)
| | L'interface USB permettant
seulement la programmation
SX Blitz
(http://www.parallax.com/DesktopModules/CATALooKStore/MakeThumbImage.aspx?ID=%2fPortals%2f0%2fImages%2fProd%2f4%2f451%2f45170-M.jpg&PORTALID=0&W=120&H=120) (http://www.parallax.com/Store/Microcontrollers/SXProducts/tabid/138/CategoryID/15/List/0/SortField/0/Level/a/ProductID/368/Default.aspx)
| | L'interface USB permettant la
programmation et le débogage
SX Key
(http://www.parallax.com/DesktopModules/CATALooKStore/MakeThumbImage.aspx?ID=%2fPortals%2f0%2fImages%2fProd%2f4%2f452%2f45214-M.jpg&PORTALID=0&W=120&H=120) (http://www.parallax.com/Store/Microcontrollers/SXProducts/tabid/138/CategoryID/15/List/0/SortField/0/Level/a/ProductID/494/Default.aspx)
| | Le micro-contrôleur SX28
SX28AC/DP-G
(http://www.parallax.com/DesktopModules/CATALooKStore/MakeThumbImage.aspx?ID=%2fPortals%2f0%2fImages%2fProd%2fS%2fSX28ACDP-G-M.jpg&PORTALID=0&W=120&H=120) (http://www.parallax.com/Store/Microcontrollers/SXProducts/tabid/138/CategoryID/15/List/0/SortField/0/Level/a/ProductID/355/Default.aspx)
| Les résonateurs,
les quartz ou
les oscillateurs
(http://www.parallax.com/DesktopModules/CATALooKStore/MakeThumbImage.aspx?ID=%2fPortals%2f0%2fImages%2fProd%2f2%2f252%2f252-00005-M.jpg&PORTALID=0&W=120&H=120) (http://www.parallax.com/Store/Components/ResonatorsCrystals/tabid/153/List/0/CategoryID/53/Level/a/SortField/0/Default.aspx)
|
Ou encore d'acquérir un kit d'apprentissage regroupant la plupart des fournitures ci-dessus avec le guide correspondant :
le SX Tech Tool Kit
(http://www.parallax.com/Portals/0/Images/Prod/4/451/45180-M.jpg) (http://www.parallax.com/Store/Microcontrollers/SXProducts/tabid/138/CategoryID/15/List/0/SortField/0/Level/a/ProductID/364/Default.aspx)
Le problème est que l'acquisition de la moindre de ces fournitures est plombée par des frais d'expédition exorbitants : $37,64 par USPS ou $53,03 par UPS.
A titre de comparaison, Chad Entringer de MonitorBoss a déboursé $12,48 pour un colis de 0,56 Kg expédié par USPS : le bloc THT pour finir de réparer le moniteur WG K8000 de HSM (http://www.gamoover.net/Forums/index.php?topic=21720.msg335467#msg335467).
Le logiciel SC-Key (http://www.parallax.com/Portals/0/Downloads/sw/sx/Setup-SX-Key-Editor-v3.3.0-(R2).zip) téléchargeable librement sur le site de Parallaxax, comporte à lui seul toutes les fonctionnalités pour développer avec les micro-contrôleurs de la famille SX :
- Un éditeur pour entrer le code source en langage assembleur.
- Un assembleur intégré SASM (http://www.parallax.com/Portals/0/Downloads/docs/prod/sx/SasmUsersManual.pdf).
- La fonction programmation à condition de disposer soit de l'interface USB SX-Blitz soit de l'interface USB SX-Key entre le PC et le micro-contrôleur à programmer.
- La fonction débogage "in situ" à condition de disposer de l'interface SX-Key entre le PC et le micro-contrôleur dont on veut déboguer le code qui a été transféré dans sa mémoire programme.
Les deux dernières fonctions n'étant utilisables qu'à condition de disposer des interfaces SX-Blitz ou SX-Key dont j'ai jugé l'acquisition trop onéreuse à cause des frais d'expédition, il va donc falloir procéder autrement pour programmer les puces SX et si nécessaire déboguer le code généré par l'assembleur.
La solution qui s'impose va donc être :
- De n'utiliser que l'éditeur et l'assembleur intégré du logiciel SX-Key puisqu'ils sont incontournables et puisque les autres fonctionnalités ne sont accessibles qu'à travers de l'interface USB appropriée.
- De programmer les micro-contrôleurs avec un programmateur dédié.
Il sera constitué par l'association :
- Du programmateur Fluffy2 (http://www.semis.demon.co.uk/Sx/SXmain.htm) facilement réalisable par un amateur.
- Du logiciel libre IC-Prog (http://www.ic-prog.com/) pour le faire fonctionner.
- D'utiliser le simulateur SX-Sim (http://www.parallax.com/Portals/0/Downloads/sw/sx/SXSim.zip) téléchargeable librement sur le site de Parallax à défaut du débogueur intégré dans le logiciel SX-Key.
Il n'est certes pas aussi performant que le débogueur "in situ" intégré et l'exécution de certaines instructions pourrait malencontreusement différer de celle d'une puce SX réelle si je me réfère a l'expérience acquise avec le simulateur Micochip pour les PIC's lors de la réalisation du discriminateur 15/24/31 KHz (http://www.gamoover.net/Forums/index.php?topic=17890.msg290932#msg290932).
La fenêtre du logiciel Sx-Key :
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101119000915-gc339-Win.SX-Key.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101119000915-gc339-Win.SX-Key.png)
La fenêtre principale du simulateur SX-Sim :
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101119001303-gc339-Win1.SX-Sim.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101119001303-gc339-Win1.SXSX-Simng)
Le panneau des entrées/sorties, affichable à la demande :- Affiché après avoir cliqué sur le bouton "I/O panel" de la fenêtre principale.
- Désaffiché de l'écran après avoir cliqué sur son bouton "Hide".
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101119001329-gc339-Win2.SX-Sim.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101119001329-gc339-Win2.SX-Sim.png)
Le simulateur utilise le listing issu de l'assemblage, (fichier avec extension en ".lst") pour simuler l'exécution des instructions du programme.
La version 2.08.09 du simulateur SXSim de Günther Daubach qui se télécharge conjointement avec le logiciel SX-Key v.3.3.0 (http://www.parallax.com/tabid/460/Default.aspx) est boguée, il est préférable de la remplacer par la version 2.08.06 issue du forum Parallax : http://forums.parallax.com/showthread.php/75647-SXSim-for-MS-Windows
- SXSim Manual_2_08_06.zip (158.7 KB) (http://forums.parallax.com/attachment.php?s=2467b4a5eb8db97a12e0a6e5da1eca3a&attachmentid=44603&d=1165975525)
- SXSim_2_08_06.zip (106.3 KB (http://forums.parallax.com/attachment.php?s=2467b4a5eb8db97a12e0a6e5da1eca3a&attachmentid=44604&d=1165975593)
La fenêtre du logiciel IC-Prog :
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101119001810-gc339-Win.IC-Prog.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101119001810-gc339-Win.IC-Prog.png)
La mémoire tampon du logiciel de programmation peut être chargée soit par le fichier objet (extension en ".obj") soit par le fichier au format Intel Hex (extension en ".hex") issu de l'assemblage.
Le programmateur Fluffy2 :
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101120004128-gc339-Fluffy2.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101120004128-gc339-Fluffy2.JPG)
- Le circuit imprimé du programmateur est fixé sur un morceau de plexiglas épais. Le connecteur DB9 de la liaison V24 vers le PC est disposé à gauche et l'embase jack de l'alimentation en 18VDC est disposée à droite.
- Le circuit imprimé du Fluffy2 a été gravé ici (http://etronics.free.fr/boutique/boutique.htm).
- Un seul support a été installé puisque dans l'immédiat seul le SX28 sera utilisé. Un support à tulipes a été préféré à l'inévitable et coûteux support Textool jugé ici superflu puisque le programmateur ne sera pas utilisé de façon intensive.
- J'ai trouvé opportun d'apporter quelques modifications de mon cru au schéma d'origine :
- Les transistors PNP ont été remplacés par des transistors MOS BS250.
- Le transistors NPN a été remplacé par un transistor MOS BS170.
- Le régulateur 12 volts et ses deux diodes 1N4148 d'appoint ont été remplacés par un 7808 dont le commun a été relié au + 5 volts.
5 + 8 = 13, le compte est bon et en principe la précision de la tension 13 volts en sortie est bien meilleure.
- L'alimentation du programmateur en 18 VDC est assurée par un bloc alimentation indépendant qui s'enfiche directement dans une prise secteur domestique.
A suivre ...
Le dispositif de jeu (la console DreamCast) est toujours le seul à pouvoir émettre des requêtes ou des ordres à destination des autres dispositifs présents sur le Maple Bus, ce qui implique que le tout premier des challenges devra être la réception et le décodage des trames descendantes émises par la console.
Chaque trame étant précédée d'un fanion, le premier job va donc consister à le reconnaître.
Comme il en existe trois différents («Start», «SDCKB Occupy authorization» et «Reset»), autant prévoir une routine de reconnaissance la plus flexible possible.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101122231807-gc339-Fanions.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101122231807-gc339-Fanions.PNG)
Ces fanions sont caractérisés par un palier bas sur le fil SDCKA encadrant un nombre pair de fronts descendants d'horloge sur le fil SDCKB. Ils débutent avec le front descendant sur le fil SDCKA et se terminent avec le front montant sur ce même fil.
L'idée de départ est d'utiliser les interruptions que peuvent générer les changements d'état sur les broches du port B du micro-contrôleur, broches préalablement déclarées comme entrées.
L'exemple de routine d'interruption donné §6.4.7, page 159 du "SX User's Manual", va servir de base de départ.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101122232633-gc339-InterruptExample.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101122232633-gc339-InterruptExample.PNG)
La concrétisation de cet exemple se réalisera dans la pratique par raccordement du fil SDCKA sur RB0 (broche 10 du SX 28) et du fil SDCKB sur RB1 (broche 11), ainsi un changement d'état sur le Maple Bus pourra interrompre le SX28 si ce changement a été préalablement autorisé à pouvoir le faire.
L'interruption interne produite par le débordement du compteur RTCC pourra servir à abandonner une attente par "time-out" comme par exemple celle inhérente à la réception complète d'une trame.
La routine d'interruption ci-dessus se doit d'être intégrée à l'intérieur du source d'un programme.
Un programme source comporte en premier lieu des directives, ne serait ce que pour définir :
- Le vecteur de reset pointant sur la séquence d'initialisation.
- Les bits de configuration qui seront programmés en même temps que le code machine dans le micro-contrôleur SX28.
Il doit aussi comporter une séquence d'initialisation permettant de pré-positionner les entrées/sorties, la source des interruptions, les variables en mémoire, et cætera.
| LIST | Q = 37, F = INHX16 | | ; Inhibit warning 37, Intel Hex output |
| DEVICE | SX28AC | | ; Sets Device type inside «DEVICE» configuration register |
| DEVICE | TURBO, SYNC, OSCHS3 | | ; Bits inside «FUSE» configuration register |
| DEVICE | OPTIONX | | ; Bit inside «FUSEX» configuration register |
| FREQ | 80_000_000 | | ; Sets up PLL on SX-Key module |
| RESET | Init | | ; Sets reset vector |
| | | | |
| | org | $100 | ; Initialization code must reside inside page 0 |
| Init | equ | $ | ; Initialization starts here |
La séquence d'initialisation devra principalement pré-positionner le port B et accessoirement quelques variables en mémoire, elle sera inspirée de l'exemple donné §4.4.1, page 137 du "SX User's Manual".
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101123232211-gc339-PortB-Configuration.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101123232211-gc339-PortB-Configuration.PNG)
Comme seulement RB0 / SDCKA et RB1 / SDCKB seront utilisés, la séquence ci-dessus devra être modifiée pour n'initialiser que ces deux entrées.
Reprenons le source de l'exemple après avoir ajouté une quatrième ligne dans l'unique table de redirection pour traiter le cas exceptionnel où des changements d'états sur SDCA et SDCKB se produiraient en même temps.
| | org | 0 | ; Interrupt routine starts at address 000H |
| | mov | M, #9 | ; Set up MODE register to read WKPND_B |
| | clr | W | ; Clear W to zero |
| | mov | !RB, W | ; Exchange contents of W and WKPND_B |
| | and | W, #00000011B | ; Mask out unused bits from WKPND_B |
| | | | ; W now indicates cause of interrupt: |
| | | | ; 00H = RTCC, 01H = RB0, or 02H = RB1 |
| | add | PC, W | ; Add W to program counter for indirect jump |
| | | | |
| Pos0 | jmp | RTCCisr | ; W = 0, jump to RTCC interrupt service routine |
| | jmp | Isr0A | ; W = 1, jump to SDCKA / RB0 ISR |
| | jmp | Isr0B | ; W = 2, jump to SDCKB / RB1 ISR |
| | reti | | ; W = 3, unexpected event |
| | | | |
| RTCCisr | nop | | ; RTCC ISR here |
| | reti | | |
| | | | |
| Isr0A | nop | | ; SDCKA / RB0 ISR here |
| | reti | | |
| Isr0B | nop | | ; SDCKB / RB1 ISR here |
| | reti | | |
L'émission d'un fanion par le dispositif de jeu (la console) produit tout d'abord un état bas sur SDCKA, donc une transition négative et par conséquent une interruption par changement d'état sur RB0.
Le logiciel du SX28 doit alors évoluer d'une position d'attente à une position de réception du fanion.
La seconde idée est celle de caractériser chaque position que sera amené à prendre le logiciel par une table de redirection spécifique. Ainsi les interruptions générées par une même source pourront être redirigées en fonction de la position logicielle courante vers la routine de traitement adéquate.
Ainsi l'unique table de redirection de l'exemple deviendra la toute première et figurera la position de repos.
La section commune dans la routine de traitement des interruptions devra être à même d'indexer la table de redirection correspondant à la position logicielle courante. Comme cette position est virtuelle et n'est concrétisée que par la table associée, une variable sera nécessaire pour stocker l'adresse de cette table :- En fait il est plus pratique de stocker l'offset par rapport à la première table.
- Cet offset devra être positionné à zéro par la séquence d'initialisation générale suite à un reset du SX28.
| | org | 8 | ; First address of user RAM |
| Offset | ds | 1 | ; Offset of the table figuring current position |
| Acount | ds | 1 | ; Used to count falling edges on SDCKA line |
| Bcount | ds | 1 | ; Used to count falling edges on SDCKB line |
| | | | |
| | org | 0 | ; Interrupt routine starts at address 000H |
| | mov | M, #9 | ; Set up MODE register to read WKPND_B |
| | clr | W | ; Clear W to zero |
| | mov | !RB, W | ; Exchange contents of W and WKPND_B |
| | and | W, #00000011B | ; Mask out unused bits from WKPND_B |
| | | | ; W now indicates cause of interrupt: |
| | | | ; 00H = RTCC, 01H = RB0, or 02H = RB1 |
| | add | W, Offset | ; Select table according to current position |
| | add | PC, W | ; Add W to program counter for indirect jump |
| Pos0 | | | ; First position : Standby |
| | jmp | RTCCisr | ; W = 0, jump to RTCC interrupt service routine |
| | jmp | Isr0A | ; W = 1, jump to SDCKA / RB0 ISR 0 |
| | jmp | Isr0B | ; W = 2, jump to SDCKB / RB1 ISR 0 |
| | reti | | ; W = 3, unexpected event |
| Pos1 | | | ; Second position : Pattern being received |
| | jmp | RTCCisr | ; W = 0, jump to RTCC ISR |
| | jmp | Isr1A | ; W = 1, jump to SDCKA / RB0 ISR 1 |
| | jmp | Isr1B | ; W = 2, jump to SDCKB / RB1 ISR 1 |
| | reti | | ; W = 3, unexpected event |
| | | | |
| RTCCisr | nop | | ; RTCC ISR here |
| | reti | | |
| | | | |
| Isr0A | | | ; SDCKA / RB0 ISR 0 starts here |
| | mode | 10 | ; Select WKED_B |
| | mov | !RB, #11111110B | ; Pattern ends with rising edge on RB0 / SDCKA |
| | clr | Bcount | ; Reset SDCKB falling edges counter |
| | mov | Offset, #(Pos1 - Pos0) | ; Compute and save offset for next position |
| | reti | | |
| Isr0B | nop | | ; SDCKB / RB1 ISR 0 starts here |
| | reti | | |
| | | | |
| Isr1A | nop | | ; SDCKA / RB0 ISR 1 here |
| | reti | | |
| Isr1B | nop | | ; SDCKB / RB1 ISR 1 here |
| | reti | | |
En rouge le traitement effectué par la routine d'interruption suite à la détection d'un début de fanion :- Inversion de la sensibilité sur RB0 pour que la prochaine interruption se produise en fin de fanion avec la transition positive sur SDCKA.
- Le compteur de transitions négatives sur RB1 / SDCKB est réinitialisé à zéro.
- La position logicielle est modifiée, elle évolue de "Attente / Stanby" à "Réception de fanion en cours / Pattern being received".
La présence d'un fanion ayant été détectée, il va alors être nécessaire :
- De compter les transitions négatives sur SDCKB / PB1 afin de pouvoir déterminer par la suite le type de fanion reçu.
C'est la routine d'interruption Isr1B qui effectue ce job. - De traiter le fanion une fois complet, c'est le front montant sur SDCKA / PB0 qui en délimite la fin.
La position logicielle devra à nouveau évoluer vers celle spécifique au type de fanion reçu, c'est la routine Isr1A qui va effectuer cette tâche.
| Isr0A | | | ; SDCKA / RB0 ISR 0 starts here |
| | mode | 10 | ; Select WKED_B |
| | mov | !RB, #11111110B | ; Pattern ends with rising edge on RB0 / SDCKA |
| | clr | Bcount | ; Reset SDCKB falling edges counter |
| | mov | Offset, #(Pos1 - Pos0) | ; Compute and save offset for next position |
| | reti | | |
| Isr0B | nop | | ; SDCKB / RB1 ISR 0 starts here |
| | reti | | |
| | | | |
| Isr1A | | | ; SDCKA / RB0 ISR 1 starts here |
| | mov | W, #11110001B | ; Mask for hiding bits 1 to 3 |
| | and | W, Bcount | ; Check Bcount |
| | sz | | ; Keep only even count less than 16 |
| | jmp | Count0 | ; Others discarded |
| | mov | W, Bcount | ; Get the even count in W |
| | add | PC, W | ; Add W to PC for indirect jump |
| | | | |
| Count0 | | | ; Table of jumps, 8 × 2 instructions |
| | clr | Offset | ; Spurious pulse on SDCKA line if count zero else unused patterns |
| | jmp | PattEnd | ; Return to standby |
| | clr | Offset | ; Count 2 : Unused pattern, return to stanby |
| | jmp | PattEnd | |
| | mov | w, #(Pos2 - Pos0) | ; Count 4 : «Start» pattern |
| | jmp | Count4 | |
| | clr | Offset | ; Count 6 : Unused pattern, return to standby |
| | jmp | PattEnd | |
| | mov | w, #(Pos3 - Pos0) | ; Count 8 : «SDCKB occupancy permission» pattern |
| | jmp | Count8 | |
| | clr | Offset | ; Count 10 : Unused pattern, return to standby |
| | jmp | PattEnd | |
| | clr | Offset | ; Count 12 : Unused pattern, return to standby |
| | jmp | PattEnd | |
| | page | $07FE | ; Count 14 : «Reset» pattern |
| | jmp | $07FE | ; Jump immediatly to SX28 reset vector |
| | | | |
| Isr1B | | | ; SDCKB / RB1 ISR 1 starts here |
| | inc | Bcount | ; Count falling edges on SDCKB / RB1 wire |
| | reti | | |
La routine Isr1A (en rouge) est appelée par la transition positive sur PB0 / SDCKA. Cette transition détermine la fin du fanion.- Le compteur Bcount qui a permis de comptabiliser les transitions sur PB1 / SDCKB est testé. Un nombre de transitions impair ou «supérieur ou égal à 16» est rejeté. Le fanion reçu est alors ignoré et le logiciel retourne en position standby.
- Le nombre de transitions étant reconnu pair et plus petit que 16, sert à indexer une table de 8 lignes, chaque ligne comportant deux instructions. Ces deux instructions permettent d'accepter le fanion ou bien de le rejeter et de retourner à la position standby.
- En cas d'acceptation, exception faite du fanion «Reset», l'offset associé à la nouvelle position logicielle est calculé et la routine d'interruption se poursuit avec un traitement différent pour chaque type de fanion. («Start» ou «SDCKB Occupy authorization»).
La routine Isr1B (en bleu) appelée par une transition négative sur PB1 / SDCKB comptabilise ces transitions.
Le traitement de fin de la routine est pratiquement la même quelque soit le type de fanion reçu. Seul le fanion «Start» prépare la réception des données qui le suivent en réinitialisant le compteur de bits et le compteur d'octets avant de rejoindre le tronc commun.
| Count4 | | | ; Ends ISR for the «Start» pattern |
| | clr | BitCnt | ; Reset bit counter |
| | clr | ByteCnt | ; Reset byte counter |
| | | | |
| Count8 | | | ; Ends ISR for the «SDCKB occupancy permission» pattern |
| | mov | Offset, W | ; Save offset for new position |
| | | | |
| PattEnd | | | ; Ends ISR for all patterns, even those rejected |
| | mode | 10 | ; Select WKED_B |
| | mov | !RB, #11111111B | ; Falling edge on RB.1 and RB.0 |
| | reti | | |
La réception du fanion «Reset» est le cas à part puisqu'elle entraîne immédiatement la réinitialisation du SX28 par appel à son vecteur de reset localisé à l'adresse $07FF (c'est l'adresse de la dernière ligne de la mémoire programme). En fait il s'agit d'une instruction de saut court localisée en $07FF que le SX28 va rechercher à cette adresse immédiatement après un reset.
Le problème est que le vrai reset réinitialise préalablement les registres internes, dont les bits de pagination, avant d'exécuter l'instruction de saut du vecteur alors qu'un appel par programme ne le fait pas. C'est pour cette raison que l'appel du vecteur se fera plutôt sur l'adresse qui le précède, en $07FE, où l'on aura pris soin d'insérer une instruction de positionnement de page.
| RESET | Init | | ; Reset Vector @ $07FF |
| | ... | ... | |
| | org | $07FE | |
| | page | 0 | ; Reset page number before using reset vector. |
La directive assembleur "RESET" est, en principe, placée au début du programme source.
Maintenant que cet algorithme de décodage est établi et son déroulement simulé avec le programme SXSim cité dans le précédent message, il ne reste plus qu'à le tester en grandeur réelle avec différents fanions qui seront générés dans un premier temps grâce à la fonction générateur de l'analyseur Scanalogic 2.
A suivre...
gc339 tu pourrais nous mettre un présentation rapide du micro pour qu'on puisse comparer au 4550 de l'upcb et avoir une petite idée de ce qu'il apporte?
Le SX28 de Scenix/Parallax/Ubicom est aux micro-contrôleurs de la famille PIC16C5x de Microchip un peu ce qu'était le Z80 de Zilog vis à vis du 8080 d'Intel. - Le jeu d'instructions de base est le même bien que les mnémoniques du langage assembleur différent.
- Il possède de nombreuses améliorations dont un mode turbo qui permet d'exécuter une instruction par cycle d'horloge au lieu de quatre cycles.
- Il a aussi été conçu à l'origine pour fonctionner à des vitesse d'horloge supérieures à 50MHz, des exemplaires triés pouvaient même fonctionner à 100MHz soit 10ns par instruction en mode turbo.
Son seul avantage par rapport au PIC4550 est sa vitesse et peut-être aussi sa rusticité. Le jeu d'instruction ainsi que la mémoire programme et la mémoire vive sont moins étendus, le nombre de périphériques internes est aussi limité, par d'interface USB, ni d'interface I2C ...
Peut-être eut il mieux valu faire cet expérimentation de décodage du Maple bus avec un micro-contrôleur plus moderne de la famille PIC32 fonctionnant avec une horloge interne à 80MHz !
Cette petite carte de développement à base de PIC 32MX340F512 vendue chez Lextronic à un prix plutôt sympathique : http://www.lextronic.fr/P4629-platine-de-developpement-pic-p32mx.html a attiré mon attention. Son seul défaut étant de ne pas posséder de port USB !
(http://www.olimex.com/dev/images/PIC/PIC32-1.jpg)