[SDMOTO] fusion SDBOOT + demonstration SD

Cette catégorie traite de développements récents destinés à nos vieilles machines, applications, jeux ou démos... Amis programmeurs, c'est ici que vous pourrez enfin devenir célèbres!

Modérateurs : Papy.G, fneck, Carl

__sam__
Messages : 7924
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [SDMOTO] fusion SDBOOT + demonstration SD

Message par __sam__ »

En ce moment je teste une carte 128Mo... elle tourne depuis 50mins... (je ne dois pas louper la fin pour savoir si c'est une fin anormale ou normale). Tu as une idée de la durée totale normale daniel ? (je mise 60mins)

[EDIT] non 1h30 et j'ai loupé la fin. Mais au vu des octets en haut de l'écran quasiments tous à $FF, je pense que j'ai correctement atteint la fin de fichier sur cette SD là.

A présent je teste la 4Go à pb qui a passé un certain temps au frigo... l'espoir fait vivre...

[EDIT2] bon la 4Go continue de recevoir $FF en plein milieu d'un morceau.
Dernière modification par __sam__ le 11 janv. 2015 19:18, modifié 2 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Daniel
Messages : 17319
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [SDMOTO] fusion SDBOOT + demonstration SD

Message par Daniel »

Environ 75 minutes.
Sais-tu construire un adaptateur DB9-Catalex sans LED ? Sinon je peux t'en envoyer un. Il faudrait savoir si ça change quelque chose. Je n'y crois pas, mais autant vérifier.
Daniel
L'obstacle augmente mon ardeur.
__sam__
Messages : 7924
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [SDMOTO] fusion SDBOOT + demonstration SD

Message par __sam__ »

Je pense que j'ai recu tous les éléments séparés pendant les vacances de Noël pour contruire un module à base de fil dupont sans soudure. Ca serait le test ultime. Par contre je ne sais pas si la DB9 rentrera ou pas. Sur l'autre port joystick ca serait plus facile mais il faudra modifier le player.. bon ca nécessitera un peu de boulot.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
__sam__
Messages : 7924
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [SDMOTO] fusion SDBOOT + demonstration SD

Message par __sam__ »

En tout cas la carte SD n'est pas en cause. Je viens de la faire passer avec succès en la faisant tourner dans DCMOTO en x10 (j'allais pas attendre 75mins quand même ;) ).

Je la teste avec un autre module catalex en ma possession (il n'a pas la même date que celui que tu m'as envoyé Daniel).

[EDIT] non ca ne change rien avec cet autre module.

... C'est quand même curieux de recevoir $FF durant la partie data. Peut-être qu'il faudrait vérifier le CRC pour detecter une erreur de transmission SPI.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Daniel
Messages : 17319
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [SDMOTO] fusion SDBOOT + demonstration SD

Message par Daniel »

Il faut savoir que la carte renvoie des bits à 1 quand elle est prête. Si la commande CMD18 a été abandonnée à la suite d'une erreur, la carte est prête pour une autre commande et toute nouvelle lecture d'octet renvoie $FF.

Le test avec dcmoto prouve que la carte ne contient pas $FF dans les données, c'est rassurant mais ça ne donne pas trop d'indication sur la nature du problème. Le PC ne lit pas la carte en mode SPI, mais en mode SD, avec des commandes différentes, il teste tous les codes retours et fait des retries en cas d'erreur.

Un test à faire (mais il faudrait avoir le courage de réécrire SDPLAY) serait d'utiliser la commande CMD17 (read single block) à la place de CMD18 (read multiple blocks) pour voir si la même erreur se produit.

Le connecteur DB9 avec sa coquille (sans les vis) doit pouvoir être utilisé sur TO8 (et MO6). Par contre c'est impossible avec le TO8D, car l'embase du connecteur manette est en retrait par rapport au boîtier. Mais il n'est pas compliqué de retirer la coquille métallique : les deux demi-coques tiennent juste avec deux rivets pas très solides.
Daniel
L'obstacle augmente mon ardeur.
__sam__
Messages : 7924
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [SDMOTO] fusion SDBOOT + demonstration SD

Message par __sam__ »

Daniel a écrit :Si la commande CMD18 a été abandonnée à la suite d'une erreur, la carte est prête pour une autre commande et toute nouvelle lecture d'octet renvoie $FF.
Oui.. mais le hic est que je ne reçois plus de token d'erreur à présent si j'ai bien écrit le code :-/ Du coup le $FF au milieu des données est très fâcheux car quasiment non détectable sans CRC.
Le test avec dcmoto prouve que la carte ne contient pas $FF dans les données, c'est rassurant mais ça ne donne pas trop d'indication sur la nature du problème. Le PC ne lit pas la carte en mode SPI, mais en mode SD, avec des commandes différentes, il teste tous les codes retours et fait des retries en cas d'erreur.
Oui j'ai regardé pas mal de code C qui utilisent le mode SD. A chaque fois ca se base sur un timeout.

