SDLEP-READER remplace tous les magnétophones d'ordinateurs.

Placez ici vos trucs et astuces, étalez sans retenue votre savoir-faire et votre science qui va nous permettre de redonner une apparence neuve et fonctionnelle à nos bouzes.

Modérateurs : Papy.G, fneck, Carl

Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: SDLEP-READER remplace tous les magnétophones d'ordinateurs.

Message par Daniel »

hlide a écrit : 06 févr. 2018 23:28 Normalement, le moteur devrait s'arrêter après la première lecture mais comme j'ai dû mettre MOTOR à la masse, SDLEP débiterait déjà le vrai programme avant que le bootloader lance son chargement.
Oui, sans commande d'arrêt du moteur les chargements de programmes en plusieurs étapes risquent de ne pas marcher.
Comme indiqué par Carl, l'allongement de l'espace entre les deux programmes peut aussi résoudre le problème.
Daniel
L'obstacle augmente mon ardeur.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: SDLEP-READER remplace tous les magnétophones d'ordinateurs.

Message par hlide »

J'ai noté que l'on utilisait un "delayMicroseconds(delai);" juste après la modification de la sortie du DATA IN, ce delai étant un multiple de 50 µs. Sauf que bien évidemment entre le moment où l'on sort de cette fonction et que l'on modifie à nouveau la sortie DATA IN, il se passe un certain temps non compté dans l'appel de la fonction. Je n'ai évidemment aucune idée de sa valeur, de son échelle comparée aux 50 µS et de sa variation.

Alors je me suis dit que j'allais utiliser la fonction "micros()" qui me devrait donner les microsecondes passées.

Je remplace ceci :

Code : Tout sélectionner

   digitalWrite(1, niveau);        // signal en sortie
   //if(i == 511) delai -= 49;       // compensation temps chgt bloc 
   delayMicroseconds(delai);       // temporisation
par cela :

Code : Tout sélectionner

   while(micros() - lastTime <= delta); // temporisation du précédent état
   digitalWrite(1, niveau);        // nouvel état du signal en sortie
   //if(i == 511) delai -= 49;       // compensation temps chgt bloc
   lastTime = micros();
   delta = delai;    
   //delayMicroseconds(delai);       // temporisation
avec delta initialement à 0. L'idée étant d'attendre qu'il s'est écoulé bien le delai précédemment calculée avand de modifier le DATA IN en incluant le temps des calculs et de lecture de l'octet depuis le SD dans ce delai et non en dehors comme c'était le cas avec "delayMicrosecondes". Au niveau du clignottement, j'ai quelque chose de similaire visuellement à ce que j'avais avec "delayMicroseconds". Et pourtant, je ne parviens pas à charger un programme normal à 1200 baud avec. A noter que "micros" retourne toujours un multiple de 4 µS pour une Arduino à 16Mhz (sinon 8 µS pour du 8 Mhz). Je cherche à comprendre ce qui ne fonctionne pas.
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: SDLEP-READER remplace tous les magnétophones d'ordinateurs.

Message par Daniel »

Je crois que le temps d'exécution des fonctions utilisées dans le programme original est négligeable par rapport aux 50µs.
Par contre la boucle while est certainement beaucoup plus longue et l'appel de la fonction micros() prend aussi du temps.
Je me demande si cette fonction est très précise, il faudrait voir ce qu'ils disent dans la doc.
Voir aussi si elle fonctionne bien quand les interruptions sont masquées.
Ces quelques réflexions ne sont pas une réponse, juste des pistes à explorer...

Pour contrôler, il faudrait mettre un oscilloscope ou un analyseur logique à la sortie DATA de l'arduino, ou encore plus simplement enregistrer le signal sur PC avec la carte son et examiner le fichier .wav obtenu.
Daniel
L'obstacle augmente mon ardeur.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: SDLEP-READER remplace tous les magnétophones d'ordinateurs.

Message par hlide »

La fonction est décrite dans ce lien.

