Un kit autour du EF6809P

C'est la catégorie reine de l'ordinophile, 8 bits et pas un de plus!
Single board ou bus S-100 acceptés.

Modérateurs : Carl, Papy.G, fneck

__sam__
Messages : 4620
Enregistré le : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: Un kit autour du EF6809P

Message par __sam__ » 04 juin 2015 16:25

As tu essayé CMPD [$1234,PCR] qui se compile en 5 octets ? (c'est le mot simple le plus long sur 6809)
Samuel.
A500 Vampire V2+, A1200(030@50mhz/fpu/64mb/cf 8go),
GVP530 (MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.

siliconal
Messages : 88
Enregistré le : 24 oct. 2014 20:59

Re: Un kit autour du EF6809P

Message par siliconal » 04 juin 2015 20:12

Pour le mode d'adressage indexé, le seul mode que j'ai programmé pour le moment est le mode indexé à déplacement nul.

Actuellement Je suis entrain de programmer le mode indexé à déplacement accumulateur A, B et D et c'est presque fini.

Les autres modes suivront rapidement.

Le mode ou je trouverai un peu de difficulté est le mode indexé à déplacement sur 5 bits (manipulation au niveau des bits donc quelques instructions de décalage ou de OU ou ET logique seront utiles) mais c'est faisable.

Le mode indexé indirect ne comportera apparemment que quelques difficultés minimes para rapport au mode indexé direct dans l'analyse syntaxique. Donc il sera laissé après avoir fini le mode indexé direct qui sera copié et complété pour avoir le mode indexé indirect.

siliconal
Messages : 88
Enregistré le : 24 oct. 2014 20:59

Re: Un kit autour du EF6809P

Message par siliconal » 05 juin 2015 13:31

Une démo de l'assemblage des instructions en adressage indexé direct à déplacement accumulateurs:

http://www.siliconcept.ma/6809/assmsilicindxoffs.avi

siliconal
Messages : 88
Enregistré le : 24 oct. 2014 20:59

Re: Un kit autour du EF6809P

Message par siliconal » 07 juin 2015 23:23


siliconal
Messages : 88
Enregistré le : 24 oct. 2014 20:59

Re: Un kit autour du EF6809P

Message par siliconal » 07 juil. 2015 19:32

jb_jb_fr a écrit :(...)
Sinon, voila des idées en vrac :
- mettre un clavier de PC connectique PS2. Je ne sais pas du tout comment ca marche (je suppose que c'est de la liaison serie). Ce sera peut-être plus facile a connecter qu'un clavier parallele
- mettre un timer pour faire soit de la mesure soit du multi tache
- mettre une horloge temps reel pour avoir la date et l'heure. De plus généralement elles ont un peu de RAM sauvegardé donc tu pourrais avoir des config sauvegardées.
Salut tout le monde,

En revenant aux anciens sujets proposés pour le développement de mon kit, je vous annonce que j'ai développé ma carte en mettant un timer qui me sert pour le moment pour le débogage, Break points et exécution pas à pas même si ce n'est pas très développé pour le moment.
Il me sert aussi pour l'horloge de l'ACIA pour la communication série, et je suis entrain de réfléchir à comment le faire fonctionner comme horloge temps réel. Pour le multitâche, je le laisse après, vu que c'est tout un projet à lui seul et que c'est très compliqué.

J'ai remplacé le petit afficheur LCD 2 x 16 par un autre plus grand 4 x 20 sur lequel je peux faire fonctionner ma carte d'une façon autonome sans avoir besoin de terminal vu qu'il peut afficher suffisamment d'informations en une seule fois.
J'ai un peu amélioré la routine d'affichage du LCD pour permettre le retour à la ligne automatique à chaque fin de ligne ou à chaque appui sur la touche "Entrée" (codes $0D +$0A), et j'ai amélioré la gestion de l'affichage en implémentant le scrolling d'une façon un peu simple pour le moment, ce qui me permet d'afficher de nouvelles lignes en gardant les trois anciennes lignes toujours affichées.

Concernant le clavier PS/, et c'est aussi très important pour ma carte puisqu'il permet de la rendre complétement autonome et sans besoin de terminal pour communiquer avec elle, j'ai réussi à lire les scancodes des touches pressées et ce en utilisant les interruptions sur FIRQ activées par front descendant de la sortie Clock du clavier PS/2.
Je suis entrain d'implémenter un petit code de conversion Scancode->ASCII, ce qui me permettra de faire entrer les caractères appuyés du clavier et ainsi entrer les commandes et textes à partir du clavier et sans besoin de terminal série.

Dans le même registre j'ai acheté dernièrement un afficher LCD TFT graphique couleur et touchscreen que j'ai pu faire fonctionner avec une carte ARDUINO UNO. La prochaine étape dans ce sens et de le connecter avec mon kit pour l'utiliser comme interface de saisie et d'affichage, ce qui rendra mon kit et ainsi le 6809 plus à la mode.

Je suis entrain d'essayer de repousser les limites du 6809 pour voir ses vraies limites, et pour le moment je trouve qu'il est toujours plus rapide que beaucoup de périphériques qu'il est obligé d'attendre pour continuer l'exécution de son code, exemple: IDE, Afficheur LCD texte microcontrôlé, EEPROM de nouvelle génération.
Jusqu'à maintenant le seul périphériques sur lequel j'ai dû faire quelques optimisation sur le code afin que le 6809 ne soit pas plus lent que lui est le clavier PS/2.

J'espère qu'il reste encore plus rapide avec l'afficheur LCD TFT graphique tactile et les autres nouveaux périphériques que je pourrai essayer prochainement.

Je posterai les codes, photos et vidéos très prochainnement.

__sam__
Messages : 4620
Enregistré le : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: Un kit autour du EF6809P

Message par __sam__ » 08 juil. 2015 00:13

cool, c'est très intéressant ce que tu arrives à tirer du 6809. :D
Samuel.
A500 Vampire V2+, A1200(030@50mhz/fpu/64mb/cf 8go),
GVP530 (MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.

siliconal
Messages : 88
Enregistré le : 24 oct. 2014 20:59

Re: Un kit autour du EF6809P

Message par siliconal » 08 juil. 2015 17:02

Moi aussi je suis surpris de ce que j'ai pu en tirer: communication disque dur IDE en 8 bits, gestion écran LCD, programmation EEPROM de 32 Ko et plus in-situ, programmation d'un moniteur à communication terminal série programmation et d'un mini assembleur exécuté directement par 6809 plus des applications de lecture de plusieurs entrée analogiques multiplexés et tous ça tient dans 4 Ko et maintenant gestion clavier PS/2.

Tout ça sans aucune surchauffe d'aucun composant (tous cadencés à 4Mhz externes, 1Mhz en interne et en bus)!!

Le seul petit problème remarqué actuellement avec tous ces composants (hors disque dur) fonctionnant tous à la fois c'est une chute de tension de presque 1 V due au courant consommé par les deux cartes qui dépasse les 600 mA (approximativement, je ne l'ai pas mesuré). J ne sais pas si c'est normal ou si il y a des court-circuits non francs sur mes cartes vu comment elles sont faites et combien elle sont encombrées!

Je suis parvenu à réaliser la conversion Scancode->ASCII, et maintenant je suis entrain d'adapter le code pour permettre au clavier PS/2 d'être l'entrée standard au lieu de ou même avec le terminal série.

siliconal
Messages : 88
Enregistré le : 24 oct. 2014 20:59

Re: Un kit autour du EF6809P

Message par siliconal » 08 juil. 2015 21:27

Vidéo montrant quelques fonctions de mon moniteur et une démo de capture de température, luminosité et tension.

https://www.youtube.com/watch?v=XOro-jV ... e=youtu.be

siliconal
Messages : 88
Enregistré le : 24 oct. 2014 20:59

Re: Un kit autour du EF6809P

Message par siliconal » 15 juil. 2015 14:40

Vidéo de demo du clavier PS/2 connecté sur mon kit 6809:

https://m.youtube.com/watch?v=gyhqOKPJCfQ

Daniel
Messages : 11699
Enregistré le : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: Un kit autour du EF6809P

Message par Daniel » 15 juil. 2015 17:42

Les progrès du système sont spectaculaires ! Je me souviens encore du premier prototype, le clavier était fait avec des fils volants qu'il fallait mettre en contact à la main. Et maintenant il suffit d'appuyer sur une touche pour envoyer le code ASCII. Il ne manque plus que la souris pour déplacer le curseur à l'écran :wink:
Daniel
L'obstacle augmente mon ardeur.

siliconal
Messages : 88
Enregistré le : 24 oct. 2014 20:59

Re: Un kit autour du EF6809P

Message par siliconal » 21 juil. 2015 16:13

Daniel a écrit :(...) Il ne manque plus que la souris pour déplacer le curseur à l'écran :wink:
Je suis entrain de réfléchir à comment implémenter et connecter une souris PS/2 (ce qui me parait ne pas être très difficile par rapport au clavier PS/2, car la seule différence réside dans le fait que la souris envoie toujours un paquet de quelques octets contenant les déplacements X et Y par rapport au dernier paquet envoyé plus et contenant des informations sur les boutons appuyés).

J'ai encore beaucoup de travail à faire pour compléter l'assembleur et optimiser le code pour le rendre plus rapide et plus compacte afin qu'il me laisse un peu d'espace mémoire pour les prochaines améliorations et nouvelles routines.

Avatar du membre
Papy.G
Modérateur
Messages : 1912
Enregistré le : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: Un kit autour du EF6809P

Message par Papy.G » 21 juil. 2015 23:11

C'est sublime!
L'interface IDE est utilisée en DMA (adressages de blocs), ou utilise un système de fichiers "standard"?
La réception de trames PS/2 ne consomme pas trop de temps processeur?
Tu arrives à exécuter du code depuis l'EEprom, ou tu ne t'en sers que pour les données?
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.

siliconal
Messages : 88
Enregistré le : 24 oct. 2014 20:59

Re: Un kit autour du EF6809P

Message par siliconal » 22 juil. 2015 12:43

Papy.G a écrit :C'est sublime!
L'interface IDE est utilisée en DMA (adressages de blocs), ou utilise un système de fichiers "standard"?
La réception de trames PS/2 ne consomme pas trop de temps processeur?
Tu arrives à exécuter du code depuis l'EEprom, ou tu ne t'en sers que pour les données?
L'IDE a été utilisé pour le moment juste pour test de lecture en sélectionnant un ou plusieurs secteurs au hasard juste pour s'assurer que la communication se fait sans aucun problème.

Pour les applications futures, ça peut être pour le datalogging en RAW sans prise en charge d'aucun système de fichier.

Ca peut aussi servir comme support de sauvergarde et lecture de fichiers en RAW ou en implémentant un système de fichier simple comme le FAT 16 sans prise en charge du partitionning ni de MBR.

Concernant le DMA, ce n'est pas encore prévu dans le développement actuelle. Je préfère ne le traiter qu'avec le multiprocessing et le multitâche, mais ce n'est pas pour bien tôt.

Pour la réception de scancodes du clavier PS/2, au début de sa programmation j'ai eu le problème de perte de quelques bits envoyés par le clavier et de ce fait ne me permettait pas de reconstituer les scanacodes d'une façon exacte, ce qui était due à la routine non optimisée. Mais après optimisation et élimination du code non nécessaire j'ai pu lire tous les bits sans problème et ainsi reconstituer tous les scancodes reçus sans d'une façon fiable (même sans prise en compte de contrôle de parité), l'implémentation de la routine par interruption FIRQ aidant.

Sinon si je devait la programmer par des scrutations de Clocks de PS/2, je crois que je n'aurais jamais pu recevoir touts les bits sans perte car le traitement serait plus lourds à exécuter.

Concernant l’exécution du code à partir de l'EEPROM, je l'ai fait en copiant le code du moniteur (qui n'est pas translatable pour le moment) après modification du point d'entrée (et ainsi toutes les références aux adresse des constantes référencées par des FCC calculées par l'assembleur, hors adresses des périphériques qui étaient référencées par des EQU et hors adresses des variables temporaires référencées aussi par EQU et qu e devaient pas changer) pour le faire correspondre à l'adresse de départ de voulue de l'EEPROM.
L'EEPROM ne pose aucun problème de lecture et se comporte comme une SRAM, par contre pour son écriture, il faut respecter un protocole bien défini pour chaque type d'EEPROM.
Mais il faut faire attention à protéger les octets écrit dans l'EEPROM car sinon ils pourront être écrasés facilement par un code non maîtrisé, car j'en ai fait les frais plusieurs fois.

Pour plus de détails sur l'EEPROM testée, voir page 6 de mon sujet.

Avatar du membre
Papy.G
Modérateur
Messages : 1912
Enregistré le : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: Un kit autour du EF6809P

Message par Papy.G » 22 juil. 2015 22:39

Ah, oui, pour l'IDE, quand je disais DMA, je pensais à adressage direct de blocs, désolé de l'abus de langage. :oops:

Tu prévois d'ajouter un uart dédié au PS/2, pour libérer un peu de temps processeur, ou tu relèves le défi de faire un maximum tel quel? :mrgreen:

Je viens de relire un peu le sujet et d'autres à propos de SBC 6809, et je comprends mieux, l'horloge est relativement lente, et de plus, le processeur peut attendre les données grâce à MRdy.
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.

siliconal
Messages : 88
Enregistré le : 24 oct. 2014 20:59

Re: Un kit autour du EF6809P

Message par siliconal » 23 juil. 2015 14:40

Papy.G a écrit :Ah, oui, pour l'IDE, quand je disais DMA, je pensais à adressage direct de blocs, désolé de l'abus de langage. :oops:
Si tu veux parler de LBA, je ne l'ai pas implémenter, mais je crois que je dois le faire pour remonter un peu en histoire vers les technologies moins lointaines et encore utilisées actuellement.
Papy.G a écrit :Tu prévois d'ajouter un uart dédié au PS/2, pour libérer un peu de temps processeur, ou tu relèves le défi de faire un maximum tel quel? :mrgreen:
Pour le PS/2, je ne crois pas que ce soit possible ou au moins que ce soit plus facile avec un UART vu que la communication PS/2 est certes série mais asynchrone (le microprocesseur doit attendre les impulsions de l'horloge du clavier pour lire les bits et ne génére sa propre horloge) à l'inverse de la communication UART.
Par contre avant de commencer à développer les routines de lecture du PS/2, en craignant que le microprocesseur soit plus lent que la fréquence du PS/2, je m'avais proposé une solution hard en se basant sur des registres à décalages et compteurs décimaux, mais j'ai laissé tmobé quand j'avais essayé la lecture logiciel et que ça a réussi avec peu de code et sans perte de bits.
Papy.G a écrit :Je viens de relire un peu le sujet et d'autres à propos de SBC 6809, et je comprends mieux, l'horloge est relativement lente, et de plus, le processeur peut attendre les données grâce à MRdy.
Oui mais moi au lieu que le microprocesseur attende un signal de l'EEPROM, pour faire simple j'ai mis une temporisation équivalente ou un peu plus grande que le temps d'écriture des données de l'EEPROM en interne.

Répondre