vendredi 30 août 2013

VPC-32, casse-tête avec les interruptions

Lors de ma dernière chronique j'écrivais que le code pour la lecture du clavier PS/2 devrait-être terminé dans la journée. Et bien c'est toujours plus long que je le crois au départ. Cette fois ci j'ai eu un sacré casse-tête à résoudre. Mon code vidéo seul fonctionnait bien, mon code clavier seul fonctionnait bien et j'ai ajouter une interruption pour le coretimer qui elle aussi fonctionnait bien seul. Mais lorsque l'interruption du TIMER 2 (vidéo) était active ni le clavier ni le coretimer ne fonctionnait correctement. Malgré une lecture et relecture de la documentation et des recherches dans l'internet je ne voyais toujours pas la solution.

Les registres de l'ombre.

Beau titre non? Ça fait roman d'espionnage. En fait je veux parler des Shadow register set. Le problème avec les micro processeurs qui possèdent un grand nombre de registres est que lors d'une interruption il faut sauvegarder de nombreux registres avant de pouvoir exécuter le code de la routine d'interruption ce qui augmente ce qu'on appelle en anglais interrupt latency. C'est à dire le temps entre le moment où une interruption est déclenchée et le moment ou le code de service de l'interruption est exécuté. Pour régler ce problème les concepteurs de ce type de micro processeur ont eu l'idée d'ajouter un second ensemble (ou plusieurs) de la general registers file de sorte que lorsqu'une interruption se produit le code de service de l'interruption utilise le second ensemble plutôt que l'ensemble des registres utilisé par le code normal. Du coup plus besoin de sauvegarder sur la pile et de restaurer à la fin de l'ISR.

Dans le cas du PIC32MX150F128B il n'y a qu'un seul ensemble de registres secondaire et c'est cette ensemble qu'on appelle Shadow register set. Cette ensemble n'est utilisé que pour les interruptions de priorité 7. Donc dans mon code puisque l'ISR du générateur vidéo NTSC doit avoir la priorité la plus élevé, je l'ai mis au niveaus 7 avec utilisation du Shadow register set. La déclaration est la suivante

void __ISR(_TIMER_2_VECTOR,IPL7SRS) tmr2_isr(void)

IPL7SRS indique au compilateur que cette interruption a le niveau de priorité 7 et utilise le Shadow Register Set (SRS). Il y a 2 autres options SOFT et AUTO. IPLxSOFT signifie que l'ensemble de registre normal est utilisé. IPLxAUTO signifie que le compilateur décide s'il peut utiliser le SRS sinon l'ensemble normal sera utilisé.

Il était évident que le problème que j'avais était causé par l'interruption vidéo, cependant n'ayant pas de débugger en circuit je n'arrivais pas à traquer le bug. Finalement il me vient à l'idée de modifier le code comme ceci pour voir.

void __ISR(_TIMER_2_VECTOR,IPL7AUTO) tmr2_isr(void)

Bingo bug réglé! Pourquoi la première version ne fonctionnait pas? Je n'ai pas eu le temps de fouiller ça mais je suis soulager qu'enfin ça fonctionne.

Beaucoup d'overhead

Pour vous donner une idée du surplus de code généré par le compilateur lorsqu'on choisi l'option IPLxSOFT voici les codes 'C' et assembleur de la première version de l'ISR du coretimer.

Le résultat en assembleur, ahoy! de toutes ces instructions seulement 8 résultent de la compilation du code écris en 'C', le reste c'est de l'overhead.

La documentation explique que lorsqu'une ISR appelle une sous-routine, UpdateCoreTimer() dans ce cas ci, le compilateur n'a pas d'autre choix que de sauvegarder l'ensemble complet des registres généraux sur la pile. Donc pour réduire l'overhead de cette ISR je n'avais d'autre choix que d'éliminer l'appel à UpdateCoreTimer(). J'ai donc modifié le code pour ceci:

Ce qui en assembleur améliore le choses mais ce n'est quand même pas gratuit.

