Go Down

Topic: Interface à base de pic pour gestion d'impulsions (Read 6 times) previous topic - next topic

Super_Cinci

A partir de mes deux signaux, dans le MEGA2560 :

- le carré représentant 352 dent / tour moteur incrémentera le timer5 (via T5 par exemple).
- le second (impulsion PMH) viendra déclencher l'ICP5.

Dans le MEGA, un timer déclenche une interruption toutes les 256ms, dans laquelle je relève TCNT5 puis fais TCNT5 = 0, et je multiplie ma valeur par 1.5 pour trouver la vitesse du moteur en tr/min.

Lors de l'iCP5, je relève ICR5 tout en laissant tourner le compteur bien sûr, puis à l'aide une seconde interruption déclenchée par l'étincelle de l'allumage, je calcule l'avance à l'allumage. (c'est surtout là que la multiplication d'impulsions aide dans la précision...)

C'est tout... Tu vas me dire que le 328P peut certainement s'occuper de tout ça de envoyer les valeur au MEGA via USART, mais non, je veux des signaux bien précis, c'est comme ça...

Les pins mentionnées ici ne sont données qu'à titre indicatif, car le MEGA va mesurer tout un tas d'autres données, et au final, les faire afficher sur deux écrans graphiques LCD de 160 x 128 qui remplaceront le tableau de bord actuel. Les autres mesures sont beaucoup plus simples, ça se fera tout seul.

De plus, le MEGA aura la lourde (mais essentielle) tâche de remplacer le câble d'accélérateur : un portar sur la pédale et un servo sur le carbu, plus de câble. Il y aura un mode "régulateur de vitesse" et un autre "limiteur de vitesse". Et certainement la gestion du starter avec un autre servomoteur, puis il me restera une troisième voie pour un troisième servo, mais pour quoi faire? je ne sais pas encore...

mon coéf de 1.5 risque de tomber à 1 si je fais une fenêtre de 170.45ms au lieu de 256ms, mais ma "fenêtre" doit être assez large pour y éxécuter les différentes fonctions, donc notamment le régulateur qui a besoin d'intervalles de calcul réguliers pour être précis.

A partir de ces deux signaux, dans un autre projet, je compte refaire un AEI (calculateur d'allumage) que l'on peut reprogrammer à souhaits. Mais je pense passer à une multiplication plus élevée, et peut-être passer sur une plateforme 32bits/168MHz comme le STM32F4 par exemple.

Mais tout ça, c'est un autre projet. Ce qui compte ici, c'est de faire de l'extraction de synchro et multiplication, rien d'autre (un peu comme les circuits vidéo)...

skywodd


La comme ça, je ne vois pas du tout. Qu'est le "générateur de signaux A"? Il me parrait difficile d'utiliser le timer 2 en sortie

Pour mieux comprendre -> datasheet page 146, figure 18-1.

Tu peut voir que OCRnA (le registre qui est comparé avec TCNTn et qui peut générer une INT sur overflow et/ou "match compare") et associé à un module "Waveform Generation" OCnA.

Comme tu as OCRnA et OCRnB tu peut utiliser OCRnA en INT "match compare" pour générer le signal n°2 (avec le morceau de code qui va bien) et OCRnB en "waveform génération" (mode FastPWM avec TOP = OCRnB) pour générer le signal n°1.

En gros le canal A génère une INT (sans signal PWM) sur lors du "match compare" OCRnA/TCNTn et le canal B génère un signal PWM (sans INT) lors du "match compare" OCRnB/TCNTn .

Tant que tu peut caser tes deux valeurs de "match compare" dans OCRnA et OCRnB avec un même prescaler pour les deux tout va bien.
Des news, des tuto et plein de bonne chose sur http://skyduino.wordpress.com !

Super_Cinci


Pour mieux comprendre -> datasheet page 146, figure 18-1.
heu... pas trouvé, page 146 : on est dans le 17.1...

Ce que je ne vois pas, c'est comment un timer peut générer un un signal carré B et une impulsion A toutes les 352 impulsions de B... Sachant que l'on décide de générer l'impulsion A en fonction du signal de référence externe...

UniseV

@Super_Cinci :
Je comprends que tu ne veuilles pas utiliser de liaison Asynchrone type USART puisque tout ton système est synchrone, tu veux du temps réel côté MEGA pour la partie calcul du retard à l'allumage. (donc dent PMH ?)

En revanche pour la partie trs/min, pour une mesure précies, il suffit de prendre un tour complet (entre 2 passsages de la dent PMH) et on obtient un calcul précis... (même haut dans les tours avec un prescaler à clk/8 on garde une précision de moins d'un tour par minutes).

Ne peut-on pas imaginer de séparer ces 2 fonctions ?
EN: Libraries are my Gurus, they make me believe anything they want !
FR: Les librairies sont mes gourous, elles me font croire ce qu'elles veulent !

Super_Cinci

#34
Aug 13, 2012, 11:07 pm Last Edit: Aug 13, 2012, 11:13 pm by Super_Cinci Reason: 1

Ne peut-on pas imaginer de séparer ces 2 fonctions ?
non.

ça fait un an que je traine sur ce projet en arduino à cause de cette interface, 7 ans qu'il est dans un coin de ma tête. maintenant que tu m'as soufflé le bonne idée (et merci!) du 368P en stand-alone, il ne me reste plus qu'à le valider et passer à la prog des LCD (qui sont équipés chacun d'un 168 que je reprogramme différemment avec bootloader arduino pour faire de l'"accélération matérielle" grave) et du méga "centraliseur". En gros, ça va me faire tourner 4 µP arduino, ça me fait déjà pas mal de prog à prévoir... L'ensemble du projet prochainement dans un topic dédié.

Go Up