Lecture d'échantillions - Page 1

J'ai fait des recherches et je n'arrive pas à trouver un moyen rapide et qui fonctionne.

C'est encore en rapport avec ma librairie:

Il existe une fonction qui permet de régler la taille des echantillions (1 échantillion peut être égal à 1, 2 ou 4 bits). Le convertiseur ce charge de la représentation des données.

Voilà, je voudrais créer une fonction très rapide qui prend en cmpte la taille d'un échantillion.

Exemple pour des échantillions de 1bits, la fonction lira un octet bit à bit et dès qu'on arrive au bit 7 on va à l'octet suivant, ça j'arrive mais la suite ce complique.
Pour des échantillions de 2 bits il faut que j'extrait les 2 premeier bit, que je joue, les 2 suivant jusqyu'à ce qu'il n'y en ai plus dans l'octet pour passer au suivant. Idem avec 4 bits.

Hors je voudrais une fonction qui gére ses 3 modes. A moins qui si vous me dite que si je fait une fonction pour chaque mode c'est bien plus rapide, je suis partant mais en attendant j'évite.

Aussi pensais vous que pour extrait plusieurs bits en même temps un masquage est rapide avec un and+décalage binaire? Du genre j'ai des échantillions de 2 bits, 1 octet conteient 4 échantillions:

7 6|5 4|3 2|1 0
------------------
1 0|1 1|0 1|0 1

Pour récupérer l'octet 7 et 6 je fait un masque 0xC0 et une division de 64.
5 et 4 0x30 16
3 et 2 0x0C 4
1 et 0 0x03 '0'

2 problème ce pose ici la division de 0, je sais qu'avec une condition je peux éviter ça mais ça ralentie, et le problème de trouver l'algo capable de trouver lui même les maques et rotation pour du 1, 2 et 4 bits par échantillions.

Si ya mieux je suis partant, n'hésitez pas.

Vous pouvez pas m'aider?

J'aurais tendance à te conseiller de faire une fonction par mode en fait perso ...

Heuresement que j'ai gagné en taille parce que 3 modes ça risque de prendre beaucoup.

Par contre quelle méthode la plus optmisé conviendée pour lire plusieurs bits en même temps. En faite je veux eviter le decalage.

Serait-il aussi plus rapide de faire une rotation avec lsr puis le mask ou mask puis division (décalage)?

Je ne peux pas commencer ma fonction sans avoir vos avis....

Personnellement, je n'ai aucune idée sur ce genre de sujets. Désolé...

Ah bon.
Les méthodes que je présente ne peuvent pas m'aider?

Vous n'auriez pas une idée pour calculer rapidement les masques et décalages?

Une méthode possible est la suivante:

Tu récupères les 2 premiers bits (7 et 6) comme ça:

 moveq.l #0,d1 ;ou clr.w ou clr.b, mais toutes ces instructions prennent 2 octets et 4 cycles, donc autant tout effacer
 add.b d0,d0
 roxl.b #1,d1
 add.b d0,d0
 roxl.b #1,d1

Ensuite, tu fais exactement la même chose pour récupérer les bits 5 et 4, 3 et 2, 1 et 0.

Quand tu as fait ça 4 fois, tu lis le prochain octet.

roxl je connaissais pas.

Mais d0 ici contient 0 au début.
Et ça marche si je veux lire en partant au début de l'octet, bit 0 et 1... je suis lourd mais je pense aussi au convertisseur WAV.

geogeo :
Et ça marche si je veux lire en partant au début de l'octet, bit 0 et 1... je suis lourd mais je pense aussi au convertisseur WAV.

Pour moi, le début de l'octet, ce sont les bits 7 et 6. C'est comme ça dans toutes les données bit par bit sur TI-89/92+/V200 (sprites, champs de bit C, ...).

Mais tu peux utiliser lsr pour récupérer les bits en partant du dernier (bit 0).

Pour toi les bits d'un octet c'est ça, en liasnt de droite à gauche.

0101 0100
0123 4567

Or moi je fait ça:
0101 0100
7654 3210
Donc l'inverse.

Je vais regarder la définition de roxl car je connais vraiment pas ça.

geogeo
: Pour toi les bits d'un octet c'est ça

Euh, je n'ai pas compris là. Mais: les numéros de bits qu'on utilise tous les 2 (il me semble) sont ceux de bset/bclr/btst:
bit 7 <-> 2⁷
bit 6 <-> 2⁶
bit 5 <-> 2⁵
bit 4 <-> 2⁴
bit 3 <-> 2³
bit 2 <-> 2²
bit 1 <-> 2¹
bit 0 <-> 2⁰

Mais dans toutes les données bit à bit sur TI-89/92+/V200, les bits sont lus de gauche à droite, donc le bit de poids fort est lu en premier. Donc l'octet commence par le bit 7 (qui vaut 2⁷) et se termine par le bit 0 (qui vaut 2⁰).

C'est pour ça que je dis que l'octet commence au bit 7, pas au bit 0.

Euh, je n'ai pas compris là. Mais: les numéros de bits qu'on utilise tous les 2 (il me semble) sont ceux de bset/bclr/btst:

Là je comprend.

