Interfacage - Page 2

hibou>c koi ton école?

Pourquoi tu dit ça:
Sur le dernier post que j'ai posté peut être que je dis des bêtises.

Je suis en 1èreS et au Lycée Jean de Beauce à Chartres.

Arf! g rien dit de tel, je ne dirai surtout pas que tu as faux sur une lign ede code en C j'y connais que dalle

L'école ct pour savoir c tout

Chartres c'est peu connus donc dans un blaide paumé.
Par contre ma méthode ne marche pas pour un programme directement fait sur TI il faut déjà passé par l'ordi qui transforme le C en programme TI qui elle réalise les actions.

geogeo>sisi, c'est ca, il faut tokeniser comme tu dis, mais pas transformer ca en langage C, parcequ'on reviendrait au meme point
faut en faire un arbre

Kran>je suis a l'N7 Toulouse
mais je critique un peu vite car je suis en premiere année, et y'en a d'autre autour de moi qui rame en info, et moi je me la pete un peu car je sais deja faire

Moi a coté je suis un petit joueur.

geogeo> T'inkiete je connais Chartres, g fais pendant trois semaines le trjet PARIS CHARTES deux fois par jours . Gt en stage chez Guerlain.

A ça me fait plaisir car quand je dis Chartres on me regarde bizarrement. A savoir que Chartres c'est la capital du parfum.

Pour en revenir au sujet je pense que de traduire les equations logique puis à partir de là faire le graphcet avec l'interface... c'est plus facile certe long à réaliser mais plus facile pour faire le graphcet et surtout plus performant.

juste un piti truc .... c grafcet

GRAphe de Fonctionnement de Commande des Etapes et Transitions

Enfin bon c une pitite parenthèse comme ca

Je me disais bien que je faisait des fautes surtout que le grafcet on le zap donc u as résond de me corriger.

En plus je me gourre vala c corrigé

Vous parlez de PL7, tokeniser, mais a mon avis, le plus important c'est de réaliser l'interface machine TI, faire une lib qui permette de gerer les IO sur TI, et de faire un montage qui marche.
Programmer une automate(sauf peut-être pour une prog graphique en grafcet) après ca deviens de suite très facile

ce que l'on fait la c'est reflechir a l'aspect global du programme.
Car comment veux-tu faire un lib qui gere l'IO sans savoir ce que l'on va envoyer...
pour l'instant, c'est de le prog papier
sinon, pour la gestion IO, y'a une doc pas mal ou il y a qq ligne de code C deja faite... cf ti-rex.net

ben moi je vois une lib qui active/désactive la sortie demandée et qui récupère l'état des entrées: vous n'y couperez pas et quelle que soit l'implémentation derrière il vous faudra ca

kran: oui exactement, un automate!

tout le monde: tout d'abord, merci de vos reflexions nombreuses et variées sur l'approche du projet

oui, effectivement, il faudrait une lib, ce serai plus pratique, notement pour les tests.
faudrait juste des fonctions du style:
activate(0b00011010); //active les sorties 1, 3 et 4
desactivate(0b00100011); //desactive les sorties 0, 1 et 5
si vous en vois d'autres a faire...

mais on ne peut rien coder pour l'instant : il faut savoir quoi envoyer : tout dépend de toi y333 et ton interface

ce que dit hibou me plait bien

Je suis en première STL spé contrôle et régulation, en mlus j'ai un train électrique alors, moi ça me branche vraiment.
Bon courage

hibou> ben j'y reflechi ( suis sur le choix des composants donc a la recherche de doc technique mais j'ai pas baucoup de temps en ce moment)
mais je vous tient au courant des que possible de la maniere de transmettre

ayé j'ai une question quand a la partie software, est-il possible d'envoyer une série de 16 bits en boucle sans pour autant arrêter le fonctionnement du programme?

Oui c'est possible mais dans ce cas il faut une interruption qui gére ça et faut voir aussi quel doit être le nombre de données sur 16 bits que tu envoye en 1 secondes car une interruption a une fréquence limitée.

enfin si on utilise l'AI1, je pense pas que ca pose de problème vu qu'il s'agit d'une fréquence relativement élevée

Ou même l'INT5 qui peut aller encore plus loin que l'INT1 mais bon dans ce cas il faut une interruption.

Pour entrer les équation du graphhcet, pour quoi ne pas utiliser le même langage que sur P.B.15 (EANT, RCEP, EPOS) car ce serait très simple à interpréter.
Je peu au besoin envoyer un exemple de graphcet simple si ça peut vous intéresser...

Désoler, j'ai l'impression de poster toujours avec un temps de retard, je passe pas assez souvent à cause de Gran Tourismo

Vraimant pas bête comme idée, ce langague est très simple et facile a traduire par un programme.
I faudrait faire des programmes qui facent la conversion graphique -> PB15 et PB15 -> 68k. On pourrait peut être même faire un interpreteur PB15.
Ceci dit avant de commencer quoi que ce soit il faut au moins une spécif matérielle!

ca peut etre interessant, mais je connais pas...
qq'un peu me donner un lien sur une doc ou m'expliquer ?

Voyez plutot PL7, si je me rappelle bien, c'est plus puissant ... (peut-être de trop vieux souvenirs ..)

PL7 c'est un language a contact si mes souvenir sont bons, ce n,'est donc peut-être pas le top pour modéliser un graphcet a moins qu'il y ai des asctuces que je ne connais pas( j'ai juste fait quelques TP dessus il y a donc forcément des truc qui m'échappent) par contre sur un PB 15 il y a une série de commande simple(EANT EPOS RCEP ...) qui permettent d'implémenter un graphcet facilement. Ca serait un moyen d'obtenir rapidement quelquchose de fonctionel. ceci dit rien n'empeche d'implémanter les 2. Le seul truc qui est vraiment a mettre 100% en commun et verifier c'est le hard

Hibou, si tu veux je peux t'envoyer notre cours sur P.B15, il n'est pas tout à fait complet, mais je pourrai sans doute demander la suite au prof.
Je peu même t'envoyer notre sujet de bac blanc et le résultat que celà donne pour que tu te rende bien compte de la simplicité du truc. (Simple à écrire, mais encore plus simple à convertir.)

Les caractéristiques du circuit devraient êtres prêtes d'ici une semaine, du moins j'espere.