Je vois que la fonction conserve le maskage des interruptions mais dépend d'une interruption pour gérer l'overflow du timer #0. L'overflow se passe tous les 1024 µs. Cet autre lien l'explique assez bien.

Les interruptions sont si pertubantes que ça ? je veux dire qu'elles prennent plus qu'une µS?
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: SDLEP-READER remplace tous les magnétophones d'ordinateurs.

Message par hlide »

Bon, si je laisse les interruptions activées, ça fonctionne maintenant. A mon avis, ce n'est pas une bonne solution de les désactiver. Pour de l'embarqué, elles devraient être assez rapides contrairement aux interruptions sous Windows ou Linux. Je vais tester avec des vitesses supérieures.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: SDLEP-READER remplace tous les magnétophones d'ordinateurs.

Message par hlide »

A force de travailler avec des processeurs véloces, je ne me suis pas rendu compte de l'énormité : à 16 Mhz, un cycle vaut 0,0625 µs. Il en faut donc peu d'instructions pour prendre 1µ (16 cycles d'instructions). Donc, ouais... il ne doit pas y avoir une très grosse marge.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: SDLEP-READER remplace tous les magnétophones d'ordinateurs.

Message par hlide »

Pour pouvoir charger à "2400 bauds", j'ai été obligé de rajouter 10 µs à "delai" à chaque calcul quand j'utilise "micros()" au lieu de "delayMicroseconds(50*pulseLength)" qui lui chargait. Je ne dis pas que c'est exactement 10 µs bien sûr mais néanmoins il apparaît que "micros()" est assez précis (à 4 µS près) et que les interruptions ne sont pas en cause. Après je me pose des questions sur le fait que j'ai besoin de faire du 60 µs comme base et non du 50 µs par rapport au LEP.
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: SDLEP-READER remplace tous les magnétophones d'ordinateurs.

Message par Daniel »

Tu devrais enregistrer la sortie de SDLEP-READER dans un fichier .wav, comme je l'ai écrit plus haut. Ca permettrait de mesurer exactement la période des créneaux rectangulaires et de mieux comprendre les conséquences de la modification du programme.

De mémoire, je crois que j'avais désactivé les interruptions pour avoir un débit régulier de lecture de la carte SD. Sinon il y avait des temps d'attente qui modifiaient un peu la période du signal en sortie.
Daniel
L'obstacle augmente mon ardeur.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: SDLEP-READER remplace tous les magnétophones d'ordinateurs.

Message par hlide »

Daniel a écrit : 26 févr. 2018 08:05 De mémoire, je crois que j'avais désactivé les interruptions pour avoir un débit régulier de lecture de la carte SD. Sinon il y avait des temps d'attente qui modifiaient un peu la période du signal en sortie.
Oui, ça se comprend si on utilise la méthode "delayMicroseconds" qui ne fait que de s'ajouter aux temps d'attente. Avec la méthode "micros()", ces temps d'attente devrait être absorbés pour donner une période stable du signal en sortie - sauf si ces temps d'attente font dépasser la période minimale requise. C'est du moins ce que j'attend de cette méthode. Il est vrai qu'entre le moment où "micros()" boucle et la mise à jour du signal de sortie, il peut y avoir une interruption mais je n'ai pas l'impression que ce soit le problème ici.

Pour la mesure des périodes en lisant à la sortie de SDLEP-READER je verrais ça le weekend prochain si j'ai ce qu'il faut pour le faire (je n'ai pas trop envie de monter la prise jack en fait).
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: SDLEP-READER remplace tous les magnétophones d'ordinateurs.

Message par hlide »

Bon je n'ai pas de quoi enregistrer un wav mais j'ai un petit oscilloscope que j'ai mis à contribution. Et voici donc ce que j'ai glané :

la documentation stipule que le créneau bas doit faire 264 µs en pulsation courte et 494 µs en pulsation longue, le créneau haut doit faire 240 µs en pulsation courte et 464 µs. La première lecture se fait sur le front montant puis relecture après 368 µs pour déterminer la valeur du bit.

Si je regarde le LEP généré à partir d'un WAV censé être normal (toutefois généré à partir d'un fichier binaire), j'ai en pulsation courte un -4 suivi de 4, soit théoriquement 200 µs que ce soit en crénaux bas ou haut. Pour la pulsation longue, j'ai -9 suivi de 9, soit théoriquement 400 µs.

Si je regarde le résultat avec la version "delayMicroseconds" sans interruption, j'obtiens du 216 µs et 460-470 µs (mesure moins précise).

Si je regarde le résultat avec la version "delayMicroseconds" avec interruption, j'obtiens du 220 µs et 460-470 µs (mesure moins précise).

Si je regarde le résultat avec la version "micros" sans rajoût de 10 µs, j'obtiens du 208 µs et 460 µS.

Si je regarde le résultat avec la version "micros" avec rajoût de 10 µs, j'obtiens du 220 µs et 472 µS.

La version "micros" sans ajustement est plus proche des valeurs théoriques. Il faut noter que l'Arduino que j'utilise a un horloge de 16 Mhz et donc une résolution de 4 µs pour "micros" (elle serait de 8 µs pour une 8 MHz). 50 µs n'est divisible ni par 4 ni par 8 donc les valeurs de LEP ne sont pas propres.

Version "delayMicroseconds" : les interruptions n'ont pas l'air d'avoir un effet préjudiciable par rapport à la granularité de 50 µs choisie pour LEP.

Pourquoi 200 µs et 400 µs ? est-ce un soucis du côté du générateur wav ? le générateur de wav fait 11 cycles de 44,1 Khz aussi bien en créneau haut que bas pour la pulsation courte et 21 cycles pour la longue. Ca donne théoriquement : 249 µs et 476 µs (arrondi à l'inférieur). ces cycles sont compatibles avec celles de la documentation : 240 < *249* < 368 et 368 < 464 < *476* (seuls les périodes des créneaux hauts nous intéressent).

249 / 50 donne 4,98 soit 4 arrondi à l'inférieur. On retrouve la valeur +/-4 de LEP.
476 / 50 donne 9,52 soit 9 arrondi à l'inférieur. On retrouve la valeur +/-9 de LEP.

Donc à cause d'une granularité de 50 µs pas fine, on a "accéléré" le débit du WAV dans le LEP.

On relève un surcoût d'un peu moins d'une vingtaine de microsecondes par rapport à la valeur calculée depuis LEP concernant la pulsation courte. Pour la version longue je ne m'explique pas les 60 µs d'écart (théoriquement 400 µs).
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: SDLEP-READER remplace tous les magnétophones d'ordinateurs.

Message par Daniel »

Il faut savoir que le décodage par l'ordinateur Thomson utilise un seuil, qui est à peu près la moyenne entre la période courte et la période longue. Au-dessous de ce seuil, c'est un bit 1, au-dessus c'est un bit 0. Finalement la valeur exacte de la période n'a pas grande importance et n'a pas besoin d'être très précise. Il faut simplement être sous le seuil pour les bits 1 et au-dessus pour les bits 0.

Mes utilitaires génèrent des fichiers .wav à 44100 échantillons par seconde, et j'arrondis toutes les périodes à un nombre entier d'échantillons. Il y a donc un écart avec la valeur théorique. Ensuite la conversion en fichier .lep introduit encore un autre arrondi sur un multiple de 50 µs. Enfin le programme de l'Arduino ne restitue pas exactement la valeur du fichier .lep. Sans compter qu'à chaque changement de secteur de la carte SD il y a encore un petit délai supplémentaire. La précision est donc loin d'être bonne, mais dans la pratique ça a toujours marché, au moins pour les Thomson. Je n'ai jamais eu d'erreur de lecture sur une bonne centaine de fichiers convertis au format .lep, aussi bien en 1200 bauds qu'en 2400 bauds.
Daniel
L'obstacle augmente mon ardeur.
Voyageur
Messages : 5
Inscription : 04 mars 2018 16:04

Re: SDLEP-READER remplace tous les magnétophones d'ordinateurs.

Message par Voyageur »

Bonjour à tous et à toutes,

Nouveau sur le forum et de passage en France pour quelques temps, je possède un Oric Atmos et j'ai réalisé un SDLEP-reader qui fonctionne bien.
Merci au développeur et à ceux qui ont pris de leur temps pour convertir des fichiers de jeux de wav en lep et les tester !
Je voudrais en faire un article à publier dans le magazine du CEO. Ça pourrait apporter une solution fiable à ceux qui comme moi n'ont pas de lecteur de K7 ou de disquettes...

Je suis également intéressé par la sauvegarde d'un programme avec le SDLEP (-Writer ?). Je sais qu'il faut du temps pour développer mais je peux tester si je peux être utile.
Mais je veux dire à Daniel : Bravo !
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: SDLEP-READER remplace tous les magnétophones d'ordinateurs.

Message par hlide »

Juste pour informer :
- après avoir ramené la précision à 16 µs au lieu de 50 µs,
- après avoir privilégié "micros" au lieu de "delayMicroseconds" et activé les interruptions,
- après avoir inclu la conversion du WAV en LEP directement dans l'outil mzf2wav pour convertir un MZF (binaire) en WAV et en LEP adapté à la résolution de 16 µs (meilleure précision au niveau des périodes des pulsations).

J'ai non seulement pu atteindre le mode turbo x3 qui était impossible avant mais j'ai aussi atteint le mode turbo x4 qui n'existait pas et que j'ai ajouté à mzf2wav.

De 1m 35s en conventionnel, je passe à 24 s en turbo x4.
Dernière modification par hlide le 05 mars 2018 14:07, modifié 1 fois.
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: SDLEP-READER remplace tous les magnétophones d'ordinateurs.

Message par Daniel »

Bien joué ! A l'occasion j'ajouterai ces informations à la page SDLEP-READER du site dcmoto.

Historiquement, quand j'ai conçu le format .lep et le module SDLEP-READER, c'était uniquement pour les ordinateurs Thomson. La valeur de 50µs était bien adaptée, et avait l'avantage de générer des fichiers .lep très courts.

Maintenant le système est utilisé avec beaucoup d'autres ordinateurs. Pour certains la fréquence des signaux est nettement plus élevée, il est tout à fait justifié de diminuer la période de base.
Daniel
L'obstacle augmente mon ardeur.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: SDLEP-READER remplace tous les magnétophones d'ordinateurs.

Message par hlide »

Voyageur a écrit : 04 mars 2018 16:18 Je suis également intéressé par la sauvegarde d'un programme avec le SDLEP (-Writer ?). Je sais qu'il faut du temps pour développer mais je peux tester si je peux être utile.
C'est plus délicat à faire, car SDLEP-READER ne gère pas le chainage des FAT (il lit en contigu d'où la nécessité de la non fragmentation de la FAT). Là pour écrire en FAT, sans le chainage, il y aurait un risque d'écraser le contenu et je ne fais pas allusion à ce que que ça pourrait prendre d'écrire un octet sur un SD car on pourrait manquer le passage de front montant ou descendant en pleine écriture. Mais ce n'est pas le plus délicat : chaque ordinateur a sa propre façon de lire les créneaux avec ses périodes. Ca nécessiste presque autant de code différent qu'il y a d'ordinateur. Donc je ne suis pas étonné que SDLEP ne soit resté qu'au stade de lecteur pour n'embarquer qu'un firmware quelque soit les ordinateurs. Ceci dit, si on doit écrire du LEP, la difficulté reste dans la distinction d'une pulsation longue et courte pour créer un LEP propre. Certes, on pourrait déterminer les périodes entre chaque fronts montant et descendant et les inscrire tel quel mais on aurait des périodes qui varieraient probablement (pas propres) et des longs silences pas très utiles pour le SDLEP-READER.
Répondre