mercredi 8 novembre 2017

minix 3

Aujourd'hui j'ai appris que minix 3 est un système d'exploitation des plus utilisés au monde. En fait même Andrew S. Tanenbaum le créateur de minix l'ignorais jusqu'à tout récemment. Depuis 2006 tous les microprocesseurs Intel Core contiennent un processeur secondaire que le fabriquant appelle Management Engine. Ce processeur fonctionne en dehors du processeur principal et du BIOS avec son propre logiciel et a accès à toutes les fonctionnalité de l'ordinateur même s'il n'y a pas de système d'exploitation installé ou même de disque dur. Il y a eu beaucoup de critiques concernant le management Engine et récemment des hackers ont trouvé une méthode pour le désactiver et par la même occasion étudier le logiciel qu'il utilise. C'est là qu'ils ont découvert qu'il utilise une version customisé par Intel du système d'exploitation minix 3. Puisque les processeurs Intel Core sont les plus utilisés dans les ordinateurs de bureau et les laptops ça signifie que minix 3 est un des systèmes d'exploitations les plus utilisés dans le monde et personne n'était au courant!

Qu'est-ce que minix 3

Minix 3 se distingue des systèmes d'exploitation plus connus comme Windows, OSX et GNU/Linux d'une façon remarquable. Contrairement à ces 3 derniers c'est un système d'exploitation à micro noyau, alors que les 3 autres sont basés sur des noyaux monolithiques.

Noyau monolithique

Tous les systèmes basés sur Unix comme OSX, ainsi que ceux basé sur Linux ou encore le noyau NT4 de Windows possèdent un noyau monolithique. Pour comprendre ce qu'est le noyau d'un système d'exploitation vous pouvez consulter l'article suivant: Qu'est-ce qu'un système d'exploitation. Un noyau monolithique comme Linux est un gros module logiciel comprenant des centaines de milliers de lignes de codes. Plus on ajoute de fonctionnalités plus il grossie. Hors Linux existe depuis longtemps et il est devenu très gros.

Micro noyau

Un micro noyau comme celui de minix au contraire implémente un minimum de fonctionnalité et renvoie tous le reste dans l'espace utilisateur. Alors qu'avec Linux, Unix et NT4 tous les pilotes de périphériques sont liés directement au noyau et fonctionne dans l'espace protégé de celui-ci.

Le problème que tente de résoudre les micro noyaux.

Le principal problème que les micro noyaux essaient de résoudre est celui de la sécurité. En effet plus un système contient de lignes de codes plus il a de chance de contenir des erreurs qui peuvent-être exploités de façon malveillante. Comme le noyau d'un système d'exploitation fonctionne au niveau de privilège le plus élevé du processeur. Les erreurs logicielles qui se trouvent dans son code posent une menace majeure à la sécurité mais aussi à la stabilité du système.

Donc la philosophie du micro noyau est de réduire le code qui tourne au niveau de privilège le plus élevé du processeur pour réduire au minimum le risque d'erreurs logicielles. Mais il y a un inconvénient, celui de la vitesse d'exécution. En effet pour accéder aux périphériques les applications doivent faire un appel au noyau de type syscall pour appeler une fonction matérielle. Un syscall est une exception logicielle ça implique un délais qu'on appelle latence. Prenons un exemple, une application veut écrire un bloc de données dans un fichier sur le disque dur. Dans un système monolithique, l'application fait un syscall en passant l'information requise au noyau. l'interruption qui répond au syscall identifie le type de demande et transmet l'information au pilote du disque dur qui effectue l'opération et le résultat de l'opération est retourné à l'application dans le bloc d'information. Dans un micro noyau le pilote est aussi une application donc pour parler au noyau il doit lui aussi faire un syscall donc chaque transaction entre une application et un périphérique implique 2 systcall. Un pour la requête et un pour la réponse du pilote. On double le nombre de syscall et comme je viens de l'écrire chaque syscall implique un délais de réponse. De plus dans un système d'exploitation chaque application existe dans un espace mémoire virtuel inaccessible aux autres applications. Donc lorsque une application veut envoyer de l'information à un périphérique le noyau fait une copie vers l'espace de l'application vers l'espace du pilote et lorsque le pilote répond le noyau copie la réponse dans l'autre sens. Ça fait beaucopu de données à copier.

Cette façon de faire est très sécuritaire mais très lente. J'ai l'occasion d'expérimenter cette lenteur chaque fois que j'utilise mon PlayBook qui fonctionne avec le système d'exploitation QNX qui est basé sur un micro noyau.

