interpolation

[arnaud2]

salut tout le monde
j'aimerai savoir comment faire une interpolation linéaire avec un pic
quels types de calcul sont a faire (sans nombre a virgule)
mon but :
enregistrer le gcode sur une carte mmc
lire le fichier avec le microcontroleur
faire l'interpolation et commander les moteurs pas a pas
j'ai pas encore defini le type de microcontroleur que je vais utiliser mais ca sera surement un pic 18f
merci

 

[coredump]

Tu veux absolument utiliser un PIC?

Pour un truc aussi complexe je te conseillerais plutot un ARM type SAM7:

http://www.sparkfun.com/commerce/produc ... cts_id=774

La carte a déja un connecteur SD/MMC, un port USB et surtout un debuggeur pas cher et ca tourne moultement plus vite (et ca se programe en C)...

Pour l'interpolation lineaire, ce ne sont que des maths, il faut juste passer en virgule fixe au lieu de virgule flottante, mais c'est un sujet un peu vaste pour un post.

 

[arnaud2]

les arm sont juste en boitier tqfp ou tsop
j'aimerais bien utiliser que des composant dip a la limite un dspic en boitier dip40
pour ce qui est de la fréquence de sortie 4000hz ca suffirait je pense qu'avec une puce a 30mips ca doit etre fesable

 

[coredump]

Il existe des headers boards qui sont pratique pour enficher dans un montage deja fait, les prix sont certes plus élevés (35$ pour une 64kB), mais au final ca peut faire gagner beaucoup de temps.

Pour avoir patiqué pendant pas mal de temps la prog sur ARM, c'est un autre monde par rapport aux microcontrolleurs type PIC et AVR.

 

[MaX-MoD]

J'ai soudé des 33Fjesaispluscombien en TQFP64 0.5mm d'écartement sur des adaptateurs trouvés sur eBay, ça se fait sans trop de pb. Il faut juste une bonne soudure avec un bon flux, la taille n'est pas critique. On soude pratiquement toutes les pattes ensembles puis on vient enlever le surplus avec le fer. C'est très rapide et ça fonctionne à 100%

Pour la comparaison ARM/PIC il faut prendre en compte le fait que les dsPIC aient un coeur DSP => une opération virgule fixe 16b = 1 cycle d'horloge (3 pour la division)

Sur les architectures qui n'ont pas de DSP ben il faut soit passer en entier ou travailler en centaines de MHz.

Je connais pas trop les ARM, mais si ils ont aussi un DSP, à 60MHz ça peut le faire
quoique les 33F sont à 40MIPS
Histoire de goûts tout ça^^

PS: qu'en est-il des libs et exemples de codes sur ARM? Microchip fournit des piles USB, Ethernet, carte SD, graphisme etc. etc. gratos, c'est plutôt bien ça

Ah, et y'a un autre sujet du type commencé par Otatiaro
interpcnc-en-mieux-ca-vous-dirait-t1523.html


Max

 

[Otatiaro]

Ah, et y'a un autre sujet du type commencé par Otatiaro
interpcnc-en-mieux-ca-vous-dirait-t1523.html

Coucou

 

[coredump]

Pour la comparaison ARM/PIC il faut prendre en compte le fait que les dsPIC aient un coeur DSP => une opération virgule fixe 16b = 1 cycle d'horloge (3 pour la division)

Max

Je suis d'accord que le coeur dsp est un avantage en terme de vitesse de traitement si on ne fait que ca, mais la je parle surtout de vitesse de developement.
L'architecture ARM est tres orthogonale, a l'opposé des pic (Edit: on dirait que c'est plus le cas des PIC24 qui sont mieux). C'est vraiment un plus quand on programme en C. En plus c'est quand meme du 32bit natif, avec de la ram et de la flash en quantité. Certe on ne l'utilisera pas quand on a besoin d'une tache simple.

Dans l'exemple que cite arnaud2, il faut lire un fichier gcode sur une MMC/SD (donc format FAT), parser le fichier pour creer l'interpolation, et enfin ensuite commander les moteurs pas a pas. Je suis meme pas sur qu'un ARM suffise pour ca (ou alors un gros).

Edit: n'oublions pas que les outils ARM/AVR sont pratiquement tous gratuit (GCC, OpenOCD, JTAG) et multiplatforme (vu que je suis sous linux c'est primordial).

 

[MaX-MoD]

okay, je regarderais ça un de ces 4, quant j'aurais le temps (= peut être l'été 2009? )

C'est vrai que c'est chiant d'être obligé de passer par Wine pour utiliser MPLAB
Du coup je garde une partition dows rien que pour ça pratiquement

A+
max

 

[arnaud2]

