Le 68000 représentait un changement majeur dans la gamme de processeur motorola. En effet un processeur 16 bits à 8 mhz, c'était largement plus rapide que le 6800, un processeur 8 bits, principal processeur de la marque. En effet il existait uniquement des versions à 1, 1.5 et 2 mhz. Il était doté d'une gamme de contrôleurs de périphériques variés comme le PIA 6821 (2 ports parallèles 8 bits) ou le ACIA 6850 (un port série). Les fréquences d'horloges maximums pour ces contrôleurs étaient alignés sur celles du 6800.
Les concepteurs du 68000 ont doté de la possibilité de se "ralentir" en générant un signal d'horloge qui dure 10 cycles d'horloge. L'objectif était de pouvoir utiliser les contrôleurs du 6800, soit pour une raison de coût, soit pour bénéficier dès la sortie du processeur de toute une gamme de contrôleurs.
De nombreux micro-ordinateurs grand public ont bénéficiés de cette caractéristique, comme le mac d'apple qui contenait un VIA 6522 ou l'atari ST qui avaient deux ACIA 6850.
mercredi 21 mai 2008
Le 68000 et les périphériques 6800.
De delphi à linux, programmation des timers
Le composant TTimer sous delphi est un composant capable de faire un appel régulier et répétitif à une procédure utilisateur.
Le délai entre les appels est réglable. Le principe de fonctionnement est simple : il s'agit de créer une fenêtre non visible, associée à une procédure de fenêtre (wndproc) capable de gérer le message WM_TIMER. En initialise les appels ensuite avec une api praticulière de windows. Le noyau Windows va,à partir de là, envoyer régulièrement un message WM_TIMER à cette fenêtre.
Ceci étant vu, je vais vous proposer maintenant de reproduire ce type de comportement sur linux.
Ce système peut quand à lui répondre à des signaux extérieur à l'application. Ces signaux peuvent être détournés par le programme vers une fonction de gestion. Si le programme ne le fait pas, le noyau tue l'application. C'est ainsi que fonctionne CTRL+C qui envoie à l'application courante un SIGINT, le signal d'arrêt du programme. Si le programme n'a pas de gestion particulière de ce signal, le noyau va effectivement stopper le programme. Si le programme gère ce signal, le programmeur devra prévoir une stratégie de sortie.
Revenons au timer. Il existe un signal SIGALRM qui est envoyé régulièrement par le noyau à une application. Ce signal sera envoyé sur demande de l'application. Bien entendu, comme tout signal, s'il n'est pas géré par l'application, il provoquera l'arrêt du programme. Si on le détourne vers une fonction, cette fonction sera appelée régulièrement.
Voici un exemple de source C sur l'utilisation des alarmes sous linux:
/*
=============================================================================
Name : timer.c
Author : OT
Description : Comment coder l'équivalent du TTimer de delphi en c sous linux ?
=============================================================================
*/
#include stdio.h>
#include stdlib.h>
#include signal.h>
#include sys/types.h>
#include unistd.h>
#include errno.h>
#include sys/wait.h>
void evenementTimer() {
printf("Top timer\n");
alarm(1);
}
int main(void) {
signal(SIGALRM, evenementTimer);
alarm(1);
// c'est mal de faire une attente active....
for (;;) {
}
}
Le bus I2C et la télévision
Dans un précédent article j'avais fait une brève présentation du bus I2C. Je vais vous présenter
maintenant quelques composants I2C utilisés en télévision. Il s'agit juste d'une liste très courte, le nombre de composants I2C est en effet très important.
Cela veut dire que toutes ces fonctions sont contrôlables par un microprocesseur ou par un pc.
STV942x : contrôleur OSD (incrustation vidéo)
TDA933x : processeur vidéo (contrôle de luminance et chrominance, balayage vertical 50,60,100 et 120 hertz, balayage horizontal)
SAA5243/45 : décodeur télétexte
SAA9055P : décodeur numérique SECAM
SAA9062/63/64 : contrôleur de déviation
SAB3035/36/37 : syntonisateur
SAA9068 : contrôle du PIP (picture in picture)
TDA8405 : contrôleur son stéréo
TDA8440 : commutateur audio / video
TDA8461 : Décodeur PAL/NTSC
