Driver de puissance maison pour moteur pas à pas.

[guol64]

Bonjour à tous,

Horsot quelle est la connectique que tu as prévu pour la liaison au PC?

Les ports série étants en voie de disparition, peut-être faut-il prévoir un port USB , même si tous les softs ne la gère pas encore?

 

[horsot]

Bonjour à tous,

Horsot quelle est la connectique que tu as prévu pour la liaison au PC?

Les ports série étants en voie de disparition, peut-être faut-il prévoir un port USB , même si tous les softs ne la gère pas encore?

Malheureusement, La carte d'interface entre mon PC et les cartes de commandes des moteurs aura qu'une interface parallèle sans "intelligence". Elle sera quasi identique à celle de picstep V4.

Même si cet interface est vieillissante, elle a encore quelques avantages techniques que ni l'USB ni le série a.

Plusieurs raisons à mon choix :
- Très simple à utiliser et à debugger.
- Je souhaite utiliser EMC2 (sous linux) qui n'autorise que le port parallèle et des quelques cartes ISA (PCI?).
- Le programme agit en machine d'état temps réel. Elle envoie les pulses au moment où le moteur doit tourner, pas avant et pas après.
On touche ici à l'aspect temps réel des systèmes d'exploitation. Windows n'en est pas un et linux peut s'improviser "temps réel mou" avec l'installation d'un module spécifique.
- Pour la connectique, ni le port USB, ni le port série n'a de capacité temps réel. Dans le cas du port parallèle, le processeur peut adresse quasi-directement les broches de ce port donc peut garantir un temps de réponse rapide (et quasi-constant).
- Pour les cartes intégrant l'USB ou le série, je pense qu'elles intègrent toute un interpolateur qui se charge du respect du timing. En gros le PC fournit des directives avec des dates, la carte se charge de faire ces directives au bon moment. Dans ce cas, le PC (port utilisé et système d'exploitation) n'a pas besoin d'être temps réel, c'est là l'immense avantage. Le gros inconvénient c'est que ça a l'air bien complexe et que je n'ai pas de temps pour ça.

D'un autre coté, la carte que je fabrique commande uniquement les moteurs à partir d'un signal "STEP" et d'un signal "Direction", qu'ils viennent directement du PC (port parallèle) ou via une carte d'interpolation (USB, série).

En espérant avoir répondu à ta question

Xavier

 

[Anonymous]

Et j'ajouterais que cela fait 5 ans que j'entends dire que les port// sont obsolètes et vont disparaître, et sur le dernier pc que j'ai fais assemblé, il y en a toujours un, de même avec la carte mère du pc de découpe, carte mère qui est sortie il y a 1 petite année..............je me demande si réellement ce port disparaîtra un jour.Et de toute façon, même si cela devait arrivé, et en sachant que pour la commande des machines il vaut mieux un PC dédié pour éviter tout problème, je vois mal des usineurs se fendre du dernier PC ,dernier cri, pour commander leur bécanes, on arrivera toujours à récupérer un vieux PC avec ledit port //.

 

[freedom2000]

D'un autre coté, la carte que je fabrique commande uniquement les moteurs à partir d'un signal "STEP" et d'un signal "Direction", qu'ils viennent directement du PC (port parallèle) ou via une carte d'interpolation (USB, série).


Xavier

J'insiste sur cette partie du message (fort détaillé) de Xavier. La carte ne fait "que" l'interface avec les moteurs. Les deux petits signaux en question (step et dir) peuvent provenir de n'importe quelle autre carte.
Y compris une carte d'interpolation.
Certains utilisent interpCNC qui est pilotable USB depuis Ninos (entre autre).
Il existe d'autres cartes compatibles Mach3 qui sortent les signaux step et dir pour les drivers

JP

 

[guol64]

Pour ma part j'ai l'intention d'utiliser la carte de commande de techlf.
Son prix est raisonnable mais pas beaucoup de programes compatibles :

Interpolation :
linéaire (4 axes ) et circulaire (2 axes)
Vitesse :
jusqu'à 50 000 pas/s sur 4 axes
jusqu'à 8 000 blocks/s (commandes)
Communication :
USB 1.1 (12Mb/s) avec un buffer local de 32 Ko
Vitesse de transmission jusqu'à 256Ko/s
Override temps réel
Contrôle de broche temps réel
Relecture des positions en temps réel
Execution des commande en continu
Entrées :
10 (0-30VDC max)
2 analogiques (0 - +10V) convertisseur analogique digital
12 bits
Sorties :
4 collecteur ouvert (100 mA max)
8 TTL ( clock & dir )
1 PWM (O-5V) pour le contrôle de la broche
1 analogique (0-10V) 12 bits/1Msps pour le contrôle la broche
Securité :
contrôle de sécurité embarqué
arrête le mouvement et la broche lorsque 1 entrée (programmable
par logiciel) est activée et active une sortie (programmable
par logiciel).

 

[freedom2000]

Pour ma part j'ai l'intention d'utiliser la carte de commande de techlf.
Son prix est raisonnable mais pas beaucoup de programes compatibles :

Interpolation :
linéaire (4 axes ) et circulaire (2 axes)
Vitesse :
jusqu'à 50 000 pas/s sur 4 axes
jusqu'à 8 000 blocks/s (commandes)
Communication :
USB 1.1 (12Mb/s) avec un buffer local de 32 Ko
......
......
par logiciel) est activée et active une sortie (programmable
par logiciel).

