Quelle combinaison choisir pour brancher les périphériques sur les nappes ?

voila le protocole d'échange pour ce type de bus:
-Demande par A
-Lecture par B de l'adresse et envoie ACK
-A lit ACK et attend
-B place la donnée sur le bus et le signale
-A lit la donnée et envoie ACK
-B lit ACK et libére le bus
-A libére le bus


"Esus" <SA.NSesus@MAJonline.frUSC.ULES> a écrit dans le message de
news:bepgg9$ql$1@biggoron.nerim.net...

Étant donné que les deux périph ne peuvent pas utiliser le bus en même
temps, il y a la valeur de l'interruption qui est prise en compte, et
c'est

l'interruption du periph maître qui est prioritaire. L'esclave ne
communique

que lorsque le maîtres rend le signal ACK de fin. (ne pas oublier que ce
sont des périphériques asynchrones).

Voilà qui deviens interressant...

Peux tu donner les étapes d'un transfert?
Je penses que l'esclave rends un ACK également, plus un DASP, pourquoi
faut

il utiliser une interruption si l'esclave remprends son traffic? Elle peut
servir en cas où les 2 unités sont sollicitées en même temps pour laisser
le bus au maître, mais vu que les unités n'envoient pas de données sans en
recevoir commande (et donc réservation du bus faite) il n'y a que là que
ça

peut servir... Je ne vois pas l'intérêt d'attendre une confirmation du
master dans la mesure où cette interrupt existe...

"aymen" <jouaymen@numericable.fr> a écrit dans le message de
news:3f105ea2$0$17913$a3f2974a@nnrp1.numericable.fr...

voila le protocole d'échange pour ce type de bus:
-Demande par A
-Lecture par B de l'adresse et envoie ACK
-A lit ACK et attend
-B place la donnée sur le bus et le signale
-A lit la donnée et envoie ACK
-B lit ACK et libére le bus
-A libére le bus

Merci. Si je comprends bien: le port voit "globalement" le message comme
venant de A (master) mais avec l'adresse réelle (A ou B) fixée par la
gestion maître/esclave.

As-tu des liens à conseiller pour voir plus en profondeur le protocole? Faut
que je me remette dans le hardware, ça fait trop longtemps que je ne me suis
pas repenché sérieusement sur ces questions.

Esus

Je n'es pas d'adresse en tête, mais le meilleur endroi pour trouver des info
sûres, c'est d'aller chercher les cours sur internet des ecoles d'ing.
spécialisées en Info.
@+

"aymen" <jouaymen@numericable.fr> a écrit dans le message de
news:3f1164c1$0$17905$a3f2974a@nnrp1.numericable.fr...

Je n'es pas d'adresse en tête, mais le meilleur endroi pour trouver des
info

sûres, c'est d'aller chercher les cours sur internet des ecoles d'ing.
spécialisées en Info.

J'avais déjà fouillé un peu de ce côté... Bon j'insisterai alors! :o)

IDE1 DD 7200 (maître)
DD 5400(esclave)

Mais dans ce cas là, le vendeur de mon graveur
m'a dit que mon DD à 7200 tr/mn allait tourner à 5400!
Ce qui ne m'enchante pas du tout...
Et d'autre part, pourrai-je booter sur l'OS (Linux) du DD 5400,
car j'ai lu sur des sites web que ce n'était pas possible de
booter sur un OS installé sur un DD esclave ?
Lydie

Chez moi j'ai:

nappe1: DD 20Go en maître (disque de boot)
Lecteur DVD en slave
nappe2: Graveur CD en maître
DD 40 Go en slave

et je n'ai pas de problème. Pas de problème non plus pour Linux qui
est sur le DD 40 Go

Sherwen

On Sat, 12 Jul 2003 18:56:32 +0200, Esus wrote:

L'IDE n'est pas comme le SCSI, la chaîne ne tourne pas à la vitesse du
périph le plus lent!

Non, le SCSI ne pose pas non plus ce type de probleme. Maintenant,
lorsqu'un periphérique "lent" transfert x octets sur le bus, le bus
restera "bloqué" plus longtemps que lorsque le transfert est effectué
par un périphérique "rapide". Mais c'est tout pareil en IDE sauf
qu'avec ses 2 periphériques max sur le bus, le probleme est moins
critique.

François