En passant l'ajout de l'interruption pour le coretimer ajoute un faible bruit de fond au signal vidéo. J'ai donc ajouter dans le fichier HardwareProfile.h la ligne #define USE_CORE_TIMER. En mettant en commentaire cette ligne dans le fichier ça supprime l'interruption du coretimer et tout le code associé pour ceux qui voudraient un signal vidéo parfais. L'élimination de ce code signifie qu'il n'y a plus de compteur de millisecondes sys_tick dans le système. Ce compteur est utile pour calculer des délais et des intervalles de temps. Lorsqu'il est présent la routine delay_ms() utilise sys_tick sinon elle utilise la routine delay_us().

Avec tout ça mon code pour le clavier PS/2 n'est pas complété, il me reste encore quelques détails... Ouais! je croise les doigts!

Mise à jour sur https://github.com/Picatout/VPC-32.

dimanche 25 août 2013

VPC-32 schéma électronique

J'ai complété la version initiale du schéma électronique du VPC-32 et j'ai créé le git du projet.

Dans le dossier ressource se trouve le projet KiCad et un document pdf du schéma électronique.

J'aurais du appellé cet ordinateur VSPC-32 pour Very Simple Personnal Computeur 32 bits. Très simple de conception, une seule feuille KiCad a suffit pour en dessiné le schéma. A part le PIC32MX150F128B il n'y a qu'un seul autre circuit intégré et c'est le régulateur de tension. On pourrait s'en passé si on décidait d'alimenter l'ordinateur avec 2 piles 1,5 Volt en série. Mais à 3 volt on est à la limite inférieure pour fournir l'alimentation positive pour le RS-232 donc 3 piles 1,5Volt avec une diode pour faire chuter la tension à 3,6Volt qui est le maximum pour le PIC32. L'ensemble de ces composants devrait coûté moins de 30$CAN. Le PIC coûte moins de 5$CAN. J'ai utilisé un connecteur RJ-11 pour le RS-232 parce que ça prend moins de place qu'un DB-9 mais je vais peut-être changé ça pour un autre type de connecteur.

Comme on le voit il ne restera que 6 E/S libres qui seront branchées sur un connecteur linéaire de 100mil nommé XBUS sur le schéma.

Présentement je suis en train d'écrire le code pour l'interface clavier. En fait je réutilise le code que j'ai déjà écris pour la série de chroniques sur le MSP430 launchpad. Le changement de plateforme ne requière que quelques changements.

Pour l'interface RS-232 le code a déjà été écris lors de ma série sur la présentation des PIC32MX.

Mais le plus gros du logiciel cependant reste à faire, l'interface pour carte SD, système de fichier FAT32, fonctions graphiques, fonctions audio. L'interpréteur, l'éditeur de texte. J'espère compléter ce projet avant la fin de l'année.

Je devrais être en mesure de faire une mise à jour du dépôt sur github contenant le code pour le clavier et le RS-232 avant la fin de la journée.

samedi 24 août 2013

VPC-32, test vidéo ntsc

J'ai débuté ce projet en faisant des tests de génération de signal vidéo NTSC B/N 320x230. Pourquoi pas 320x240 pour être conforme au standard QVGA?. En principe avec la méthode de scan utilisé on devrait obtenir 240 lignes visibles à l'écran, 262 moins les 20 lignes réservés au vertical retrace. Mais en pratique sur les 2 téléviseurs que j'ai essayé seulement 230 lignes sont visibles à l'écran. Je ne gaspillerai donc pas 400 octets de mémoire RAM pour des lignes qui ne sont pas visibles. Donc le tableau représentant le bitmap vidéo occupe 320x230/8 soit 9200 octets de RAM.

Circuit de test

Voici le circuit utilisé pour faire mes test vidéo. Cette partie du circuit ne devrait pas être modifiée en cours de projet. Le signal vidéo généré est conforme à mes attentes.

La diode D1 n'est pas strictement nécessaire, le circuit fonctionne sans elle, sauf que je constate que la réponse en haute fréquence est meilleure avec cette diode installée. Dans mon image test les lignes verticales les plus étroites se confondent lorsque je l'enlève.