existe t'il des cours online sur la programmation des arm en francais?
quand j'etai encore a l'ecole on avais un vieux tour cnc (ceux ou on enregistrait le gcode sur des mini casettes)
ben le microcontroleur c'etait un 8052AH qui gerait tout
je pense quand meme qu'un dspic est capable de mieux

 

[armaris]

Pour l'ARM, je plussois, j'ai tendance à délaisser le PIC pour les nouveaux projets.

Tu devrais pouvoir faire quand même de l'interpolation (linéaire, circulaire et hélicoïdale) avec un PIC, il faut travailler en entier, seule la fréquence max sera limitée.

Je te mets un lien vers quelques algorithmes élémentaires, attention le fichier fait 27Mo.
Ils sont tirés du livre "Synthèse d'images : algorithmes élémentaires" de G. Hégron chez Dunod informatique, il date de 1985 mais les algos n'ont pas changés.

 

[Otatiaro]

Salut,

Depuis le temps que j'y pense, j'ai retrouvé l'algo auquel je pensais quand je voulais me faire une carte d'interpolation ...

Ca s'appel l'algorithme de Bresenham, c'est tout con, mais didiou que c'est puissant (en gros, on ne travaille qu'en entier, pas de division, et ca, c'est bon ).

++

PS : Au cas ou ... http://fr.wikipedia.org/wiki/Algorithme ... _Bresenham

[EDIT] En plus ca fait aussi de l'interpolation circulaire, elliptique, sinusoidale, etc ... y'a bon non ?

 

[MaX-MoD]

Yup, je connais, j'avais commencé (ébauché^^) avec Nicolas Morel un interpolateur (moi à base de dsPIC, lui à base d'ARM).
je ne me rappelle plus vraiment de la vitesse mais le dsPIC était plus rapide que l'ARM à 20% de fréquence pross en plus.
J'en avais retenu que c'était utilisable, mais je n'avais recueilli aucune donnée sur le traitement du fichier G, génération de pulses, etc.

 

[armaris]

@Otatiaro.

Tous les algos (Bresenham, ...) sont dans le fichier que j'ai mis en lien.

 

[arnaud2]

voila ca avance

l'algorithme d'interpolation linéaire est terminé et testé
pour le moment je ne vais pas mettre d'interpolation circulaire carla plupart des logiciels de fao peuvent converti les arc de cercle en vecteurs

la micro qui sera utilisé est un pic18f4685 car il a presque 100ko de memeoire programme et 4ko de ram

apres test la frquence maxi de sortie des pas est de 50khz tout en gerant les accelerations et la vitesse de depart avec la puce a 10mips (40mhz)

en final il y aura plusieurs mode de fonctionnement

-autonome : le fichier gcode sera dans une carte mmc (fat16) et
dera lu et interpolé

-rs232 : chaque ligne de code est envoyé par port serie puis executé
a la fin du mouvement le pic renvoie l'info comme quoi tout
est fait et que le pc peut envoyé la ligne suivante

-manuel : deplacement de chaque axe en continu ou d'une mesure
genre 0.01 0.1 1 ou 10mm

pour visualiser tout un ecran lcd 128*64 piloté par spi

peut etre par la suite (soyons fou) un ecran 240 *128 avec affichage graphique des trajectoires des axes

pour le moment la partie interpolation est faite

voici le code (en basic)Voir la pièce jointe code.zip

 

[MaX-MoD]

Tiens, justemen ce WE je m'ennuyais et j'avais commencé à intégrer Bresenham sur mon PIC32 (80MHz )
Je vais regarder ton code, et voir si on peut facilement le porter pour PIC32.

Si tu m'y autorise, bien sûr

Avec la puissance des PIC32, j'avais rapidement évalué un max à 200KHz-1MHz, USB, RS232, CAN ou ethernet

Par contre, il faut un buffer de vecteurs, sinon la vitesse d'avance risque d'être très faible dans les courbes...

 

[arnaud2]

le code que j ai mis tu peut en faire ce que tu veux sinon je l'aurais pas mis en ligne

mon code c'est l'algorithme de Bresenham main legerment modifié pour travailler uniquement en entier c'est pour ca que pour calculer le ratio y/x et x/z je multiplie par 1000 et apres j'additionne 1000 dans l'integration
sinon le reste c'est tres simple

il suffit de determiner l'axe maitre puis faire 2 interpolation en meme temps

mais bon le plus chiant c'est de faire tout les menu de parametrage et de controle

pour ce qui est de mettre un buffer de vecteurs je pense pas que c'est nessecaire d'apres les données de mikroelektronica la lecture d'une ligne de fichier sur une carte mmc prend 5ms + dans mon programme l'interpretation du gcode prend a peu pres autant ce qui fait une pause de 1/100eme de seconde entre chaque ligne de code ce qui est negligeable

pour l'instant le programme fait 14ko de memoire dans le pic mais tout les menus et les immages pour l'ecran lcd graphique risquene de prendre pas mal de place aussi