Pourquoi FORTH n'a jamais été populaire

J'ai choisi DIOS FORTH comme langage de programmation pour le VPC-32 pour 2 raisons:

1. Adapter DIOS FORTH pour le VPC-32 était la solution la plus simple et exigeant le moins de temps.
2. J'ai toujours été séduit par l'extrême simplicité de la syntaxe du FORTH.

Ceci dit je n'ai jamais vraiment développer de programmes en FORTH bien que j'ai lu les 2 livres écris par Leo Brodie ainsi que celui de Robert Van Loo intitulé Programmer le FORTH aux éditions Marabout. Je me suis amusé avec ce langage et j'en suis resté là. Pourquoi?

Oui le FORTH a un aspect séduisant par son extrême simplicité. On pourrait dire la même chose de la programmation en assembleur. Mais ça demande aussi plus d'effort. Le problème avec le FORTH est qu'il faut continuellement visualiser l'état de la pile des données. Quand on programme en FORTH il faut en quelque sorte faire le travail fait normalement par le compilateur. On empile les paramètres et ensuite on appelle la fonction. Il faut continuellement s'assurer que la pile est balancée.

Voici un exemple comparant une fonction appellée fibo écrite en python et ensuite en FORTH. J'ai encadré en rouge ce que j'ai saisie à l'écran dans les 2 cas.

D'abord on constate que l'écrite de la version FORTH demande moins de caractères mais pour quelqu'un qui ne connais pas le FORTH ce n'est pas plus compréhensible que du chinois.
dup, swap et over sont des mots qui servent à manipuler les valeurs qui sont sur la pile des arguments (données). dup empile une copie de l'élément qui est au sommet de la pile. swap inter change la position des 2 éléments qui sont au sommet de la pile et finalement over crée une copie du deuxième élément et le place au sommet de la pile. Le . lui remplace le print(n) de python. En python toute cette gymnastique est en partie faite par le compilateur et par une affectation à une variable temporaire: tmp=n1 et ensuite on retransfert tmp dans n0. Tout ça est fait en FORTH par des swap, dup et over. En fait c'est plus efficace en FORTH. Plus efficace mais plus exigeant au niveau du mental.

Voilà pourquoi FORTH n'est jamais devenu un langage populaire. Il est certain qu'à force de le pratiquer on devient plus à l'aise avec ces manipulations mais le fait est que l'apprentissage de python ne demande pas un tel effort au programmeur débutant.

En conclusion je suis en train d'étudier les options qui s'offre à moi dans le but de remplacer DIOS FORTH par un interpréteur python. A moins qu'il y est au final suffisamment d'espace dans la mémoire flash pour les deux langages.

VPC-32, forth et shell

Mon travail sur le VPC-32 progresse. Après avoir étudié plusieurs options et travaillé sur la création d'un système forth personnel écris en assembleur, j'ai laissé tombé ce travail pour adapter DIOS Forth de Lubos Pekny. Comme le travail de M. Pekny est bien fait et entièrement écris en 'C' l'adaptation a été facile.

J'ai ensuite travaillé sur le shell de commande. Les commandes dir, del,copy,ren,forth et more sont maintenant fonctionnelles. Il m'en reste encore 7 à écrire. Je travaillerai ensuite sur l'éditeur de texte.

Le module son est partiellement fonctionnel et permet actuellement de jouer des mélodies mono tonale en arrière plan.

Voici une capture d'écran d'une session forth.

Pour ceux qui ne connaisse pas le language Forth, j'ai simplement défini un nouveau mot dans le dictionnaire qui s'appelle test. Ce test imprime simplement une suite de n nombres à partir de zéro. Le nombre est passé en argument sur la pile de donnée, ici il s'agit d'un nombre 10. En Forth tout est inversé, on empile les arguments ensuite on appelle le mot (fonction).

Question quiz

Combien de LEDS peut-on contrôler indépendamment l'un de l'autre avec un MCU qui n'a que 3 E/S comme par exemple le PIC10F200?

Si je vous dis 4 serez-vous sceptique?

