Expérimentation avec le microcontroleur SX28 Scenix/Parallax/Ubicom

[gc339]

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 permet de télécharger toutes les notices ainsi que les logiciels nécessaires à cette expérimentation.

Il est aussi possible d'acheter individuellement sur ce site les fournitures et les composants nécessaires à un développement pour un coût modique :

La carte de développement SX Tech Board

L'interface USB permettant seulement la programmation SX Blitz

L'interface USB permettant la programmation et le débogage SX Key

Le micro-contrôleur SX28 SX28AC/DP-G

Les résonateurs, les quartz ou les oscillateurs

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

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.


Le logiciel SC-Key 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.
• 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 facilement réalisable par un amateur.
  • Du logiciel libre IC-Prog pour le faire fonctionner.
• D'utiliser le simulateur SX-Sim 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.

La fenêtre du logiciel Sx-Key :

La fenêtre principale du simulateur SX-Sim :

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".

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 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)
• SXSim_2_08_06.zip‎ (106.3 KB

La fenêtre du logiciel IC-Prog :

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 :

• 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 18V_DC est disposée à droite.
• Le circuit imprimé du Fluffy2 a été gravé ici.
• 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 V_DC est assurée par un bloc alimentation indépendant qui s'enfiche directement dans une prise secteur domestique.

A suivre ...

[gc339]

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.

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.

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".

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...

[BigPanik]

c'est super, mais pourquoi ne pas avoir utilisé le hardware de l'upcb?

BP

[keube]

c'est super, mais pourquoi ne pas avoir utilisé le hardware de l'upcb?

BP

Regarde le topic sur le décorticage des manettes dreamcast de gc339 le micro PIC a l'air d'être un peu léger pour le décodage du protocole mapple. D'ailleurs il me semble bien que Toodles l'a implémenté sur le Chtulu, cette carte est basée sur quel micro? 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?

[gc339]

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 !

[keube]

merci bien
On peut effectivement imaginer que si le pic 4550 était limite le SX28 devrait passer avec une fréquence supérieure et un mode boost. Sinon quelqu'un sait sur quel micro Toodles a fait son cthulu avec lequel il aurait réussi à s'interfacer avec la dreamcast?

[speedsterharry]

"Q: I have a Cthulhu, but I don't know if I have a PS3 only version, or an MC Cthulhu. How can I tell the difference?
A: If the Cthulhu is assembled, just plug it into a PC and check the game controller applet in the Control Panel. The name should be very clear about whether it is meant for PS3/PC or is a MultiConsole version. If the Cthulhu is unassembled, look in the bag for a set of four diodes; MC Cthulhu kits come with diodes, but PS3 Only versions don't. If you're looking at just the chip, look at the first row of text on the chip; the PS3 Only version will have the text 'F24' on it, usually 18F2450. The MC Cthulhu will have the text 'F25' on it, usually 18LF2550."