filetage avec microcontrolleur

[vibram]

je t'avoue que je bloque un peu, tout les indicateurs sont au vert et je n'ai pas de detail sur le message d'erreur...

 

[vibram]

je ne suis donc pas totalement fou, je n'avais pas la possibilité à l'origine
https://lujji.github.io/blog/stlink-clone-trace/

La suite dans quelque jours lorsque j'aurais recu le vrai ST link ou lorsque j'aurais trouvé qqun pour me faire la modif

 

[nopxor]

Sinon tu peux utiliser le ST-Link de ta carte Nucleo.
https://www.sevenwatt.com/main/picos-arm/picos-arm-lpc810-swd-jtag-with-nucleo-stm32/

 

[vibram]

Sinon tu peux utiliser le ST-Link de ta carte Nucleo.
https://www.sevenwatt.com/main/picos-arm/picos-arm-lpc810-swd-jtag-with-nucleo-stm32/

exact, j'ai essayé cet aprem, j'arrivais bien à envoyer le sketch mais impossible d'avoir le debug...
Je re tente demain... ca demande un peu de patience !!

 

[vres]

Voici des copies d'écran de ma configuration avec une dicovery stm32f01.
Il n'y a pas de grosse différences.
Même pour programmer mes cartes Olimex, je me sert de STlink d'une carte discovery, sur la liaison SW, j'ai aussi NRST de câblé.

Pour tes problèmes de rapidité, c'est un peu normal tes fonctions run_ccw et Run_cw te bouffent des milliers de cycles.

De même au lien d'utiliser GPIO_WriteBit(GPIOA, GPIO_Pin_3, 0) tu peux utiliser GPIOA->BRR = GPIO_Pin_3 ou pour GPIO_WriteBit(GPIOA, GPIO_Pin_3, 1) GPIOA->BSRR = GPIO_Pin_3
C'est beaucoup plus rapide il n'y a pas d'appel de fonction.

 

[vibram]

Salut CNCSERV,

Pour les fonctions run_cw & CCW, je m'en sers uniquement au démarrage pour vérifier que mon moteur tourne correctement. Elles seront enlevée dans la version finale. je vais faire des tests sans pour voir l'incidence.
Ok je vais faire les changements pour le Writebit, je ne connaissais pas le BRR et BSRR, interessant.

Pour la config, j'ai aucun souci pour envoyer le sketch que ce soit avec le clone st link chinois ou avec le st link du nucleo mais c'est le trace/debug qui ne fonctionne pas. Et je vois qu'il n'est pas activé dans ta config.
J'ai commandé un vrai ST link v2, j'espere que je vais m'en sortir avec.

