Schéma orignal[1] - routé


Schéma final


Proto




La belle araignée .../un autre spécimen ...
Rien ne vaut une bonne récup de composants CMS.

Routage (les pistes sont en 12mil soit 0.3 mm)


Carte Interface, taille réelle : 80*55 mm


Interface DSP<=>PC brut de gravure puis étamée/percée


Référence d'utilisation

Cable carte<=>PC

Signal DSP	Pin DB15	Signal SPP	Signal EPP	Pin PC
D0	1	D0	D0	2
D1	2	D1	D1	3
D2	3	D2	D2	4
D3	4	D3	D3	5
D4	5	D4	D4	6
D5	6	D5	D5	7
D6	7	D6	D6	8
D7	8	D7	D7	9
READ	9	STROBE	R/W_	1
PAGEx	10	BUSY	Wait	11
RST	11	INIT	Reset	16
GND	12	GND	GND	18
N.C.	13	N.C.		N.C.
RDY	14	AUTOFEED	DataStrobe	14
IT	15	SELECT IN	AdressStrobe	17

Mise au point

Après réalisation, test de tous les signaux via routine de test dans ti_util.
Chargement de ti_test à la place du kernel, signal carré à 2Hz sur XF0

Bench

• Le mode Compatible (BGenio) correspond à l'utilisation d'un driver 'haut-niveau' type DlPortIO, c'est à dire effectuant un appel de driver(DeviceIoControl) lors de chaque E/S.
• Le mode User Port consiste à effectuer les E/S directement depuis l'appli haut niveau(sans appel de driver donc). Sous NT/2K/XP, il est nécessaire d'autoriser ces accès via un soft externe type UserPort.
• Le mode Driver(COMDSP) correspond à un driver fait spéciallement pour l'application. Les E/S sont effectuées directement en assembleur depuis le driver. Il n'y a donc qu'un seul appel au driver par envoi/réception de paquet

• Le transfert d'un octet nécessite en mode standard 4 E/S.
  • 1 lecture pour vérifier qu'il y'a réellement un cycle en attente
  • 1 écriture pour sortir les 8 bits de données
  • 1 écriture pour mettre à 1 le signal de 'strobe'
  • 1 écriture pour mettre à 0 le signal de 'strobe'
    
• Le mode EPP (fonctionnement de l'EPP)(utilise le port // en mode EPP), permet d'effectuer un cycle en 2 E/S
  • En EPP, les fonctions des différentes pattes sont changées. En renvoyant l'opposé de DataStrobe (pin 14) sur Wait (pin 11), le cycle se déroule au plus vite possible (on peut également 'bloquer' le signal Wait à 0 ou 1 si il n'y a pas de demande de cycle - ce qui se traduira par un timeout au niveau de l'EPP).
  • On doit donc effectuer 1 écriture (qui sort les données et active le strobe)
  • 1 lecture pour évérifier qu'il n'ya pas eu de timeout (indiquant qu'il n'y avait pas de cycle de deamndé)
• Le mode Fast permet de retirer une E/S (Le mode Fast ne vérifie pas qu'un cycle est réellement demandé. Une seule vérification est alorsréalisée à la fin du transfert). En EPP le mode Fast vérifie pas qu'il n'y a pas eu de timeout uniquement à la fin du transfert.
• Le mode 16 bits en EPP permet en théorie de diviser le nombre d'E/S par 2 [une E/S effectue 2 cycles de 16 bits]. En réalité, il y'a une surcharge équivalente au temps d'1/2 E/S
• Le mode 32 bits permet en théorie de diviser le nombre d'E/S par 4 [une E/S effectue 4 cycles de 16 bits]. En réalité, il y a une surcharge équivalente au temps d'1/2 E/S

Le mode Compatible (BGENIO), standard est celui qui contient le plus de vérifications et permet donc de trouver l'origine d'un problème de transfert.

Les taux indiqués sont les taux réels sur des paquets de 16380 octets (aucune autre occupation de la machine). Machine : PIII 500MHz.

	SPP		EPP
	8 bits		8 bits		16 bits		32 bits
	Standard	Fast	Standard	Fast	Standard	Fast	Standard	Fast
Mode Compatible (BGENIO)	22 Ko/s	30 Ko/s	44 Ko/s	87 Ko/s	86 Ko/s	162 Ko/s	164 Ko/s	287 Ko/s
Mode UserPort (accès direct)	146 Ko/s	188 Ko/s	272 Ko/s	541 Ko/s	409 Ko/s	810 Ko/s	545 Ko/s	820 Ko/s
Mode Driver (COMDSP)	148 Ko/s	193 ko/s	N.A.	511 Ko/s	N.A.	630 Ko/s	N.A.	682 Ko/s

En mode compatible, le temps d'appel du driver est le facteur le plus limitant. Limiter le nombre d'appels au driver est le plus rentable.

En mode User Port, il n'y a aucun appel de driver, les vitesses sont d'une part plus élevées et sont à ce moment limitées par le reste des composants du système (chip Super I/O contenant le port //, pont PCI/ISA, vitesse du proc du PC, code 'non utile' pour la transmission - appel de fonction C, tests, etc). A noter que les performence en mode User Port sont boostée lorsque qu'une machine virtuelle 16 bits (ntvdm standard démarré dès qu'on démarre une application 16 bits sous Windows NT/2K/XP) est en chargée en mémoire. (?!?!)
Explication : due à une boucle d'attente n'ayant normallement pas à attendre à base de sleep(1)

En mode driver, les appels au driver, bien que largement moins fréquent (1 seul par paquet) sont toujours TRES couteux en temps d'appel. A noter qu'en interne le temps réellement mis par le driver pour effectuer l'envoi correspond à un taux de transfert de 1.1Mo/s. L'envoi d'un paquet de 16380 octets à 1.1Mo/s prend 14,8 ms environ. Le taux réel de 682 Ko/s correspond à un temps de 24,017 ms, soit 10 ms de perdues dans la nature par envoi.

Attention les appels qui sont utilisés sont les plus basiques, il est possible d'effectuer des appels 'Fast', normallement plus rapides [infos sur les performences des appels au drivers NT - allemand].