Helios est prêt

[BatteMan]

BatteMan

#107803

Yomgui : Je me lève tôt

Moi aussi je suis bien content, et pas que pour toi !

—

/me postera donc une news demain matin bonne heure, voire bonheur !

Only Amiga makes it possible !

[Yomgui]

Yomgui

#107804

Et voilà….

[edit] c’est sur Aminet maintenant

Petite info, la version de l’archive n’est pas la version des binaires… c’est dissocié et c’est fait exprès!

Pour le reste… lisez le readme… je me suis pas fais ch$$$ à l’écrire pour rien non plus

/me qui écrit ce post depuis OWB sur MorphOS (avec un microscope, hein fab )

[CLS2086]

CLS2086

#107805

Good !

Tu as pu tester quel type de flux en capture ?

[BatteMan]

BatteMan

#107806

Et hop, tu n’as même pas mis ton archive en ligne à 4h00 du mat’

Du coup la news est en ligne ! Merci Yomgui pour ton boulot de malade !

—

/me essayera ça !

Only Amiga makes it possible !

[Screetch]

Screetch

#107807

Helios reconnait quoi comme type d’extension FireWire ?

Disque durs ?

Camescopes ?

Abonnez-vous à ma nouvelle chronique "En Route vers le Futur" sur Youtube !

[Yomgui]

Yomgui

#107808

Va falloir que j’indique cela dans une FAQ…

Helios ne fait que de gérer la couche transport du firewire, à l’instar du TCP/IP.

Le Firewire ne contient pas de couche applicative.

J’ai juste rajouté un petit bout de code (fonction Helios_ROMGetNodeType()) qui retourne un entier pour indique un type de protocol connue si le device l’indique: AV/C et SBP2 mais cela s’arrete là.

Je suis en train de faire une avc1394.device qui sera elle une couche applicative, servant à controler une caméra par exemple (juste controler, pas obtenir les données d’image/son, pour cela il faut que j’implémente le mode isochrone).

[Yomgui]

Yomgui

#107809

Ce w.e. j’ai fait mes premiers essais de vitesses sur Helios.

Lecture en S400 asynchrone sur la mémoire du Peg1, depuis le Peg2: 10 Mo/s

(5Mo/s en S100).

C’est pas mal pour un code pas optimisé et la façon la plus beurk pour le faire, ainsi que l’utilisation de l’interface en Python pour cela!

Release bientôt prête donc.

[XRAY]

XRAY

#107810

Héhé, pas mal du tout, bravo…et avec le LEP, ça donne quoi;-)

Quel homme ce Yomgui, qui fait pleins de tests avec pleins de trucs:-)

Alors on attend que tu réalise la release

A12C4

XRAY

Consultant @Relec&Home

[Yomgui]

Yomgui

#107811

Je viens tout juste de finir l’optimisation… .je rentre tester!

[Tcheko]

Tcheko

#107812

Alors?

[serge]

serge

#107813

on est dans la bonne voie.

Bientôt, on fera des films qu’on titrera avec Titler d’Amigazeux, qu’on retouchera avec Pixel pour des petits détails et qu’on manipulera avec Blender pour les effets spéciaux. On mixera avec PSA et on encodera le tout avec ffmpeg pour finir par visionner avec Mplayer.

Tout ceci en ayant capturé l’image grâçe à Helios bien entendu

/me rêve d’un logiciel de montage à la MovieShop New Generation manipulant du DV

RyZen Rulez 😉

[Yomgui]

Yomgui

#107814

Alors, bah ça merdouille grave!

J’avais un problème de temps réel (résolus) déjà qui provoqué un premier blocage machine dans une boucle sans fin.

après j’avais un problème d’overflow des 2 pauvres buffers de réception des réponses… que je pensais résoudre en balançant 16! bah non…

J’ai un autre problème plus … problématique!

Je loupe encore des réponses! Les requêtes sont bien toutes envoyées, mais par exemple sur 512 requêtes (de 2048 octets, soit 1Mo de transfert) je loupe 396 réponses: elles n’arrivent jamais dans mes buffers d’entrées.

Ce cas arrive quand le DMA des entrées réponses n’a plus de place mémoire disponible pour les réceptionner. Donc Helios est trop lent à les traiter (les paquets de réponses). Le chip OHCI fait donc disparaître ces paquets même si ils ont été acquittés du côté de la source, sans aucun avertissement d’aucune sorte… Dans le jargon 1394 cela devrait provoquer un « split-transaction timeout », une requête n’a pas reçue de réponse dans un délais impartis. Et comme la source n’est pas avertie que son paquet réponse c’est fait rejeter (car acquittement reçu), il ne renverra jamais ce dernier.

La norme 1394 donne un délais fixé par défaut à 100 ms pendant lequel une requête doit avoir reçue une réponse, après la requête doit être annulée. Malheureusement l’OHCI ne gérant pas automatiquement cela c’est au soft de le faire. mais si je dois mettre un timer pour chaque requêtes je vous raconte pas la perte de temps CPU!

J’ai pas trouvé encore de solution pour cela, pi encore malade mardi… pffuu :'(

[Yomgui]

Yomgui

#107815

ah ah! ça y est, j’ai déjà un truc plus fonctionnel maintenant, je loupe plus mes réponses (ou presque…).

Donc test sur 1 transfert de 1Mo en asynchrone:

19294349 octects/s (~18Mo/s)

C’est beaucoup mieux déjà! (39% de la bande passante utilisée).

Bon par contre j’ai un autre bug… car test de 10Mo = réponses perdues…

[papiosaur]

papiosaur

#107816

Courage Yomgui !!! Tu es le plus fort !!!

www.amigang-store.com

[Yomgui]

Yomgui

#107817

Mes problème de paquets perdu presque résolu..

20Mo/s à 2h30 du mat!

J’ai réussi à transférer 100 Mo en 5 secondes, avec une vrai pile ‘quasi’ complète.