Hier j'ai recu mon keypad, j'ai donc activé (et tout fonctionne, c'est deja ca !) les ecrans de selection de pas et de longueur de filetage.
Je vais tester tes conseils d'ici ce weekend et je vais voir ce que ca donne
Mais j'ai besoin du debug pour comprendre ce qu'il se passe dans les variables car dans l'état actuel le stepper ne tourne que dans un sens et ne s'arrête jamais. A voir donc

edit:
config:

Noir sur le reset et gris sur PB3 pour le SWO
Les cases Reset and run et Download to flash sont cochées ou décochées selon mais cela ne change pas mon souci de debug (j'ai lu qu'on devait les décocher pour le debug)

 

[vres]

c'est le trace/debug qui ne fonctionne pas. Et je vois qu'il n'est pas activé dans ta config.

Oui pourtant il fonctionne

Dans Output tu as bien Debug information de coché ?

 

[vibram]

Oui pourtant il fonctionne

Dans Output tu as bien Debug information de coché ?

Oui oui, ca fait quelques heures que je passe la dessus et essayé pas mal de choses, je commence à me poser des questions
Pourtant là j'ai une config qui se rapproche de ce que tout le monde semble avoir

 

[saico]

Avec le St-link2 on peut effectuer deux opérations différentes :

1- Le débogage qui permet de visualiser tout les variables que tu définis ainsi que le déroulement de ton programme, et pour cela ton St-link « clone » fera très bien l’affaire.

2- Le trace qui permet l’accès à quelques fonctionnalités avancées comme le suivi des exceptions, les interruptions, les registres d’état et les périphériques hardware (USART, GPIO, SPI…) et plein d’autres choses sympa , et particulièrement le ITM qui est utilisé généralement pour rediriger le « printf() » . Pour activer le trace, l’utilisation du pin SWO ( PB3 ) est obligatoire mais malheureusement n’est pas disponible sur le connecteur du St-link « clone ».

Donc pour pouvoir activer le trace tu dois utiliser le st-link présent sur une carte Discovery ou Nucleo, ou si tu aime t’amuser avec la soudure CMS tu as l’option de souder un petit bout de fil sur le pin 31 (PA10) du stm32f103 présent sur le st-link, et pour des raisons pratiques, tu peux sacrifier une broche 5V sur le connecteur pour souder l’autre bout du fil.

 

[vibram]

Merci Saci, ça confirme ce que je pensais mais j'ai toujours l'erreur de no synchronisation et je ne sais pas d'où cela vient...
J'ai commandé un vrai st link je vais voir si cela résoud le problème mais je n'y crois pas trop. J'ai testé le SWV sur une fréquence d'horloge allant de 8 à 72Mhz par incrément de 8mhz et sans succès

 

[coredump]

Ta vitesse SW est surement trop élevée, ces petits debugger ne sont pas très fiable, 1MHz c'est quasi leur limites.
Pour un outil plus sérieux il y a les JLink de Segger qui sont très bien. La version EDU est a 60€
Leur système RTT est mieux fait que le SWO (qui est supporté aussi) car ca ne tue pas le temps réel autant que le SWO qui est une horreur de ce coté.

 

[saico]

Si tu utilises la carte Nucléo, Je t’invite à vérifier que les deux bridges SB12 et SB15 sont bien dessoudés. ( se trouvent sur le dos de la carte, voir photo )

Pour la vitesse, je ne peux pas dire si c’est un problème ou pas, de mon coté j’utilise exactement le même Clone à 1$ que le tien ( sur la photo un peu plus haut ) et ça fonctionne correctement à 4MHz même avec un noyau RTX exécutant 8 taches simultanément, après reste à discuter la fiabilité des composant sur ces clones !

 

[vres]

Il se passe quoi quand tu lances le debogage ? tu as bien un message ?

 

[vibram]

J'ai le message en bas No syncronization

mais je viens de voir que j'ai bien le bridge de soudé entre SB12 et SB15...ce serait une piste
Je vais regardé car lorsque j'avais regardé le user manuel, j'ai pas vu que ceux ci devaient être dessoudés
Edit: OK c'est clairement indiqué pour le SB12
http://www.st.com/content/ccc/resou...df/jcr:content/translations/en.DM00105823.pdf page 18
pour le SB15 c'est moins évident. Je voulais juste vérifier avant de d'enlever un composant que je ne pourrai pas forcément remettre par la suite
Je viens de tester en les enlevant, pas plus de succès ;(


et lorsque je passe par le soft ST Link utility:

 

[vres]

L'explication saci la peut-être donné :

2- Le trace qui permet l’accès à quelques fonctionnalités avancées comme le suivi des exceptions, les interruptions, les registres d’état et les périphériques hardware (USART, GPIO, SPI…) et plein d’autres choses sympa , et particulièrement le ITM qui est utilisé généralement pour rediriger le « printf() » . Pour activer le trace, l’utilisation du pin SWO ( PB3 ) est obligatoire mais malheureusement n’est pas disponible sur le connecteur du St-link « clone ».
Donc pour pouvoir activer le trace tu dois utiliser le st-link présent sur une carte Discovery ou Nucleo, ou si tu aime t’amuser avec la soudure CMS tu as l’option de souder un petit bout de fil sur le pin 31 (PA10) du stm32f103 présent sur le st-link, et pour des raisons pratiques, tu peux sacrifier une broche 5V sur le connecteur pour souder l’autre bout du fil.

En revanche l'évaluation des variables et les points d'arrêt doivent fonctionner, c'est déjà pas mal.


Edit: il semble que SWO soit le fil gris donc tu l'as visiblement branché

 

[saico]

Si tu peux poster la partie de ton programme qui configure l'oscillateur ( system_stm32f10x.c ), on pourrait peut être vérifier que la fréquence système est correctement déclarée.

 

[vibram]

Tous les essais que j'ai mis ici sont avec le ST link incorporé à mon STM32F411 donc pas de clone chinois.
je vois quelqu'un demain qui va se pencher sur le cas et me montrer les bases du debugger comme je ne suis pas habitué à cet objet
Par la meme occasion, j'essaierai le code avec les modifitcations que tu m'as suggerées

Voici le code:
Pour moi, c'est à la ligne 115 qu'on definit la valeur à 72Mhz

Vous devez être connecté pour voir ce contenu.

 

[saico]

Tout semble correcte, ton horloge système est à 72Mhz, le trace fonctionne correctement on utilisant ton fichier poster et le clone st-link.

fais encore une autre tentative avec le stlink de la carte Nucleo ( toute en gardant les deux bridges déssoudé ! ) et puis essai avec les deux fréquences 72Mhz puis 36Mhz.

 

[vibram]

j'insiste sur le fait que tout fonctionne bien pour l'envoi etc.
Le sketch de test:

Vous devez être connecté pour voir ce contenu.

mes branchements:

et ma config:
(essayé avec 72 et 36 comme conseillé)

j'avais vu un tuto ou il disait qu'il fallait changer la size du dernier printscreen, 2 ou 1, j'ai vu que tu as laissé 2. Là encore j'ai testé les 2, sans succes

 

[saico]

Alors, j'ai créé un autre projet pour tester ton code posté, et là tout fonctionne correctement.

une piste à creuser : avec un multimètre, vérifier que la liaison est bien établie entre le PB3 ( broche 38 ) du STM32F103 sur la carte de test, et le PA10 ( broche 31 ) du STM32F103 sur le St-link.

 

[vibram]

OK merci, je vais voir ca demain et eventuellement tester avec une autre carte

 

[vres]

Je ne comprend pas, normalement la visualisation des variables et les points d'arrêt doivent largement suffirent pour déboguer ton programme.

Je ne sais pas trop ce que les infos dans Debug viewer vont t'apporter de plus

Pour ton application il faudrait une routine à 50kHz minimum pour avoir un résultat satisfaisant. Tu ne vas pas écrire une ligne a chaque fois !

 

[vibram]

Bonsoir,
je me suis bien plongé dedans aujourd'hui, on m'a filé un coup de main pour le trace: mon STm32 chinois n'était pas bien soudé, et le PB3 n'était donc pas relié. Je ne sais pas si cela était visible au multimetre mais l'oscillo de la personne qui m'a aidé l'a bien détecté.
Le debug et le trace fonctionne parfaitement apres changement du board et modification du pin 1 du CN4 car je n'avais pas compris qu'il fallait 1 alim et VCC, j'avais juste mis l'alim...

Concernant le projet en lui meme, j'ai un peu avancé mais de maniere pas tres scolaire. j'ai passé 2h a essayé de trouver la frequence du APB1 et je n'ai pas réussi. Du coup j'ai trouvé des exemples sur internet et j'ai adapté les valeurs en essayant de trouve run juste milieu entre l'amperage, la vitesse etc. Sauriez-vous me dire comment je trouve cette frequence? j'ai vu les histoires de divide clock etc. je n'ai pas trouvé la valeur du prescaler, je sais juste que j'ai un SYSCLK à 72Mhz.
J'aimerais être plus ua point la dessus car je pense que cela influe sur le souci que je vous présente dessous en video.
J'ai rajouté un if dans le cas ou le codeur ne bouge pas. je ne sais pas si c'est une bonne méthode car cela augmente le temps de traitement mais j'avais des problemes de stabilité à l'arret. C'est soit ca, soit des "&&" dans les deux autres conditions.

Ensuite j'ai essayé de rentrer les bons parametres d'avance, step etc.
Je ne suis pas loin du but mais je dois encore ajouter des conditions lorsque je pilote mes moteurs à savoir respecter la longueur du filetage et ne pas depasser les fins de course car je n'ai pas mis de capteur, un jour qui sait . Mais avant les capteurs; j'aimerais deja prévoir ca au niveau software.
je ne me fais pas trop de souci sur ca, il faut juste que je me mette dessus une fois que le moteur sera parfaitement piloté.

Donc voici une video qui montre mon probleme. Je pense que la cause est la frequence interruption mais je ne serais pas surpris que d'autres erreurs n'arrangent rien.
Les symptomes: lorsque je tourne le codeur "rapidement" dans un sens ou l'autre, le moteur tourne "rapidement" dans un sens ou l'autre mais il y a toujours quelques pas de décalage avant le changement de sens. lorsque je tourne le codeur lentement, là le décalage est nettement plus important, presque 1 tour. Sans compter que le mouvement n'est pas fluide à basse vitesse mais pas sur que je puisse remedier à cela.

Voici le code mis à jour:

Vous devez être connecté pour voir ce contenu.

 

[vres]

C'est pas trop mal, reste a affiner.
Il faudrait que t'arrive a mesurer la frequence d'interruption et la durée de de la fonction. Il n'y a pas beaucoup de flottants mais quand je t'ai donné le code je pensai au f04 avec FPU.
En examinant le code, ils y a plusieurs choses qui ne vont pas :
Tu ne fais pas les même conditions de déplacement sur le CW que sur le CCW.
Avec le code que je t'ai donné, le changement de Dir se fait en même temps que le Step.. c'est très mauvais

Je te fait les corrections cet aprèm.

 

[saico]

La configuration de l’horloge est détaillée dans le fichier « systeme_stm32f10x.c »

Ligne 987, fonction « SetSysClockTo72(void) » :

Le AHB prescaler ( HCLK ) à la ligne 1022 : RCC_CFGR_HPRE_DIV1

Le APB1 prescaler ( PCLK1 ) à la ligne 1028 : RCC_CFGR_PPRE1_DIV2

Le APB2 prescaler ( PCLK2 ) à la ligne 1025 : RCC_CFGR_PPRE2_DIV1



Les valeurs possibles sont définies dans « stm32f10x.h » à partir de la ligne 1724.



Ton TIM2 est configuré pour générer des interruptions à une fréquence de 4Khz :

F_TIM2= 72000000 / (71+1) / 250 =4000.

Donc une fréquence step de : 4000 / 2 = 2KHz.

A cette fréquence le moteur tournera à : (2000/500)*60=240rpm

@CNCSERV te propose d’aller beaucoup plus haut en fréquence afin d’avoir un résultat satisfaisant.

Note : le délai minimum de quelques µs après changement de direction est à respecter, tu peu gérer ça dans ta routine d’interruption du TIM2 en rajoutant d’autre(s) valeur(s) de cycle par exemple « cycle=2,3,… ».

 

[saico]

Juste pour voir clair :

 

[vres]

Note : le délai minimum de quelques µs après changement de direction est à respecter, tu peu gérer ça dans ta routine d’interruption du TIM2 en rajoutant d’autre(s) valeur(s) de cycle par exemple « cycle=2,3,… ».

Je viens de me rendre compte de cette erreur, j'ai fait ça vite fait

 

[vibram]

La configuration de l’horloge est détaillée dans le fichier « systeme_stm32f10x.c »

Ligne 987, fonction « SetSysClockTo72(void) » :

Le AHB prescaler ( HCLK ) à la ligne 1022 : RCC_CFGR_HPRE_DIV1

Le APB1 prescaler ( PCLK1 ) à la ligne 1028 : RCC_CFGR_PPRE1_DIV2

Le APB2 prescaler ( PCLK2 ) à la ligne 1025 : RCC_CFGR_PPRE2_DIV1



Les valeurs possibles sont définies dans « stm32f10x.h » à partir de la ligne 1724.



Ton TIM2 est configuré pour générer des interruptions à une fréquence de 4Khz :

F_TIM2= 72000000 / (71+1) / 250 =4000.

Donc une fréquence step de : 4000 / 2 = 2KHz.

A cette fréquence le moteur tournera à : (2000/500)*60=240rpm

@CNCSERV te propose d’aller beaucoup plus haut en fréquence afin d’avoir un résultat satisfaisant.

Note : le délai minimum de quelques µs après changement de direction est à respecter, tu peu gérer ça dans ta routine d’interruption du TIM2 en rajoutant d’autre(s) valeur(s) de cycle par exemple « cycle=2,3,… ».

On est d'accord que dans ce cas, comme le prescaler div est différent de 1; alors le timer clock est multiplié par 2 ? il me semble que c'est ce qui est écrit dans le manuel. Cela est concordant avec ce que tu mets
Merci en tout cas, c'est exactement ce que je cherchais comme explication et que je ne reussissais pas à trouver.

C'est pas trop mal, reste a affiner.
Il faudrait que t'arrive a mesurer la frequence d'interruption et la durée de de la fonction. Il n'y a pas beaucoup de flottants mais quand je t'ai donné le code je pensai au f04 avec FPU.
En examinant le code, ils y a plusieurs choses qui ne vont pas :
Tu ne fais pas les même conditions de déplacement sur le CW que sur le CCW.
Avec le code que je t'ai donné, le changement de Dir se fait en même temps que le Step.. c'est très mauvais

Je te fait les corrections cet aprèm.

Oui oui les conditions font parties des choses que je dois revoir en effet ! Je voulais terminer par cela une fois que j'avais mes interruptions correctement configurées

Je suis de festival aujourd'hui mais je vais reflechir à cette histoire de cycle pour intégrer le changement de dir avant le step mais comme ca la solution ne me saute pas aux yeux. J'essaie de trouver et je comparerai avec ce que tu vas me proposer
J'ai changé mes variables prescaler et count mais pour j pense qu'il faut d'baord que j'ai le bon code pour les changements de direction avant de voir cela.

Tu parles d'une routine à 50Khz donc un step tous les 25Khz ? ca donne 40us ce qui est toujours dans les clous par rapport aux capactés du driver. Je vais tester cela des que mon changement de dir est en bonne et due forme


edit: mon prochain projet j'incluerai cubemx et HAL
j'ai tenu à ne pas m'en servir sur ce projet car cetait le premier et je voulais impérativement comprendre ce qu'il se passait. maintenant que j'y vois plus clair, je vais pouvoir m'aider de cet outil qui simplifie pas mal la tache pour ce genre de chose...

 

[saico]

Tu parles d'une routine à 50Khz donc un step tous les 25Khz ? ca donne 40us ce qui est toujours dans les clous par rapport aux capactés du driver

Pour une fréquence d’interruption de 50Khz, c'est-à-dire

Vous devez être connecté pour voir ce contenu.

F_TIM2= 72000000 / (71+1) / 20 =50000 Hz

le moteur tournera à : (25000/500)*60=3000 rpm

C’est un peu élevée comme vitesse ( à vérifier en fonction des capacités de ta configuration « moteur-driver-alimentation » ), @CNCSERV aurait plus de connaissances là-dessus et il peut t’en parler.

Je propose plutôt une fréquence d'interruption de 20Khz ( ou encore moins ) donc :

Vous devez être connecté pour voir ce contenu.

F_TIM2= 72000000 / (71+1) / 50 =20000 Hz

Vitesse moteur maximale : (10000/500)*60=1200 rpm

 

[vres]

Pour la Fréquence pour un moteur Pas à Pas et pour ton application 20kHz c'est largement suffisant en 1/8 de pas ça nous donne (20000/1600 ) * 60 = 750tr/min

Vous devez être connecté pour voir ce contenu.

C'est 0.2% garanti sans bug

Pour les butées logicielles comme on ne gère pas les accélérations, il y une possibilité de décrochage du moteur.