Recherche programmeur PC et autres talents!
- fred_c
- Dept: 80
- Collec Perso: 11 flips
- Rech/Achete: 0 flip
- Messages : 4657
- Enregistré le : 01/10/2002
- Niveau : Confirmé
- Pro / revendeur : non
- Localisation : proche d'Amiens
Papo06 je suis d'accord avec toi sur plusieurs points :
Concernant la portabilité du C, oui si on utilise le même compilateur (gcc) le code sous Windows et sous Linux sera très proche en effet. Comme tu le dis, en supposant que la partie matérielle soit identique et que les options de compilation soient équivalentes.
Oui, programmer en JAVA demande quelques connaissances notamment si on souhaite s'appuyer sur les extensions temps réel.
En effet la notion de temps réel n'est pas lié à un langage mais au système informatique associé son application. Un système informatique est l'association d'une partie matérielle et d'une partie logicielle, cette dernière est le Système d'Exploitation (ou Moniteur ou Exécutif) et les programmes à exécuter.
La où je ne te rejoins pas c'est sur la notion d'ordonnancement qui casse le temps réel. Il est tout à fait possible de faire du multitâche (ou multithread) est de rester déterministe. Il faut alors avoir défini les contraintes temporelles et s'être assuré quelles soient toutes respectées.
Le fait de travailler sous Windows de façon classique, avec l'ordonnanceur (scheduler) va rendre le système totalement non déterministe et de ce fait rendre le fonctionnement quelque peu aléatoire.
Je pense qu'il est impossible de se passer de "windows" pour "vpinmame" ? Dans ce cas je suis convaincu qu'il serait impossible de gérer un plateau de flipper en direct.
Je pense donc que la solution de Romain est la bonne, le PC est là pour faire tourner l'application et les entrées/sorties sont contrôlées par déport (via USB) sur des cartes avec des microcontrôleurs.
Concernant la portabilité du C, oui si on utilise le même compilateur (gcc) le code sous Windows et sous Linux sera très proche en effet. Comme tu le dis, en supposant que la partie matérielle soit identique et que les options de compilation soient équivalentes.
Oui, programmer en JAVA demande quelques connaissances notamment si on souhaite s'appuyer sur les extensions temps réel.
En effet la notion de temps réel n'est pas lié à un langage mais au système informatique associé son application. Un système informatique est l'association d'une partie matérielle et d'une partie logicielle, cette dernière est le Système d'Exploitation (ou Moniteur ou Exécutif) et les programmes à exécuter.
La où je ne te rejoins pas c'est sur la notion d'ordonnancement qui casse le temps réel. Il est tout à fait possible de faire du multitâche (ou multithread) est de rester déterministe. Il faut alors avoir défini les contraintes temporelles et s'être assuré quelles soient toutes respectées.
Le fait de travailler sous Windows de façon classique, avec l'ordonnanceur (scheduler) va rendre le système totalement non déterministe et de ce fait rendre le fonctionnement quelque peu aléatoire.
Je pense qu'il est impossible de se passer de "windows" pour "vpinmame" ? Dans ce cas je suis convaincu qu'il serait impossible de gérer un plateau de flipper en direct.
Je pense donc que la solution de Romain est la bonne, le PC est là pour faire tourner l'application et les entrées/sorties sont contrôlées par déport (via USB) sur des cartes avec des microcontrôleurs.
- romain
- Collec Perso: 11 flips
- Rech/Achete: 0 flip
- Messages : 2048
- Enregistré le : 01/10/2002
- Niveau : Expert
- Pro / revendeur : non
Les fonctions de communication bas niveau que j'écris se chargeront de la communication entre le PC et la carte pour rendre cet aspect transparent à celui qui voudra programmer.
un exemple : un appel à activerbobine(2) activera le bobine N°2 point.
Ces fonctions existeront donc en librairies (.dll sous windows, .so sous linux par exemple) et pourront donc être intégrées dans n'importe quel langage par la suite...
Il se trouve que pour bosser en bas niveau, il n'y a rien de tel que l'efficacité du C et la rapidité d'un langage compilé et déterministe.
Le tout est de faire un .h pour windows et un .h pour linux concernant les appels aux fonctions propres à chaque système (port com etc...) et d'en changer lors de la compilation de la source sur l'un ou l'autre des environnements.
Le microcontrôleur se charge d'alléger considérablement la charge du PC pour des tâches simples et répétitives : balayage de la matrice des lampes, scrutation des contacts etc...
De plus, en cas de problème du côté PC (plantage, latence, non réponse) des systèmes de sécurité peuvent être mis en place (contrairement à une interface directe comme PinMame-HW) pour la protection du matériel (ex: désactivation des bobines).
Pour l'instant, aucune partie de code de commande du flipper ne sera déporté dans le microcontrôleur, tout sera géré par le PC; le micro sera simplement esclave du PC.
bon flip
un exemple : un appel à activerbobine(2) activera le bobine N°2 point.
Ces fonctions existeront donc en librairies (.dll sous windows, .so sous linux par exemple) et pourront donc être intégrées dans n'importe quel langage par la suite...
Il se trouve que pour bosser en bas niveau, il n'y a rien de tel que l'efficacité du C et la rapidité d'un langage compilé et déterministe.
Le tout est de faire un .h pour windows et un .h pour linux concernant les appels aux fonctions propres à chaque système (port com etc...) et d'en changer lors de la compilation de la source sur l'un ou l'autre des environnements.
Le microcontrôleur se charge d'alléger considérablement la charge du PC pour des tâches simples et répétitives : balayage de la matrice des lampes, scrutation des contacts etc...
De plus, en cas de problème du côté PC (plantage, latence, non réponse) des systèmes de sécurité peuvent être mis en place (contrairement à une interface directe comme PinMame-HW) pour la protection du matériel (ex: désactivation des bobines).
Pour l'instant, aucune partie de code de commande du flipper ne sera déporté dans le microcontrôleur, tout sera géré par le PC; le micro sera simplement esclave du PC.
bon flip
Addams - T2 - Fathom - Special Force - Robocop - OxO - EATPM - Silverball Mania - TZ - BK2K - Totem
ex : RFM - Judge Dredd - RoadShow - NBA - ToM - WoZ
ex : RFM - Judge Dredd - RoadShow - NBA - ToM - WoZ
-
- Dept: 000
- Rech/Achete: 0 flip
- Messages : 24
- Enregistré le : 09/12/2005
- Pas vu depuis plus de 10 ans
- Niveau : Débutant
- Pro / revendeur : non
- Localisation : Saint Quentin en Yvelines
Hmm,
Donc tu as déjà certaines fonctions, ca c'est bien. Tu nous fournirais une liste pour voir ?
Le PC gère les choses à faire suivant les retours qu'il a (genre j'allume telle lampe si on déclenche telle bobine). Que doit pouvoir gérer le PC comme "objets" ?
Je distingue déjà les lampes, les sons, et le matériel. Dans le matériel, il y a les bobines (le truc rond sur lequel la bille rebondit ? j'y connais pas grand chose en flipper, je suis plutôt MAS désolé ), quoi d'autre ?
Donc tu as déjà certaines fonctions, ca c'est bien. Tu nous fournirais une liste pour voir ?
Le PC gère les choses à faire suivant les retours qu'il a (genre j'allume telle lampe si on déclenche telle bobine). Que doit pouvoir gérer le PC comme "objets" ?
Je distingue déjà les lampes, les sons, et le matériel. Dans le matériel, il y a les bobines (le truc rond sur lequel la bille rebondit ? j'y connais pas grand chose en flipper, je suis plutôt MAS désolé ), quoi d'autre ?
Mimi
- Papo06
- Dept: 06
- Collec Perso: 1 flip
- Rech/Achete: 0 flip
- Messages : 4905
- Enregistré le : 30/03/2005
- Pas vu depuis 2 mois
- Niveau : Confirmé
- Pro / revendeur : non
- Localisation : Mougins
On est d'accord c'est ce que j'ai mal dit: il faut un noyau avec extensions temps réel, par exemple un noyau qui dispose d'un schéduler qui alloue un temps parfaitement connu à chaque tâche, et non pas le noyau linux ou windows par défaut alloue un temps qui dépend de tout un tas de paramètres et qui en plus change sans cesse (calcul du Nice dynamique).fred_c a écrit : La où je ne te rejoins pas c'est sur la notion d'ordonnancement qui casse le temps réel. Il est tout à fait possible de faire du multitâche (ou multithread) est de rester déterministe. Il faut alors avoir défini les contraintes temporelles et s'être assuré quelles soient toutes respectées.
Sous windows il y a d'origine le mode 'realtime' (qui est simplement une priorité maxi) qui bypass totalement le scheduler, comme ça on est pas emmerdés, une fois une tâche lancée dans ce mode, le système ne reprend jamais la main, sauf si on fait de l'attente passive avec des wait, sleep, ou tout autres appel système qui rend la main au scheduler, il faut faire un prog 100% actif.
Il faut juste faire gaffe à permettre de sortir facilement du programme parce que ça bloque tout, on ne peut même plus éteindre l'ordi avec le bouton en facade :)
Pascal
- romain
- Collec Perso: 11 flips
- Rech/Achete: 0 flip
- Messages : 2048
- Enregistré le : 01/10/2002
- Niveau : Expert
- Pro / revendeur : non
Salut,
pour ceux connaissant le fonctionnement de Visual Pinball, que pensez-vous de commander un vrai flipper avec le même style d'algorithme ?? (du VBS si je ne m'abuse...)
L'avantage c'est qu'il est "assez" simple, possède un niveau d'abstraction élevé (contrairement au C) et le code des tables virtuelles déjà existantes aurait juste besoin d'être réadapté si la table était créée réellement...
Vos avis ? un IDE compatible ?
Concernant le temps réel, je ne pense pas que ce soit une priorité absolue : si un PC fait tourner cette application, je doute que la personne joue à un jeu vidéo en même temps...
Cependant il faut définir un délai de réponse maximal (j'ai entendu parler de 10ms sur les Pinball 2000 ?), et déjà faire des essais pour voir ce que ça donne...
De mon côté, avec des leds sur les sorties du microcontrôleur, elles s'allument un schouilla avant les points lumineux dans la matrice du VPinMAME sur l'écran du PC !! une interface graphique ça semble bien plus lourd à gérer que d'envoyer 2 malheureux octets sur une liaison sérielle
Mimi-> non je n'ai pas encore de fonctions, mais c'est la vision que j'ai aujourd'hui du programme final... rien n'étant définitif pour l'instant !
pour ceux connaissant le fonctionnement de Visual Pinball, que pensez-vous de commander un vrai flipper avec le même style d'algorithme ?? (du VBS si je ne m'abuse...)
L'avantage c'est qu'il est "assez" simple, possède un niveau d'abstraction élevé (contrairement au C) et le code des tables virtuelles déjà existantes aurait juste besoin d'être réadapté si la table était créée réellement...
Vos avis ? un IDE compatible ?
Concernant le temps réel, je ne pense pas que ce soit une priorité absolue : si un PC fait tourner cette application, je doute que la personne joue à un jeu vidéo en même temps...
Cependant il faut définir un délai de réponse maximal (j'ai entendu parler de 10ms sur les Pinball 2000 ?), et déjà faire des essais pour voir ce que ça donne...
De mon côté, avec des leds sur les sorties du microcontrôleur, elles s'allument un schouilla avant les points lumineux dans la matrice du VPinMAME sur l'écran du PC !! une interface graphique ça semble bien plus lourd à gérer que d'envoyer 2 malheureux octets sur une liaison sérielle
Mimi-> non je n'ai pas encore de fonctions, mais c'est la vision que j'ai aujourd'hui du programme final... rien n'étant définitif pour l'instant !
Addams - T2 - Fathom - Special Force - Robocop - OxO - EATPM - Silverball Mania - TZ - BK2K - Totem
ex : RFM - Judge Dredd - RoadShow - NBA - ToM - WoZ
ex : RFM - Judge Dredd - RoadShow - NBA - ToM - WoZ
- alain91
- Dept: 000
- Rech/Achete: 1 flip
- Messages : 257
- Enregistré le : 19/07/2004
- Niveau : Débutant
- Pro / revendeur : non
- Localisation : ballancourt
vitesse
Bonjour à tous,
Les bumpers ne sont pas gérés de manière autonome ? C'est à dire que le bumper si il est activé, se débrouille tout seul pour descendre et renvoyer la balle ?..
Et seulement après, 'tranquillement' envoyer l'info au cpu ?
Si ce n'est pas ça, c'est un peu dommage non ?.
Les bumpers ne sont pas gérés de manière autonome ? C'est à dire que le bumper si il est activé, se débrouille tout seul pour descendre et renvoyer la balle ?..
Et seulement après, 'tranquillement' envoyer l'info au cpu ?
Si ce n'est pas ça, c'est un peu dommage non ?.
- Papo06
- Dept: 06
- Collec Perso: 1 flip
- Rech/Achete: 0 flip
- Messages : 4905
- Enregistré le : 30/03/2005
- Pas vu depuis 2 mois
- Niveau : Confirmé
- Pro / revendeur : non
- Localisation : Mougins
Non tous les flips récents activent la bobine du bumper via un switch faible puissance, ça permet de supprimer l'alimentation de la bobine au bout de 1 ou 2 secondes si la bille ou la coupelle est 'coincée', dans le cas contraire ben ça fait comme dans les mécas et les premiers électroniques: ça fume
Pascal
Pascal