Re: [openplacos-dev] link des interrupts

[miaouf kirsh <miaoufkirsh@xxxxxxxxx>]

Je dirais meme plus, la pluspart du temps les board ne les implementeront pas.

Une arduino a 4 pin d'interupt il me semble, la pluspart des cartes n'en on pas ou alors elle ne seront pas implementé (c'est pas evident a faire).

apres ca sera surement utilisé dans des drivers style "je recois un mais sur gmail et je veut qu'une lampe s'alume".

idem coté client, ca sera rarement utilisé, je vois mal comment faire remonter de l'info a un client web par exemple.

En fait, ce qui est surtout genant, c'est le set/unset. je m'etait posé la question quand je pensais a une interupt signal only. A priori c'est pas genant  de pas l'avoir implementé, le signal ne sera juste jamais trigé, par contre pour les methodes call, ca va pas marcher si la pin ne les implementent pas.

Changer de pin ou d'iface ne changerais pas grand chose finalement, car le composant ne sait pas si une pin est reelement pluggé quelque part. A un moment si il déclare utiliser l'interupt sur ses pin de sorties, c'est qu'il va vouloir l'utiliser donc il faut que ca soit branché quelque part.

Donc les composants qui déclarent avoir besoin d'une fonction d'interupt programmable (Signal + Set/Unset) devront forcement se brancher sur quelque chose qui a une fonction d'interupt. 

A ce moment la le type qui n'a pas de fonction d'interrupt sur le driver devra passer a travers un composant qui emule une interupt.

A mon avis, la pluspart des composant n'implementerons pas d'interupt, car il n'on pas vocation a le faire il me semble.

Si tu prend un sensors, je trouve que c'est pas son role de proposer une intérupt, si le type veut que quelque chose réagisse quand tu passe au dessus de 25°C, ben il utilise un composant fait pour qui se plug sur le sensor. enfin c'est mon point de vu.

Apres pour la solution 2, ca m'embale pas vraiment. J'imagine qu'il y aura des cas ou ca pourrai poser des problèmes (pas d'exemple en tete), et puis ca va forcer le codeur de composant a faire du travail en plus qui n'est pas vraiment nécessaire. 

Inclure ca dans la libcomponent ca me parais deja pas mal compliqué. Une interrupt se programme, et la maniere dont elle se programme depend a priori du type d'iface en question, donc la libcomponent devra interpreter la programmation et la valeur de retour du read pour savoir comment et quand lever l'interupt. Donc cette fonction de fake interupt au niveau de la libcomponent ne sera compatible qu'avec certaines ifaces, ca devient franchement pas evident.

Franchement, moi je dirais que si un composant a besoin d'une interupt, ben c'est a l'utilisateur de brancher ca sur un truc qui fait de l'interrupt, quit a passer par un composant en plus qui emule de l'interrupt, mais au moins c'est l'utilisateur qui maitrise sa chaine.

enfin voila mon avis.

Le 31 juillet 2011 08:34, flagos <flagospub@xxxxxxxxx> a écrit :

Yop,

Je reviens avec mes interrupts, je viens de réaliser un truc: les
interrupts sont tout de meme pas le truc dont on va avoir besoin tout
le temps. Il va arriver que des boards ne les implementent pas. La,
comme on a fait le linking, il si une board ne supporte pas les
interrupts, on ne pourra pas plugguer les composants qui le supportent
! Ou alors il faut changer le truc: deplacer les interrupts dans une
autre iface et faire un link au niveau iface dans la config ? Un peu
penible quand meme de declarer les interfaces dans la config ...

Je vois que 2 solutions pratiques:
1. Declarer des interrupts dans une autre pinoche. Ca fait un peu
double boulot dans la config mais ca pourrait marcher. C'est tjs
pareil, c'est penible au niveau config cette affaire
2. Imposer aux gens de supporter les interrupts. La au moins on ne
s'emmerderait plus sur ces considerations sur la config.

La 2 peut paraitre drastique mais je me dit que si la libComponent
amene de base une émulation d'interrupt a base de pulling sur le read,
au final on peut aussi bien s'en sortir.

T'en penses quoi ?

--
Tapé depuis mon clavier