[Projet PIC] Programmation d'un siège de simulateur de vol !

[invitef900c612]

Bonjour à toutes et tous,

Je viens de commencer un projet d'étude. Comme le nom de ce post l'indique il s'agit cette fois-ci d'un simulateur de vol.
Mon travail est plutôt simple à expliquer.

Mais commençons par le commencement.
Le simulateur existe. Une bonne chose de faite !
Le logiciel de vol existe(semblable dans le principe à Fly Simulator de Micro$oft !).

Mon travail consiste à commander différents moteur qui reproduirons, dans un premier temps, les inclinaisons de l'appareil.
Très simple donc, si le pilote tire sur le manche, le nez de l'appareil se lève etc etc...



Pour être plus technique à présent, je travaille avec un PIC16F877A (rassurez-vous ce n'est pas moi qui l'est choisi, on me l'a imposé... car je suis sûr de pouvoir en trouver un plus "adapté" à l'application... un 16F877, quel gachis ^^).
Et le principe est simple: lorsque le logiciel réagit aux commandes du pilote, il récupère les informations des angles.
On ne peut faire plus simple.

Ensuite il les envois par un port série RS232 vers mon pic qui traite ce signal et agit sur les moteurs...
Vous voyez, rien de bien compliqué !!




Seulement j'avoue être un peu rouillé niveau PIC et du coup je patoge en début de projet !!!
J'ai donc tout de suite pensé à vous !!

L'informaticien me demande de lui donner les informations concernant les trames qu'il doit m'envoyer.
C'est à dire que c'est moi qui lui dit de m'envoyer X octets codés de telle ou telle manière...

Bon jusque là ca peut aller pour moi, j'espere aussi pour vous.


Là où je bloque c'est pour la vitesse de transmission. Le cycle de transmission devrais-je dire!

En effet je sais que j'ai un quartz de 20MHz et que je recois(depuis mon PIC) des trames qui ressemblent à ceci:
code tangage / octet poids fort / octet poids faible / code roulis / octet poids fort / octet poids faible /

Le code tangage et roulis étant deux chiffres permettant de différencier les informations qui m'arrivent. Simplement!



Mais ce que je ne sais pas dire c'est la période à laquelle l'informaticien, enfin le programme, doit m'envoyer les trames.
Le plus rapidement possible pour que le simulateur réagisse vite, mais pas trop rapidement pour ne pas écraser des données(et donc faire n'importe quoi !!!)

J'ai bien évidement consulté le datasheet du PIC16F877 section USART mais... j'arrive pas à tout saisir !!
Les histoires de synchrone, asynchrone, master, slave... je sais pas quoi choisir ni quoi faire !!!!
De plus je ne me rappel plus comment se servir des tableaux qui sont dans cette section!!!


Voilà, mon message touche à sa fin, j'espere avoir été assez clair!!
Et j'espere que quelqu'un pourra me sortir de là ^^
D'avance merci...
-----

[invite359f3846]

Tout d'abord tu dois choisir la façon dont le pic et le pc vont dialoguer. Je pense que ton choix se porte sur une liaison série RS232. En googlant, tu te rendras vite compte que différentes vitesses de connexion sont possibles. Dans les datasheets du 16F877A, tu pourras trouver sa vitesse maximum de transfert. Mettons que ce soit 115600 bauds (de tête...).
Cela veut dire que tu peux transmettres 115600 bits/secondes. Mais attention, le RS232 possède une en-tête, celle-ci consomme des bits et une fin. Donc n'oublie pas de les comptabiliser.
Source: http://www.commentcamarche.net/pc/serie.php3
La communication série se fait de façon asynchrone, cela signifie qu'aucun signal de synchronisation (appelé horloge) n'est nécessaire: les données peuvent être envoyées à intervalle de temps arbitraire. En contrepartie, le périphérique doit être capable de distinguer les caractères (un caractère a une longueur de 8 bits) parmi la suite de bits qui lui est envoyée.
C'est la raison pour laquelle dans ce type de transmission, chaque caractère est précédé d'un bit de début (appelé bit START) et d'un bit de fin (bit STOP). Ces bits de contrôle, nécessaires pour une transmission série, gaspillent 20% de la bande passante (pour 10 bits envoyés, 8 servent à coder le caractère, 2 servent à assurer la réception).

Bon voilà après ce n'est vraiment pas compliqué...

[invite359f3846]

En me relisant, j'ai oublié de dire qu'il faut également connaître la fréquence maximale de rafraîchissement de la "position" des moteurs... De là, cela ne sert p-e à rien d'avoir une connexion RS232 très rapide...

[RISC]

Bonjour La Praline,

Tu es relié a un PC donc tu dois utliser le mode asynchrone de l'USART pour communiquer. Voir le chapitre 10 de la documentation (sections 10.0 à 10.2) :
http://ww1.microchip.com/downloads/e...Doc/39582b.pdf

Tu peux trouver beaucoup d'informations (notes d'applications, examples,...) sur le PIC16F877A ici :
http://www.microchip.com/stellent/id...cName=en010242