si ce n'est pas indiscret, pourquoi as-tu besoin d'une telle débauche de technologie ? Surtout si peu de programmes sont compatibles ?

 

[guol64]

En fait, lorsque je me suis lancé dans ce projet en début d'année, je me suis jugé inapte à réaliser quoi que ce soit en électronique vu mon niveau. J'ai donc traité le problème un peu n'importe comment.
En parcourant les forums j'ai compris qu'il y avait en gros deux solutions:
Soit une pilotage direct par PC qui semble très dépendant des performances du PC, soit une carte d'interpolation qui fait le tampon entre le PC et les drivers (dites moi si je me trompe). Le must étant la carte d'interpolation, je n'ai pas réfléchi une seconde quand j'ai vu cette carte USB d'occas pour 40€, ce n'est qu'après que je me suis posé la question du logiciel.
Dans un second temps (en cherchant les drivers pas chers ) je suis tombé sur ce topic, et je me suis aperçu qu'en fin de compte en réfléchissant un peu et en se documentant beaucoup on pouvait faire de belles choses. Ce qui m'a interressé sur la carte de MDog c'est que je pouvais choisir d'utiliser ou non ma carte d'interpolation, et ainsi me laisser accès à un panel de logiciel plus important.
Pour l'instant ma seule préoccupation est de controler la rotation des moteurs, mais peut-être qu'un jour j'essayerais de contrôler la broche.

 

[freedom2000]

En parcourant les forums j'ai compris qu'il y avait en gros deux solutions:
Soit une pilotage direct par PC qui semble très dépendant des performances du PC, soit une carte d'interpolation qui fait le tampon entre le PC et les drivers (dites moi si je me trompe). Le must étant la carte d'interpolation,
Pour l'instant ma seule préoccupation est de controler la rotation des moteurs, mais peut-être qu'un jour j'essayerais de contrôler la broche.

Tu ne trompes que sur une chose --> la performance du PC n'est pas "critique". Avec mon vieux Pentium IV à 1,6 GHz (qu'on trouve partout pour pas cher) j'arrive à faire tourner le kernel de Mach3 à 100kHz ce qui est très au dessus de mon besoin !
Avec EMC2 je pense que le temps réel est encore meilleur.
Une carte d'interpolation est bien la meilleure solution. Mais un port // de PC d'il y a 5 ans est plus que largement suffisant !
Après il faut choisir ton soft de pilotage. Moi j'utilise Mach3 qui offre une palette incroyable de possibilités (contrôle rotation broche, contrôle THC plasma... et j'en passe !


