[Thomson] Vidéo avec son en streaming

[irios]

Auto-oscillation.

[Daniel]

La démo tourne en boucle depuis midi sur le MO5. Il n'y a pas eu une seule erreur après plus de 50 passages. On peut donc dire que le montage est opérationnel. Quand j'aurai un oscilloscope en bon état j'analyserai précisément le bit de synchronisation pour comprendre la nature des parasites. Mais dès maintenant je vous engage à construire l'interface pour voir les démos sur vos machines.
Ajoutez une résistance de 1K entre D8 et GND (fil blanc et fil noir côté gauche).

sdanim4.png (54.15 Kio) Consulté 4915 fois

Dernière version du sketch Arduino :

Code : Tout sélectionner

/**************************************************\
*                 S D A N I M 4                    * 
*           (c) 2015 - Daniel Coulom               *  
*           http://dcmoto.free.fr/                 *
*           http://forum.system-cfg.com/           *
*--------------------------------------------------*
* Ce code est distribue gratuitement dans l'espoir *
* qu'il sera utile, mais sans aucune  garantie  et *
* sans  engager  la  responsabilité  de  l'auteur. *
* Vous  pouvez  l' utiliser,  le  modifier  et  le *
* diffuser librement, en conservant cette  licence *
* et les références de l'auteur dans   toutes  les *
* copies. L'exploitation commerciale est interdite.*
\**************************************************/

/***************************************************
*                Version 2015.08.14                *
****************************************************
Historique
2015.08.14 temporisations ajustées, fonctionnement ok 
2015.07.30 premiere version issue de sdanim3

Communication parallele avec un ordinateur Thomson
Lecture des donnees dans un fichier sur carte SD
Envoi des octets sur le port D a destination du
port manettes de l'ordinateur Thomson.

Connexion module Catalex pour carte micro SD
 GND --> GND
 SCK --> D13
MISO --> D12
MOSI --> D11
 VCC --> VCC (5V)
  CS --> D10

Connexion DB9 de la manette 0
   1 --> D0 (RX)
   2 --> D1 (TX)
   3 --> D2
   4 --> D3
   5 --> VCC (+5V)
   6 --> D8
   7 --> non connecte
   8 --> non connecte
   9 --> GND
   
Connexion DB9 de la manette 1
   1 --> D4
   2 --> D5
   3 --> D6
   4 --> D7
   5 --> non connecte
   6 --> non connecte
   7 --> non connecte
   8 --> non connecte
   9 --> non connecte
 
 This sketch uses the SimpleSDAudio library for SD card access.
 Visit SimpleSDAudio website for more information:
 http://www.hackerspace-ffm.de/wiki/index.php?title=SimpleSDAudio
*/

#include <sd_l0.h>
#include <sd_l1.h>
#include <sd_l2.h>

#define SD_FILE "sdanim4.sd"
//#define SD_FILE "debug.sd"

SD_L2_File_t AudioFileInfo;  
uint8_t SD_L1_CardCommand(uint8_t cmd, uint32_t arg);
uint8_t string[1024];

void setup()
{
 int i;                    // compteur de boucle
 uint8_t octet;            // zone de stockage temporaire d'un octet
 uint32_t count = 0;       // compteur d'octets
 
 //Initialisations
 noInterrupts();           // desactiver les interruptions
 //pinMode(8, INPUT_PULLUP); // configurer pin8 en entree (bit de synchronisation)
 pinMode(8, INPUT);        // configurer pin8 en entree (bit de synchronisation)
 DDRD = 0xff;              // configurer port D en sortie
 PORTD = 0x00;             // initialiser port D a zero
 SD_L0_CSPin = 10;         // definir CS de la carte SD en D10
 SD_L2_Init(string);       // initialiser la carte SD
 SD_L0_SpiSetHighSpeed();  // frequence d'horloge maxi 

 // Search for file SD_FILE in Rootdir (=cluster 0),
 // search shortname files only (0x00,0x18)
 SD_L2_SearchFile((uint8_t *)SD_FILE, 0UL, 0x00, 0x18, &AudioFileInfo);
 
 // send CMD18 (multiblock read)
 uint32_t offset = AudioFileInfo.ActSector;    // offset = secteur
 if (SD_L1_GetCardType() != SD_CARD_TYPE_SDHC) // si carte non SDHC
     offset <<= 9;                             // offset = octet
 SD_L1_CardCommand(18, offset);                // lance CMD18

 while(count < AudioFileInfo.Size) // tant qu'il reste des octets
 {
  // attente octet 0xfe de debut de bloc
  while(SD_L0_SpiRecvByte() != 0xfe); 
  //traitement d'un bloc de 512 octets lu sur la carte SD 
  // 36 boucles completes de 14 octets plus
  // 1 boucle partielle de 8 octets (36*14 + 8 = 512)
  i = 37; //compteur de boucles
  while(1)  //boucle d'envoi des 512 octets des données d'un secteur
  {
   PORTD = SD_L0_SpiRecvByte();   // echantillon de son impair
   octet = SD_L0_SpiRecvByte();   // lecture anticipee octet video 1
   while((PINB & 0x01) == 0);     // attente bit de synchro à 1  
   PORTD = octet;                 // octet video 1
   delayMicroseconds(3);          // temporisation
   PORTD = SD_L0_SpiRecvByte();   // octet video 2
   delayMicroseconds(8);          // temporisation
   PORTD = SD_L0_SpiRecvByte();   // octet video 3
   delayMicroseconds(5);          // temporisation
   PORTD = SD_L0_SpiRecvByte();   // octet video 4
   delayMicroseconds(7);          // temporisation
   PORTD = SD_L0_SpiRecvByte();   // octet video 5
   delayMicroseconds(8);          // temporisation
   PORTD = SD_L0_SpiRecvByte();   // octet video 6
   delayMicroseconds(5);          // temporisation
   PORTD = SD_L0_SpiRecvByte();   // echantillon de son pair
   octet = SD_L0_SpiRecvByte();   // lecture anticipee octet video1 ou CRC1
   while((PINB & 0x01) == 1);     // attente bit de synchro à 0  
   if(--i == 0) break;            // fin du bloc atteinte 
   PORTD = octet;                 // octet video 1
   delayMicroseconds(3);          // temporisation
   PORTD = SD_L0_SpiRecvByte();   // octet video 2
   delayMicroseconds(8);          // temporisation
   PORTD = SD_L0_SpiRecvByte();   // octet video 3
   delayMicroseconds(5);          // temporisation
   PORTD = SD_L0_SpiRecvByte();   // octet video 4
   delayMicroseconds(7);          // temporisation
   PORTD = SD_L0_SpiRecvByte();   // octet video 5
   delayMicroseconds(8);          // temporisation
   PORTD = SD_L0_SpiRecvByte();   // octet video 6
   delayMicroseconds(5);          // temporisation
  } 
  SD_L0_SpiRecvByte();            // deuxieme octet CRC
  count += 512;                   // 512 octets par boucle 
 }
}

