forum.system-cfg.com

J'expliquerai, c'est promis, mais pas tout de suite car j'ai des invités dont je dois m'occuper.
Pour patienter une autre vidéo et une photo du montage fonctionnel.
http://www.filedropper.com/ccr

Fichier .mp4 (58 Mo)

Il ne faut pas oublier que le premier CCR-mute a fonctionné une fois, puis plus jamais, avec le même programme. Il y a donc un problème hard légèrement aléatoire, mais pas totalement. En particulier il semble sensible au contenu du fichier, selon qu'il y a plus ou moins de bits à 1. Je n'ai pas d'in...

CCR-mute-full va jusqu'au bout et plante lors du retour au Basic. L'image est brouillée du début à la fin, exactement comme CCR normal. Je reconnais les mêmes motifs.

Dans CCR, j'ai vu les titres et une partie de la séquence de guitare, mais pas l'écran de fin. Le plantage est brutal : tout l'écran devient incohérent et le programme s'arrête en moins d'une demi-seconde. Côté hard je ne sais pas dire. L'analyseur donne l'illusion de créneaux parfaits, mais ce n'es...

Avec mute440 je ne sais pas dire : la vidéo semble bonne, mais il y a quelques points noirs un peu bizarres. http://www.filedropper.com/mute440 Je vais maintenant faire le test avec CCR (sans CRC :wink: ). Suspens... Et voilà pour CCR : - Au premier lancement : bon pendant 6 ou 7 secondes, puis plan...

J'ai l'impression que la vidéo incr est bonne. Je me trompe peut-être ?
http://www.filedropper.com/incr

fichier binaire (2 MHz) : début de l'analyse :

Je suis à peu près au même point. Je vois des bugs imaginaires, et ensuite je m'aperçois que c'est bon. Tu as bien compris, la lecture de la carte SD par SD_L0_SpiRecvByte() dure entre 2 et 2,5 µs, c'est pourquoi les delayMicroseconds() ont des valeurs inférieures de 2 µs à la temporisation visée. T...

Pour moi c'est clair maintenant, il y a deux problèmes différents : 1) Problème hard Dans la vidéo de "diapason" postée hier soir, on remarque des traits horizontaux colorés, plus ou moins aléatoires. Je crois que ce sont des parasites. Hier soir le MO5 n'était pas relié à la terre. Aujour...

J'ai vu hier le problème de lecture d'un octet de trop en fin de bloc et je l'ai corrigé. Dans le code publié un peu plus haut, j'ai enlevé la lecture de CRC1 en fin de boucle, puisqu'il est déjà lu dans "octet" avant la sortie du while. De toutes façons ca ne provoquait pas d'erreur : ent...

@sam : Le changement de bloc + l'attente de l'octet $FE dure en moyenne une dizaine de cycles. C'est très peu par rapport aux 60 cycles entre deux échantillons, et je ne pense pas que ça puisse dépasser. D'ailleurs, si ça dépassait, il y aurait une chance non négligeable de tomber sur un bit 7 à zér...

Je découvre tout juste le logiciel, et je n'ai pas trouvé le moyen d'afficher les valeurs hexadécimales sur la représentation graphique. Par contre les échantillons capturés peuvent être exportés dans différents formats de fichier, en particulier en binaire. En ouvrant le fichier binaire avec un édi...

A mon avis mieux vaut ne pas toucher le programme Thomson et adapter l'Arduino. Il y a des temporisations partout et il est très facile de les ajuster. Reste à comprendre quel octet vidéo est décalé. C'est probablement un déplacement, mais j'ai beau chercher avec l'analyseur, je ne trouve pas. L'err...

Oui, nous sommes bien d'accord, il y a 56 cycles. Par rapport à une boucle normale de 60 cycles il y a donc 4 µs en moins. L'arduino, lui, reste à la cadence d'une boucle normale, il envoie peut-être un ou plusieurs octets vidéo un peu trop tard. Je vais essayer de les écrire encore plus tôt (à la l...

A la fin le MO5 est planté. Par contre hier, quand il se synchronisait mal, il finissait normalement sur un bit 7 à zéro.

As-tu une explication pour les 4 µs manquantes entre les deux premiers bits de synchronisation de chaque bloc ?
C'est une cause possible de décalage.