HectorDuino

[yo_fr]

Aie,
Le problème de fiabilité n'est pas du à mon montage TTL, mais aux driver SD :
J'ai une Mega et les points de câblage de la SD sont les pin 50 à 53
d'un autre coté j'utilise le port L (donc les pin 49 à 42) et A (22 à 29).

Bref, lors de l’exécution si je fais une lecture de SD Ram juste avant de causer avec Hector, j'ai une plante. si je supprime cette lecture , non utile dans mon soft, le transfert se réalise...
J'utilise la libraire SD (pas sdfat)
Je pense décâbler le port L pour l’éloigner des E/S de la carte SD.
Une autre voie aussi : il semble que la SDRam reçoit ses signaux en 3.3V et ma platine est en 5V... il me faut donc mettre un convertisseur (SparkFun par exemple à base de BSS138).
=> Lors de l'utilisation de lecteur SD, vous utilisez des convertisseurs ?
Bref je suis pas au bout. C'est dommage car c'est pas mal fonctionnel (50%)

[Daniel]

J'obtiens la meilleure fiabilité avec le module Catalex, équipé d'un régulateur 3.3V et d'un buffer bidirectionnel pour adapter les signaux 5V de l'Arduino aux signaux 3.3V de la carte SD. Pour les interfaces SDMOTO et SDMO avec les ordinateurs Thomson j'utilise aussi le même module.

A défaut de buffer, on peut faire des montages avec des résistances ou des diodes Zener, mais c'est beaucoup moins fiable.

[yo_fr]

C'est bien ce que je crains.
C'est assez bizarre car l'utilisation des programmes de base ont l'air de fonctionner...
Avec parfois des petites incohérences (une lecture de directory ne laisse parfois de coté des fichiers...)

[6502man]

Tu dis que si tu fais une lecture SDRAM ça plante, sinon ça fonctionne et que la lecture SDRAM n'est pas nécessaire à ton soft ?

La lecture SDRAM c'est sur l'Arduino, l'Hector, la SD, VBhector ???

[yo_fr]

Effectivement je n'ai pas été dans les détails du projet...

Alors d'abord le câblage ;
Il s'agit simplement de raccorder les ports dispos sur le connecteur latéral d'Hector à la platine Arduino.
Il y a 8 bits dans un sens et 8 bits dans l'autre, ça c'est pour les data. Ensuite il y a 2 mémoires (externe à Hector)
* Une qui mémorise l'écriture d'un octet par Hector, qui est dispo à Hector en lecture pour savoir s'il peut en écrire un autre. C'est le périphérique qui remet cette mémoire à 0 lorsqu'il lit l'octet.
* Une seconde mémoire existe et c'est pour l'autre sens (écriture du périphérique, lecture et RAZ par Hector).
Ces deux mémoires ne peuvent être programmées car Hector va trop vite pour l'Arduino. J'ai donc mis en place 2 mémoires à base de 7474.

Le raccordement est le suivant :
Port A Hector (Broches 2 à 9 de la 36 broches) => Port A Arduino (pin 22 à 29) : Octet Hector => Arduino

Port B Hector (Broche 10,17,19,13,24,20,12,18 de la 36 Broches) <= Port L Arduino (pin 49 à 42) : Octet Arduino => Hector

Pour ce qui est des mémoires :

7474.JPG (31.63 Kio) Consulté 5290 fois

Ici on voit que les mémoires sont distribuée et à Hector et à Arduino : L'un à besoin de savoir que l'autre lui a envoyé quelque chose et l'autre à besoin de savoir que l'un à pris en compte l'octet pour, éventuellement, en envoyer un autre... (donc ce principe est valable dans les 2 sens).

Le fonctionnement du RESET est assez simple : Je récupére le RESET d'Hector (broche 31 de la 36 points) et la mets sur l'entrée pin 9 de l'arduino.
En cas de détection du RESET dans l'Arduino renvoi l'info de RESET via la pin 8, c'est le signal entrant 2 fois dans le 7474 pour remettre à 0 les 2 mémoires.
A suivre le soft de l'Arduino!

[yo_fr]

Donc le soft :
De base j'ai quelques fonction de "bios" : Lecture et écriture
* Lecture : On regarde si l'entrée disant qu'un octet a été écrit, si oui, on le récupérer et on fait un crénaux sur le raz de la mémoire,
* Ecriture : On regarde si Hector a bien lu l'octet précédent (mémoire à 0), alors on écrit l'octet et set la mémoire.