RB7 broche 16 est une entrée de synchronisation pour le signal vidéo généré par un périphérique SPI. Ce signal provient d'un OC en sortie sur la broche 11. Les périphériques SPI sur les PIC32MX peuvent fonctionner en mode frame. Dans ce mode le SPI envoie des octets tant que l'entrée sync est active. Le signal de synchronisation en question est généré par un périphérique OC Output Compare et sert à retarder l'envoie du signal vidéo en début de ligne.

code source

test-NTSC.c

font.h

Les MCU PIC32MX possèdent 4 canaux DMA (Direct Memory AAccess). L'utilisation du DMA pour envoyer les bits vidéo au SPI permet d'accaparer le MCU un temps minimum pour la génération du signal vidéo. En effet le DMA va chercher les octets directement dans la mémoire RAM pour les envoyer au SPI sans intervention du core MCU qui lui pendant ce temps peut s'occuper à d'autres tâches.
Au niveau logiciel ce qui m'a donné de la difficulté c'est d'obtenir un signal avec une bonne synchronisation horizontale. Dans mes premiers essais le démarrage du signal vidéo était déterminer par un délais logiciel. Hors une interruption même au niveau de priorité le plus élevé a un temps de latence variable car le MCU doit compléter l'instruction en cours avant de répondre à l'interruption. Le résultat était des lignes verticales en dent de scie et les caractères étaient déformés. J'ai trouvé la solution de ce problème dans le livre de Lucio Di Jasio, Programming 32-bit Microntrollers in C1. La solution consiste a utiliser le mode frame sur le SPI qui génère le signal vidéo et à déclencher le départ part un signal matériel qui lui ne subit pas de variation temporelle. Pour arriver à ce résultat Jasio utilise la transition montante de l'impulsion de synchronisation horizontale du signal NTSC. Mais comme il doit y avoir un délais d'au minimum 4,7µSec entre la fin de cette impulsion et le début du signal vidéo on doit trouver une façon d'introduire un délais supplémentaire. Pour introduire ce délais Jasio utilise un deuxième canal DMA qui envoie des 0 au SPI. Donc un délais en multiple de 32 bits peut être ajouté en début de ligne avant que le vrai signal vidéo soit envoyé. Sur les PIC32 les canaux DMA peuvent-être mis en chaîne. Donc le premier canal envoie un certain nombre de zéros pour créer un délais et lorsqu'il a terminé sa tâche déclenche le deuxième canal qui lui envoie les vrai bits vidéo au SPI.

Même si le livre de Jasio a été une source d'inspiration j'utilise une méthode différente pour générer le délais. Ma méthode permet une résolution du délais beaucoup plus fine. Cette résolution est en fait celle de la période du signal PBCLK qui alimente le TIMER 2. Donc au lieu d'utiliser un deuxième canal DMA j'utilise un deuxième OC qui est cadencé par le TIMER 2 comme celui qui génère le signal de synchronisation NTSC. J'ai donc 2 signaux de sortie OC en phase, celui sur la broche 14 qui est la synchro NTSC et celui sur la broche 11 qui est la synchro pour déclencher le SPI. Il suffit d'ajuster la constante SPI_DLY pour que la transition montante soit retardée d'au moins 5µsec par rapport à celle de HSYNC pour que le signal vidéo parte au bon moment. Et d'utiliser cette transition montante à la place de celle de HSYNC pour déclencher le SPI.

Avec cette méthode j'obtiens un signal vidéo parfais et je peux ajuster finement la position horizontale simplement en modifiant SPI_DLY. Étant donné la qualité du signal obtenu ce code va probablement demeuré tel quel dans la version finale du projet.


NOTES:
1) Programming 32-bit Microcontrollers in C, Exploring PIC32, Lucio Di Jasio, ed. Newnes

projet VPC-32

C'est à la fin des années 70 qu'on a vu apparaître sur le marché les premiers ordinateurs personnels avec un clavier et un interpréteur BASIC, tel que les Apple II, TRS-80 , Commodore PET. Ces premiers ordinateurs personnels utilisaient des microprocesseurs 8 bits tel que les MOS Technologies 6502, Zilog Z80 et Intel 8080. L'acronyme PC (Personnal Computer) est entré dans le langage courant quelques années plus tard avec le premier IBM-PC. Ces ordinateurs coûtaient chers, en dollars constant le TRS-80 vaudrait aujourd'hui plus de 1200$. Considérant ses faibles capacités c'est ridicule par rapport à ce qu'on pourrait faire avec la technologie d'aujourd'hui.