Bonne chance

[A voir en vidéo sur Futura]

[invitef900c612]

Bonjour et merci de vos réponses,

Alors j'ai encore(et toujours :s ) quelques points de "flou" dirons nous dans mon avancement...

Tout d'abord Rodrigue, tu parle de "rafraichissement de positionnement des moteurs"... Qu'estce que tu entends exactement par là???
Ce sont des moteurs pas à pas... Et les moteurs pas à pas ont des plages de fréquence de travail certes, mais je ne pensais pas qu'on signal issu d'une RS232 pouvait dépasser en fréquence cette plage... Cela pourait être le cas ???

Et puis j'ai bel et bien "googler" comme un malade et la doc du 16F877A je l'épluche de fond en comble(enfin... je pensais^^) jusqu'à l'usure... enfin bref j'ai bien trouver les tableaux correspondant aux vitesses mais je n'arrive pas à l'exploiter !

Encore que, maintenant que vous m'avez donné des renseignemets ca pourrais se faire !



Risc, pourquoi dois-je(c'est le "DOIS" qui me choques^^) utiliser l'asynchrone ??... bon c'est vrai que j'ai pas d'horloge et tout et tout, et je comptais bien utiliser le mode asynchr. mais tu as l'air de dire ça pour une autre raison...
Sinon ta section 10.0 à 10.2 va me servir... je ne sais pas le pourquoi du comment mais je n'étais pas tombé dessus avec ma doc à moi !!!
Parce que malgré le fait que la datasheet correspond au PIC16F877A, il y en a plusieurs, et elles ne sont pas exactement pareil (PIC16F87XA, PIC16F877, etc, ...)...

Bon je potasse tout ça en attendant de vos nouvelles,
Encore merci beaucoup !!!

[invitef900c612]

Bonjour àt ous, c'est encore moi !!!

Vos conseils m'ont beaucoup aidé.
Mais il me reste toujours une zone d'ombre à résoudre !!!


Déjà j'ai fait un petit schéma fonctionnel de mon système histoire que tous le monde voit bien où je veux en venir et de quoi je parle !!
(soit dit en passant c'est une réalisation personnel sous Paint... appréciez la maitrise )

Bref donc comme on le constate sur ce schéma, j'ai des trames qui arrivent de mon pc, un pic qui les traites, puis qui les envois sur les moteurs...
Encore une fois ce n'est pas moi qui est choisis d'utiliser tant de pic, je sais qu'on aurait pu l'éviter mais... les profs sont les profs... donc j'applique comme un bon soldat "SIR YES SIR !!"


Je ne ferais pas un cours sur les PCF ou les L6208, je pense que vous connaissez...



Et ma question, on y vient, tout les combien de temps le pc peut/doit 'envoyer des trames(de six octets rappellons-le) ???
Y'a-t-il un moyen de le calculer?(si oui lequel)

(pas que j'ai peur que mon PIC ne suive pas mais il faudrait que je justifie ca à mon prof... alors... )



D'avance merci...
Cordialement

[invitef900c612]

pardon à tous, j'ai (encore!!) oublié de joindre le fichier !!!

[RISC]

Risc, pourquoi dois-je(c'est le "DOIS" qui me choques^^) utiliser l'asynchrone ??... bon c'est vrai que j'ai pas d'horloge et tout et tout, et je comptais bien utiliser le mode asynchr. mais tu as l'air de dire ça pour une autre raison...
Sinon ta section 10.0 à 10.2 va me servir... je ne sais pas le pourquoi du comment mais je n'étais pas tombé dessus avec ma doc à moi !!!
Parce que malgré le fait que la datasheet correspond au PIC16F877A, il y en a plusieurs, et elles ne sont pas exactement pareil (PIC16F87XA, PIC16F877, etc, ...)...
!!!

Bonjour,

Tout d'abord quelques points au niveau références des ciruicts :

1/ chaque symbole est important dans une référence : le PIC16F877 n'est pas pareil que le PIC16F877A (les différences peuvent être mineures mais il faut toujours vérifier). Donc, dans ton cas, tu dois vérifier quels circuits tu as et utiliser la doc adéquate. Le PIC16F877A est plus récent et recommandé pour les nouveaux développements.

2/ La documentation est révisée régulièrement chez un constructeur. Donc la meilleure façon d'avoir la dernière documentation est de la télécharger SUR LE SITE du constructeur.
Chez Microchip, tu peux savoir si tu as le dernier document en vérifiant la date de la documentation et la lettre à la fin de la référence. Exemple, pour le PIC16F877, Microchip a fait une documentation commune au PIC16F876 ET PIC16F877. Elle s'appelle donc PIC16F87X (X=6 ou X=7 ;=). La dernière version est le document : "30292c.pdf" que tu peux télécharger ici :
PIC16F87X

3/ Concernant le choix de la liaison asynchrone (UART) la raison est simple : tous les PC (sauf les Laptops récents) possèdent une liaison série (appelée aussi RS232). C'est donc très facile de dialoguer avec le PC dans rien avoir à développer au niveau hardware côté PC.
Dans ton schéma il manque les drivers de niveau entre le PIC16F877 et le PC (tu peux utiliser des MAX232 ou autres circuits similairesqui transforment les transitions 0 -> 5V du micro en -12V à -3V et +3V à +12V.
Il y a plein de notes d'application qui montrent le schéma d'une liaison série sur un PIC.

[RISC]

N'ayant pu éditer mon message (limite des 5mn ) je continue ici :

Pour l'UART tu peux monter jusqu'à 1,25Mbits max mais je te conseille de rester en dessous de 115200 bauds car les PC (UARTS) savent rarement gérer des vitesses supérieures et quand ils le peuvent tu ne trouves pas de soft ...

Donc en faisant un petit calcul simple :
115200 bits/s max
Pour chaque data transférée, il faut :
1start bit + 8bits data + 1stop bit (min) donc 10 bits ce qui donne donc :
115200 / 10 = environ 1152 octets utiles /s ce qui suffira largement pour ton appli (tu pourras meme réduire la vitesse si tu le souhaites)

Ca s'éclaircit ?

a+

[invite359f3846]

Trois pics 16F877A pour commander deux moteurs pas-à-pas?

[invitef900c612]

Bonjour à tous, dis donc je suis matinal !!!


Mais je vais tacher d'être clair malgré tout !!


==> Alors Rodrigue, en effet je suis exactement du même avis que toi, trois PIC16F877A pour commander deux moteurs pas à pas et récupérer une liaison série ce n'est même plus du gachis, c'est carément à cause de ça que la planète se réchauffe (je les soupsonne même d'être à l'origine des guerre dans le monde c'est pour dire!!!!).

Mais comme je l'ai dis et re-dis, ce n'est pas moi le boulet, moi j'exécute les ordres... malgré le fait que je ne soit vraiment pas pour gaspiller du matos comme ça...
Mais bon c'est leur argent, qu'il en fassent ce qu'ils veulent après tout...$$$$$$$TCHI-TCHING$$$$$$




==> Sinon Risc, là j'avoue que tu vas vraiment m'être utile, ce n'est pas grand chose et à vrai dire je savais plus ou moins ça mais... quand on est dans le flou et qu'on sait pas comment s'en sortir, un peu de clarté est la bienvenue!!!
Donc en effet 1oo ooo baud ca devrait largement passer dans le sens où j'ai 6 octets à traiter tous les 1oo ms... soit 60 octets/sec... on est loin des 1XXX utiles ^^





Mais, comme toujours(y'a toujours des "mais" en électronique !!! vous avez remarquez !), cette réponse m'amène à me poser une autre question...

Maintenant que je sais que l'informaticien peut envoyer ces info aussi souvent qu'il le veut(me demandez pas pourquoi il veut pas en envoyé plus souvent que toute les 100ms... encore une fois je trouve ça débile mais bon... ), estce que, dans ma programmation, je dois définir une vitesse précise ou, grâce au IT, je récupère les trames quand elles arrivent sans me poser trop de question ???