"Annie D." <annie.demur@free.fr> a écrit dans le message de
news:3F18997D.403B9EB4@free.fr...

B'soir/nuit

Voici ce que j'ai retenu de mes lectures de diverses spécification ATA.

1. Contrairement à ce que vous écriviez, les transferts de données sont
_synchrones_, cadencés par un signal d'horloge. Il n'y a pas de signal
d'acquittement ACK à chaque donnée transférée. Il n'y a pas non plus de
notion d'adresse, les octets ou les mots de 16 bits sont transférés
séquentiellement du premier au dernier.

Ca me semble plus logique, vu mes infos. Mais j'ai un peu de mal à les
organiser...
Dans mon vieux Macmillan est cité pour l'interface ATA normale le flag DRV
(bit dans les blocs de commandes) pour la sélection d'un des 2 contrôleurs,
et du signal DASP (broche 39) pour distinguer quelle est l'unité active.
Cela permet de toute évidence, avec la notion de maître/esclave, de réaliser
un adressage par multiplexage.
Toute fois il y a des signaux DRQ3, DACK3 (broches 21&29) qui me laissent
perplexe!

3. En mode Ultra DMA(...)
Autre différence, les deux fronts du signal d'horloge, montant et
descendant, donnent lieu au transfert d'un mot de 16 bits.

Attention, l'interface IDE ATA a toujours été de 16 bits contrairement l'IDE
XT (8 bits, utilisés par les XT et les premiers AT PS/2). Le double front
permet d'augmenter le débit mais pas la taille des mots. En te lisant on
peut comprendre que les 16 bits viennent du double front!

la période minimum en Ultra DMA mode 2 est 120ns, correspondant à une
fréquence maximum de 8,33MHz, et à un débit maximum de 33,3Mo/s.

Pour souligner ton exemple, en mode d'entrées/sorties programmées à 120 ns
(PIO 4, norme ATA-2), on a un taux de transfert (débit) de 16,6 Mo/s, mais
dans ce mode le double front n'est pas utilisé.

Le transfert des données se fait alors par une connexion VL-bus ou au bus
local PCI et il est géré par le processeur.
En mode DMA, ce transfert se fait directement avec la mémoire et il est géré
soit par le contrôleur DMA soit par le chipset de l'interface IDE même (le
southbridge de nos jours). Ce dernier cas est appelé DMA avec asservissement
de bus.