De nos jours il est possible de fabriquer soi-même son propre ordinateur qui aurait des capacités supérieures à ceux de cette époque pour moins de 50$. Mon projet VPC-32 (Very Personnnal Computer 32 bits) a pour but de fabriquer un ordinateur à très faible coût mais avec des capacités égales ou supérieures à celle du TRS-80 modèle 1 en utilisant un minimum de composants de la technologie moderne. voici un diagramme bloc de l'ordinateur que j'envisage.

Ce diagramme ne représente que l'idée initiale et pourrait évoluer en cours de chemin. A l'époque les programmes étaient enregistrés sur des cassettes audio ou au mieux sur des disquettes 5-1/4" simple face d'une capacité de 170Ko. Le VPC-32 aura quand à lui un lecteur de carte SD, plus rapide et avec une capacité de stockage représentant plusieurs milliers de disquettes.

Donc pour fixer les idées voici les caractéristiques du VPC-32 tel qu'envisagées à ce moment-ci.

  • Microcontrôleur 32 bits PIC32MX150F128B (DIP-28).
  • 1 clavier PS/2 pour la saisie.
  • 1 interface RS-232.
  • 1 sortie vidéo NTSC Blanc/Noir.
  • 1 sortie audio monophonique (PWM).
  • 1 lecteur de carte SD.
  • Affichage texte 28 lignes de 53 caractères.
  • Affichage graphique 320x230 B/N.
  • Un éditeur de texte simple.
  • 1 interpréteur moderne (pas BASIC), FORTH?, PYTHON?, LUA?, AUTRE...

Je vais utiliser le moins de composants possible et ce seront des composants en format pour montage à travers trou de sorte que n'importe quel amateur pourra le fabriquer sur une carte de prototypage à grille de 100mil. Il sera alimenté à 3,3Volt (3,0-3,6Volt). Il pourra donc être alimenté par 2 piles AA ou CC. J'ai choisi le PIC32MX150F128B car c'est le modèle de PIC32MX disponible en DIP-28 qui possède la plus grande capacité mémoire. 128Ko de flash et 32Ko de RAM. La mémoire vidéo à elle seule occupera 9200 octets.

Donc à l'allumage de l'ordinateur la console va présenté l'invite de commande du langage choisi (à déterminer) et l'utilisateur va entrer du code et des commandes en interactif ou lancer l'éditeur de texte.

Je vais présenter une série de chroniques au fur et à mesure que le projet va évolué. Puisque ces derniers temps j'ai travaillé beaucoup sur la génération de signal vidéo NTSC je vais commencer par ça tandis que c'est frais en mémoire.

A cette époque la mémoire FLASH n'existait pas encore et le langage 'C' n'était pas répandu comme aujourd'hui. Le système d'exploitation était entièrement écris en assembleur et inscris dans une mémoire ROM, il n'était donc pas question de flasher une nouvelle version du BIOS(OS). Pour ma part je vais travailler en 'C' en évitant l'assembleur autant que possible.

samedi 17 août 2013

Pong sur PIC10F322

Pong est le premier jeux vidéo commercialisé pour l'usage à domicile au début des années 70. Après avoir vu ce jeux réalisé sur un PIC12F1840, je me suis demandé s'il serait possible de le réaliser sur un MCU encore plus petit. Pour le savoir il fallait tenter l'expérience. Ce que j'ai fait avec succès.

démo sur youtube

Circuit électronique

matériel requis

  • 1 microcontrôleur Microchip PIC10LF322
  • 2 prise audio RCA
  • 1 condensateur céramique 100nF
  • 1 condensateur électrolytique 10µF
  • 1 commutateur ON/OFF pour l'alimentation
  • 2 piles 1,5Volt pour l'alimentation
  • 1 diode 1N4148
  • 2 transistors NPN 2N3904
  • 2 résistance 1K 1/4watt
  • 3 résistances 10K 1/4watt
  • 1 résistances 470R 1/4watt
  • 3 résistance 4k7 1/4watt
  • 1 résistance 100R 1/4watt
  • 4 boutons à contact momentané