JP

 

[guol64]

Bonjour Freedom

Je crois surtout que tu as raison sur un point : il faut savoir précisement ce que l'on veut faire pour établir un cahier des charges précis et ne pas partir à l'aveuglette : c'est la clé de la réussite d'un projet (et là je sais de quoi je parle).

En fait ce n'est pas vraiement mon cas: j'ai découvert les réalisations de CN amateur en naviguant sur la toile et j'ai été imédiatement séduit par le concept. Etant pas mal bricoleur et curieux, je me suis lancé sans plus de réflexion. N'ayant pas beaucoup de temps libre en ce moment j'avance par petits pas désordonnés, et pour être complètement exact je n'ai fait que survoler les différents logiciels.

Cependant je ne crois pas que ce soit du temps perdu : celà permet d'apprendre, de faire des erreurs, de les comprendre, et de les analyser pour ne pas les reproduire plus tard. Je ne suis en train de réaliser que la V1 alors que d'autres ont déjà leur V2 fonctionelle!

Bon ce matin je me suis remis sur le PCB, et pour ne pas avoir à inverser les sorties dans le programme, je me suis remis dans la même config que la carte d'origine, celà sera plus simple pour tout le monde (surtout pour moi, comme ça je n'aurai pas à modifier ton programme pour l'utiliser )

 

[freedom2000]

Bonjour Freedom

En fait ce n'est pas vraiement mon cas: j'ai découvert les réalisations de CN amateur en naviguant sur la toile et j'ai été imédiatement séduit par le concept.

J'ai fait exactement comme toi --> l'apprentissage est la meilleure façon pour apprendre.
Ce n'est pas du temps perdu, ça j'en suis sûr.
Le plus difficile est savoir à quoi on veut destiner sa CNC... J'étais parti sur du modelisme "pur", d'où ma V1. Puis le virus se propage ... le bois... l'alu ... le plasma. C'est "sans fin" mais que c'est bon
Et à vrai dire je ne sais toujours pas à quoi va me servir ma V2 ... je trouverai en temps utile

JP

 

[horsot]

Et à vrai dire je ne sais toujours pas à quoi va me servir ma V2 ... je trouverai en temps utile

JP

Enfin un moment de lucidité

 

[freedom2000]

Il a fait un temps de merde ce week end dans les Pyrénées... Heureusement j'avais mon PC

J'en ai profité pour relooker le code du driver afin d'en améliorer les performances.
Jugez plutôt :

le driver dépasse les 100 kHz de fréquence de step sans décrocher. ça veut dire qu'il est désormais utilisable avec la toute dernière version de Mach3 poussée dans ses derniers retranchements (kernel à 100 kHz)

Évidemment je ne recommande pas d'utiliser Mach3 à 100 kHz (risque d'instabilité) ; mais c'est toujours bon de savoir que le driver peut tourner à ces vitesses folles

Pour arriver à ceci, j'ai optimisé le code en supprimant tout ce qui était inutile dans la partie "temps réel critique" (le traitement des steps)
J'ai du déboucler des boucles, supprimer des appels de sous programmes et dupliquer les tables de sinus pour éviter des calculs. Le code est donc "moins beau" mais il est bougrement plus efficace. Souvenez vous, j'étais à environ 69 kHz, et maintenant à 100 kHz
Je pourrais encore gagner un peu en supprimant le calcul d'index des µpas.. mais dans la mesure où j'ai atteint la cible symbolique des 100 kHz, je m'arrête là

J'en ai profité pour améliorer un peu la gestion du mode "réduction de courant" pour éviter d'entendre des petis "clics" dans le moteur toutes les 30s quand on atteint la valeur de repos à 40% de puissance... (du détail !)

Moins anecdotique, j'ai également équilibré les durées de traitement des steps. Quelque soit la direction (en avant ou en arrière) le traitement des signaux Direction + Step prend exactement 9,6 µs