Fondamentalement ce qu'il se passe dans le read() des filesystem, si on doit lire un truc plus gros que 512 octets sur carte SD, c'est une commande de lecture de bloc multiples qui est envoyé. La routine read compte le nombre de blocs (ou d'octets) correctement reçus, et le retourne à read. En effet en C read ne lit pas toujours exactement le nombre d'octets demandé mais peut retourner moins. C'est ce qui sauve le coup pour les API de carte SD. Car à ce moment la le code C qui n'a pas recu l'intégralité du buffer doit faire une nouvelle demande de lecture à partir du dernier point correct, ce qui permet de passer outre les erreurs transitoires. C'est bien la 1ere fois (hors réseaux) où je comprends pourquoi le read() peut retourner moins d'octets que demandés.
Un test à faire (mais il faudrait avoir le courage de réécrire SDPLAY) serait d'utiliser la commande CMD17 (read single block) à la place de CMD18 (read multiple blocks) pour voir si la même erreur se produit.
Oui. J'ai même pensé éliminer la partie musique pour simplement afficher à l'écran les parties "attente de token", données, et crc et surtout maintenir le compteur d'adresse synchro pour pouvoir derémarrer au même point de la chanson plus tard.

:idea: Au passage : si on maintient les adresses synchro, on pourrait détecter les appuis sur les flèches pour faire avancer ou reculer le morceau de musique de 30 secs d'un coup. Ca serait une "feature" intéressante pour un player.
Le connecteur DB9 avec sa coquille (sans les vis) doit pouvoir être utilisé sur TO8 (et MO6). Par contre c'est impossible avec le TO8D, car l'embase du connecteur manette est en retrait par rapport au boîtier. Mais il n'est pas compliqué de retirer la coquille métallique : les deux demi-coques tiennent juste avec deux rivets pas très solides.
J'ai un connecteur sans soudure, je crois que la coque se dévisse, mais je sens qu'il est trop large pour le lecteur de D7..

Au cas où utiliser l'autre port joystick est il compliqué ?
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Daniel
Messages : 17319
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [SDMOTO] fusion SDBOOT + demonstration SD

Message par Daniel »

En théorie ce n'est pas compliqué, en pratique c'est très embêtant pour deux raisons :
- Il faudrait reprogrammer l'EPROM
- On aurait la lecture de données sur le bit 4 au lieu de l'avoir sur le bit 7, c'est moins pratique à manipuler et ajoute quelques cycles à la routine de lecture d'un octet.
Ceci dit, en informatique tout est possible. Mais peut-être pas dans le même nombre de cycles.

[Edit]
Je ne comprends pas le problème avec le lecteur de disquette. Un connecteur DB9 débarrassé de sa coquille métallique n'est pas plus large qu'un connecteur de joystick. Voir sur la photo à gauche et au milieu : http://dcmoto.free.fr/bricolage/sdmoto/ ... 140724.jpg
Daniel
L'obstacle augmente mon ardeur.
__sam__
Messages : 7924
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [SDMOTO] fusion SDBOOT + demonstration SD

Message par __sam__ »

Oui ca devrait aller alors. Cool je vais me baser sur ce modèle, mais en retirant la coquille métallique: http://dcmoto.free.fr/bricolage/sdmoto/ ... dupont.jpg

En fait c'est même pas celui là car le DB9 est celui-ci:
Image
(encore moins de soudure)
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Daniel
Messages : 17319
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [SDMOTO] fusion SDBOOT + demonstration SD

Message par Daniel »

Le connecteur de la photo ci-dessus ne convient pas pour le TO8D. En enlevant la coquille métallique, il reste le corps du connecteur en plastique noir, il ne passe pas dans le trou du boîtier. On peut le scier, mais c'est de la boucherie.

Le connecteur utilisé pour un montage sans soudure, tel que sur la photo http://dcmoto.free.fr/bricolage/sdmoto/ ... dupont.jpg
est celui-ci : http://www.ebay.fr/itm/DB9-9-Pin-Lock-S ... 1580060140

Image

Pour le connecter sur MO6 ou TO8, il suffit d'enlever les deux vis.
Pour le connecter sur TO8D il faut aussi enlever la coquille métallique.
Daniel
L'obstacle augmente mon ardeur.
__sam__
Messages : 7924
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [SDMOTO] fusion SDBOOT + demonstration SD

Message par __sam__ »

J'ai ceux-ci
Image
qui n'ont pas de vis. Or je n'ai pas de quoi faire sauter les rivets sous le coude (perceuse, poinçon). (Quand ca veut pas... ca veut pas.)

Je vais peut-être regarder ce qui est plus à ma portée: la partie soft en dumpant à l'écran les octets recus. Déjà j'aimerais savoir si c'est toujours le même octet du fichier qui pose pb ou si ca varie autour d'un certain endroit de la carte. (Mon sentiment est que le point de rebouclage varie sur de longues période. L'an dernier c'était à la fin de la chanson 1; et cette année c'est plus loin vers la chanson 3 ou 4.. mais une fois que ca plante à un endroit, cet endroit reste une paire de jours.)
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
__sam__
Messages : 7924
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [SDMOTO] fusion SDBOOT + demonstration SD

Message par __sam__ »

Hum... Je tombe sur un truc curieux..

Si j'ai bien analysé le code, le test de sortie ne se fait pas à chaque échantillon, mais tous les 8 échantillons (bmi qui suit play8). Aussi j'ai réécrit un player à l'arrache pour qu'il aille pleine vitesse sans les délais ni la récupération des échantillons à jouer au moment des CRC, mais qui cependant teste la fin avec un BMI tous les 8 échantillons joués. Du coup le player est tout petit et va très vite.

Or d'une part je n'entends plus spécialement de craquements (mais ca va peut être trop vite pour les percevoir), et d'autre part je n'ai pas de sortie intempestive. Une grande première! Enfin je n'ai testé que jusqu'à la chanson 4 ou 5 parce qu'au delà ca fait long et que d'hab ca sort bien avant. Pourtant mon prog de test précédent qui vérifie le token d'erreur ainsi que le player d'origine sortent bien de façon prématurée au même morceau de musique.

Je suis perplexe... Il doit y avoir un truc évident que je ne vois pas. A priori les players sont fonctionnellement identiques. Seule la vitesse d'exécution diffère.

A noter: la carte est une SANDISK. Or la doc des SANDISK (http://dlnmh9ip6v2uc.cloudfront.net/dat ... SDSpec.pdf) indique que la carte s'endort si après une fin de commande elle ne recoit rien pendant 5ms (paragraphe 1.10: automatic sleep mode). Normalement c'est transparent, sauf que je ne sais pas ce qu'est la fin de commande quand on fait de la lecture de blocs multiples. Il y a peut-être un truc spécial à ce niveau là. J'y crois pas trop: 5ms c'est long, même pour le 6809.

Je viens de modifier le player "rapide" pour qu'il bufferise le dernier bloc reçu et maintient un compteur 32bits d'offset dans le fichier. Demain je vais essayer de le laisser tourner jusqu'au bout. S'il sort de façon prématurée je connaitrait à la fois l'offset et le dernier bloc lu. Je pourrais comparer avec ce qu'il y a vraiment sur le fichier SD avec un editeur hexa. Peut-être verrais-je qu'on lit autre chose que ce qui est attendu.

[EDIT] Dans le code https://github.com/greiman/SdFat/blob/m ... d2Card.cpp, je vois que régulièrement, et en particulier après l'envoi de CMD18, le programme envoie 8 bits à 1 vers la carte (chipSelectHigh()). Est-ce qu'on réalise cela? Il est aussi indiqué que pendant tout le transfert on doit avoir le chipSelect à l'état bas. Est-ce bien le cas du coté thomson ?
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
__sam__
Messages : 7924
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [SDMOTO] fusion SDBOOT + demonstration SD

Message par __sam__ »

Trop impatient de connaitre le résultat j'ai attendu la fin du morceau avec le player simplifié. Tout est ok avec lui. Le dernier bloc recu (juste avant $019CE200) est strictement identique entre la carte SD et ce qu'a lu le TO8. Donc je suis maintenant convaincu qu'il n'y a pas d'endormissement de la carte, ni token d'erreur, ni problème matériel avec la led, ni rien et que tout est OK avec un player simplifié.

J'ai profité de l'écoute, pour relire le code du player d'origine, et j'ai l'impression que la partie "joue les octets inter blocs" est bizarre. Est-ce que je me trompe en disant que ce code utilise un nombre quasiment fixe de cycles, et donc attend un nombre maxi d'octets interblocs. De ce que je comprends il lit jusqu'à 6 (ou 8?) fois un tel octet. Si on lit $FE plus tôt que prévu , alors les lectures suivantes sont factices (routine TEMPO) jusqu'à atteindre le nombre attendu d'octets interblocs, tout ca pour manger un temps constant.

Ok je comprends le principe qui est astucieux.

Mais si le nombre d'octets interblocs est supérieur, alors on repart lire des échantillons audio alors que la carte SD continue de fournir des octets interblocs. On joue donc $FF un certain nombre de fois (=> craquements), et si ca dure plus de 8 octets, le 8 eme octet lu par PLAY8 provoque un BMI et sortie prématurée du player d'origine.

Oui c'est ca, c'est forcément ca l'explication! Bien sur! Ca relie les deux phénomènes que j'observe: craquements nombreux et sortie prématurée ==> Si le nombre d'octets d'attente est trop long à certains endroits de la carte, alors on lit de faux échantillons qui font sortir le programme plus vite que prévus dans la version initiale du player.

Demain (oui car là il est trop tard), je vais faire en sorte que la boucle lecture d'échantillons inter blocs ne soit pas de duree fixe, mais attende un vrai $FE pour sortir. On va perdre en régularité de la musique, mais ce sera quasi imperceptible car le player simplifié qui ne joue rien pendant les CRCs et les octets interblocs ne fait pas entendre de craquements.

Oui je pense que je suis sur la bonne piste là... suspens...
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Avatar de l’utilisateur
petitjd
Messages : 2007
Inscription : 23 oct. 2007 11:50

Re: [SDMOTO] fusion SDBOOT + demonstration SD

Message par petitjd »

Ca sent bon là, bravo pour cette persévérance!
Je ne sais pas comment tu fais pour coder et y voir clair à plus de minuit!
PetitJD
Tortue Jeulin: www.tortue-jeulin.com
Nanoreseau: www.nanoreseau.net
Proteus III: www.proteus-international.fr
__sam__
Messages : 7924
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [SDMOTO] fusion SDBOOT + demonstration SD

Message par __sam__ »

Pour y voir clair ? Ben j'utilise une lampe ! :P (à l'aide -- LED ;) )

De toute façon, quand je suis devant l'ordi avec le cerveau "actif", je ne vois pas vraiment le temps passer et il m'est impossible de me coucher. En revanche devant la TV, vu que les programmes ne stimulent plus mon esprit, je m'endors très rapidement :mrgreen:
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Daniel
Messages : 17319
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [SDMOTO] fusion SDBOOT + demonstration SD

Message par Daniel »

Quand __sam__ explique un truc compliqué tout devient clair 8)

