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