Le circuit est conçu pour fonctionner avec une alimentation de 3 à 3,6 volt. RA0 est la sortie vidéo qui est ajoutée au signal de synchronisation NTSC qui sort sur RA1. RA2 est la sortie audio mais sert aussi d'entrée pour les boutons de contrôle qui déplacent les raquettes vers le bas. RA3 est utiliser pour les boutons qui déplacent les raquettes vers le haut. L'agencement des transistors Q1 et Q2 permet de sélectionner quel boutons sont lus puisqu'on ne dispose que de 2 entrées on doit les lire en alternance. la sortie vidéo RA0 est utilisée pour sélectionner la lecture joueur gauche/joueur droite. Lorsque la sortie RA0 est à 3 volt le transistor Q1 est en saturation alors que Q2 est bloqué. Ce qui permet seulement aux boutons de gauche de fonctionner. Lorsque la sortie RA0 est à 0 volt Q1 est bloqué et Q2 est en saturation permettant aux boutons de droite de fonctionner. Cette lecture n'interfère pas avec le signal vidéo ni la sortie audio car elle n'est effectuée que lorsqu'il n'y a pas de son et de vidéo en sortie.

Le code source

L'ensemble du projet est sur https://github.com/Picatout/pong. Le programme comprends 2 fichiers, pic10f322_m.inc est un fichier de macros d'usage général. Le programme principal est dans le fichier mini-pong.asm. Le programme est entièrement écris en assembleur et occupe presque la totalité de la mémoire flash soit 510 des 512 instructions possible. 42 octets RAM sont attribués à la mémoire bitmap vidéo. La minuterie TIMER2 est utilisée pour générer le signal de synchronisation NTSC par PWM. Une interruption se produit à la fin de chaque cycle PWM. Toute la logique du programme s'exécute à l'intérieur de cette interruption. Les tâches à exécuter sont cédulées selon le numéro de ligne conservé dans la variable ln_cnt. Au début de l'interruption la variable est incrémentée ensuite le céduleur choisi la tâche a exécuter en fonction de cette valeur. Étant donner que la tâche video_output a la plus haute priorité elle est cédulée avant toutes les autres. Les autres tâches ne sont exécutées que lorsqu'il n'y a pas de sortie vidéo. Chaque tâche doit-être complétée avant la fin du cycle PWM donc avoir une durée inférieure à 63,5µSec.

pic10f322_m.inc
mini-pong.asm

Il a fallu que le code soit analysé minutieusement en accordant la priorité à la réduction de sa taille pour réussir à le faire entrer dans cette espace limité. J'ai eu plusieurs échecs de compilation part manque d'espace avant de réussir à caser le programme dans cet espace restreint.

Au démarrage le joueur de gauche a le service. On peut identifier le joueur qui a le service par la balle placée au centre de sa raquette. Pour faire le service le joueur doit déplacer sa raquette dans une direction ou l'autre. Lors de l'échange un joueur peut modifier la trajectoire de la balle en positionnant sa raquette pour que la collision avec la balle se fasse à un endroit différent de la raquette. Les raquettes on 3 pixels en hauteur. Si la balle atteint le pixel du haut la balle repart à 45 degrés vers le haut. Si la balle frappe la raquette au centre elle repart à l'horizontal. Si elle frappe sur le pixel du bas elle repart à 45 degrés vers le bas. Pour modifier la vitesse de la balle il faut changer la valeur de BALL_DLY. Pour changer la vitesse de déplacement des raquettes il faut changer la valeur de BTN_DLY.

mercredi 7 août 2013

msp430 launchpad, partie 11

génération signal NTSC 256x230 pixels