Les recherches se poursuivent pour améliorer la performance des systèmes d'exploitations à micro noyau mais ils ne seront jamais aussi rapides que les systèmes monolithiques. Ils sont utilisés principalement pour leur sécurité mais aussi pour leur modularité qui permet de réduire la taille du système en enlevant simplement les modules qui ne sont pas nécessaires à l'application. C'est sans doute ce qui a incité Intel à utiliser minix 3 pour son Management Engine.

Cette découverte va peut-être intéresser plus de développeurs au projet minix 3 qui pour le moment est plutôt anémique.

mercredi 9 août 2017

détecteur de métal

Dans cet article je décris la construction d'un détecteur de métal construit autour d'un PIC10F322 et d'un oscillateur Colpitts en base commune.

Origine d'un projet

La semaine dernière je sors de la maison pour aller prendre l'allée qui se trouve à l'arrière. J'aperçois mon voisin qui a l'air de chercher quelque chose.
- Salut Jacques!
- Salut Robert! Qu'est-ce que tu cherches?

Il ouvre la main pour me montrer plusieurs vis et clous.
- J'ai fais une crevaison ici hier.
- Ha! Moment d’embarras...

En juin j'ai refais la clôture qui borde cette allée. Hors je n'avais pas ramassé toutes les clous et vis qui y sont tombés. J'aurais du être plus attentif à la récolte des vieux clous et vis. Mais ce n'est pas si facile de les trouver à travers l'herbe et le gravier. Je me suis dis qu'un détecteur de métal serais utile dans cette opération de nettoyage. Plutôt que d'en acheter un j'ai décider de le fabriquer. Projet de fin de semaine.

Schématique

Montage carte

Assemblage final

Mise à l'essaie

Dans ce bref vidéo les objets détectés sont dans l'ordre, une rondelle en acier, 1 pièce de 5 cent en nickel et 1 pièce de 1 cent en cuivre.

Description

Le détecteur de métal est constitué d'un oscillateur Colpitts en montage base commune. Il comprend le transistor Q1 2N3904, l'inductance L1 et les condensateurs C4 à C7. R1,R2 ainsi que C2 ne servent qu'à polariser le transistor dans sa zone de conduction. C6 et R3 sont les éléments qui permettent la rétro-action positive entre le collecteur et l'émetteur. Le circuit accordé est formé de L1, C4,C5 et C7. C4 et C7 en parallèles forment l'équivalent d'un condensateur de 4,4nF. Je n'avais pas de 4,7nF en main mais si vous avez un, remplacez C4 et C7 par un seul condensateur de 4,7nF. Une fraction du signal du circuit accordé est renvoyée à l'émetteur de Q1 à travers le condensateur C6. La fréquence de cet oscillateur mesurée à l'oscilloscope est de 460Khz. Mais la valeur exacte n'est pas importante car c'est la variation de fréquence que le logiciel va mesurer. La sortie de l'oscillateur est envoyée au microcontrôleur PIC10F322 sur la broche 3, T0CKI à travers C8 et R4. La logique de détection est simple, il s'agit simplement de détecter les variations de fréquence de l'oscillateur causées par la présence prêt de la bobine L1 d'un objet métallique. Dans ce but la minuterie TIMER0 est utilisée pour compter les cycles de l'oscillateur pendant un intervalle de 32 millisecondes a répétition en comparant chaque mesure avec la précédente. Si cette valeur varie dans la même direction 2 mesures consécutives on considère qu'il y a présence d'un objet métalique et l'alarme sonore est activée.

Construction de la bobine L1 et assemblage.

Dans une planche de pin de 3/4" d'épaisseur (19mm) j'ai découpé un disque de 6" (15cm) de diamètre. Avec une lime queue de rat j'ai creusé une cannelure sur toute la circonférence du disque afin d’accueillir le bobinage. Le bobinage est comprend 17 tours de fil émaillé numéro 22 AWG (0,6mm). Mesuré avec un appareil LCR j'obtiens une valeur de 115µH pour cette bobine tel qu'indiqué sur la schématique.

Pour le manche j'ai utilisé une tige de peuplier à section carrée de 1/2" (12,5mm) qui est maintenue au disque avec une vis et de la colle.

Un petit boîtier en contre-plaqué 1/8" (3mm) a été fabriqué et fixé au manche pour contenir le circuit électronique.