Bien sûr le programme reste à iso fonctionnalités :

---

fully ported on PIC16F57
adapted to Mdog's µstep board design
includes 1/2, 1/4, 1/8, 1/16 µstep mode
includes different DAC tables for LMD18245T drivers
includes idle mode current reduction :
after 30s 75%
after 90s 40%

performances :
step interrupt detection
time min to detect step interrupt : 6 cycles --> t0 = 1.2 µs
time max to detect and process interrupt : 48 cycles --> t0 + t1 = 9.6 µs
timemax to detect and process time out : 63 cycles --> t0 + t2 = 12.6 µs

step width MUST be greater than 1.2 µs to be detected
step frequency MUST NOT be greater than 1/9.6 MHz = 104166 Hz in order to NOT loose steps
so to be safe :
use Mach3 kernel speed up to 100 kHz (maximum possible value of Mach3 in 2009 !!!)
set Step Pulse width to 2 or 3 µs under Mach3

---

Le source et le binaire sont désormais uniquement disponibles sur mon site ici : driver JPG V1 (c'est beaucoup plus simple pour les mises à jour...)

JP

 

[horsot]

Salut JP !

Les grands esprits se rencontrent, j'ai codé l'adressage de mes tables avec la même idée sous-jacente! Par contre je n'ai pas fusionné les tables A et B (j'ai beaucoup plus de place) ceci pour ne pas avoir à générer un index secondaire pour le DACB. Bref avec toutes ces tables, j'ai même fini par écrire un petit script (en python) pour les générer à partir d'un fichier CSV mais surtout pour éviter de me tromper en "copier-coller".

Par contre, j'ai utilisé une autre méthode pour ajouter ou soustraire une valeur à l'index relatif : j'ajoute dans tout les cas, une valeur positive ou une valeur "négative" calculée une fois pour toute à l'init. Ça m'a permis de fusionner une partie du programme (ajouter/soustraire).

A première vue, j'allais te dire que tu confondais banques de l'espace RAM/Registres (géré par STATUS) avec zone d'adressage programme (normalement géré par par PCLATH). Puis je me suis dit "JP n'aurait pas publié un truc sans le tester, je vais regarder la datasheet" et là surprise PCLATH a disparu dans le 16F57 et utilise les bits de STATUS (économies de bout de chandelles)! Sur le 16F876 (et tous les autres que j'ai eu dans les mains) ces deux sont séparées, PCLATH est à part. Le 16F57 n'a pas fini de m'étonner...

En tout cas bravo pour le code, de mon coté je gère maintenant le microstepping, la sélection de courant et la réduction du courant. Il me reste à coder les tables "Power torque" et la fonction micropas "doux" : génération de nanopas pour aller de manière "douce" d'un micropas à au suivant (oui j'y tien).

Xavier

 

[freedom2000]

Salut JP !

Par contre, j'ai utilisé une autre méthode pour ajouter ou soustraire une valeur à l'index relatif : j'ajoute dans tout les cas, une valeur positive ou une valeur "négative" calculée une fois pour toute à l'init. Ça m'a permis de fusionner une partie du programme (ajouter/soustraire).


Puis je me suis dit "JP n'aurait pas publié un truc sans le tester"

Xavier

Fais moi passer ton bout de code sur l'addition = soustraction !
Ceci dit, j'ai inclus tout ça dans un seul test : celui de la patte "Direction" on ne doit donc pas gagner grand chose... 1 ou 2 cycles ?

sur le dernier point tu ne crois pas si bien dire... Je n'ai testé que sous simulateur (mais longtemps car il pleuvait )

JP

 

[horsot]

Fais moi passer ton bout de code sur l'addition = soustraction !
Ceci dit, j'ai inclus tout ça dans un seul test : celui de la patte "Direction" on ne doit donc pas gagner grand chose... 1 ou 2 cycles ?

