asservissement de vitesse par PIC

[invite81170861]

Bonjour,
je dois réaliser un asservissement de vitesse grâce à un pic! mais je ne sais pas exactement comment m'y prendre.
La mesure de la vitesse est faite grâce à une sonde à effet hall qui génère un signal carré: en mesurant la fréquence de ce signal on connait la vitesse! puis l'afficher sur un écran LCD ou afiicheur 7segments.
Et, je dois délivré une tension analogique d'alimentation 0-10V.
J'aurais voulu savoir si quelqu'un pouvait me rensigner un peu,
*sur le choix d'un PIC ( je ne mis connait pas du tout )
*est-ce possible de les programmer qu'en C?
*je pense qu'il faudrait que je réalise une sorte de fréquencemètre!?

De plus, "VDD" est-ce la tension maximale que le PIC peut fournir??

si quelqu'un a déjà réaliser quelque choses du même type ou sait à peu près comment si prendre

Meric d'avance,
cordialement
JIM
-----

[Toufinet]

Salut,

Pas trop compris la(les) question(s) ..
Dis nous-en un peu ( beaucou ) plus, si tu veux obtenir des réponses.

PS : oui, VDD est la tension max que peut "délivrer" un PIC ( cependant je me permet de te rappeler que c'est un composant numérique, donc en sortie d'un PIC, tu auras soit VDD , soit VSS ), et oui, on peut le programmer en C, moyennant certaines restrictions ( taille du code limitée ( pour les versions gratuites ), ou alors tu achètes le compilateur CCS ).

[invite1b38f1ee]

salut,

Va faire un tour sur le site des fribottes:
http://fribotte.free.fr/bdtech/index.html

et plus précisément PID sur PIC V1 et V2

[invite81170861]

en fait je dois délivré une tension analogique 0-10V! puis faire c'est le calcul de la vitesse, mais ça je pense pourvoir le faire en C! et en fonction de la consigne je dois réguler,aservir la commande en tension!

en gros ce que je voudrais d'abord savoir c'est comment faut il faire pour délivrer une tension analogique 0-10V

[A voir en vidéo sur Futura]

[invite1b38f1ee]

Avec un convertisseur numérique-analogique ou avec une PWM suivie d'un filtre passe bas. Tout dépend de ton cahier des charges.

[invite1b38f1ee]

Quelques liens pour la deuxieme solution:
http://fr.wikipedia.org/wiki/Modulation_de_largeur_d'impuls ion#Exemple_simple_:_un_conver tisseur_num.C3.A9rique-analogique
http://www.linuxfocus.org/Francais/N...ticle251.shtml

Si tu n'a que 5V et que tu en veux du 10 tu peux utiliser des montages type "doubleur de tension" mais tu n'auras pas beacoup d'intensité.

[invite81170861]

Merci ordepedro,
ça ne devraai pas poser de problème, lors de mes tests j'avais des courants inf à 1mA.
cependant un montage "doubleur de tension", c'est avec un ampli OP

[invite1b38f1ee]

Il existe des circuits intégré doubleur de tension, chez microchip par exemple:
http://www.microchip.com/ParamChartS...g=en&pageId=79

ou sinon à base de diode et de condensateurs:
http://licencer.free.fr/diodes.html (partie 6)

Je n'ai aucune idée de la quatité de la tension générée (bruit, stabilité) et cela pourrait être une très mauvaise surprise si tu t'en sert comme tension de référence pour un DAC.


Sinon peut être une autre solution:
un DAC 0/+5V puis une amplification avec un AO pour avoir 0/10V, à voir...

[invite81170861]

OK merci c'est cool ça! je vais voir ce que je peux faire!
et puis je n'ai besoin que d'une précision de 0.2V!!