Le montage électronique lui-même est fait sur une plaquette de bakélite de 7cm x 9cm à pastille de cuivre sur une seule face.

Description logicielle

Donc le signal de l'oscillateur est capturé à l'entrée T0CKI (broche 3) et les cycles sont comptés par le TIMER0 sur un intervalle de 32 msec. La minuterie TIMER2 est utilisée comme compteur de période pour la génération de la tonalité d'alerte de 500 hertz générée par le périphérique PWM1. La routine débutant à init: initialise les périphériques et active l'interruption sur le TIMER2. Cette minuterie possède un diviseur en sortie qui permet de déclencher l'interruption après un certain nombre de cycles. Le post-diviseur est configuré pour une interruption à tous les 16 cycles de TIMER2. Une fois l’initialisation complétée le logiciel tombe dans une boucle infinie goto $ car la détection se fait à l'intérieur de la routine d'interruption qui débute à ìsr:. À chaque interruption on fait une lecture de TMR0 qui représente le nombre de cycles de l'oscillateur comptés sur une durée de 32 msec. En fait il s'agit du nombre de cycles modulo 256 car on n'a pas besoin du compte complet puisque les variations d'une interruption à l'autre sont nettement inférieures à 256. Pour chaque interruption on conserve cette valeur dans la variable last. La variable run est une variable temporaire qui représente la dernière lecture de TMR0 faite au début de la routine d'interruption. On compare donc cette dernière valeur avec la valeur de last et on incrémente ou décrémente la variable slope en fonction de la différence entre les 2 valeurs. Si run est plus grand que last on incrémente slope car ça signifie que la fréquence de l'oscillateur a augmentée. Au contraire si run est plus petit que last ça signifie que la fréquence à diminuée et donc slope est décrémentée. Si run et last ont la même valeur slope est ramenée à zéro et la tonalité d'alarme est désactivée. Pour que la tonalité d'alarme soit réactivée il faut que la valeur absolue de slope soit égale ou supérieur à la constante TR_LVL. Ce code très simple qui n'occupe que 66 instructions donne de bons résultats.

J'ai testé différentes valeurs pour la durée d'échantillonnage et pour la constante TR_LVL c'est avec ces valeurs que j'obtiens le meilleur résultat.

Technique de balyage

La technique de balayage consiste à tenir le disque de la sonde 1 ou 2 cm au dessus du sol dans le plan horizontal et balayer de gauche à droite ni trop vite ni trop lentement. Avec un peu de pratique on trouve rapidement la bonne vitesse de balayage.

Lorsqu'un objet est détecté il ne faut pas arrêter le balayage de la sonde au dessus de l'objet mais plutôt faire des aller-retour. Un arrêt du balayage permet à l'oscillateur de se stabiliser sur une nouvelle fréquence et donc rend le détecteur silencieux.

Notez que la détection se produit lorsque l'objet est au plus proche du rebord du disque et non en son centre.

Conclusion

De réalisation économique et rapide il ne faut cependant pas s'attendre à ce qu'il est la sensibilité d'un bon détecteur vendu dans le commerce.


  1. sources du projet sur github

lundi 10 juillet 2017

ForthEx (partie 3)

Depuis le dernier article sur le projet ForthEx, je n'ai cesser d'y travailler et je peux dire qu'à ce point ci le projet est pas mal abouti. ForthEx peut maintenant être contrôlé en remote via le port RS-232 et un émulateur VT102 sur le PC. J'ai créé un éditeur de texte simple et un système de blocs pour la sauvegarde sur EEPROM externe ou carte SD. De plus la documentation html est complète avec description de chacun des 445 mots qui sont dans le dictionnaire en mémoire FLASH du MCU, sans oublier un tutoriel. Le tutoriel consiste en la description du code source d'un jeu classique appellé snake. Voici donc un démo du jeu en action.

Conclusion

Le temps passé sur ce projet m'a permis de mieux connaître le langage Forth au point ou maintenant je peux lire un programme Forth aussi facilement que s'il était écris en C et je n'ai pas eu plus de difficulté à écrire le jeu snake en Forth que j'en aurais eu en C.

Comme n'importe quoi d'autre il suffit d'y mettre le temps et les efforts pour maîtriser ce langage. Ceux qui prétendent que ce langage est plus difficile à comprendre ou lire qu'un autre ne se sont tout simplement donner la peine de l'étudier sérieusement.