Je suis vraiment nul de ne pas y avoir pensé. C'est évident, dans certains cas le programme traite les octets inter-blocs comme des données, ces octets sont à $FF et s'il y en a 8 ou plus ils provoquent le bouclage intempestif. S'il y en a moins de huit il n'y a pas de bouclage, mais un gros craquement.

Dans l'espoir de limiter les défauts, j'ai augmenté il y a quelques mois le nombre d'échantillons inter-blocs (de 6 je suis passé à 8 ). Ce n'est pas suffisant dans certains cas, l'octet $FE de début de bloc n'est pas reçu dans les délais. La solution est de l'attendre dans tous les cas.
__sam__ a écrit :On va perdre en régularité de la musique
Si on ne reçoit pas $FE avant d'avoir joué les 8 octets, oui, il faudra attendre l'octet $FE pour continuer. Je ne sais pas quel est la durée maxi entre deux blocs. Si on passe le nombre d'échantillons supplémentaire de 8 à 16, peut-être est-ce suffisant pour être bon dans tous les cas. On peut même aller jusqu'à 64 octets, en mettant un bit supplémentaire dans chaque octet du bloc.
__sam__ a écrit :pendant tout le transfert on doit avoir le chipSelect à l'état bas. Est-ce bien le cas du coté thomson ?
Dans l'interface SDMOTO, CS est soudé à la masse, rien ne peut le sortir de l'état bas.