Dans la conclusion de la partie 8 de cette série de chroniques, je mentionnais que j'entrevoyais la possibilité d'utiliser une mémoire RAM SPI Microchip 23K256 comme mémoire vidéo pour augmenter la résolution. Dans cette chronique je présente le résultat des mes expérimentations à ce sujet. Avec le circuit et le logiciel présenter ici j'obtiens une résolution de 256x2301 pixels en noir et blanc. La mémoire 23K256 possède 32Ko mais le buffer vidéo n'en utilise que 256/8*230=7360. Tous les fichiers du projet sont sur https://github.com/Picatout/ntsc-3

Le circuit


P2.1 est la sortie synchronisation NTSC qui se trouve à utiliser la minuterie TIMER_A1 pour générer un signal PWM à la fréquence du balayage horizontal. La sortie P2.0 est utilisée pour générer un signal de blanking qui consiste à mettre la cathode de D1 à 0 volt pendant la phase de synchronisation. La diode D1 a pour rôle d'empêcher que le voltage du signal vidéo n'abaisse le niveau de tension en bas du niveau noir puisque le signal à la sortie SO du 23K256 peut tirée la sortie vidéo vers le haut mais pas vert le bas. Le signal vidéo est récupéré à la sortie de la mémoire 23K256 à la broche 2. P1.5 est le signal clock qui contrôle l'interface SPI de la RAM tandis que P1.7 est le MOSI ( MCU vers RAM) et P1.6 le MISO ( RAM vers MCU). P2.2 contrôle le chip select de la RAM.

Voici une capture à l'oscilloscope du signal vidéo qui est générer par ce circuit.


Le niveau plus que noir représente les seuils avant (front porch) et arrière (back porch) du standard NTSC. Le balayage est de type progressif 263 lignes mais seulement 230 lignes sont visible à l'écran. Le fichier main.h contient les constantes reliées au signal vidéo.

Logiciel

Le fichier spi-ram.c contient le code pour l'interface avec la RAM SPI et peut-être utilisé dans d'autres projets sans changement. Le démo ne s'en sert que pour l'initialisation de l'interface SPI.

Le démo consiste à copier l'image (fonction copy_img_2_sram dans le fichier main.c) qui est en mémoire flash du MCU dans la mémoire 23K256 pour l'afficher et ensuite à imprimer une ligne de texte en bas de l'écran. Le message est MSP430G2553 B/W NTSC VIDEO DEMO. 256X230. l'image du loup est contenu dans le fichier loup.h et fait 176x233 pixels on a donc 2 bandes noires de chaque côté. Voici une photo prise de mon téléviseur montrant le résultat.


Dans le dossier images du dépôt github se trouve l'image originale loup.bmp, le fichier loup.txt qui est le data extrait de loup.bmp et finalement le script openEuphoria que j'ai utilisé pour convertir loup.txt en loup.h, cvt-loup.ex. L'image en tons de gris est convertie en noir et blanc en utilisant l'algorithme de Floyd-Steinberg.

Contrairement au démo de la partie 8 celui-ci a recours à la programmation assembleur (nstsc-isr.asm) pour les interruptions du TIMER A1 et ce afin d'optimiser la vitesse d'exécution car l'essentiel du temps processeur se passe dans ta1_ccr0_isr et ta1_ccrx_isr.

Limitations

Le principal problème avec ce système est la vitesse (lenteur) avec laquelle on peut mettre à jour la mémoire SRAM. En effet on ne peut l'accéder que pendant la phase de synchronisation verticale. Ce qui donne environ 1 milliseconde à toute les 16 millisecondes. Et pendant cette milliseconde on ne lit/écris qu'un maximum de 32 octets par interruption ta1_ccr0_isr. Dans la première version du démo, la fonction draw_char utilisait les fonctions dot et erase_dot pour écrire dans la mémoire SPI RAM un pixel à la fois. Ça prenait plusieurs secondes pour écrire une seule ligne de texte. J'ai donc modifier le code pour utiliser un tampon en mémoire MCU (disp_buffer) où la chaîne complète est écrite avant de transférer le disp_buffer dans la 23K256 ligne par ligne. Avec cette méthode ça prend une fraction d'une seconde. A cause de cette lenteur écrire un jeux vidéo sur ce système présenterais un défis. Une solution possible est d'aligner les sprites sur les octets et d'utiliser une dimension horizontale multiple de 8 bits, i.e. 8x8, 8x16, 16x16. Il faut comprendre cependant que ça prend le même temps de mettre à jour une grille de 8x8 que 16x8. Le transfert entre MCU et SPI RAM se faisant par ligne de 32 octets. Comme le programme principal dispose de très peut de temps pour faire son travail aligner les sprites sur les octets éviterais d'avoir à shifter les bits à gauche ou à droite comme c'est fait dans draw_char. On peut aussi utiliser un buffer vidéo double dans la SRAM puisqu'il y a suffisamment de mémoire libre.

