Indicateur de puissance embarqué

[foisse]

Tu n'as pas tout à fait tort (sauf que les rev.3 sont en 16 bit), juste que l'asm (pour en avoir fait) c'est pas accessible à tout le monde et le but des arduino c'est justement ça, puis pour les pros on peut toujours programmer des pic ou s'attaquer aux core libs vu que c'est open source (c'est d'ailleurs comme ça que c'est debuggué).
Il y a aussi des émulateurs et des debugguers que tu peux installer ou alors en programmant directement l'avr avec atmel studio.

Sinon, ça me paraissait un peu bizarre de pas pouvoir faire de prog. concurrentielle sur arduino alors j'ai trouvé ça: http://concurrency.cc/ qui permet en plus de programmer en occam-pi.

L'autre solution que j'envisage c'est d'utiliser des cartes un peu plus performantes du genre beagle board ou encore mieux mais plus cher le gumstix

[Spocky35]

Vous parlez en chinois directement traduit de l’hébreu
Il se peut - c'est probable - que ce que vous évoquez présente des avantages, mais, pour retrouver le fil initial de la discussion, je persiste à penser que la difficulté viendra bien davantage des dispositifs qu'on souhaite raccorder à cette carte, quelle qu'elle soit, que des perfs de la carte elle même et du langage de programmation qu'elle utilisera.
J'ai été lire (en diagonale) ce forum qui évoque la nébulisation et qui s'attarde sur le diamètre des gouttes... Je vois bien l'idée, mais il y a pas mal d'étapes avant de pouvoir envoyer ces gouttes dans le cylindre... Et je ne suis pas sur que l'écueil principal sera la programmation, car ça n'ira pas chercher dans des choses bien compliquées (même moi je dis ça !! )

[foisse]

Vous parlez en chinois directement traduit de l’hébreu
Il se peut - c'est probable - que ce que vous évoquez présente des avantages, mais, pour retrouver le fil initial de la discussion, je persiste à penser que la difficulté viendra bien davantage des dispositifs qu'on souhaite raccorder à cette carte, quelle qu'elle soit, que des perfs de la carte elle même et du langage de programmation qu'elle utilisera.
J'ai été lire (en diagonale) ce forum qui évoque la nébulisation et qui s'attarde sur le diamètre des gouttes... Je vois bien l'idée, mais il y a pas mal d'étapes avant de pouvoir envoyer ces gouttes dans le cylindre... Et je ne suis pas sur que l'écueil principal sera la programmation, car ça n'ira pas chercher dans des choses bien compliquées (même moi je dis ça !! )

Tu as raison, l'usage de la programmation concurrentielle règle seulement un problème: pouvoir exécuter plusieurs taches en même temps.
Il me semble que dans ce cas, créer un autre système d'admission est plus simple que d'adapter celui d'origine (et les avantages sont énormes: par ex.stopper le moteur si plus d'huile, différents profils de réglages: éco, sport... réglages en fonction du temps: humidité, chaleur...).
Ça signifie par ex. qu'il va falloir injecter l'huile, l'essence et l'air "au même moment" ou à des moments précis et en ça la prog. concurrente est nécessaire.

[Spocky35]

Bha il me semblait avoir compris qu'en terme d'échelle de temps (microsecondes pour la carte, centaines de millisecondes pour le moteur) on n'était pas vraiment gèné, et si deux commande se succèdent à ... 50 µs d'interval par exemple, on reste dans le même "temps moteur". Mais bref, l'essentiel c'est que toi tu sois à l'aise avec cet aspect là des choses, je serai pour ma part bien plus "accroché" par le coté "périphériques"

[foisse]

C'est vrai c'est peut-être un peu "too much". J'ai pas encore suffisamment réfléchit à toutes les opérations qu'il va falloir faire pour gérer toute la partie admission via électronique mais certaines opérations me semblait être plus longues que ça (notamment la com. avec affichage...). à voir.

[diabolo38]

la contrainte RT pour gerer l'avance c'est chaud car le retard entre la prise en charge du capteur d'allumage et la programmation du delay pour driver le DI doit etre trés court qq micro-sec au plus (precision mieux que le degré a 200Hz=12000rpm) ...
Ce n'est meme pas forcement de la prog concurrentiel et c'est encore plus simple a faire direct en interruption (sans decendre a asm) il faut "juste" assigné les bonne priorité d’interruption et bien pensé son archi soft/hard/perif micro pour avoir la bonne configuration si on mange déja un bonne partie de la contrainte RT pour juste gere un it timer qui sert presque a rien (le temps en ms)
bon celui qui veut sortir l’artillerie lourde peu y aller avec son RT-OS et un mirco qui pédallea 100x plus rapide que nécessaire mais c'est vraiment sur dimensionné .
bon chacun voit midi a sa porte et trouves des solution souvant proche de ce qu'il connais ou peu aprendre au quotidien ... j'ai perso pas besoin de plus de 8bit et qq Mhz des KB des liben pagaille pour faire tout ce qui a été fait jusqu'a la ...

[foisse]

J'ai besoin d'apprendre beaucoup de chose avant d'en arriver là mais je sens qu'il y en a ici qui pourront me préter leurs neuronnes

Question: est-il possible (et comment) de connecter l'arduino sur le cdi ignitech ?
est-ce que dans ce cas là ça ne simplifierai pas le travail de gestion d'allumage/avance ? (que pourra t'on gérer avec l'arduino sur l'ignitech ou avec l'ignitech sur l'arduino ?)

[diabolo38]

l'ignitech peu te fournir un signal di "tacho" qui est une division du nombre de tour/moteur
si je dis pas de betise il a aussi un entrée qui permet de basculé d'une set de courbe (alummage valve) a un autre donc de mettre en place un mode "run/safe" ou "sport/eco"
il y aussi une entée dite "TPS " trhotle position sensor qui peu servir a driver les courbes alumae suivant deux axe



je crois qu'il y aussi moyen de positioné des sortie dite "aux" suivant les regime moteur et ou tps

mais toute la gestion de/des courbe valve et alumage est interne et ne peu etre modifié a la volé cela doit passé par une reprogrammation des tables

[foisse]

Merci.
ça doit suffire si on peut piloter les courbe d'allumage via le TPS (merci à philartis pour ce boulot de débourage sur le TPS).