Sirion – Thylacine
8 sujets de 1 à 8 (sur un total de 8)
-
En parcourant le net, je suis tombé sur ce paquet
thylacine.boing.net/Thylacine1.3.lha
C’est le paquet de dev de Thylacine, qui comporte une pile Sirion.
Dans un premier temps j’ai eu un doute: pourquoi me casser la tête à faire une pile alors que cette pile existe déjà… ben j’ai installé et ça marche pas… (normal, je n’ai pas de Thylacine)
Est-ce qu’il faut le 3.5 et 3.9 voir le 4.0 pour utiliser ce truc ?
En désassemblant (je sais, Chris Hodges n’aime pas la manière dont je procède pour évaluer les programmes des autres) usbrestart, usbstop, je découvre que ces outils réclament une « usbprivate.library »:
usbstop passer 1 dans D0 en sautant à l’offet -42().
usbrestart passer 2 dans D0 en sautant à -42().
usbstart se contente d’ouvrir le usbsys.device avec un zoli OpenDevice(). mais bon ca provoque un guru comme je n’ai pas la carte…
USBInspector
réclame une structure dans usbprivate.library, puis des objets re-action.Je pensais qu’il suffisait de simuler usbsys.device pour être comme Sirion, mais non… 😡 c’est plus compliqué.
Quelqu’un peut-il me confirmer l’existence de l’usbprivate.library dans l’OS4.0 quand Sirion tourne ?
Je suis à 60% d’écriture de mon propre usbsys.device.
La veille j’en étais à USBGetEndPoint() et USBEPControlXferA().
reste plus qu’à finir et tester la chose… :sweat: Comme disait Desproges, le doute…
Oh le vilain curieux !
Ben oui, d’ailleurs c’est la première fois que je la remarque.
Mais à mon avis, comme son nom l’indique, cette lib n’est pas nécessaire pour réimplémenter l’API de Sirion, elle est juste là pour les outils annexes, comme tu pourrais faire une usbanaiis.library du même style, si nécessaire.
coucou centaurz
(Tu es témoin, ton petit bout de code d’il y a deux mois à fait des p’tits !
)Je me demandais justement quels outils je pourrais récupérer…
Or:
usbstart a malheureusement le même nom que le programme principal de ma pile, qui contient tout, comme ça pas d’encombrement dans devs:. Il suffirait de faire un anaiis.device dans devs: mais bof…
usbstop c’est juste un envoi de message iorequest « stop », or pour Sirion, c’est un saut dans la fameuse usbprivate.library
usbrestart, c’est l’équivalent de mon usbreset, là aussi que je gère avec un envoi de message io « reset ».
usbinspector se sert de structures non documentées de usbprivate.library (d’où son nom de private)
Je pense que cette version est trop vieille pour supporter le tag SeeClaimed des USBFindInterface ou USBFindFunction.
Il me faudrait un USBInspector qui fonctionne en 3.1 avec la dernière API usbsys.device (mais il n’existe pâââs!)
Je ne sais pas si c’est une bonne idée de faire aussi une « usbprivate.library », ne sachant pas trop ce qu’elle peut contenir et qu’en plus elle doit être de version/révision 1.1 dans ce paquet.
En plus au niveau doute: je confond allègrement interface et fonction: pour moi c’est kifkif, pareil, du même tonneau. Est ce que quelqu’un(voire une) pourrait m’expliquer la différence?
Oui la pile Sirion que tu as récupérée est bien l’ancêtre de celle actuellement fournie avec l’OS4.0, mais ça fait un bout maintenant…
A mon avis comme le dit Centaurz usbprivate.library n’est utile qu’aux outils internes de la pile en dehors d’eux personne n’y accède. A mon avis cette librairie est créée dynamiquement au démarrage de usbsys.device certainement via un MakeLibrary() elle est donc spécifique à chaque release de la pile.
Je confirme également que ta pile n’aura certainement pas le tag SeeClaimed car il a été rajouté dans la version de la pile livrée avec l’update 4 ou l’oS4Final je ne me souviens plus.
Pour finir la différence entre une fonction et une interface est plutôt simple : prenons le cas d’une imprimante Canon MP520 du point de vue de la pile USB il s’agit d’une fonction (au passage c’est le terme utilisé dans les specs USB) en revanche comme elle est à la fois imprimante et scanner elle fourni deux interfaces : une pour la partie imprimante et une pour la partie scanner (et peut-être même une troisième pour accéder en mode MassStorage à sa mémoire interne pour récupérer les scans).
En gros une fonction correspond à ton périph en entier alors qu’une interface correspond à l’une des fonctionnalités qu’offre celui-ci.
Un pilote de type fonction va verrouiller la totalité du périphérique qui deviendra donc inaccessible aux autres pilotes, tandis qu’un pilote de type interface ne va verrouiller que la partie qui l’intéresse laissant ainsi libre les autres fonctionnalités pour d’autres pilotes sachant gérer cela.
En gros : « Divide and conquer »
Pour faire une analogie orientée objet : une fonction est une classe, et une interface est… une interface
Une classe pouvant implémenter plusieurs interfaces différentes (ou non d’ailleurs) à la fois, si tu veux faire du code un peu générique tu vas utiliser le polymorphisme et paramétrer tous tes codes avec l’une ou l’autre des interfaces plutôt que par la classe elle-même… Enfin cela ne t’éclairera que si tu as quelques notions de programmation objet sinon ça va t’enliser encore un peu plus
/ Merci Alex pour cette belle explication.
Je vais l’imprimer et l’encadrer au dessus de mon PC.
Fonction => le device.
Interface => une des différentes possiblilités offertes par le device.
Autrement dit je peux laisser tomber ce paquet obsolete Thylacine et développer sereinement ma tite pipile dans mon coin. Peut-être faut il que je change les noms de mes exécutables qui peuvent prêter à confusion et utiliser moi aussi MakeLibrary() pour éviter de polluer devs:
Quoique usbstart, usbstop, usbreset c’est assez générique comme noms.
Est-ce que les commandes usblist et usblist1 que j’ai mis sur aminet sont équivalentes à USBInspector ? (USBFindInterface avec le tag SeeClaimed=TRUE, comme le source passé par centaurz dans un autre fil d’ici)
En regardant l’API usbsys.device, il est flagrant qu’on ne peut pas gérer le mode isochrone: il faudrait pouvoir réserver une bande passante pour gérer un nombre limité d’interfaces. Les requêtes aux « endpoints » sont sérialisées et ne peuvent pas être prises en compte en temps réel.
Je comprends mieux maintenant pourquoi il y tant de tension entre Siron/Poseidon…
Qui s’occupe de Sirion sur OS4? (si ce quelqu’un existe
) Qui s’occupe de Sirion sur OS4? (si ce quelqu’un existe )
A l’origine, c’était Thomas Graff (il existe vraiment, j’ai déjà vu un de ses posts sur utilitybase
, mais il ne donne plus beaucoup de signes de vie.Je crois que TetiSoft a fait des petites modifs sur la pile juste avant la dernière maj d’OS4. RWO quand à lui travaille depuis longtemps sur des nouvelles classes (ptp…) et on dirait bien qu’il a accès aux sources de Sirion.
Au niveau de la compatibilité, du moment que tu arrives à être le plus possible compatible avec le usbsys.device, à mon avis c’est déjà très bien. Le reste (ce qui est privé…) sert juste pour afficher des infos secondaires sur l’état de la pile et l’arborescence du bus, et rien ne t’empêche par exemple d’afficher plus d’infos que Sirion là-dessus.
Autrement dit je peux laisser tomber ce paquet obsolete Thylacine et développer sereinement ma tite pipile dans mon coin.
Je pense que le fait d’être compatible niveau API avec Sirion est un réel plus car permet d’avoir une audience plus large. En plus si par la suite tu développes des extensions si ça se trouve un jour ce sera Sirion qui copiera l’API d’ANAÏS
Est-ce que les commandes usblist et usblist1 que j’ai mis sur aminet sont équivalentes à USBInspector ?
/ Je n’ai malheureusement pas encore pris le temps de tester tes outils sur mon OS4… Faut vraiment que j le fasse.En regardant l’API usbsys.device, il est flagrant qu’on ne peut pas gérer le mode isochrone: il faudrait pouvoir réserver une bande passante pour gérer un nombre limité d’interfaces. Les requêtes aux « endpoints » sont sérialisées et ne peuvent pas être prises en compte en temps réel.
Je pense qu’en effet l’API actuelle ne propose pas de quoi réaliser des transferts isochrones, mais rien n’empêcherait d’ajouter cela dans l’API existante.
Qui s’occupe de Sirion sur OS4?
Je confirme ce que centaurz a dit (ça devient une habitude
à l’origine c’était Thomas Graff et il semblerait que TetiSoft a corrigé des bugs dans les deux dernières versions et que RWO ai développé des nouveaux drivers mais dernièrement qu’il serait aussi en train de faire évoluer la pile elle-même.
8 sujets de 1 à 8 (sur un total de 8)
- Vous devez être connecté pour répondre à ce sujet.