Suite à ces 2 instructions je suis maintenant capable d'envoyer le microcode à Hector : en effet ici je récupère le principe de l'échange avec le Disc2 : Si on selection l'option "4 Disquette" Hector envoi un octet à AA et ensuite il attend un bloc de programme qui sera chargé en mémoire et lancé. C'est donc ce que je fait : j'envoi un code qui permet d'écrire un code ascII à l'écran, d'attendre une touche (et retourner son code ascii) de mettre une mémoire à une certaine valeur, de lire une mémoire et d'envoyer le contenu, de charge un bloc en mémoire et d'envoyer un bloc mémoire....

A l'aide de cela j'ai bâti un interpréteur de commande dans l'Arduino permettant de communiquer avec Hector. par exemple

Code : Tout sélectionner

Ecrit_Phrase("\r\nFichier enregistre ")

écrit à l'écran d'Hector le texte "Fichier enregistre"...


Au sein de l'arduino j'ai les fonctions de gestion de la carte SD. J'ai donc dans l'interpréteur de commende créé des fonction telque DIR, TYPE pour liste un directory ou le contenu d'un fichier. Les fonction SAVE et LOAD, par exemple, viennent lire ou écrire la SD selon les info reçus depuis Hector directement. Le systeme est parfaitement indépendant du PC : seule la carte Arduino et Hector sont nécessaire au fonctionnement

Comme je le disais, la mise au point du microcode, des principes de l'échange entre la machine host et l'Aduino, j'ai testé cela avec VBHector. OK le code de l'émulation de la platine Arduino était en VB, mais cela m'a permis de développer tout le reste. Le passage à la phase Hector physique n'était alors soumise qu'aux bug électronique et de passage au code C.

[yo_fr]

Pour expliquer mon souci maintenant :
Lorsque j'envoi le microcode à Hector, par exemple :

1) j'attend que l'octet de synchro arrive (AA) (via la fonction lecture)
2) dés qu'il est là, j'envoi octet par octet le microcode (via la fonction écriture)
3) j'envoi le prompt.

Dans ma 1ere version le microcode était inclu dans un tableau C ( byte Microcode[376] = {....} )
Cela fonctionnait très bien.
Pour des raisons d'évolution, il est intéressant d'avoir la main sur le microcode et donc qu'il soit en fichier à la racine de la carte SD.
J'avais donc créé une boucle :
Lecture octet SD => ecriture dans Hector.

Voyant que cela ne fonctionnait pas (sans raison apparente), j'ai repris mon tableau de byte, en laissant la lecture de la SD .... toujours planté ! J'ai donc supprimé la lecture de la carte SD (donc inutile car les octets étaient dans le tableau de byte) et là cela fonctionne...
Donc le simple fait de lire un octet engendre le plantage de ma communication avec Hector.
Ce n'est pas un problème, je pense de temps de lecture, car si je remplace la lecture de la SD par une instruction de type delay(4) (4ms !) cela fonctionne toujours... (ou alors la lecture d'un octet peut être très longue..?)

[6502man]

Je comprends mieux le fonctionnement de ton montage maintenant

Donc tu as un buffer RAM pour les échanges entre l'Arduino et l'Hector .

Tu dis :
"Lecture octet SD => ecriture dans Hector."
Je pense que c'est beaucoup trop lent, est ce que tu ne pourrais pas plutôt procéder comme ça :
- Créer un tableau de byte[xxx]
- attendre la synchro (AA)
- lire le fichier entièrement et stocker dans le tableau de byte[xxx]
- envoyer byte par byte le micro code stocké dans le tableau de byte[xxx] à l'Hector

A moins que l'hector attende une réponse très rapide après la synchro ?

Autre solution charger au démarrage de l'Arduino le micro code dans le tableau de byte[xxx] ???

[yo_fr]

C'est pile poil ce que j'ai fait....
Charger le fichier dans un tableau buffer 1Ko au démarrage et ensuite transférer.

[irios]

Pourrais-tu faire le schéma exact du montage 74LS74 ?
Ce composant fonctionne avec un front montant et non avec un niveau logique. Il prend en compte une information quand à son entrée il voit une transition entre le niveau bas vers le niveau haut et dont le temps de transition minimum doit être de 25ns.
Les différents problèmes pourraient être :
- Le temps de transition n'est pas bien calibré
- Le découplage alimentation du boitier TTL
- Positionnement de pull-up sur les signaux preset et reset
- Le temps minimum à un niveau bas sur les signaux preset et reset de 20ns
- La largeur d'impulsion de l'horloge doit être au minimum de 25ns
- L'alimentation Vcc doit être compris entre 4.75V et 5.25V

En espérant que tu puisses avancer dans ton débuggage !!

[yo_fr]

Alors, l'alim est prise sur la platine et j'ai un beau 5V (4.91v)

J'ai une petite capa entre 7 et 14.