Je précise ces points sur le transfert car la question a été soulevée
précédement! ;o)
Je ne fais là que résumer mon cher Macmillan (l'édition spéciale de 1997
pour la maintenance et l'upgrade hardware).

Esus

aymen wrote:

Donc si je mets un disque UDMA mode 5 en maître avec un vieux DMA 2 en
esclave, comme par magie ce dernier aura aussi le débit du mode 5 UDMA ?

Non,

Merci de reconnaître que ce que vous aviez écrit était faux.

mais si tu mets un UDMA2 en maitre et un UDMA5 en slave l'UDMA2, est
utilisé pour les deux.

Non. Chaque disque utilise son mode indépendamment de l'autre.

Tu peux faire le test si ça t'interresse avec un benchmark pour avoir la
vitesse de transfert de tes disques dures, tu verra.

Déjà fait, il y a pas mal de temps. Résultat sans appel : chaque
périphérique se comporte exactement de la même façon qu'il soit seul sur
le canal ou avec un autre périphérique utilisant un mode différent. Y
compris en mélangeant des périphériques Ultra DMA et non Ultra DMA.

Étant donné que les deux périph ne peuvent pas utiliser le bus en même
temps, il y a la valeur de l'interruption qui est prise en compte, et
c'est

l'interruption du periph maître qui est prioritaire.

Ça me paraît difficilement réalisable : les deux périphériques d'un
canal IDE partagent le même signal d'interruption INTRQ utilisé à tour
de rôle, donc de ce point de vue ils ont la même priorité.

Excellent ! et c'est pour ça, qu'on utilise le systeme de priorité
Maitre/Esclave.
Pour determiner qui passe avant l'autre.

Vous ne voulez toujours pas l'admettre, hein, qu'il n'y a pas de
priorité en IDE. En IDE, au plus un seul des deux périphériques d'un
canal est actif à un moment donné, et c'est le système hôte qui décide
avec lequel des deux il travaille. Pendant ce temps, l'autre est
inactif, il n'a rien à demander. Tant qu'on ne lui demande pas
d'exécuter une opération, c'est comme s'il n'existait pas. Et l'hôte ne
peut pas demander une opération aux deux en même temps. Il n'y a donc
tout simplement pas de priorité à gérer.

Notez au passage qu'au moins à partir de l'ATA-2, les dénominations
maître et esclave disparaissent et sont respectivement remplacées par
"device 0" et "device 1", éliminant toute notion de supposée hiérarchie
ou priorité.

Le signal ACK est envoyé sur le bus lors d'un demarage d'une session et sa
fin, pour les peripheriques qui n'ont pas un temps processeur alloué.

C'est peut-être de la belle théorie comme celle qu'on enseigne à l'école
ou dans les livres, mais ceci n'a rien à voir avec le fonctionnement
décrit dans les spécifications du protocole ATA. Les avez-vous au moins
lues ?

Petite explication:
Il ya deux façon de gerer les peripheriques:
-Pooling:

C'est "polling". Si vous voulez avoir l'air crédible, au moins écrivez
correctement les termes techniques que vous employez.

le processeur verifie à intervalle regulier l'etat E/S du periph,
(ex: RAM)

Drôle d'exemple de périphérique que la RAM. Par contre on peut utiliser
le polling avec un périphérique IDE. Bien sûr, ce n'est pas très
efficace en occupation CPU, il vaut mieux utiliser les interruptions si
on a autre chose à faire en attendant la fin d'une opération.

-Interruption: Le periph envoie une interruption, pour reclamer un temps
processeur.

Plutôt pour réclamer son attention. Le temps alloué, c'est autre chose.

Dans ce deuxième cas lors des communication il ya un signal qui s'appelle
ACK qui permet aux deux composants de demmarer une communication et en suite
une deusieme fois de la terminer.

Ça, c'est vous qui le dites et je me demande bien d'où vous le sortez.
Mais ça ne se passe pas comme ça en IDE/ATA.

Je vais vous décrire brièvement le déroulement d'une opération de
transfert IDE tel que je l'ai compris. Certains aspects sont un peu
simplifiés.

1. Le système hôte envoie une commande sur le bus en écrivant dans une
série de registres (type d'opération, numéro de cylindre, tête, secteur,
nombre de secteurs...). Les deux périphériques du canal reçoivent cette
commande, aussi l'état d'un des bits dans un des registre, appelé DEV
pour "device", spécifie le périphérique adressé : 0 pour Device 0 ou
maître, 1 pour Device 1 ou esclave. Seul le périphérique concerné est
actif par la suite.

2. Supposons une opération de lecture de secteurs. A réception de la
commande, le disque l'exécute : il va déplacer ses têtes, lire les
secteurs demandés sur les plateaux et les placer dans une mémoire tampon
(buffer) interne. Pendant ce temps, il signale au système hôte qu'il est
occupé en activant un bit BSY (pour "busy") de son registre d'état, que
le système hôte peut lire.
Pendant ce temps, l'autre périphérique est inactif.

3. Quand les données sont dans le tampon, prêtes à être transférées vers
le système hôte, le disque désactive le bit BSY et active le bit DRQ
("data request") dans son registre d'état pour demander le transfert des
données. En même temps, il active le signal de demande d'interruption
INTRQ ("interrupt request"). Ainsi, le système hôte dispose de deux
moyens de savoir que le périphérique est prêt à transférer les données,
soit par interruption, soit par polling.
Pendant ce temps, l'autre périphérique se tourne les pouces.

4. Le transfert des données peut s'effectuer selon plusieurs modes :
PIO, Multiword DMA, Ultra DMA, selon les capacités du disque et du
système hôte.

4.1 En mode PIO, le système hôte reçoit les données de façon "classique"
en lisant plusieurs fois un registre particulier du disque. A chaque
lecture, ce registre contient une nouvelle donnée. La lecture utilise
les signaux de sélection et d'adresse CS0, CS1, DA0 DA1 et DA2 du bus,
et le signal de lecture DIOR ("data input/output read") qui synchronise
les transferts.

4.2. En mode Multiword DMA, le disque active un signal DMARQ ("DMA
request") pour demander un transfert DMA à l'hôte. Celui-ci prépare le
transfert de son côté et répond en activant un signal DMACK ("DMA
acknowledge"). Ensuite, le disque fournit un mot de donnée à chaque
cycle du signal DIOR piloté par l'hôte. Le transfert est synchrone.
Contrairement au mode PIO, les signaux de sélection et d'adresse ne sont
pas utilisés et restent inactifs.

4.3. En mode Ultra DMA, la mise en place du transfert commence comme en
Multiword avec les signaux DMARQ et DMACK. D'autres signaux spécifiques
sont aussi utilisés : l'hôte désactive le signal STOP et active le
signal HDMARDY ("host DMA ready"). Ensuite, le disque fournit deux mots
de données à chaque cycle du signal DSTROBE ("device strobe") qu'il
pilote, un sur chaque front montant et un sur chaque front descendant.
Le transfert est synchrone.
Pendant ce temps, l'autre périphérique n'en fiche toujours pas une.

5. A la fin du transfert, l'opération de lecture est complètement
terminée. Le bus est libéré et une autre commande peut être envoyée à
l'un ou l'autre disque.

Maintenant, vous pouvez m'expliquer comment vous faites coller votre
théorie avec ça.

Esus wrote:

Toute fois il y a des signaux DRQ3, DACK3 (broches 21&29) qui me laissent
perplexe!

Les véritables noms des signaux de ces broches sont DMARQ et DMACK. Je
décris leur rôle dans les transferts en mode Multiword DMA et Ultra DMA
dans un autre article de ce fil. Je n'en ai pas la certitude, mais je
suppose qu'ils étaient prévus pour être reliés aux paires de signaux de
contrôle DRQn/DACKn des canaux du contrôleur DMA du bus ISA. Toutefois
je trouve curieux que ce soit le canal DMA 3 qui soit alloué à l'IDE,
car c'est un canal 8 bits alors que les modes DMA de l'IDE fonctionnent
en 16 bits.

3. En mode Ultra DMA(...)
Autre différence, les deux fronts du signal d'horloge, montant et
descendant, donnent lieu au transfert d'un mot de 16 bits.

Attention, l'interface IDE ATA a toujours été de 16 bits contrairement l'IDE
XT (8 bits, utilisés par les XT et les premiers AT PS/2).

Ce qui n'empêche pas de réaliser des transferts en 8 bits en mode PIO.

Le double front
permet d'augmenter le débit mais pas la taille des mots. En te lisant on
peut comprendre que les 16 bits viennent du double front!

Ah non, pas du tout ! Chaque front d'horloge transfère un mot de 16
bits, point.

Pour souligner ton exemple, en mode d'entrées/sorties programmées à 120 ns
(PIO 4, norme ATA-2), on a un taux de transfert (débit) de 16,6 Mo/s, mais
dans ce mode le double front n'est pas utilisé.

Voilà. Même raisonnement et même débit en Multiword DMA mode 2.

Le transfert des données se fait alors par une connexion VL-bus ou au bus
local PCI et il est géré par le processeur.

Disons que ça a été prévu pour. Mais rien n'interdit qu'un contrôleur
hôte fasse du DMA avec un mode PIO. De même, rien n'interdit que le
processeur transfère lui-même les données (donc en PIO, programmed
input/output) alors que le disque utilise un mode Multiword DMA.

En mode DMA, ce transfert se fait directement avec la mémoire et il est géré
soit par le contrôleur DMA

C'est ce qu'on peut déduire d'une comparaison entre l'interface ATA et
le bus ISA. Mais il semble que les mauvaises performances du contrôleur
DMA ont conduit à l'abandon de cette possibilité sur les PC 486 à bus
ISA ou VLB. Je n'ai pour ma part jamais vu de canal DMA attaché aux
périphériques IDE. En pratique, ce sont les modes PIO qui étaient
utilisés. Une autre solution plus performante mais également plus
complexe et donc onéreuse aurait été d'intégrer un contrôleur hôtes
ayant sa propre maîtrise du bus système (bus mastering). Mais il a fallu
attendre l'apparition du bus PCI pour assister à la généralisation de
tels dispositifs dans les PC.

soit par le chipset de l'interface IDE même (le
southbridge de nos jours). Ce dernier cas est appelé DMA avec asservissement
de bus.

Solution la plus moderne et de loin la plus efficace, surtout avec un
bus comme le PCI qui a de TRES mauvaises performances en accès PIO.