Salut la communauté,
Je reviens d'une semaine de vacances où je n'avais rien à faire de mes soirées une fois ma fille couchée. J'ai donc ressorti mon vieux projet (et oui, toujours d'actualité).
Après quelques changements de véhicule, il était temps de s'y remettre et de revoir certaines choses.
Comme je l'avais précisé, la nouvelle receveuse du gadget me simplifie grandement la tâche grâce à son calculateur d'injection qui me fournit en temps réel une trame de 37 octets sur l'état du moteur (température, rotation, capteurs, durée d'injection, avance allumage, défauts...). Il ne me reste donc plus grand chose à traiter : gestion de l'accélérateur (je remplace le câble par un potar et un servomoteur), vitesse en km/h, conso, quelques capteurs. Je me suis donc rabattu sur un MEGA2560.
Presque toutes les mesures seront traitées par interruptions, ce qui veut dire que loop() sera vide (enfin presque). Voici la liste des INTs que j'ai déjà prévues :
ISR (PCINT0_vect) : gestion d'un clavier matriciel 4x5, les touches sont bufferisées dans un FIFO.
ISR (USART3_RX_vect) : réception de la trame de données série du calculateur d'injection, les données remplissent un tableau de 37 bytes.
ISR (TIMER4_OVF_vect) et ISR (TIMER4_ICP_vect) : calcul de la vitesse en km/h et incrément des compteurs kilométriques
ISR (TIMER5_ICP_vect) : calcul de la consommation (xx,x l/100)
ISR (ADC_vect) : numérisation automatique de 8 entrées analogiques renseignant un tableau de 8 word
ISR (WDT_vect) : timer de déclenchement à intervalles réguliers (256ms) pour le régulateur de vitesse
Bref, l'idée est que toutes les variables de données se mettent à jour automatiquement, il suffit alors de les lire quand on en a besoin, c'est tout... De même, j'aurai 3 sorties servomoteur gérées directement par les sorties hard PWM du timer1, genre un simple OCR1A = valeur; suffit à changer la position du servomoteur. Pour les deux écrans du TDB, j'utilise USART 1 et 2 pour leur envoyer les données à afficher.
Tout ça est bien gentil, mais j'ai eu la chance d'ouvrir le wiring.c et d'y découvrir toute une initialisation barbare des timers, ainsi que de l'ADC. j'ai donc viré tout ça, histoire que le core arduino ne me configure pas les ressources de traviol pour rien (de même pour les fonctions delay(), micros()..., je les ai virées). Je configure le tout directement par les registres, en lisant le datasheet de l'AVR. J'ai aussi viré la gestion de l'USART3 pour pouvoir récupérer l'INT correspondante. J'ai aussi vu quelque part (dans le main.c je crois) qu'entre deux exécutions de loop(), il y avait un "doSerialEvents();", ce qui ne me plait pas trop, il faut que je vois ce que c'est et le virer également au besoin.
Ne serait-ce que pour la conversion analogique numérique, analogRead() prend un temps fou, car elle lance une numérisation et attend les 104µs de la conversion pour obtenir le résultat. Il faut savoir que 104µs représentent 1664 instructions (oh le beau nombre!), et que tout ça, c'est perdu dans un while(...){rien;}. sur 8 conversions à la suite, ça nous fait à peu près 13 500 instructions de perdues. Il faut quand même savoir que le CAN est indépendant, et qu'il fait les conversions tout seul dans son coin sans utiliser le CPU. J'utilise donc l'INT du CAN, déclenchée une fois la conversion terminée, et qui relance elle-même une nouvelle conversion puis rend la main au programme. Ca prend à peine 30 instructions contre les 1700 du core arduino. On apprend beaucoup en déchiffrant les datasheets...
Je pense gérer moi-même la gestion des ports série par la suite, car décidément, l'équipe arduino ne s'est pas trop occupée des temps de traitement...
Restera à voir si les interruptions ne se bouffent pas trop les unes-les-autres, que ça me laisse un peu de temps processeur pour le traitement...
A suivre!