par contre j'ai pas mis de pull up sur les TTL mais les entrées de l'arduino j'ai mis les pull up interne.

J'ai un cordon d'environ 1m entre l'Hector et l'Arduino dans un câble blindé (d'origine un câble imprimante PC)

[irios]

Il serait intéressant de voir à l'oscillo les signaux horloge, data, reset et preset.
Et regarder aussi si tu as du bruit sur l'alimentation 5V.
Dès que tous ces points seront levés, je pense que tu pourras de pencher coté Arduino.

[yo_fr]

en ce moment j'ai pas trop le temps, mais hier soir je me suis essayer à finir le transfert par petits bloc (*) :

Etape 1 : Lecture SD par Arduino et mis en buffer

Etape 2 : Envoyer le buffer à Hector par une fonction d'envoi de data (sur la longueur du buffer)

Etape 3 : Si on a pas fini le transfert total on reboucle à l'étape 1

Et là je me suis aperçu que cela fonctionnait...

(*) : préalablement je chargeais 1 octet depuis la SD et je l'envoyais à Hector puis rebouclage sur l'ensemble du fichier...


Le buffer au départ était de 512 octets, je l'ai passé à 1Ko puis 5Ko (reste de la mémoire de l'Arduino).... Ca marche toujours

J'ai repris mon émulateur et j'ai mis un délai de fonctionnement dans l'envoi des données lors d'un transfert à Hector (dans la "simulation" de l'Arduino)... ça marche plus même symptomes !

En rapprochant tous ces fait j'en arrive à une conclusion : si le transfert dure trop longtemps ça plante !

Il est donc probable que mon problème soit bien soft et non hard (pourquoi je transférerais sans pb X*5ko et non la totalité ?)

En relisant mon code que je transferts dans Hector lors du boot de l'Arduino (le Microcode) j'ai vu que je n'avais pas inhibé les interruptions...

Je ne dis pas que le pb est là (car je ne vois pas pourquoi ce petit code de récupération d'octet serait gêné par une interruption), mais cela doit tourner autour autour de ça quand même...

ça avance par petits pas (surtout en ce moment) mais ça avance :
Hier soir j'ai pu charger le basic 3X, Pengo, Monitrix, Space opera, 2 jeux FORTH, les jeux br : Formule 1, Envahisseurs, grenouille, Othello mais pas Assemblex qui lui ne passe jamais (c'est probablement ma sauvegarde qui n'est pas bonne où il y a encore un truc pas carré...)

Pour info : ces fichiers sont créés sur l'émulateur (VBHector en mode spécifique, pas encore diffusé), enregistrés sur la SD et chargés via l'Arduino !
A suivre donc !

[6502man]

Un buffer de 512 octets est très bien car cela correspond aux secteurs SD

Si tu boucle x fois 512 octets ca fonctionne ou ca plante au bout d'un certain nombre de fois 512 octets ?

Tu transfert sans problème 5 Ko mais au dela ca plante ?

Ton BIOS attend des transferts par blocs et tu peut temporiser entre chaque bloc, ce qui te permet de lire le bloc suivant sur l'Arduino ?

Ton schéma de transferts pourrait ressemblai à ca :
- Hector envoi demande de lecture d'un fichier
- Arduino retourne le nombre d'octets à lire ou le nombre de buffer à lire
- Hector attend le début du premier buffer (pendant ce temps Arduino lit un buffer sur la carte SD)
- Arduino envoi un buffer octet par octet à hector (Hector réceptionne les octets)
- Hector ce remet en attend du buffer suivant si pas dernier buffer transféré (pendant ce temps Arduino lit le buffer suivant)
etc etc ...

Ca te permet d'avoir tout t'on temps pour lire avec l'Arduino buffer par buffer

Si tu ne connait pas le nombre de buffers total à lire, tu peux simplement envoyer les buffers à la suite jusqu'a indiquer à Hector un flag de fin de lecture

[yo_fr]

non, non ça plante plus !
Comme je le disais je pense que cela tient du fait que j'envoyais plein de données et lors d'une interruption Z80 Hector cela ce passait mal (pour une raison que je dois creuser). Mais là cela semble impeccable !

Pour info l'interpréteur de commande se trouve dans l'Arduino. Cela me permet d'avoir un microcode envoyé à Hector très court (entre 353 octets et 400 octets selon les versions) ce qui me permet de charger les programmes commerciaux dans le reste de la machine (je loge ce microprogramme dans la ram d'écran BR, qui n'est jamais utilisée dans les programmes BR (puisque c'est l'écran !) ni dans la plupart des programmes HR...


-HR = haute résolution; BR : basse résolution (pour les non Hectoriens de souche !