Re: [openplacos-dev] link des interrupts

[flagos <flagospub@xxxxxxxxx>]

Le 31 juillet 2011 12:59, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a écrit :
> 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".

Je pense pas que ce soit vraiment le cas d'utilisation classique. Pour
ca, le composant qui gere le mail va directement taper sur la
libclient, comme rails quoi. Faire remonter une interruption a un
autre composant qui va declencher l'effecteur, c'est un peu
capilotracté.

Non je pense sincerement que ca sera utilisé comme une vraie
interruption, du genre une porte qui s'ouvre. Bref, la ou le pulling
va montrer ses limites. Pour les cartes, oui il va y avoir un vrai
travail a faire, mais bon c'est qd meme une feature interessante.

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

Oui ca me parait moins pertinent.


> 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.

Et comment tu fais pour passer de "tu me fais un interrupt lorsque tu
depasse 25 degres" a "tu me fais une interrupt lorsque tu depasse 3,7
Volts" ? Seul le composant de temperature peut faire la conversion.

> 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.

Je pense que ce soit si compliqué.

> 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.

Oh non, pas du pulling ! On est en 2011 quand meme !

>
> 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
>>
>>
>
>



-- 
Tapé depuis mon clavier