h3bus a écrit :
Je suppose que tu fait u contrôleur PS2 en bitbang.
Dans ce cas tu va envoyer ta donnée bit par bit. à Chaque bit envoyé tu fait ton XOR, tu te retrouve à la fin avec ta parité.
|
Ouaip je bosse en bitbang (connaissais pas le terme avant merci wiki),
OK je pense que ta méthode est pas mal, j'y avais pas pensé vu que je preparais mes paquets bien avant de les envoyer. J'essaie dès que je peux...
h3bus a écrit :
Cela dit, vu la vitesse du PS2, ta méthode fera pas ramer ton µC à 12 MHz...
|
Mon problème enfait, c'était juste d'être sur d'avoir le temps de faire tout mes calculs entre 2 fronts d'horloge (au moment ou je suis censé envoyer mes données) mais je pense que de côté là, je suis large, nan?
Citation :
The clock frequency must be in the range 10 - 16.7 kHz. This means clock must be high for 30 - 50 microseconds and low for 30 - 50 microseconds.. If you're designing a keyboard, mouse, or host emulator, you should modify/sample the Data line in the middle of each cell. I.e. 15 - 25 microseconds after the appropriate clock transition
|
SquiZZ a écrit :
Avoir un BYTE qui s'apelle word, ça me fait mal à la tête
Sinon, si t'as de la place en rom, tu peux précalculer la table sur PC et ensuite le 'calcul' se résume à un accès mémoire. Un peu overkill pour une parité, mais souvent utilisé pour les crc ou les fonctions trigo.
|
Ouais, peu après avoir posté, je suis tombé sur cette page http://graphics.stanford.edu/~seander/bithacks.html qui en donnait un exemple (Compute parity by lookup table), mais ca me paraissait un peu lourd pour calculer la parité d'un un mot de 8bits.
Message édité par utb diablo le 24-11-2010 à 10:55:43
---------------
Au royaume des aveugles, les borgnes sont rois xo0