sur le dernier point tu ne crois pas si bien dire... Je n'ai testé que sous simulateur (mais longtemps car il pleuvait )

JP

On ne gagne pas grand chose en effet mais le code est un peu plus simple (à mes yeux). On gagne la "complexité" d'une soustraction en moins car la gestion du modulo devient inutile (la valeur que tu ajoutes avant la soustraction).

Voici le code à l'init pour générer la valeur positive et négative:

Vous devez être connecté pour voir ce contenu.

Dans l'interruption :

Vous devez être connecté pour voir ce contenu.

Voila je n'ai pas vérifié que le temps d'exécution soit constant, je ferais ça en dernier lieu pour l'instant ça ne doit pas être très loin.

Xavier

 

[freedom2000]

On ne gagne pas grand chose en effet mais le code est un peu plus simple (à mes yeux). On gagne la "complexité" d'une soustraction en moins car la gestion du modulo devient inutile (la valeur que tu ajoutes avant la soustraction).


Xavier

very clever

Je teste ce soir et je gagne encore 1000 Hz dans la fréquence pulse !

JP

 

[guol64]

Bonjour à tous,

Freedom j'aurais une question indiscrète : quel est ton métier?
Car tu as l'air compétent dans beaucoup de domaines : c'est impressionnant.

Et encore bravo de prendre le temps de nous faire partager tout ça.

 

[horsot]

very clever

Je teste ce soir et je gagne encore 1000 Hz dans la fréquence pulse !

JP

Thanks :-p

Je viens de finir la gestion des interruptions (je n'y toucherai plus, à moins que...). Aller pour te taquiner je te donne les résultats : 35 instructions entre 2 pulses => 7µs entre 2 pulse de STEP => plus de 142kHz!!! !

Bon aller c'est vrai j'ai triché, mon pic gère les interruptions alors ça a été bcp plus facile qu'avec ta rougne (ça y est c'est dit)! Dire que je pourrais aller au dessus des 150kHz en écrivant directement sur le port de sortie une fois la table lue mais je n'aurais pas 0,4µs entre les signaux LMD_A et LMD_B.

Xavier

La capture de la simulation :

 

[horsot]

Bonjour à tous,

Freedom j'aurais une question indiscrète : quel est ton métier?
Car tu as l'air compétent dans beaucoup de domaines : c'est impressionnant.

Et encore bravo de prendre le temps de nous faire partager tout ça.

S'il te le dit il faudra qu'il te tue, c'est à cause de ça que je suis en cavale

C'est vrai qu'il est bon le bestio, surtout pour un...

Xavier

 

[freedom2000]

Bonjour à tous,

Freedom j'aurais une question indiscrète : quel est ton métier?
Car tu as l'air compétent dans beaucoup de domaines : c'est impressionnant.

Et encore bravo de prendre le temps de nous faire partager tout ça.

S'il te le dit il faudra qu'il te tue, c'est à cause de ça que je suis en cavale

C'est vrai qu'il est bon le bestio, surtout pour un...

Xavier

Disons que je suis un manuel contrarié avec la tête dans les étoiles

Depuis on embauche des jeunes, ils sont meilleurs que nous les "anciens" ... Enfin on le leur laisse croire

JP

 

[freedom2000]

Aller pour te taquiner je te donne les résultats : 35 instructions entre 2 pulses => 7µs entre 2 pulse de STEP => plus de 142kHz!!! !


Xavier

:

Chapeau bas le P'tit jeune

En plus tu maitrises le simulateur mieux que moi

et tu as eu l'élégance de me laisser le record pendant un jour

JP

 

[horsot]

Chapeau bas le P'tit jeune

En plus tu maitrises le simulateur mieux que moi

et tu as eu l'élégance de me laisser le record pendant un jour

JP

Merci chef! J'apprécie le compliment!

