Bonjour,
Peut simuler facilement un signal PWM via le port serie ou parall�le d'un PC le tout avec borland c++?
Merci de votre aide....
Version imprimable
Bonjour,
Peut simuler facilement un signal PWM via le port serie ou parall�le d'un PC le tout avec borland c++?
Merci de votre aide....
Je suppose que tu demande si on peut faire un signal PWM avec le port RS232 ou //.
D�j�, pourrais tu en dire plus sur ton signal PWM?
Oui c ca exactement. Je veux pouvoir envoyer un PWM(frequence entre 10 et 500Hz) sur le port serie au pourcentage choisi dans un text ou combo peut importe. Merci de votre aide....
Bonjour
Oui, c'est simple � faire.Citation:
Envoy� par jeannot27
Tu calcul quelle est la p�riode de ton signal, pour conna�tre la dur�e de chaque �tat, et tu affecte cette valeur � ton timer. Sur chaque �v�nement OnTimer, tu change l��tat du signal de sortie.
Et si ton signal n�est pas un signal carr�, tu change la valeur de la property interval de ton timer a chaque fin de demi periode. (Haut,Bas)Code:
1
2
3
4
5
6
7 void __fastcall TForm1 :PWMTimerTimer(TObject* Sender) { static bool bPWM = false; bPWM = ! bPWM; }
Tu peux utiliser par exemple, le signal DTR comme bit de sortie. Il existe des composants gratuits pour piloter le port serie.
TComport:
http://petit.developpez.com/serie/cours_tcomport/
Async Pro
http://sourceforge.net/projects/tpapro/
Voila, bon courage
ALain
En fait je fais un champ ou l'utilisateur va donner le pourcentage du PWM, un bouton g�n�rer et voila....J'aimerais travailler avec un signal de periode 20ms.....est ce possible d'echantilloner a cette frequence via la pin RTS du port serie ?
Merci
mon code dans le Timer:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 void __fastcall TForm1::Timer1Timer(TObject *Sender) { if(high == true) { ComPort1->SetRTS(true); //Mise à +15V de RTS high = false; Timer1->Interval = StrToInt(Edit1->Text)* 0.2 ; } else { ComPort1->SetRTS(false); //Mise à -15V de RTS high = true; Timer1->Interval = 20 - StrToInt(Edit1->Text)*0.2; } }
Bonjour,
Une p�riode de 20ms sous windows, c'est chaud!.
M�me si tu peux th�oriquement obtenir cette p�riode, tu n'auras jamais une stabilit� suffisante pour g�n�rer un rapport cyclique constant.
Pour t'en convaincre :
Supposes que tu d�sires une pr�cision de 10% (je ne suis pas exigeant)
imaginons que ta sortie soit r�gl�e sur 10%, ton T_ON devrait avoir une dur�e de 2ms +/- 0,2ms. A ma connaissance, il est impossible d'obtenir cette pr�cision sous Windows.
Si tu travailles sur une application professionelle, je te conseille plut�t d'utiliser un petit automate programmable en liaison avec ton soft PC.
Tu trouveras facilement des mod�les tr�s bon march� int�grant une fct PWM. Il existe aussi des cartes PCI sp�cialis�es qui impl�mentent ce type de fonctionalit�.
Dans tous les cas, la pr�cision d'un TTimer ne suffit pas pour travailler correctement � une p�riode aussi basse.
Bruno
En faisant des essais, je suis arriv� a 200ms de periode pour avoir un PWM clair a 50% (donc en fait 100ms un changement d'etat toutes les 100ms...)
comment optimiser le code pour realiser le moins d'operations possible dans le timer... car c'est lui qui met le bordel non? si j'ai mon Timer regl� sur 100ms par ex, il faut que les operations contenus dans le timer mettent moins de 100ms...non? comment exterieuriser du code hors du timer?
Merci
Bonjour,
Il est vrai qu'un TTimer n'est pas forc�ment la bonne m�thode pour obtenir les meilleures performances en termes de r�solution et de pr�cision.
Il y a eu des posts r�cents � ce sujet ici.
Pour ma part, j'ai fait des essais avec les diff�rentes technos possibles (QueryPerformanceCounter, mdi...), mais le meilleur r�sultat que j'ai pu obtenir c'est par un simple thread et un bon dosage de GetTickCount et de Sleep dans la m�thode Execute du thread.
Mais ton probl�me de fond n'est pas ici. Il vient tout simplement du syst�me d'exploitation qui ne permet pas de descendre aussi bas en p�riode, tout au moins pour ton application qui exige :
- Une p�riode relativement stable.
- Un rapport cyclique TRES stable.
Ce qui est impossible � atteindre sous Windows avec T=20ms!
Salut !
En supposant que l'on puisse utiliser le MIDI, on devrait obtenir une bonne
pr�cision. Il suffit de fixer les param�tres du m�tronome en cons�quence.
L'astuce, si cela en est une, consisterait � utiliser une callback pour transmettre
les messages MIDI (ponctuels). Le cycle s'appuie sur un note_on suivit d'un note_off,
en boucle, dont les dur�es respectives r�glent la sym�trie du signal.
Le signal MIDI est transmis sur son propre port de sortie et de ce fait, on peut,
normalement, se servir de ce processus pour travailler simultan�ement sur l'un des
ports SERIE.
Par contre... c'est du genre "usine � gaz" !!!
A plus !
Le plus simple serait � mon avis de piloter un petit NE555 qui g�n�rerait le signal PWM, en fonction de la tension moyenne pr�sente sur une broche du port parall�le ou du port s�rie ou autre ( un condensateur en parral�le avec une r�sistance pour moyenner, reli� � un transistor sur le controle du NE 555 ).
De mani�re g�n�ral, si tu voix les mots "rapides", "pr�cis" et "PC" dans la m�me phrase, tu peux te faire du soucis ^^
En revanche, il existe un composant TIMER plus performant que le standard donn� par Borland ... je n'ai plus le nom en t�te, je vais essayer de le retrouver.
S'il ne manque pas bcp de pr�cision pour que ca marche, c'est peut-etre une solution.
[Edit] j'ai trouv� : http://www.ciemmesoft.com/componenti/categorieing.asp?ID=13&PAG=1&LANG=2&ORD=1&QTA=10
J'ai jamais test� par contre, mais d'apr�s les commantaires tu peux tapper dans le 0.1ms ( Ca me laisse perplexe quand m�me, ils se sont peut-etre plant� d'un z�ro mais c'est � essayer)
" This component provides timing accurate to 0.0001 seconds. The timer can trigger events at a stable speed"
Salut !
Ici il semble qu'il faille g�n�rer ce signal depuis un PC sur un port s�rie.
Si le sujet peut �tre d�clin� sous forme de r�alisations �lectroniques discr�tes ou
non, alors on a le choix quant aux circuits int�gr�s � utiliser mais on n'est plus
vraiment sur le bon forum !
D'ailleurs un simple 555... �a me laisse un peu perpl�xe compte tenu de la fr�quence
et de la sym�trie. La fr�quence d'un 555 n'est-elle pas li�e au temps de charge et de
d�charge.. donc... toute variation de sym�trie devrait se traduire in�vitablement par
une variation de fr�quence... et �a supposerait donc une usine � gaz hardware, pour la
pr�cision).
Autant prender un xr2206 ou un ic8038 ou directement un DCO ou un �C et dans ce cas pr�cis,
la liasion s�rie ne servirait plus qu'� transmettre la fr�quence et le rapport de sym�trie
� un dispositif dot�, lui, d'un ou plusieurs timers de pr�cision.
Mais l�, �a devient de la plomberie (et pour ceux qui le prendraient mal... mon fer � souder
n'est jamais tr�s loin !) !
Si l'objetcif est de g�n�rer un signal carr� asym�trique BF, dans ce cas on peut le faire
directement via la carte son ! La pr�cision est alors li�e � la fr�quence d'�chantillonnage.
Reste � savoir, ici, comment le signal est exploit� et quelle est l'importance de la pr�cision
dans le traitement en aval ! Tout comme le MIDI, l'AUDIO implique �galement une mise en oeuvre,
donc du d�veloppement !
A plus !
haaa, la carte son c'est pas b�te du tout comme id�e ... par contre faut regarder ce que ca rend au niveau fr�quence, parceque la carte coupe la BF mais je sais pas � combien ... 50 Hz ? ca fait du 20ms ... ouai ca doit passer.
Autre probl�me, la tension de commande, est-ce que la carte son d�livre qq chose de suffisent ?
S'il faut rajouter un Aop en comparateur derri�re, autant reprendre l'id�e du NE.
sinon ya des cartes qui �chantillonnent jusqu'� 96 kHz et m�me au-del� ( 44kHz pour les standards ).
Concernant le NE555, oui c'�tait pour le principe, mais si c'est pour commander un moteur ou un servomoteur, on fait des miracles avec ses petites bestioles, avec des composants stables en temp�ratures et une carte bien isol�e CEM pour les parasites.
Mais c'est vrai qu'on est vraiment vraiment limite. La solution exar est la meilleur je suis de ton avis aussi.
L'avantage c'est que c'est du low cost ^^, si on commence � mettre du �C l� dedans, le prix d�cole toute suite.
Mais j'y pense, j'avais pilot� 8 servomoteurs en PWM il y a quelques ann�es avec les 8 DATA du port parall�le ... c'�tait en Borland TurboC sous DOS mais je me rappel que j'avais des probl�mes de stabilit� du signal qui m'avait pouss� � couper l'alimentation des moteurs apr�s mise en position aproximative.
J'avais attribu� cela aux parasitage du PC ( ca rayonne pas mal ces bestioles ) mais maintenant qu'on en parle, � tout les coups c'�tait un probl�me de stabilit� en fr�quence du au timer qui �tait pas super synchro.
On a donc une fois de plus la preuve de la limitation du TIMER interne d'un PC.
Au plus j'y pense au plus je me dit que la carte son c'est pas b�te du tout.
Faut juste rajouter un comparateur derri�re pour r�hausser le signal peut-etre car la tension de commande doit �tre en 5 ou 10v je suppose ?
(je sais pas combien ca sort une carte son).
C'est plus simple que les autres solutions, par contre pour avoir un signal de 10 Hz de p�riode ... j'ai peur que ce soit trop coup� par le filtre de la carte son, tu en penses quoi ?