J'ai eu un idée et j'ai décidé de la vérifier avec un PIC10F200. Il s'agit d'utiliser GP3 comme sortie pour contrôler un LED en utilisant le Weak Pullup et un transistor. Si on active la résistance Weak pullup sur une entrée, celle-ci est tirée à +5Volt. J'ai fait le test avec un transistor bi-jonction 2N3904 et un transistor MOSFET 2N7000. Dans le cas d'un transistor bi-jonction c'est le courant qui circule dans la base qui commute le transistor. D'après la feuille de spécification du PIC10F200 lorsqu'une entrée est mise à Vss le courant à travers le weak pullup est de 250µA. Si le transistor a un gain de 100 on obtient 25mA de courant au collecteur. En pratique à cause du voltage base-émetteur, le courant dans la base est moindre que ça. Je mesure 2,56 volt au bornes de la résistance de 200 ohm lorsque la LED est allumée ce qui donne 12,8mA. Si je remplace la résistance par 100 ohm, j'obtient 22mA. Le gain du transistor est probablement supérieur à 100.

Avec un transistor MOSFET 2N7000 l'impédance d'entrée de ce type de transistor est très élevée et c'est le voltage qui commute le transistor. Donc lorsqu'on active le pullup le transistor passe en conduction. Cependant il faut utiliser une résistance de 1M entre le gate et Vss pour que la LED s'éteigne lorsqu'on désactive le pullup. Avec ce transistor et la résistance de 100 ohm j'obtiens 23,7mA à travers le LED.

On a donc 4 sorties indépendantes pour contrôler 4 LEDS ou autre chose.

#include <P10F200.INC> radix dec __config _WDTE_OFF & _MCLRE_OFF #define OPTION_CFG ~((1<<T0CS)|(1<<PSA)) led_on macro movlw OPTION_CFG andlw ~(1<<NOT_GPPU) option endm led_off macro movlw OPTION_CFG option endm udata dly_cntr res 1 tmp res 1 org 0 movwf OSCCAL bcf OSCCAL, 0 main led_off call delay led_on call delay goto main delay clrf tmp clrf TMR0 movlw 100 movwf dly_cntr delay_01 movlw 39 addwf tmp, F movfw TMR0 subwf tmp, W skpz goto $-3 decfsz dly_cntr goto delay_01 return end

VPC-32, progression

Cette semaine j'ai travailler sur le code pour la console texte ainsi que sur le système de fichier sur carte SD. Grâce au code emprunté au projet Pinguino j'ai progressé rapidement en ce qui concerne l'accès à la carte SD et au système de fichier FAT. Donc actuellement je suis capable d'utiliser les fonctions de l'API du système FAT qui se trouve dans le fichier ff.c du projet Pinguino. Je n'ai pas tester la fonctionnalité de toute l'interface mais j'arrive à ouvrir un fichier obtenir ses statistiques, lire, me déplacer dans le fichier et le modifier. La carte de 2Go que j'utilise est formatée en FAT16. Je n'arrive pas cependant à utiliser une carte formatée en FAT16 sur mon laptop qui est en Windows 7. La fonction mount() ne reconnaît pas le système de fichier dans ce cas. Je n'ai pas d'ordinateur en Windows xp. Je ne sais si ça fonctionnerais si la carte était formatée sous ce système d'exploitation pas plus sous quel système d'exploitation la carte que j'utilise présentement a été formatée. La différence doit se située au niveau du système de fichier.

Donc je progresse, il me reste à créer la librairie graphique, un shell de commandes basique, l'interpréteur pour le langage (python ou autre) et à intégrer tout ça ensemble. Pour l'intégration je vais peut-être installer un noyau exécutif pour céduler les tâches.

Je suis satisfait du rythme de progression actuel.

dépôt: https://github.com/Picatout/VPC-32

VPC-32, prototype #1

