9 réponses à ce sujet

[sebastienKent]

Permettez moi de me presenter, je m'appelle Seb, et j'aimerai vous poser une question "informatico-electronique" ( :D )



Je m'explique ayant des connaissances "un peu plus" developpé en informatique et qu'en electronique, je me demandai si quelqu'un pouvez repondre

a ma question liant informatique et electronique ( ...... j'ai decouvert les joies de l'electronique avec un bouquin pour les nuls et mes vieilles connaissances du lycée :p ) :



" est il possible d'imaginer la conception d'un circuit electronique de la meme facon que l'on imagine un programme en C++ (ou en Csharp ou n'importe quelle autre langage objet) ?"



Complement d'explications pour que tout le monde puisse comprendre ma question et peut-etre m'aider :



En programmation il existe un raisonnement (appliqué a un certain langage visualBasic, C++ et csharp par exemple) que l'on appelle Programmation Orienté Objet ( POO ). Le principe est simple et, je pense, pourrait etre resumé ainsi ( ) :



"On assemble des bouts de codes ( qui ont une specificité particuliere) pour pouvoir creer, au final, une application unique."

C'est un peu comme les transformers que l'on pouvait assembler et donc en faire un robot unique :D !



"Et est ce qu'en electronique, il est possible de cumuler et assembler plusieurs autres circuits pour n'en faire qu'un ?"

Petit exemple : j'ai un circuit qui allume une LED toutes les secondes ( 1 CI 555, 2 resistances, un condensateur et bien sur une LED).

J'enleve la led et relie le premier circuit au second qui lui, par exemple allume une Led constamment.

" Puis - je en conclure que la led du deuxieme circuit clignotera ?"

" Faut il simplement recalculer les valeurs du deuxieme circuit par rapport a la tension appliqué (et lié) par le premier circuit ?"



Desole si ma question fait tres "amateur", mais tel est mon niveau en electronique, je ne suis qu'un petit ^^

Merci par avance.

[Astondb8-RX]

Bonsoir

Tout aussi débutant que toi je vais tout de même tenter une réponse et un expert me corrigera si je me trompe. Cela me permettra de savoir si j'ai bien saisi comment tout cela se déroule.. (si vous le permettez bien sur).

Donc tous les codes que j'ai vus jusqu'à présent sont linéaires. A chaque fois, il était fait des go to N° de ligne ou go to Flag. Dans ces conditions pas d'orientation objet. (enfin, corrigez-moi bien sûr)

D'autre part, toujours si j'ai bien compris, il suffirait de prendre un contrôleur possédant suffisamment de ports pour envoyer ou recevoir des données dont tu as besoin pour faire tourner ton application. Tous les exemples que j'ai vus pour l'instant se n'utilisaient qu'un seul contrôleur. Mais cela ne veut pas dire qu'il est impossible qu'un contrôleur en pilote un ou plusieurs autres. Mais (et là encore je m'avance sans doute un peux), mais dans ce cas il devrait y avoir certaines contraintes, je pense qu'il faudrait travailler avec la même base de temps donc avec une horloge externe commune. Sauf bien sûr si un contrôleur sait en asservir un ou plusieurs autres.

Donc, je suppose que rien n’empêche de réserver sur un contrôleur un ou plusieurs ports configurés en sortie qui en piloteraient un ou plusieurs autres. De plus, j'imagine que sur des montages complexes, les ports d'un gros contrôleur pourraient s’avérer insuffisants. Mais dans ce cas, pourquoi ne pas utiliser un UC? Un Proc même d’ancienne génération saurait gérer des situations extrêmement complexes et disposerait d'un nombre de ports gigantesque..Je dis cela, mais ne saurais en aucun cas programmer un vieux 6800 ;-)
Voilà ce que je crois et ce que j'ai compris, mais ne prends surtout pas ces mots comme une réponse, mais plutôt comme une autre question complémentaire... Répondre à une question pas une autre question ce n'est pas répondre je sais... ;-)