Sinon (ça n'a rie à voir avec les derniers messages), mais avec mes recherches sur les PICs, j'ai lu mais pas tout le temps "oscilateur avec quartz 4MHz"??
Je voudrait savoir si pour gérer le Timer du PIC il faut lui rajouter un quartz!? je n'ai pas très bien saisi cela?

merci cordialement

[freepicbasic]

pour faire une sortie 0-10V
Il faut piloter un transistor en PWM qui commutera du 10 ou plutôt du 12V, afin de générer les tensions désirées, suivie d'un filtrage pour faire une tension continu .
cette tension devrait attaquer un transistor collecteur commun NPN pour faire un courant suffisant.

[freepicbasic]

Schéma rapide d'un PWM sur 12V.
Le 7805 alimente le pic
Le potentiomètre sur une entrée analogique permet de régler le PWM

modif;
une résistance entre C1 et R2 est nécessaire

[invite81170861]

waou c'est cool ça pat
j'vais travailler ce que tu m'a fournit
encore merci @ pluch

[invite1b38f1ee]

Je voudrait savoir si pour gérer le Timer du PIC il faut lui rajouter un quartz!? je n'ai pas très bien saisi cela?

Le timer du pic peut utiliser l'oscillateur du pic ou bien une entrée avec incrémentation du timer sur flanc montant ou descendant. Regarde le dans cours PART1 de bigonoff la partie sur les timers ça te paraîtra beaucoup plus clair.

[invite81170861]

d'accord ordepedro je vais télécharger cela!!
je ne captais pas parce que dans tous les exemples que je trouve il parle de quartz pour l'oscilateur et sur les docs techniques des PIC ils nous parlent d'oscilateurs internes

MERCI

[invite2562e666]

Bonjour,

A moins que tu n'aies déjà le matériel pour programmer le PIC et/ou qu'il te soit imposé, je te déconseille vivement le PIC12f de freepicbasic et aussi de lire le cours de bigonoff, qui se rapporte uniquement à l'assembleur :

Je te conseille un µC moderne et performant à 8 pattes (seul point commun avec le 12F de freepicbasic), le MC9S08QG4 :
- il a 4 Ko de Flash (1,7 K pour le 12F) et 256 octets de ram (contre 64 pour le 12F)
- Il fonctionne sur horloge interne à 8Mhz (contre 1mhz (=4Mhz/4) pour le 12F)
- Il est programmable en C (bigonoff le déconseille déjà pour les 16f, alors pour les 12F.. ). Un "device initialisation" se charge de configurer les périphériques et de générer le code C associé.

De plus, tu peux avoir un "ensemble de développement", pour moins de 10 € comprenant
- l'IDE/compilateur C gratuit CodeWarrior
- un µC MC9S08QG4
- un programmateur/debugger in-circuit (impossible sur un 12F sans investir 150€)
Tu pourras faire tes tests sans enlever le µC de sa "clé usb".

http://www.elektor.fr/default.aspx?tabid=28&art=63140

(le pdf est en téléchargement gratuit)

Alors voilà, si tu n'y es pas contraint, évite ces µC qui sont lents, viellots et difficiles à programmer/debugger.


thierry

[DavidDB]

Salut,

Au contraire de Thm, moi, je conseille l'utilisation des µC Microchip, la littérature tant en français qu'en anglais foisonne sur le net, des cours de grande qualité en français et gratuits sont largement disponibles sur net...

Ces µC, sont faciles à programmer et à debugger.
Quant à la vitesse d'exécution des instructions, il faut relativiser, 1MIPS est dans 99.99% des cas amplement suffisant pour l'utilisation en amateur...

Par contre, gérer un LCD avec un µC huit broches risque de très fortement brider le futur projet (à moins d'utiliser un registre à décalage pour la gestion du LCD; ce qui laisserait dans le meilleur des cas deux I/O de libre)
Concernant le langage C, la famille des 12F n'y est absolument pas adaptée, même si l'on trouve des compilo pour ce genre de composant sur le net...

David.

[invite81170861]

en fait, je me suis renseigner et pour mon appli en fonction de ce que j'ai besoin et je pense utiliser un 16f628 / 627 / 84.

[freepicbasic]

le MC9S08QG4 :

Un µc sur la base du 68705.
Avec code asm Mototola
J'ai survolé le datasheet rapidement pour me faire une idée.

- Il fonctionne sur horloge interne à 8Mhz (contre 1mhz (=4Mhz/4) pour le 12F)

il faut en moyenne 2 à 3 codes pour une instruction...
Donc diviser la freq par 3 ce qui donne 2.66Mips et non pas 8 comme sous entendu...
Pour la taile mémoire idem de 1 à 6 instruction disons 3 en moyenne , donc 4k / 3 .

De plus, tu peux avoir un "ensemble de développement", pour moins de 10 €

Le jdm fait soi meme coute que quelques euros , moins de 10.
MPLAB et toute la doc et AN (Applications Note) sont gratuites.
Les prix des chips sont très bas.
On en trouve facilement, contrairement aux Freescales...

Pour la protection Microchip est blindé, je ne sais pas pour ce µC à vérifier.
Un débogueur trop performant peu permettre aussi de pirater le soft , donc à voir.

Quant a la programmation je pense que l'assembleur est indispensable , au moins le connaitre.
Le petit Microchip n'a que 32 instructions et le MC9S08QG4 environ 300.
D'ou un temps d'aprentissage supérieur.

Le code est sans doute plus facile pas de bank et de page , enfin sur cette version.
Je n'ai pas trouvé la doc sur la programmation du chip afin de faire un programmateur comme celle de Microchip.

Dans l'ensemble au premier abord ,il semble, peut être, un peu mieux ,
reste à voir
les consommations mode sleep ,
oscillateur interne pas clair dans la doc...
les divers doc et la distribution.
Voir si un service "Web hot line" existe chez eux comme chez Microchip qui m'a très aimablement renseigner lors d'un problème qui me bloquait une série de pic16F876 I/so.

Quant aux points argumentés par DavidDB aucun doute Microchip est très fort.
Je ne suis pas sur qu'on trouve du code de ce µc sur ce site.
Contrairement au pic

[invite2562e666]

Bonjour, Freepic

Je ne vais pas relancer le débat, mais juste préciser deux choses dans ton intervention, avec lesquelles je ne suis pas d'accord :
1.

il faut en moyenne 2 à 3 codes pour une instruction...
Donc diviser la freq par 3 ce qui donne 2.66Mips et non pas 8 comme sous entendu...
Pour la taile mémoire idem de 1 à 6 instruction disons 3 en moyenne , donc 4k / 3 .

NON, (je supposes que tu as voulu dire cycles) car pour faire l'équivalent d'une instruction HC(S)08, il faut en moyenne 2 à 3 instructions PIC. Je pourrais te donner 50 exemples. les "i" HC08 sont donc totalement différents des "i" PIC. Regarde la note (d'ailleurs fortement tendancieuse et de mauvaise foi) microchip TB071.
Taille mémoire : idem : si en un ou 2 octet (= 1 instruction HC08), on fait ce que font 2 à 3 instructions PIC de 14 bits, le calcul est vite fait.

2.

Le jdm fait soi meme coute que quelques euros , moins de 10.
MPLAB et toute la doc et AN (Applications Note) sont gratuites.
Les prix des chips sont très bas.

L'USBSYDER08 n'est pas qu'un programmateur mais une interface BDM (Debugger temps réel in-circuit), donc l'équivalent d'un ICD2. Je crois que l'on est pas encore prêt de voir cela chez microchip.
Personellement, je mets TOUS mes programmes/montages au point avec le debug in-circuit, cela fait gagner un temps fou.
Pour le prix, compare un MC9S08QG8 à un PIC16F88 chez farnell par exemple...

Et pour finir, le plus petit QG4 se programme en C et se debugge avec un BDM. Cela se fait il sur un 12F ? Si oui, avec quoi, à quel prix ??

thierry

[freepicbasic]

(je supposes que tu as voulu dire cycles)

oui, bien sur!

car pour faire l'équivalente d'une instruction HC(S)08, il faut en moyenne 2 à 3 instructions PIC. Je pourrais te donner 50 exemples. les "i" HC08 sont donc totalement différents des "i" PIC. Regarde la note (d'ailleurs fortement tendancieuse et de mauvaise foi) microchip TB071.
Taille mémoire : idem : si en un ou 2 octet (= 1 instruction HC08), on fait ce que font 2 à 3 instructions PIC de 14 bits, le calcul est vite fait.

Cela dépend du code exécuté.
Le jeux d'instruction Motorola est plus adapté pour un µp généraliste.
Il est difficile de faire une comparaison.
D'une application à l'autre cela va tourner à l'avantage de l'un ou l'autre.

Et pour finir, le plus petit QG4 se programme en C et se débogue avec un BDM. Cela se fait il sur un 12F ? Si oui, avec quoi, à quel prix ??

J'ai réaliser le Monitor 6805 avec sa carte , avant d'utiliser les Microchip il y a bien 10 ans, je connais bien la différence, le déboguage sur Pic est infernal...
Cela à été fait pour la protection du Soft chez Microchip.
Et les applications du genre ModChip Pic12C508 à 1 euro pour bricoler les consoles ont fait sa réputation.

Le problème est en grande parti commercial ,
il a fallu 10 ans aux µC basé sur les µp Motorola pour réagir fasse aux µc Microchip.
Le retard va être dur à ratraper.

Pourquoi Windows est devenu incontournable alors que Unix est vraiment mieux...?

Car aux niveaux des utilisateurs comme moi , le temps investi sur un µc est important, le fait de passer sur un autre se fera que si des raisons vraiment justifiées apparaissent.
Le fait d'avoir quelques Microchip à écouler dans mes tiroirs , sont pour le moment une bonne raison de ne pas changer...
Mais la raison fondamentale du choix Microchip est sa doc irréprochable et unique , il y a aucun secret.
Le fait qu'une information manque (genre Microsoft qui nous noie sous des doc payantes et inutiles) donne l'impression du client "vache à lait"...
Le datasheet du MC9S... semble complet à première vue, mais je n'ai pas vu la partie prog du chip, peut être existe t elle (j'ai seulement survolé la doc...) , mais voila déjà une raison bloquante , idem pour Atmel toujours une bricole qui manque ,

et a qui s'adresser pour un renseignement?
Sachant que 80% si ce n'est pas tous les courriers mails sont sans réponses...

[invite2562e666]

Bonjour, Freepicbasic

Car aux niveaux des utilisateurs comme moi , le temps investi sur un µc est important, le fait de passer sur un autre se fera que si des raisons vraiment justifiées apparaissent.
Le fait d'avoir quelques Microchip à écouler dans mes tiroirs , sont pour le moment une bonne raison de ne pas changer...

Là, on est bien d'accord.

..., mais je n'ai pas vu la partie prog du chip, peut être existe t elle (j'ai seulement survolé la doc...) , mais voila déjà une raison bloquante , idem pour Atmel toujours une bricole qui manque ,

et a qui s'adresser pour un renseignement?
Sachant que 80% si ce n'est pas tous les courriers mails sont sans réponses...

On trouve bien sûr ce renseignement dans la datasheet.
Chapitre 17, développement support ,... :
17.3.2 : Communication détails
17.3.3 : BCD commands.
Tout y est.
Et si ils ne répondent pas aux mails (ce que je n'ai jamais eu l'occasion de tester), il y a toujours les forums freescale.

Par contre, si je regarde la datashhet du PIC16F88, chapitre 17 ; développement support, ce ne sont que des pubs pour :
MPLAB, MPASM, C17/C30 (dans la datasheet 16F88??), ICD2, ICE, PROMATE, PICDEM, ... Si l'on veut faire quelque chose de sérieux avec des chips "bon" marché", le "bon marché" se transforme vite en "bien cher".

Et quand à la "culture du secret", as-tu déjà lu le cours de Bigo se rapporant au debug 16F877, avec l'adresse "secrète" 0x2004 ??, c'est assez ridicule.

Donc, là, j'aurais aussi tendance à te retourner ton argument.

thierry

[freepicbasic]

Et quand à la "culture du secret", as-tu déjà lu le cours de Bigo se rapporant au debug 16F877, avec l'adresse "secrète" 0x2004 ??, c'est assez ridicule.

les 2 docs ont disparus du site Microchip effectivement

Elles sont Là LOL =>
> <http://ww1.microchip.com/downloads/en/DeviceDoc/39025f.pdf>
> <http://ww1.microchip.com/downloads/en/DeviceDoc/50032d.pdf>

L'adresse 0x2004 est l'adresse de retour du Break (PCL) rien de bien mystérieux.
Mais comme je le disais un déboggueur permet de pirater le firmware.
Le fait d'avoir l'adresse du break, le permet donc.
La lecture de tout les registre après chaque step , permet de reconsistuer le programme par déduction...
Mauvaise Nouvelle pour Microchip.

Je comprend leur réaction sur ce point , qui n'est pas l'attitude hyper lucrative de "Bill Gate".
Pas comparable.

A ce niveau (piratage de firmware) Freescale est surement guère mieux lotis.

Le mode ICD2 ne m'a jamais vraiment interessé , je le considère comme un bricolage , le fait de condamner 2 pins me semble inadmissible...

[DavidDB]

Salut,

Je ne suis pas vraiment certain que Freepicbasic soit complètement dans le vrai...

De mes souvenirs, le blocage de l'adresse 0x2004 venait "simplement" du fait que Microchip voulait éviter le clonage de l'ICD1 avec une sécurité supplémentaire vu que le firmware était protégé et ceci, à l'époque ou il était les seuls sur le marché à proposer ce type de débuggeur à prix attractif.
Depuis un certain temps déjà, tout cela a été abandonné, et il est facile d'obtenir des informations officielles sur le sujet.

Ensuite, concernant le piratage du firmware grâce à l'ICD, c'est oublier que pour obtenir le mode debugger sur un µC, il faut programmer les fuses et de ce fait la mémoire programme est corrompue et inexploitable...
De plus, l’adresse 0x2004 n’est active que si le mode débuggeur est actif.

Concernant la remarque de Thm sur la pub des outils de développements pour les µC Microchip, elle partiellement non fondée ; elle renvoie bien sur des « choses gratuites », mais cela demande simplement d'aller ouvrir d'autres documents relatifs aux outils proposés pour avoir toutes les infos nécessaires. Il est en effet absurde d'inclure sur chaque datasheet des milliers de pages qui sont 100% compatibles dans la gamme des µC.
Maintenant, il est aussi normal que Microchip tente de vendre ses propres produits du style PICDEM ou autre…

David.

[freepicbasic]

Ensuite, concernant le piratage du firmware grâce à l'ICD, c'est oublier que pour obtenir le mode debugger sur un µC, il faut programmer les fuses et de ce fait la mémoire programme est corrompue et inexploitable...

Certains fusibles sont programmables dans les 2 sens, et à ma connaissance seul les "code protect" efface le pic, donc on doit pouvoir mettre debug on ou off sans effacer le prog ( a vérifier).

[DavidDB]

Bien oui, si tu veux protéger ton firmware, il faut activer le code protect et donc même avec un ICD, il n'est plus possible d'obtenir le programme...

Si le code protect est désactivé, le firmware n'est pas protégé, et donc nul besoin d'un ICD pour le lire...

David.

[freepicbasic]

Bien oui, si tu veux protéger ton firmware, il faut activer le code protect et donc même avec un ICD, il n'est plus possible d'obtenir le programme...

ce n'est pas la question que je pose.
Si le mode debug peut être enclenché ?
Alors que le pic est en mode protection , donc programme illisible , alors la reconstitution du programme grace au point d'arrêt en mode step by step est possible.
Pas avec les outils Microchip évidemment ...

[DavidDB]

Non,

ce n'est évidemment pas possible, même si tu arrivais à passer en mode debug après une programmation du code protect, l'ICD(ou autre) renverait des données bidons et inexploitables (exactement le même principe qu'une tentative de lecture d'un PIC avec code protect activé)

David.

[invite03481543]

Le problème est en grande parti commercial ,
il a fallu 10 ans aux µC basé sur les µp Motorola pour réagir fasse aux µc Microchip.
Le retard va être dur à ratraper.

Pourquoi Windows est devenu incontournable alors que Unix est vraiment mieux...?

Je rejoins freepicbasic sur ce point, d'autant que Microchip a constaté que Freescale revenait fort et à largement diversifié et revisité ses structures internes comme le montre la famille PIC30F notamment.
Les rfPIC et dsPIC vont également dans ce sens ainsi que le rapprochement avec Zigbee très récemment.
Il est fréquent de constater que des développeurs ont basculé de Philips ou Motorola vers Microchip comme pour mon propre cas par exemple, à l'époque ou ces grandes firmes ne s'intéressait pas au "petits".
Maintenant il faut bien sur sortir les grosses rames de compétition pour reconvertir les gus comme moi, comme dit le dicton "chat échaudé craint l'eau froide".
Autre chose, je n'ai jamais été bloqué dans toute les applications que j'ai pu faire en Microchip depuis 10 ans maintenant, les docs sont claires, Microchip sait communiquer via mail ou téléphone, ce n'est pas le souvenir qu'il me reste de Motorola à l'époque.
Pour ma part je travaille avec ICD2 et je trouve que ça marche bien, pour 120 euros y a pas de quoi se réveiller en sueur.
@+

[freepicbasic]

ce n'est évidemment pas possible, même si tu arrivais à passer en mode debug après une programmation du code protect, l'ICD(ou autre) renverait des données bidons et inexploitables (exactement le même principe qu'une tentative de lecture d'un PIC avec code protect activé)

Si quelqu'un a un ICD2 pour Tester , ce serais interessant de savoir !
Cela me semble pas si évident que ça.

Les registres et le bus étant interne ,
il faut bien que le µc lise le prog,
donc à priori le debug devrait fonctionner même en mode protection,

Bien sur il pas certain que les outils Microchip sachent le faire.

[invite03481543]

Surement mais on va peut-être arrêter là le sujet, parcequ'on va entrer dans un domaine limite avec la charte.
Aucun µC ou système n'est inviolable, mais la finalité étant forcément de mauvaise intention, je ne souhaite pas que le forum devienne un lieu de rendez-vous pour ce genre de sujet.