[Edit]
Je viens de relire le code de SDPLAY, et j'ai corrigé l'explication (ci-dessus), car la première version n'était pas correcte. Dans la boucle qui joue les échantillons supplémentaires, en SUPP, SUPP1, il y a déjà le test de $FE. Si $FE a été reçu, il n'y a plus d'autres lectures d'octets (la lecture est remplacée par une temporisation en SUPP2).
Le problème est ensuite la reprise de l'exécution en PLAY1 : si $FE a déjà été trouvé, c'est bon. Sinon il faut continuer à lire les octets inter-blocs. L'erreur est de considérer ces octets comme des données. Ils sont à $FF et s'il y en a huit ou plus ils provoquent le rebouclage. S'il y en a moins de 8 ils provoquent un craquement. Il faut, en PLAY1, tester si l'octet $FE a déjà été lu. Si oui, continuer, sinon l'attendre avant de continuer.

@sam : pour éviter de faire la modif chacun de son côté, préfères-tu la faire ou me la laisser faire ?

[Edit2]
Finalement je vais corriger moi-même, et profiter de l'occasion pour passer à 64 le nombre d'échantillons supplémentaires. Ainsi on évitera, j'espère, les irrégularités de rythme. Les craquements chez moi prouvent que 8 octets ne sont pas suffisants, le bouclage intempestif chez __sam__ prouve que 16 octets ne sont pas suffisants. J'espère que 64 octets supprimeront tous les problèmes.
Daniel
L'obstacle augmente mon ardeur.
Répondre