Pour le simulateur MPLAS :
1) pour générer des signaux c'est dans "Debugger -> Stimulus -> New Workbook" (stimulus que tu peux sauver dans un fichier).
2) pour tracer les chronogrammes c'est dans "View -> Simulator Logic Analyser".
Personnellement je trouve ça un peu pauvre en fonctionnalité pour le debug. Ça fait un peu vieillot.

Pour le record, ce n'est pas de la fausse modestie, mais on ne peut pas vraiment comparer nos résultats on travaille pas sur le même matériel. C'est comme si un gars codait ça dans un FPGA et qu'il nous dise :
100MHz!!! et sans forcer...

A bon entendeur

Xavier

PS : Sérieusement un FPGA est beaucoup plus adapté à ce genre de chose qu'un microcontrôleur. Le soucis, c'est pour faire le PCB dans le garage. A moins de partir sur un circuit générique où le FPGA est déjà présent attendant que l'on branche les LMD18245 sur les I/O... En fait avec un FPGA, quelques ADCs et des LMD18200, on peut faire bien mieux qu'avec les LMD18245. Mais que de boulot!

 

[freedom2000]

Pour le record, ce n'est pas de la fausse modestie, mais on ne peut pas vraiment comparer nos résultats on travaille pas sur le même matériel.

PS : Sérieusement un FPGA est beaucoup plus adapté à ce genre de chose qu'un microcontrôleur. Le soucis, c'est pour faire le PCB dans le garage. A moins de partir sur un circuit générique où le FPGA est déjà présent attendant que l'on branche les LMD18245 sur les I/O... En fait avec un FPGA, quelques ADCs et des LMD18200, on peut faire bien mieux qu'avec les LMD18245. Mais que de boulot!

Ceci étant... si on regarde le code de "microstep" qui utilise un µcontroleur de ton type (20 MHz avec interruptions) on voit ceci :

Approximate motor performance speeds:
Microstep10 routine runs about 25% slower due to the longer step calculation routine.
Microstep10 about 1400RPM.
Microstep8 about 2000rpm (53Khz step input rate).
Microstep4 about 3500rpm (46Khz step input rate).
Halfstep about 3000rpm (20Khz step input rate).
Tested results with a Superior Electric M091-FD09 at 44volts motor supply. TurboCNC on P2-500 PC.
Maximum rpm speeds will vary depending on motor type and computer speed.

Le record du Monsieur est de 53 kHz ... à comparer aux 140 KHz de Xavier et aux 106 kHz sur ma rogne.
Et en plus son record est en 1/8 de pas... nous c'est valable en 1/16° ...

Bon d'accord nous c'est aussi sans le moteur !!!!

Une raison à ça : le code en C par rapport à du code optimisé en assembleur...

Je pense que plus personne ne doutera de la supériorité de ce langage pour les applications "time critical"

Pour le FPGA on va attendre un peu. Il m'a fallu 49 ans pour toucher aux PICs... alors le FPGA...
Mais je suis tenté

JP

 

[freedom2000]

Xavier,

J'ai fait ta modif --> j'ai gagné 0,4 µs (2 cycles)

Donc mon nouveau record : 108695 Hz

faut dire que je ne suis pas aidé par ma rogne qui n'a même pas le "sublw"...

faut faire à l'ancienne pour avoir l'opposé d'un nombre :
complément à 1
incrément de 1

JP

 

[horsot]

Et en plus son record est en 1/8 de pas... nous c'est valable en 1/16° ...

JP

Heu, en 1/32ième pour moi. Tu vas dire que je viens de le coder pour te donner tord mais en fait j'ai d'autres raisons.

1) Les "pages" font 256 éléments et j'ai 2 tables par pages. J'ai trouvé ça dommage de mettre deux tables de 64 (1/16° de pas) alors que deux tables de 128 (1/32° de pas) rentraient.

2) Je me suis fais ch*** à coder un script de génération de table alors autant qu'il serve à en générer des grosses! (ok elle n'est pas vraiment bonne cette raison)