void loop(void) {
}

[__sam__]

Ne peut-on pas détecter les parasites avec un système logiciel anti-rebond? Par exemple on prend comme valeur du bit d'ack la valeur majoritaire sur les 3 dernières lectures de ce bit (il y aura toujours une majorité avec 3 valeurs).

[Notator]

Il faudrait pour cela un échantillonnage très rapide ; et avec un Arduino...

[Daniel]

Ne peut-on pas détecter les parasites avec un système logiciel anti-rebond?

Je n'y avait pas pensé, mais c'est une bonne idée qui mérite d'être étudiée. Je vais essayer.
Le programme actuel permet d'envoyer un octet 0,3 µs après réception du bit de synchronisation. On doit pouvoir allonger ce délai jusqu'à 1 ou 2 µs, ce qui permet de lire pas mal de fois le port B (au moins 4 ou 5 fois). Je donnerai les résultats dès que possible...

[Fool-DupleX]

Ou est ta connexion de GND ? je vois un GND cote thomson branché à RAW, qui n'est pas un GND, ca me semble vraiment bizarre.

Edit: Ah, je soupconne que les noms des signaux ne sont pas les bons cote thomson. Donc ou est le GND ?

Edit 2 : oui, la pin 9 ... Ce serait possible d'avoir des vrais schemas ? On y comprend rien la ...

[PcKid]

Merci daniel , c'est vraiment génial ce procéder.

[Daniel]

Ce serait possible d'avoir des vrais schemas ?

J'ai utilisé Fritzing pour le schéma Arduino. Dans sa bibliothèque de composants il n'a pas les connecteurs DB9 des joysticks Thomson, alors j'ai pris des connecteurs DB9 d'un câble série. Il faut lire uniquement les numéros des broches, pas les noms. Pour la signification des numéros, voir ici : http://dcmoto.free.fr/connecteurs/
Je sais, il faudrait que j'apprenne à créer des composants dans Fritzing, mais je suis très paresseux

@Sam : J'ai essayé de tester plusieurs fois l'état du bit de synchronisation, jusqu'à 20 fois, ce qui prend environ 2,5 µs (testé avec l'analyseur logique). Je pense que dix tests sont suffisants pour supprimer les erreurs pendant la transmission effective des octets. La difficulté est d'empêcher le démarrage de l'Arduino avant le début de la boucle. Il s'écoule au moins 10 secondes, et pendant ce temps il doit y avoir des milliers de petits pics à ignorer, et les 20 tests ne suffisent pas. Donc, pour l'instant, j'en reste à la méthode hard. Plus tard je reviendrai peut-être sur la méthode soft car j'ai d'autres idées : inverser le bit de synchronisation pour commencer par un zéro, tester le bit 7 de l'échantillon son pour détecter le début de la boucle...

[__sam__]

Je ne comprends pas bien pourquoi les mini pics perturbent l'arduino si tu lis le bit de démarrage de la même façon que le bit de synchro (valeur majoritaire sur 10 ou 20 échantillons). En gros il te suffit d'utiliser systématiquement la routine

Code : Tout sélectionner