Finalement la vitesse de transfert SPI est augmentée (diviseur 2 au lieu de 3) pendant les opérations vidéo video_op. Ceci afin de laisser du temps à la boucle de code programme principal. Il n'en reste vraiment pas beaucoup entre chaque interruption.

Autre avenue à explorer

Microchip vend une mémoire RAM sérielle SPI (23LC512) qui peut utiliser un bus 1,2,4 bits. A 4 bits on pourrait fabriquer un D.A.C. avec 16 niveaux de gris en conservant la même résolution. 32Ko (29440 Octets en fait) suffirait pour un buffer simple ou 64Ko pour un double.

Mise à jour 2013-08-09

Il y avait des bugs dans ntsc-isr.asm qui ont été corrigés. J'ai aussi modifié le démo pour utilisation de pages vidéo. Maintenant le démo utilise 2 pages vidéos. Une copie l'image du loup est faite d'une page à l'autre et les 2 pages sont affichées en alternance avec le numéro de la copie en bas de l'écran. Ça prends environ 5 secondes par copie!!


NOTES:
1) En fait j'ai obtenu une résolution de 384x230 pixels en diminuant le diviseur de l'interface SPI à 2. Mais le haut de l'image était quelque peut distortionnée. Je suis donc redescendu à 256x230 (SMCLK_DIV=3) pour obtenir une meilleur stabilité.

vendredi 2 août 2013

msp430 launchpad, partie 10

Carte de prototypage sans soudure

Je me suis fabriquer une petite carte de prototypage sans soudure pour brancher directement sur la carte launchpad. Dans cette partie je décris le matériel et donne les instructions pour construire une telle carte.

1

Matériel requis

  • 1 morceau de stripboard avec grille de 100mil. 1,75"x2" (45mmx51mm).(
  • 1 mini carte de prototypage sans soudure 170 points avec dessous auto-adhésif (i.e. Robotshop.com p/n RB-Spa-139).
  • 2 rangés de 10 broches de connecteurs SIL 100mil. mâle (i.e. Robotshop.com p/n RB-Dfr-113).
  • 2 rangés de 10 broches de connecteurs SIL 100mil. femelle. (i.e. Robotshop.com p/n RB-Ada-27).

Fabrication

Entre les 2 rangées de connecteurs sur la carte il y a 1,8 pouce (45,7mm) et la carte elle-même a 2 pouces (50,8mm) de largeur. Il faut donc couper un morceau de carte stripboard comme illustré ici.

Les lignes noires indiquent l'endroit où il faut couper les bandes de cuivre pour isoler les connecteurs de gauche de ceux de droite.

Soudez d'abord côté cuivre sur la deuxième rangé de trous à partir du rebord les connecteurs femelles. Comme on est côté cuivre il faut laissé un espace entre le plastique du connecteur et la carte afin que la pointe du fer à souder puisse atteindre les broches. Il faut utiliser une pointe de fer à souder très fine.

Soudez les connecteurs mâles du côté opposé de la carte et il ne reste ensuite qu'à coller la mini carte de prototypage entre les rangés de connecteurs côté cuivre. J'ai identifié les connections en collant simplement des étiquettes de papier sur les connecteurs femelles.


Notes:
1) Les connecteurs qui viennent avec la carte launchpad sont femelles mais pour ma part j'avais plutôt utilisé des connecteurs mâles sur la carte de sorte que pour mon montage je n'ai utilisé que des connecteurs femelle, comme un observateur attentif l'aura noté sur la photo du haut.