2 bis) J'ai 3 jumpers (8 possibilités) pour sélectionner le mode de microstepping et mon code n'en utilisait que 5 maintenant c'est 6! : full, 1/2, 1/4, 1/8, 1/16 et 1/32. (ok elle n'est pas vraiment bonne cette raison non plus)

2 ter) J'ai surtout mis ça pour la fonction "pas doux" parlé un peu plus haut ici.

Au fait, c'est quoi l'intérêt du 1/10ième de pas? C'est par curiosité, de toute façon je ne pourrai pas l'intégrer dans mon programme, vu sa structure il marche car les tables sont une puissances de 2.

 

[horsot]

Xavier,

J'ai fait ta modif --> j'ai gagné 0,4 µs (2 cycles)

Donc mon nouveau record : 108695 Hz

faut dire que je ne suis pas aidé par ma rogne qui n'a même pas le "sublw"...

faut faire à l'ancienne pour avoir l'opposé d'un nombre :
complément à 1
incrément de 1

JP

Que 2 cycles? Tu as mis le calcul dans le code d'"interuption" ou à l'init?
De manière générale j'ai mis tout les calculs dans l'init, pour les changer => reset obligatoire.

Ta rogne n'aura pas fini de me surprendre! Tu changes quand? A moins que tu prennes ça comme un défis

Ok pour "work around" de la soustraction

Xavier

 

[freedom2000]

Heu, en 1/32ième pour moi. Tu vas dire que je viens de le coder pour te donner tord mais en fait j'ai d'autres raisons.



Au fait, c'est quoi l'intérêt du 1/10ième de pas? C'est par curiosité, de toute façon je ne pourrai pas l'intégrer dans mon programme, vu sa structure il marche car les tables sont une puissances de 2.

1/32 ° bien vu

Mais ça ne va pas te servir à grand chose je pense... Actuellement avec mes gros moteurs coupleux à forte inductance et grosse inertie je tourne en ... 1/2 pas. C'est là que j'ai les meilleures perfos.

Je crois que "microstep" a fait des 1/10 µpas parce qu'il a des problèmes de perfos ...

JP

 

[freedom2000]

Que 2 cycles? Tu as mis le calcul dans le code d'"interuption" ou à l'init?
De manière générale j'ai mis tout les calculs dans l'init, pour les changer => reset obligatoire.

Ta rogne n'aura pas fini de me surprendre! Tu changes quand? A moins que tu prennes ça comme un défis

Xavier

à chaque cycle il faut bien ajouter la valeur d'index...
Pour la soustraction (que je fais à cahque cycle) j'ai juste un cycle de plus que l'addition qui est compensé par l'absence de goto en fin de traitement... Exactement le même nombre de cycles sans un seul NOP

Bon, pour finir sur ma rogne...
Le traitement des steps en désactivant le mode "réduction de courant" se fait en : 7 µs

fréquence de pulse : 142857 Hz

Mais là je pense être au taquet... sauf à séparer les tables DAC A et DAC B
Alors que toi tu peux optimiser surement encore un peu non ?

JP

Pas si mauvaise ma rogne !!!!!

 

[horsot]

Mais là je pense être au taquet... sauf à séparer les tables DAC A et DAC B
Alors que toi tu peux optimiser surement encore un peu non ?

JP

Alors là tu me cherches!
J'ai tout désactivé : le mode réduction de courant et l'écriture différée sur les ports de sortie, là je ne pense pas pouvoir faire mieux (j'ai déjà 2 tables)!
Question timing je suis à 29 cycles => 4,8µs => 172,4kHz. Mais je préfère largement l'ancienne version à 142kHz, j'avais 2 cycles (0,4µs) entre le changement de LMDA et LMDB maintenant j'en ai 8 (1,6µs).

Xavier

Les petits chronogrammes :

 

[horsot]

Pour info, juste en supprimant la réduction de courant mais en gardant l'écriture différée, je suis à :
31 instructions => 6,2µs => 161kHz... Ca peut être une option de compilation.

Xavier