#define NUM_ECHANTILLONS 10
int READ_PINB() {
   int cnt = 0, i = NUM_ECHANTILLONS;
   while(i--) if(PINB & 1) ++cnt;
   return cnt > (NUM_ECHANTILLONS>>1);
}

dans les boucles de polling.

[Daniel]

Oui, mais l'Arduino n'est pas rapide et il faut faire le test en 2 µs maxi, on n'a pas le temps d'appeler une fonction, ni de faire beaucoup d'opérations. J'ai essayé autre chose du même genre, en initialisant une variable n à zéro :

Code : Tout sélectionner

//attente bit synchro à 1
while(n < 3)
{
 n = PINB & 0x01; 
 n += PINB & 0x01; 
 n += PINB & 0x01; 
}
....

//attente bit synchro à 0
while(n > 0)
{
 n = PINB & 0x01; 
 n += PINB & 0x01; 
 n += PINB & 0x01; 
}

La démo se plante si j'enlève la résistance de 1K. Je n'ai pas contrôlé les timings à l'analyseur logique, mais je pense que le problème est ailleurs. Donc pour l'instant je reste à la solution hard, qui fonctionne parfaitement depuis deux jours (aucune erreur). J'ai aussi commandé un oscilloscope pour en savoir plus (pas celui du lien précédent, un autre du même genre mais plus connu).

Pour Fool-DupleX j'ai refait un schéma propre

sdanim4_20150817.png (10.09 Kio) Consulté 5148 fois

[Fool-DupleX]

J'observe que le signal de la ligne 6 sur la manette est dans l'extension jeux également reliée à CA2 du PIA, qui possède, si cette ligne est programmée en entrée (ce qui est le cas en principe sur Thomson), une pull-up interne. Se pourrait-il que cette pull-up joue un rôle dans cette affaire ?

[Daniel]

Ah oui, c'est bien possible qu'il y ait un bruit ou des parasites passant par l'intermédiaire de cette résistance.

Il faut de toutes façons une pull-up d'un côté ou de l'autre pour que le signal passe à l'état haut. Comme elle est dans le 6821 je n'en ai pas mis côté Arduino. Il serait toutefois plus logique d'avoir l'inverse, mais on part du principe qu'on ne modifie pas le Thomson, alors il faut faire avec... La solution de la pull-down de 1K, à défaut d'être très orthodoxe, est efficace, alors pour l'instant je m'en contente. Je lui reproche seulement de diminuer fortement la tension au niveau haut, qui devient trop proche du seuil de l'Arduino.

Je reprendrai les recherches la semaine prochaine avec un oscilloscope, il apparaîtra peut-être des choses intéressantes...

[Fool-DupleX]

Oui mais avoir a la fois une pull-up et une pull-down est un non-sens, puisque cela conduit à créer un pont résistif : la tension de la ligne flotte quelque part autour de R2/(R1+R2)*Vcc. Je me demande si tout cela ne conduit pas simplement a un signal qui suroscille mais de manière à ce que finalement les oscillations secondaires se trouvent juste en-dessous des seuils de basculement, parce que le signal varie par exemple quelque part entre 1V et 4V. A voir.

[Daniel]

J'aimerais bien connaître la cause exacte des difficultés rencontrées, car elles sont probablement de même nature que beaucoup de phénomènes inexpliqués rencontrés avec des interfaces Thomson.

Je pense en particulier à mon doubleur de bus http://dcmoto.free.fr/bricolage/doubleur/index.html . Il fonctionne plus ou moins bien en fonction de l'ordre des contrôleurs sur la nappe. Idem pour le Megabus Peritek, sur lequel je n'ai pas réussi à faire fonctionner le contrôleur CS91-280. Je l'attribuais à la longueur excessive de la nappe, mais il y a peut-être autre chose. Et enfin tous les essais de connexion de cartes SD ou compactflash ont montré des problèmes similaires.

Dans un proche avenir je vais ajouter une page au site dcmoto pour présenter le matériel et les applications. Il serait pas mal (__sam__, si tu as le temps...) de préparer un petit exemple de fichier .sd, de moins de 10 Mo pour pouvoir le mettre en téléchargement à dcmoto, et libre de droits pour permettre la diffusion de la vidéo sur internet. Ce n'est pas facile à trouver, et je n'ai pas beaucoup d'idées...

[Fool-DupleX]

Les problèmes rencontrées sur un bus sont d'un tout autre niveau que celui d'une ligne qui connecte deux portes logiques. En mettant ton prochain oscillo sur le bus du Thomson, tu pourras déjà constater a quel point les signaux du bus sont bruités et de mauvaise qualité. Sur un bus, outre les problèmes de match d'impédance et de niveau, il faut considérer également le cross-talk entre les lignes, le fan-out des drivers (i.e. le nb maximum de peripheriques attaquables simultanément) et les rebonds liés au fait que le bus reste ouvert à son extrémité. L'impédance dépend de la longueur du bus, l'espace entre les lignes agit également comme capacité parasite. C'est compliqué. Il y a des modèles et ca se calcule, mais pas facilement.