Mais bon je m’arrête avant de raconter trop de bêtises. J’espère ne pas avoir pollué ton post avec que des âneries, mais comme c'est une question que je me posais aussi j'en ai profité pour partager ce que j'imaginais. Comme cela, un expert pourra à la fois te répondre de façon précise et me dire où sont mes erreurs. Donc j’espère que tu ne m'en voudras pas.

Cordialement
Yves

[miky-mike]

J'avoue que j'ai du mal a voir vraiment ta comparaison entre orienté objet (je dirais par après OO pour simplifier) et electronique mais :

Les microcontroleur peuvent être (et de plus en plus) programmé avec un code OO (par exemple en pseudo c++, je pense notamment a l'arduino) Bon évidement tu n'auras pas toute les spécifications de l'OO.

Si pour toi l'OO en électronique est le fait de pouvoir mettre plusieurs "brique" ensemble comme la compris Astondb8, alors la oui c'est possible.
En effet comme Astondb8 le dit, nous pouvons grâce a un microcontroleur "mère" contrôlé d'autre microcontoleurs fils (liaisons serie, SPI, I2C, ...).

Par contre est ce que c'est a cause que nous sommes au matin , mais je ne comprend pas bien ce que tu veux dire avec ton exemple de led.

[Luj]

Pour la programmation d'un micro-contrôleur, aucun problème on le fait effectivement en Programmation Orienté Objet : souvent par encapsulation de code dédié à une même fonction dans une classe, c'est ce qu'on fait dans les bibliothèques d'Arduino, avec des appels simples du type servo.read(); servo.write(); sur une instance de la classe Servo. Et on fait même (deux ou trois fois dans mes derniers projets) de l'héritage, par exemple sur le projet Mario Chuck j'ai fait une classe Articulation qui étendait la classe Servo pour lui ajouter une conversion d'angles et un rafraichissement régulier des vitesses.

Pour ce qui est de la conception de circuits électroniques, ça ne peut pas s'appeler "orienté objet" puisqu'il n'y a pas (entre autres) d'instanciation possible d'un circuit, c'est juste de la recopie de circuits existants. Si c'est le fait d'interconnecter des circuits entre eux et de les faire communiquer, on n'a pas attendu l'invention du concept d'objet pour faire un découpage en composants. Il faudrait d'ailleurs mieux oublier la notion d'objet : en POO, on peut faire beaucoup d'appels successifs (imbrications d'opérations qui s'appellent les unes les autres) qui vont poser des problèmes en électronique : longueur du circuit, parasites, fiabilité des connexions, vitesse d'envoi du signal.

[Astondb8-RX]

Bonjour,

Une question tout de même à propos de ce que j'avance sur la base de temps commune.
Est-ce obligatoire, préférable, sans importance ?

Merci

[sebastienKent]

Ok je vous remercie pour ces reponses rapides.

@ Modération:" met un titre en rapport a ton sujet la prochaine fois", je serai plus clair la prochaine fois ... desole ^^

@ miky-mike : L'exemple reprend l'idee qu'il me suffirait "simplement" de reprendre les calculs des differents elements electroniques, necessaires au bon fonctionnement de deux circuits differents assemblés ensemble ............ouf!!!!!

je retente, le circuit A crée un signal X a un endroit de sa structure.
Et ca tombe bien, parce que, comme par hasard, mon circuit B (qui produit un signal Y) a besoin d'un signal de type X pour fonctionner.
Apres 2 fils conducteurs, une resistance et quelques recalcules, marchera ou marchera pas ?

(ce n'est qu'un exemple, une question qui m'est apparue sans prevenir lol ^^)

@Astondb8 :"....Donc tous les codes que j'ai vus ...." Corrige moi si je me trompe, mais meme en poo le systeme d'execution des instructions reste lineaire, le principe est le succes de cet "methode" : la reutilisabilite du code pour d'autres applications qui n'ont, a priori, aucun rapport (?)

[webshinra]

miky-mike l'arduino, c'est pas du pseudo C++, c'est du vrais c++ ( avr-g++ ), on ne crée pas un langage en définissant une fonction :
{
setup();
while(1) loop;
}[/code]
( oui, j'avais envie de pinailler )

edit: sinon je suis assez d'accord, en électronique ou découpe en sous fonctions, qui pourrais rappeler des instances de classe, chaque circuit identique pourrais etre comparé a une instance d'une meme classe ( et donc l’état evolura donc selon le même schéma mais indépendamment de ses jumeaux ).
mais en fait, je pense que la façon de pensé en électronique serais plus celle de la programmation concurente.

edit bis:
en fait ta question est plutôt naive, globalement, il est evidement possible d'assemblé plusieurs circuits, et on découpe même chaque circuit en sous fonctions, cela permet, comme la POO, l'abstraction, c'est a dire, indépendamment de la structure interne, pouvoir piloté un syteme.
c'est un peu comme un servomoteur, ils on tous plus ou moin le même type de commande, non pas que se soit le plus adapté mais il vaut mieux une solution non optimal mais interopérable que l'inverse.


[miky-mike]

@webshinra : Je dis pseudo car nous n'utilisons pas tout les concepts du C++
Maintenant j'avais juste fait un test mais je ne code pas complétement avec

[zeqL]

Je "reprend" les deux points de vue abordés, avec d'abord celui de la POO dans l'électronique :

- Personnellement je trouve que la POO pour l'électronique c'est vraiment inutile, les classes peuvent parfois être utiles, mais vu que l'on programme la plupart du temps en C et que pour des projets d'électronique il n'y a pas trop d'envergure, passer au C++ et à un niveau d'abstraction supérieur est un peu inutile.
Néanmoins quand je parle d'électronique je fais une différence avec la programmation embarquée, cette dernière regroupant de la programmation "électronique" d'envergure (gros microcontroleurs (genre PIC24F, dsPIC) ainsi que les microprocesseurs et DSP. Dans ce cas vu la puissance disponible et aussi les projets important, utiliser une couche d'abstraction supplémentaire est compréhensible. Mais pour programmer des PIC12F ou même 18F, le C est largement suffisant.


Concernant l'OO électronique :

- C'est faisable en électronique analogique mais c'est assez prise de tête parce qu'il faut envisager tous les cas (niveaux de tension) pour les entrées et sorties et donc adapter la "boite noire" pour qu'elle est un fonctionnement "sûr" (qu'on ait pas de comportement aléatoire), notamment au moyen d'hysterésis.
Donc c'est assez chiant à faire mais faisable

- En numérique c'est ca va, on a que deux états donc cela simplifie plus, de plus grâce à des circuits programmables (CPLD, FPGA) on peut tester en vrai en programmant différentes "boites" et en prévoyant des liaisons externes entre elles par exemple, au moyen d'interrupteurs, de jumpers, de fils.
(ou dans le code)

[Luj]

[quote"zeqL"]vu que l'on programme la plupart du temps en C et que pour des projets d'électronique il n'y a pas trop d'envergure[/quote]

Quand on passe 40 heures sur un code C d'un robot mobile, ça devient un projet d'envergure. Car quand il faut le faire évoluer un an plus tard avec deux ou trois autres développeurs, on se retrouve bien stupide devant trente-six fonctions linéaires dont la moitié sont des copié/collé avec quelques modifications :)

[quote"zeqL"]la programmation embarquée, cette dernière regroupant de la programmation "électronique" d'envergure (gros microcontroleurs (genre PIC24F, dsPIC) ainsi que les microprocesseurs et DSP.[/quote]

Ah ok, on n'a pas les mêmes rillettes alors..

[quote"zeqL"]
- En numérique c'est ca va, on a que deux états donc cela simplifie plus, de plus grâce à des circuits programmables (CPLD, FPGA) on peut tester en vrai en programmant différentes "boites" et en prévoyant des liaisons externes entre elles par exemple, au moyen d'interrupteurs, de jumpers, de fils.
(ou dans le code) [/quote]

Euh, c'est de la programmation par composants, rien à voir avec l'OO.