J'ai complété le montage du prototype #1 du VPC-32 modèle 1. Réussi à faire le montage sur une carte à bandes avec grille de 100mils même si les connecteurs RJ-11, PS/2 et carte SD n'était pas conçus pour ça. Pour le RJ-11 il y a 2 rangés de 3 broches espacées de 100mils avec une distance 100mils entre chaque rangée mais les 2 rangés sont décalées de 50mils. J'ai du percé de petits trous entre ceux déjà existant pour la deuxième rangée. Pour la base SDCard les 7 premiers contacts sont à 100mils mais les autres sont plus rapprochés. Mais comme je ne me sert pas des contacts 8,9, du détecteur de carte et du détecteur de protection contre l'écriture qui sont les contacts rapprochés j'ai pus ignorer ces contacts. Je suis soulagé de ne pas avoir eu à fabriquer un circuit imprimé.

Autres photos sur https://github.com/Picatout/vpc-32/tree/master/resources/prototype

Pour le pilote de carte SD je vais essayé de trouver du code open-source adaptable facilement à ce MCU. C'est la prochaine étape.

Liste matériel

• 1 carte de prototypage à bandes 4" x 5" (10cm x 12,5cm).
• C1 électrolytique 47µF/16Volt
• C2, C3 céramique 22pF
• C4,C5,C6,C7 céramique 100nF
• C8 électrolytique 10µF/16Volt
• C9 céramique 4,7nF
• C10 céramique 2,2nF
• D1 diode rectification 1N4001
• D2 Status LED 2mm vert
• D3 Power LED 2mm rouge
• D4,D5 diode commutation 1N4148
• J1 base carte SD, Digikey P/N A101492CT-ND
• J2 base miniDIN-6 contact (PS/2), Digikey P/N 5749180-1-ND
• J3 prise RCA jaune, Digikey P/N CP-1462-1-ND
• J4 base RJ11, Digikey P/N A31422-ND
• J5 prise RCA noire, Digikey P/N CP-1459-1-ND
• K1 (3 contacts), P1 (2 contacts), P3 (5 contacts), barrette contacts 100mils, Digikey P/N SAM1035-50-ND
• P2 5 contacts) barrette contacts 100mils angle 90degrés
• Q1 transistor PNP 2N3906
• Q2 transistror NPN 2N3904
• R1,R2 résitance 1/4W 5% 51k
• R3,R4,R6,R11,R15,R17 résistance 1/4W 5% 10k
• R5,R7 résitance 1/4W 5% 150 ohm
• R8,R19 résistance 1/4W 5% 1K
• R9 680R
• R10 10R
• R12 120R
• R13,R14,R16 résistance 1/4W 5% 4k7
• R18 résistance 1/4W 5% 3k3
• SW1 bouton contact momentané N/O
• U1 régulateur de tension 3,3Volt LDO LM3940-3.3
• U2 Microcontrôleur Microchip PIC32MX150F128B
• X1 crystal 10Mhz

VPC-32, pourquoi ça ne fonctionnait pas!

Dans la chronique précédente je parlais du casse-tête que j'ai eu avec les interruptions. J'ai trouvé pourquoi ça ne fonctionnait pas. Les PIC32MX1xxx/2xxx n'ont pas de Shadow Register Set. C'est fou le temps qu'on perd lorsqu'on ne prends pas le temps de lire la documentation au complet.

Depuis la dernière chronique j'ai testé le code pour le clavier PS/2 tout semble OK. J'ai aussi complété la table de caractères dans font.h pour les 127 premiers codes ASCII.

Finalement à la fin de ma dernière chronique je mentionnais que l'interruption du coretimer introduisait du bruit dans le signal vidéo. Je mentionnais aussi dans cette même chronique à quel point l'option IPLxSOFT dans la déclaration des ISR introduit un overhead incroyable lorsque l'ISR appelle une sous-routine. Puisque tmr2_isr utilise l'ensemble de registres normal (n'ayant pas de SRS) et que tmr2_isr appelait la fonction DmaChnEnable() le temps de latence était énorme. Ce problème est réglé j'ai simplement remplacé l'appel à la sous-routine DmaChEnable() par une simple affectation au registre DCH0CON. Ce qui a eu pour effet de réduire la latence de tmr2_isr et de faire disparaître le bruit dans le signal vidéo.

DCH0CON |= 128; // remplace DmaChEnable(0);

Je suis prêt maintenant à commencer le travail sur le pilote de périphérique pour la carte SD. Mais avant je dois fabriquer un prototype du VPC-32.

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