Interruptions : 4ème dimension - Page 1

Je suis retombé sur un comportement bizarre, que je crois avoir déjà rencrontré il y a quelques années lorsque je travaillé sur du rescaling pour la version TI-89 de Sim.

Lorsqu'un handler d'auto-int 5 est "trop long" (peut-être lorsque qu'il met plus de temps à s'exécuter que l'inverse de la fréquence de l'AI5), la calc semble geler complètement, au milieu du code de cet handler. Bizarrement, lorsque l'auto-int 3 se déclenche pendant ce gèle (je fais les tests sur une Titanium, il suffit de provoquer une activité USB), tout continue normalement, et l'handler de l'auto-int5 reprend son execution.
Forcer SR à $2700 pour éviter de la réentrance dans l'handler (même si c'est inutile, le masque par défaut fixé par le 68k fait déjà ça) ne change rien. Et comment se fait-il que l'auto-int 3 débloque quelque chose, alors qu'il est lui aussi théoriquement masqué...

Ca m'embête bien tout ça. Des suggestions ou des idées de tests à faire on-calc pour tenter de comprendre ?

Marrant en effet.
Je suppose que ça a déjà été testé, mais est-ce qu'on est sûr que le masque du SR permet vraiment d'inhiber certaines interruptions lorsqu'on se trouve dans un état normal (c'est-à-dire non gelé comme dans ton expérience) ?
Je ne connais pas précisément le fonctionnement matériel du 68000, donc je ne sais pas s'il est possible de se débrouiller pour que matériellement cette histoire de masque/priorité saute.

Le 68k User's Manual indique simplement que "the processor priority level is set to the level of the interrupt being acknowledged" lorsqu'une interruption se déclenche. Je suppose que le système de masque continue de fonctionner comme normalement (mais je n'ai pas testé).
Et je viens de vérifier que l'auto-int 3 est bien une interruption masquable comme les autres en temps normal sur Titanium.

L'int 6 ne permet pas de debloquer ?

Non, il a pas l'air de changer quelque chose.

D'un autre cote, il fut un temps ou l'int 3 et l'int 5 partageaient du materiel en commun (Int 3 etait un timer).
Peut etre est-ce un reliquat ?

Juste pour me rappeler, c'est pas l'AI3 qui est chargée de se déclencher chaque seconde sur TI89 ? Comment fonctionne l'horloge sur TITI ?

Sur HW2, AMS > 2.06 fonctionne comme ça.

L'horloge et le système de transfert USB partage la même AI ?

Je ne sais pas comment ça fonctionne sur HW3, ni où trouver de la doc dessus, mais il semble que l'USB utilise l'AI3.

Sur titanium, l'horloge ne fonctionne plus avec l'ai3, mais avec un rtc hardware.

OK !

PpHd :
D'un autre cote, il fut un temps ou l'int 3 et l'int 5 partageaient du materiel en commun (Int 3 etait un timer).
Peut etre est-ce un reliquat ?

Peut-être bien. Je fais faire un petit test à faire tourner sur HW2, puisque si c'est ça, ça devrait se comporter de la même manière.

heu ça a un rapport avec le bug dont tu parles sur ton blog, ça?

Oui

explique moi, ça m'intéresse
j'envisage d'acheter une titanium pour devel dans cette direction, j'ai déja fait le cable mini-a/usb femelle

squalyl^2 :
j'ai déja fait le cable mini-a/usb femelle

Fait, en soudant bout à bout ? Dan Englender m'avait déconseillé de tenter ça, "because of the shielding that's needed at high frequencies" comme il dit.

oui, mais attention j'ai pas fait ça comme un porc

chaque petit conducteur est soudé (pas seulement torsadé ^^) et entouré d'une petite gaine thermo,
le fil de masse non isolé est soudé sans gaine thermo, il est donc en contact avec un petit morceau de papier alu normal rajouté, entouré autour des 4 petits fils internes isolés. puis après je mets le tout dans une gaine thermo plus grosse pour la tenue mécanique. le blindage n'est pas interrompu dans mon cas, j'y ai pensé

Ok, bah tant mieux si marche, parce que c'est pas facile de mettre la main sur ces trucs

hmmm je viens de penser à un truc

68k User's Manual
indique simplement que: the processor priority level is set to the level of the interrupt being acknowledged

je parie que les auto int de plus petit numéro sont plus prioritaires que celles qui ont un numéro plus grand.
du coup quand tu es dans l'auto int 5 le niveau d'interruption du 68000 est réglé à AUTO_INT_5_HANDLER = 0x74 et seules les interruptions de numéro plus faible (comme l'auto int 3, numéro 0x6C) peuvent interrumpre le traitement de l'irq courante, ce qui empêche l'auto int 6 (=0x78) de s'exécuter.

me prends pas pour un *bip* je découvre rien!

relis 3-4 je crois que c'était pas 100% clair pour eux.

je croyais que c'etait l'inverse, que les AUTO_INT plus grand avaient plus de priorité que les plus faibles

ben faut croire que non

quand je vois que INT_VEC_RESET = 0x04, INT_VEC_BUS_ERROR = 0x08, INT_VEC_ADDRESS_ERROR = 0x0C, INT_VEC_ILLEGAL_INSTRUCTION = 0x10, INT_VEC_ZERO_DIVIDE = 0x14 (tigcc: intr.h) je pencherais à croire que c'est l'inverse, sinon on pourrait pas resetter la calc souvent

on aurait dit que tu me faisais le papa qui voit que "gamin découvre"

désolé je reste calme...

#sang espagnol#

et pourtant depuis un an je vis avec une #sang coreen# ce qui fait que je m'oblige a pratiquer le #cépagraaaaave... caaaaalme# mais je suis pas a l'abri d'un départ au quart de tout parfois

squalyl^2 :
je parie que les auto int de plus petit numéro sont plus prioritaires que celles qui ont un numéro plus grand.

Non, c'est l'inverse
En fait tu mélanges exception, interruption, niveau d'interruption, priorité (ie niveau d'exception) et masque d'interruption, qui sont plein de trucs différents.
Concernant le problème du reset : "The reset exception corresponds to the highest exception level" d'après le MC6800 User's Manual. Et l'offset dans la table des vecteurs n'a rien à avoir avec la priorité.

ben je pensais que les vecteurs étaient stockés dans l'ordre des numéros toussa #shy# #petipetit# #desolé martial#