Mais dans toutes les données bit à bit sur TI-89/92+/V200, les bits sont lus de gauche à droite, donc le bit de poids fort est lu en premier. Donc l'octet commence par le bit 7 (qui vaut 27) et se termine par le bit 0 (qui vaut 20).

Donc là il faut lire de gauche à droite, 76543210

C'est pour ça que je dis que l'octet commence au bit 0.

C'est toujours comme ça.


Je crois qu'on s'embouillé sur la lecture. D'habitude je lis de droite à gauche en commencant à 0 et toi à 7.

geogeo
:

C'est pour ça que je dis que l'octet commence au bit 0.

C'est toujours comme ça.

Euh, tu as dû rater mon édition là.

geogeo :
Je crois qu'on s'embouillé sur la lecture. D'habitude je lis de droite à gauche en commencant à 0 et toi à 7.

Moi, je lis de gauche à droite en commençant par 7. Ça donne les mêmes numéros que toi, mais le "début" est de l'autre côté.
Et si je fais ça, c'est parce que c'est le format utilisé un peu partout. Tu es à peu près le seul à coder tes données en commençant par l'octet 0 sur TI-89/92+/V200.

Cf. par exemple cet extrait de la structure SYM_ENTRY:
unsigned short busy : 1, local : 1, flag1_5 : 1, flag1_4 : 1, collapsed : 1, twin : 1, archived : 1, in_view : 1;
Comme tu peux voir, le bit 5 vient en troisième, avant le bit 4.

Moi, je lis de gauche à droite en commençant par 7. Ça donne les mêmes numéros que toi, mais le "début" est de l'autre côté. Et si je fais ça, c'est parce que c'est le format utilisé un peu partout. Tu es à peu près le seul à coder tes données en commençant par l'octet 0 sur TI-89/92+/V200.

Mon prof nous rire au nez i on lis de gauche à droite.

Cf. par exemple cet extrait de la structure SYM_ENTRY:
unsigned short busy : 1, local : 1, flag1_5 : 1, flag1_4 : 1, collapsed : 1, twin : 1, archived : 1, in_view : 1; Comme tu peux voir, le bit 5 vient en troisième, avant le bit 4.

Du temps que je m'y retrouve.


C'est peut être des détails mais quand on est auto-didacte c'est très utile de savoir ça.

Je vais essayer ta méthode ce soir.

geogeo
: C'est peut être des détails mais quand on est auto-didacte c'est très utile de savoir ça.

Je précise aussi que les conventions pour les champs de bits dépendent de la plateforme et du compilateur.

Jai fait des recherches et rien sur roxl, en gros elle fait quoi cette fonction?

[url]http://www.technoplaza.net/assembly/index.cgi?p=68ks7#*** ROXL ***[/url]

Au fait, un truc auquel je viens de penser: plutôt que roxl.b #1,d1, tu peux aussi utiliser addx.b d1,d1, c'est 2 fois plus rapide (4 cycles à la place de 8). Cf. [url]http://www.technoplaza.net/assembly/index.cgi?p=68ks5#*** ADDX ***[/url].

Ouah c'est pas négligeable. Roxl est une fonction très utile.

Tu multiplie par 2 avec d0 pour récupérer 1 bit?
Puis tu sauvegarde ce bit dans d1.
Tu procéde pareil pour le bit suivant...?

Donc d0 est un pointeur de rang.
d1 stocke les 2 bits.

Oui.

Mais d0 contient quoi comme valeur au début? 1?

Maintenant si je veux faire des ections de 4 bits, sois je reprend ta méthode mais je crois que ça sera lent et gros ou soit je fait un mask puis rotation et 2 variable d'où je doit calculer le mask et l'autre la rotation? A ton avis laquelle serait mieux en vitesse?

geogeo
: Mais d0 contient quoi comme valeur au début? 1?

Au début, tu fais un move.b (a0)+,d0 pour lire ton octet.

Maintenant si je veux faire des ections de 4 bits, sois je reprend ta méthode mais je crois que ça sera lent et gros ou soit je fait un mask puis rotation et 2 variable d'où je doit calculer le mask et l'autre la rotation? A ton avis laquelle serait mieux en vitesse?

Je pense que le masquage est plus rapide, mais ma solution est plus simple à généraliser (utiliser le même code pour les 3 cas (1 bit, 2 bits, 4 bits), avec les registres utilisés pour des dbra initialisés différemment).

Dans le cas 1, y a vraiment plus simple.

Ah excuse moi, toi tu est partant pour faire une fonction qui gére les 3 modes en même temps? Dans ce cas j'ai réfléchie et je préfére éviter car je vais perdre énormément de vitesse.

Je suis revenu à l'idée de faire 3 fonctions pour chaque mode, toute façon je ne peux pas faire mieux puisque la fonction du 2 bit et 45 bits et très différente de la 1 bit pour jouer le son.

1 bit, vraiment très simple.
2 bits avec la méthode que tu as citée plus haut et dont je trouve rapide et très simple. Je n'avais pas pensez à ça et je troyuve ça vraiment puissant.
4 bits j'obterais vraiment avec un mask et décalage.

Une division est plus rapide qu'une rotation, je sais c'est différent mais c'est pour savoir.

Au début, tu fais un move.b (a0)+,d0 pour lire ton octet.

C'est tellement logique.