Système multitâche pour microcontrôleur

[doul11]

Bonjour,

Dans le but de comprendre et d'utiliser un système multitâche pour µC, j'ai essayé de faire un système qui soit le plus simple, je ne pense pas que cela représente un grand intérêt d'un point de vue technique, mais d'un point de vue pédagogique oui, par la simplicité du système ça peut permettre de comprendre les bases, j'attends vos avis.

J'ai donc commencé par le système en gestion coopérative, puis je ferais le même système mais en gestion préemptive. Le système est très simple il se compose d'un ordonnanceur qui se charge d’exécuter les application les unes après les autres et d'un service de temporisation en temps réel 16 bits au pas de 1ms.


Partie 1 : gestion coopérative

Dans ce mode de gestion le système appelle les application et elles rendent "gentiment" la main au système qui appelle alors une autre application, les application sont organisés sous forme de grafcet : action 1 -> condition 1 -> action 2 -> ... l'application rends la main au système avant le test de condition et le système mémorise l'adresse de retour, par la suite quand la condition est fausse on retourne au système, si elle est vraie on passe a l'action suivante et ainsi de suite ... identiquement pour toutes les applications.

J’utilise le compilateur sdcc cible 8051, je ne pense pas que le code soit facilement portable : il y a beaucoup de chose propres a ce compilateur, mais l'idée de base est bien là et doit pouvoir se réécrire pour n'importe quel système pourvus qu'il puisse manipuler facilement les adresses de son code.


l’ordonnanceur : difficile de faire plus simple

//first call
app0Led();
app1Led();

//system
app_counter=0;

while(1)
	{
	callApp(app_counter);
	
	app_counter++;
	
	if(app_counter == APP_NUMBER){app_counter=0;}
	}

exemple d'une application : clinotement d'une led

#include "os_extern.h"
#include "app0_led.h"
#include "system.h"


void app0Led(void)
{
while(1)
	{
	//***************** step 1
	LED0=LED_ON;

	//***************** test 1
	app0_tempo=250;

	setReturnAdr(&app0_adr);
	if(app0_tempo > 0){return;}


	//***************** step 2
	LED0=LED_OFF;

	//***************** test 2
	app0_tempo=250;

	setReturnAdr(&app0_adr);
	if(app0_tempo > 0){return;}
	}
}

le coeur du système : manipulation des adresses

#include "os_extern.h"
#include "system.h"

void setReturnAdr(short *app_adr)
{
_asm

pop ar2 //app msb return adr
pop ar1 //app lbs return adr 


mov r0,dpl //save return adr in *app_adr
mov @r0,ar1
inc r0
mov @r0,ar2


__endasm;
}


void callApp(char app_number)
{
_asm

mov a,dpl //a=app_number
mov b,#2
mul ab
add a,#_app0_adr
mov r0,a //r0=app(app_number)_adr

mov ar1,@r0
push ar1
inc r0
mov ar1,@r0
push ar1 //stack adr to app(app_number)

__endasm;
}

en pièce jointe la totalité des fichier sources pour le système coopératif avec deux applications.

Alors qu'en pensez vous ? toutes les critiques sont la bien venue, j'aimerais m'améliorer en programmation.
-----

[PA5CAL]

Bonjour

Je pense que :
- tu pourrais écrire l'ensemble du code en C, de sorte que ton code soit totalement portable (le premier noyau multitâche que j'ai codé il y a 25 ans n'avait pas une seule ligne d'assembleur, ce qui m'a permis depuis lors de le réutiliser très souvent sur des plateformes très différentes),
- tu aurais pu poster ton sujet sur le forum informatique, car il n'a que très peu de rapport avec l'électronique.

[doul11]

- tu pourrais écrire l'ensemble du code en C, de sorte que ton code soit totalement portable (le premier noyau multitâche que j'ai codé il y a 25 ans n'avait pas une seule ligne d'assembleur, ce qui m'a permis depuis lors de le réutiliser très souvent sur des plateformes très différentes),

C'était mon idée de départ, mais j'ai pas su faire, c'est mon premier programme en C pour µC alors je ne suis pas a l'aise, comme je savais faire en assembleur, j'ai fait comme ça pour voir si ça marche, j'aimerais arriver a tout faire en C.

Tu peut m'en dire un peut plus sur ton système ? merci.

- tu aurais pu poster ton sujet sur le forum informatique, car il n'a que très peu de rapport avec l'électronique.

Dans ce cas un modérateur peut déplacer le fils dans un forum qui lui semble plus pertinent.

[PA5CAL]

Tu peut m'en dire un peut plus sur ton système ? merci.

Désolé, mais comme la destination de ce noyau est commerciale, je ne vais pas en poster les détails sur un forum public.

Réfléchis un peu à la manière de parvenir à ce que tu souhaites faire, et à la façon de l'utiliser simplement dans le code des applications que tu feras tourner dessus.

[A voir en vidéo sur Futura]

[doul11]

Désolé, mais comme la destination de ce noyau est commerciale, je ne vais pas en poster les détails sur un forum public.

Je comprends bien que tu ne puisse pas en parler.

Sinon pour tout faire en C je crois que je suis sur la bonne piste : il faut manipuler le pointeur de pile, du genre :

i=SP++; //pop i

--SP=i; //push i

comme ça je peut récupérer et changer les adresses.

[DAUDET78]

Tu as aussi des produits tout fait http://www.picos18.com/

[PA5CAL]

Sinon pour tout faire en C je crois que je suis sur la bonne piste : il faut manipuler le pointeur de pile, du genre :

i=SP++; //pop i

--SP=i; //push i

Ce n'est pas portable. Ce code ne fonctionne pas sur la majorité des compilateurs C standards.

[invite29971eb1]

Tu as aussi des produits tout fait http://www.picos18.com/

Sans parler de FreeRTOS, d'ecOS...ou de FemtOS (ce dernier sur AVR), tous gratuits

[doul11]

Tu as aussi des produits tout fait http://www.picos18.com/

ça ne m’intéresse pas, j'ai pas de contraintes au niveau des performances et j'aime bien faire les choses moi même, ça permet de bien comprendre comment ça fonctionne. Cette activité est pour moi un loisir, donc c'est pas grave si je "perds du temps en bricolages", si un jours j'ai besoin d'un système solide et performant là oui je ferais avec un système tout fait.

[inviteda3670f6]

Tu devrais jeter un coup d'oeil sur le site de FreeRTOS, c'est un os temps réel préemptif ou collaboratif open source et gratuit. Tu ne pourras pas faire un OS portable même s'il est écrit totalement en C. LE problème c'est que le scheduler a besoin de faire les sauvegardes de contexte, et les compilateurs génèrent eux même leur propre sauvegardes lors d'appels de fonction, ou d'interruptions. Même FreeRTOS utilise une partie dédiée à chaque processeur, et cette partie de code est écrite en assembleur sur toutes les plateformes, elle intègre en outre les spécificités de sauvegardes de registre pour les interrputions. Certains processeurs ne sauvegardent rien, pas même l'adresse de retour, ou le status register dans le cas des interruptions. Il est important d'en tenir compte pour la sauvegarde de contexte.
Les sources de FreeRTOS très light sont très instructives... ;o)
A plus

[PA5CAL]

Même FreeRTOS utilise une partie dédiée à chaque processeur, et cette partie de code est écrite en assembleur sur toutes les plateformes, elle intègre en outre les spécificités de sauvegardes de registre pour les interrputions.

S'il est exact que chaque configuration matérielle nécessite une partie dédiée à la sauvegarde des contextes (pour les interruptions matérielles ou logicielles, le multitâche et autres mécanismes de sécurisation), en revanche il n'est obligatoire que cette partie nécessite *toujours* une écriture en assembleur. Sur certaines plateformes, ces aspects sont directement pris en charge par le matériel et le compilateur, et même sur les autres l'inclusion des opcodes nécessaires ne passe pas non plus forcément par une écriture en assembleur, même si c'est souvent le cas.

Quoi qu'il en soit, tous ces mécanismes sous-jacents ne doivent absolument apparaître dans le code source du noyau que par une référence totalement neutre, faute de quoi ce dernier perd énormément de sa portabilité.

À moins bien sûr qu'on se moque totalement de faire tourner un jour le code sur une autre plateforme que celle visée, il est bon de garder à l'esprit que les systèmes automatisés programmables en C ne se limitent pas à celles héritées des anciennes architectures d'Intel ou de Motorola...

Le code C présenté ici est encore beaucoup trop imprégné du type de plateforme visé. (En comparaison, celui que j'avais réalisé en C a pu être implanté sur un multicœur et sur un réseau de portes sans aucune réécriture).

[PA5CAL]

... Notamment, je suis dérouté de voir apparaître de l'assembleur à l'intérieur d'une fonction C, avec les mécanismes de pile que cela implique. Ici, une partie sensée être au centre du fonctionnement du système créé est reléguée à la périphérie du programme.

D'une manière générale, l'organisation du code en C doit délimiter très distinctement les différentes parties fonctionnelles du programme, ainsi que les différentes parties liées à des choix techniques. En particulier il ne doit par faire apparaître les choix imposés par le matériel au milieu d'un fichier source ou d'une fonction destinés à être génériques. En prenant cette précaution, le code est réutilisable moyennant un minimum de réécriture lorsque les choix fonctionnels ou techniques évoluent... la programmation peut alors constituer un investissement plutôt qu'une dépense brute.

.

[inviteda3670f6]

S'il est exact que chaque configuration matérielle nécessite une partie dédiée à la sauvegarde des contextes (pour les interruptions matérielles ou logicielles, le multitâche et autres mécanismes de sécurisation), en revanche il n'est obligatoire que cette partie nécessite *toujours* une écriture en assembleur.

Ce n'est pas TOUJOURS le cas, mais très souvent, et encore à condition de bien connaître son cross compilateur. Si c'est facile pour les toolchains gcc, je ne miserai pas un kopec pour des cross compilateur fait par des tierces personnes, comme on en trouve sur la majorité de CPU low end. Le second problème majeur, c'est l'optimisation, qui va mettre un bazar monstrueux puisque le code est réordonnancé à la compilation, même avec gcc... Donc si on omet de supprimer toutes les options d'optim on risque de rapidement s'arracher les cheveux

Sur certaines plateformes, ces aspects sont directement pris en charge par le matériel et le compilateur, et même sur les autres l'inclusion des opcodes nécessaires ne passe pas non plus forcément par une écriture en assembleur, même si c'est souvent le cas.

L'avantage d'écrire en assembleur le code de sauvegarde, c'est qu'on est assuré qu'aucun compilateur ira modifier le code natif.

Quoi qu'il en soit, tous ces mécanismes sous-jacents ne doivent absolument apparaître dans le code source du noyau que par une référence totalement neutre, faute de quoi ce dernier perd énormément de sa portabilité.

C'est une évidence, c'est la raison pour laquelle j'encourageais à jeter un oeil sur les source de FreeRTOS qui propose un répertoire "portage" qui contient les 2 ou 3 fichiers à modifier pour assurer le portage sur un autre processeur.
A plus

[PA5CAL]

L'avantage d'écrire en assembleur le code de sauvegarde, c'est qu'on est assuré qu'aucun compilateur ira modifier le code natif.

Ça dépend de la chaîne de compilation utilisée. J'en connais qui sont capables, quand on le leur demande (ou quand on ne leur demande pas de ne pas le faire), d'optimiser le code assembleur intermédiaire (quand il existe) ou le code machine final produit par n'importe quel langage.

Il est certain que, comme tu le suggères, on doit nécessairement maîtriser ses outils pour qu'ils ne prennent pas l'initiative de modifier maladroitement le travail qu'on réalise.

Beaucoup plus que pour la programmation d'applicatifs (pour laquelle les options par défaut conviennent généralement), la programmation système passe par une connaissance préalable des mécanismes de génération du logiciel et des réglages y afférant. C'est comme ça qu'on s'aperçoit parfois que certaines chaînes de compilation sont carrément inadaptées au travail à réaliser.

[inviteda3670f6]

Je parle en connaissance de cause, j'ai des optimisations (voire des bugs) de compilo qui m'ont généré des m*rdes épouvantables...
Les frame pointeurs aussi dans leur genre apportent leur dose d'emmaverdavement.
A plus

[invitef2181dcc]

@PA5CAL et doul11 :

- D'une le sujet qu'à posté doul11 a tout à fait sa place dans ce forum électronique, étant donné que l'électronique comprend aujorud'hui une partie Hardware et une partie Software ainsi que le VHDL. Ce qu'à posté doul11 c'est du système embarqué, ce n'est pas de l'informatique haut niveau Java, C++ ou C# et autres langages orienté objet. Le pilotage de signaux électriques pour allumer une LED c'est de l'électronique. Ce qu'il a posté n'a surtout rien à voir avec l'informatique haut niveau.

- LED0 et LED1 ne sont pas portables, tu crois vraiment qu'on peut créer un OS multitâche pour n'importe quel microcontrôleur sans même modifier le nom des registres ? Impossible. Et comment reprendre une tâche qui a été interrompue si on n'accède pas au pointeur de pile ni n'écrit quelques ligne en assembleur, impossible ! Les RTOS et OS pour microcontrôleurs disponibles dans le commerce doivent en règle générale être recompilés pour s'adapter à l'architecture hardware du système.

- Enfin, pour doul11, mes encouragements, merci pour les informations que tu nous as apportés, je te conseille aussi de jeter un coup d'oeil sur les interruptions et les timers du 8051 ca pourra t'aider pour que ton système multitâche devienne réellement un micro OS multitâche.

++

[Jack]

Bienvenue Spyeye,
mais tu arrives un peu tard pour cette discussion il me semble.

De plus:

Ce qu'à posté doul11 c'est du système embarqué, ce n'est pas de l'informatique haut niveau Java, C++ ou C# et autres langages orienté objet

On peut faire du "haut niveau" en embarqué, en C++ également.
Et même en C# ou en java pour peu que le système fasse tourner la machine .net ou java qui va bien.

A+

[PA5CAL]

- D'une le sujet qu'à posté doul11 a tout à fait sa place dans ce forum électronique, étant donné que l'électronique comprend aujorud'hui une partie Hardware et une partie Software ainsi que le VHDL.

Tout d'abord, bravo pour avoir ressorti du placard une discussion qui date de près d'un an.


Ensuite, l'électronique, c'est une branche de la physique appliquée, qui repose sur l'étude et l'utilisation des propriétés de conductions des électrons libres.

Écrire le code d'un logiciel n'en fait pas partie. C'est de l'informatique, sans plus.

Et si l'informatique a aujourd'hui matériellement besoin d'un support électronique, par principe elle en ignore complètement l'existence et le fonctionnement pour s'appuyer sur des concepts purement mathématiques.


Le fait est que le sujet de doul11 ne concernait aucune question touchant de près ou de loin l'électronique, seulement des problèmes de programmation.

[invitef2181dcc]

@Jack :
Bonjour,
"On peut faire du "haut niveau" en embarqué, en C++ également."
Je sais , mais quand on fait du haut niveau (C#, Java) en systèmes embarqués on s'éloigne du hardware, c'est pour ca qu'on préfère employer des termes comme middleware, informatique industrielle (qui est un terme plus général), plutot que systèmes embarqués ou firmware. Car la couche applicative fait abstraction totale du hardware, c'est pour ca que j'ai dit que quand on fait du bas niveau on reste dans le domaine de l'électronique. Le Java et le C# par exemple font abstraction totale du hardware et nécessitent déjà la présence d'un OS (Windows CE pour le C# embarqué).

[invitef2181dcc]

Bonjour,

D'une part je n'était pas là il y a un an.

"Ensuite, l'électronique, c'est une branche de la physique appliquée, qui repose sur l'étude et l'utilisation des propriétés de conductions des électrons libres."

Je suis Ingénieur Electronique spécialisé en systèmes embarqué, et je peut t'assurer qu'à part les chercheurs et les physiciens, les électroniciens et ingénieur électronique font abstraction totale des propriétés et la physique de l'électron libre.
" l'étude et l'utilisation des propriétés de conductions des électrons libres." concerne plutôt la physique des états condensés (PEC) que l'électronique.

"Écrire le code d'un logiciel n'en fait pas partie. C'est de l'informatique, sans plus." Dans ce cas le VHDL tu le place où ? Où place tu l'électronique numérique qui est de la technique ? L'électronique comprend une partie analogique et une partie numérique, et firmware depuis l'apparitions de composants programmables. la partie firmware peut être comprise dans l'électronique numérique.

wikipédia :
"L'électronique est une branche de la physique appliquée, traitant entre autres de la mise en forme et de la gestion de signaux électriques, permettant par exemple de transmettre ou recevoir des informations."
Chose qui est absolument le cas pour le C embarqué sur 8051.
L'informatique haut niveau fait abstraction du hardware, ce qui n'est absolument pas le cas du firmware, où pour son codage il faut comprendre certaines architectures hardware numériques du composants.

"Et si l'informatique a aujourd'hui matériellement besoin d'un support électronique, par principe elle en ignore complètement l'existence et le fonctionnement pour s'appuyer sur des concepts purement mathématiques."
Pour l'informatique haut niveau certes, car il tourne déjà sur une interface graphique, mais certainement pas pour le C Embarqué il est IMPERATIF de connaître l'architecture hardware pour connaître quels composants piloter pour ne pas griller des composants etc...

Et si tu n'est pas convaincu tu n'a qu'à regarder les autres sujets de ce forum, rien que sur la première page j'ai recensé DIX sujets rein que sur les microcontrôleurs et les systèmes embarqués (des PIC pour la plupart d'entre eux).
D'autant plus que dans toutes les écoles d'informatique il n'existe pas de spécialité système embarqués. Cette spécialité, qui comprend la programmation en C sur microcontrôleur, est quasi uniquement présente dans les les écoles qui enseignent électronique.
Je suis moi même la preuve que les systèmes embarqués est une branche d'électronique, puisque je suis Ingénieur Electronique spécialisé en Systèmes Embarqués !!!!!

[Jack]

Le Java et le C# par exemple font abstraction totale du hardware et nécessitent déjà la présence d'un OS (Windows CE pour le C# embarqué).

Pas forcément. Microsoft propose 3 déclinaisons du framework .net, dont .net micro framework. Il existe des carte compatibles arduino qui font tourner ce framework, sans OS donc. Je fais mumuse avec, et c'est plutôt sympa pour bricoler.

Dans ce cas le VHDL tu le place où ?

VHDL relève clairement de l'électronique. Ce n'est qu'un langage de description qui a peu rapport avec l'info, en particulier si on ne s'intéresse qu'à ce qui est synthétisable.

Je suis moi même la preuve que les systèmes embarqués est une branche d'électronique, puisque je suis Ingénieur Electronique spécialisé en Systèmes Embarqués

Bof! Je ne pense pas que l'on puisse cloisonner comme ça les différentes disciplines techniques. L'embarqué est un domaine transversal, qui fait appel à des compétence électroniques ET informatiques.
Mais j'ai peur que l'on parte dans un débat infini, chacun des intervenants ayant un avis quelque peu différent en fonction de son expérience personnelle.

En tout cas, ravi de t'avoir parmi nous. Tes connaissances nous serons sûrement précieuses.

A+

[PA5CAL]

D'une part je n'était pas là il y a un an.

Tu n'étais pas non plus là il y a cinq ans. Vas-tu également ressortir des discussions de 2007 ?

Je suis Ingénieur Electronique spécialisé en systèmes embarqué, et je peut t'assurer qu'à part les chercheurs et les physiciens, les électroniciens et ingénieur électronique font abstraction totale des propriétés et la physique de l'électron libre.

Et moi je suis aussi ingénieur diplômé en électronique, et j'interviens également dans de nombreux autres domaines d'activité, notamment l'informatique.

Quand je fais de l'électronique, les grandeurs que je manipule ne sont les tensions, courants, puissances, fréquences, spectres etc. , bref tout ce qui caractérise plus ou moins précisément les phénomènes physiques qui reposent ou sont associés à la « conduction des électrons libres ». La simple circulation d'un courant dans un fil de cuivre en fait partie, et il n'est pas besoin de se restreindre à la PEC pour y toucher.

VHDL tu le place où ?

Il ne s'agit que d'un langage descriptif, qui a la même valeur que le dessin à l'encre de Chine pour les schémas électroniques, hormis le fait qu'il s'adresse à une machine. Écrire en VHDL ou faire du dessin, ce n'est pas faire de l'électronique, c'est seulement utiliser un moyen d'expression.

Où place tu l'électronique numérique qui est de la technique ?

L'électronique numérique, c'est de l'électronique pour les composants, et des techniques numériques, dérivées des mathématiques Booléennes, pour l'organisation.

Quand on fabrique et qu'on implante un circuit numérique sur un PCB, on fait de l'électronique. Quand on programme le firmware, c'est de l'informatique, pas de l'électronique.

L'architecture hardware traite de l'organisation de fonctions informatiques matérielles sans jamais entrer dans le détail de leur fonctionnement physique. C'est de l'informatique, pas de l'électronique.

Et si tu n'est pas convaincu tu n'a qu'à regarder les autres sujets de ce forum, rien que sur la première page j'ai recensé DIX sujets rein que sur les microcontrôleurs et les systèmes embarqués (des PIC pour la plupart d'entre eux).
D'autant plus que dans toutes les écoles d'informatique il n'existe pas de spécialité système embarqués. Cette spécialité, qui comprend la programmation en C sur microcontrôleur, est quasi uniquement présente dans les les écoles qui enseignent électronique.

Ce n'est pas parce que des disciplines sont associées qu'elles sont confondues, que ce soit à l'école (qui diversifient les enseignements) ou sur les forums (sur lesquels arrive n'importe quoi).

Je suis moi même la preuve que les systèmes embarqués est une branche d'électronique, puisque je suis Ingénieur Electronique spécialisé en Systèmes Embarqués !!!!!

Et moi je développe des systèmes embarqués depuis plus de vingt ans, et je n'ai jamais fait de confusion entre la partie électronique et la partie informatique. Les problèmes traités et les outils utilisés ne sont pas les mêmes.

[Jack]

Et moi je développe sur des systèmes embarqués depuis plus de vingt ans, et je n'ai jamais fait de confusion entre la partie électronique et la partie informatique. Les problèmes traités et les outils utilisés ne sont pas les mêmes.

Reconnais que la frontière est mince parfois, quand on programme au plus près du hardware. Par exemple lorsque tu configures le timer d'un µcontrôleur, on aura besoin d'un électronicien "numérique" ou d'un informaticien? Un peu des 2 je pense. Je m'interroge donc sur l'intérêt de vouloir à tout prix vouloir classer le technicien ou l'ingénieur dans un des deux domaines.

A+

[PA5CAL]

Je m'interroge donc sur l'intérêt de vouloir à tout prix vouloir classer le technicien ou l'ingénieur dans un des deux domaines.

En fait on ne le fait pas lorsque les deux domaines sont abordés. On qualifie d'électronicien celui qui développe le hardware et le software, et d'informaticien celui qui ne développe que le second.

Il n'en reste pas moins qu'on a bien affaire à deux domaines différents.

[Jack]

On qualifie d'électronicien celui qui développe le hardware et le software, et d'informaticien celui qui ne développe que le second.

C'est une définition d'électronicien, ça !
On pourrait transposer le débat entre l'électronique et l'électrotechnique. La création d'un variateur pour moteur asynchrone est-il un job d'électronicien ou d'électrotechnicien?
Voilà pourquoi je suis moins catégorique que toi. C'est plus un problème de compétence que d'étiquette.

A+

[PA5CAL]

C'est une définition d'électronicien, ça !

En fait je prends plutôt la casquette de l'informaticien pour dire ça.

L'informaticien part du principe que le matériel fait ce qu'on lui demande, ou qu'en des circonstances définies (transmissions notamment) il ne le fait pas et qu'une solution purement logicielle est attendue.

En tant qu'informaticien, lorsque j'écris « registre = 0; » je m'attends à retrouver 0 dans registre après l'exécution du code (hors multitheading).

En tant qu'électronicien, je dois faire en sorte que ça arrive dans les conditions physiques définies dans le cahier des charges.


Il m'est justement déjà arrivé d'avoir du code qui ne s'exécute pas comme convenu (en faisant « registre = 0; » je me retrouvais avec une valeur non nulle dans registre), et de m'apercevoir que le problème était purement matériel (verrouillage incorrect des bascules du registre de sortie à cause des conditions électriques extérieures sur un 68HC11). Les informaticiens qui travaillaient avec moi trouvaient ça inconcevable et ne savaient pas absolument pas quoi faire. Mais j'aurais été le dernier à leur jeter la pierre, parce que ce n'est absolument pas leur boulot de régler ces questions-là, ils ont d'autres choses à faire plus importantes dans d'autres domaines.

C'est plus un problème de compétence que d'étiquette.

Exact. Mais l'étiquette suggère aussi des compétences minimales.

On peut parfaitement profiter des compétences d'un technicien ou d'un ingénieur dans un domaine qu'il connaît bien parce qu'il est intimement lié à sa qualification, mais on ne lui pardonnera pas des difficultés pour exercer son cœur de métier.

Pour fabriquer une carte d'acquisition vidéo, il faut un électronicien. Pour y implanter un logiciel de reconnaissance de forme, il faut un informaticien. On peut tenter d'utiliser l'un ou l'autre pour faire les deux, mais alors il ne faut pas se plaindre si le projet n'aboutit pas.

[Jack]

Pour fabriquer une carte d'acquisition vidéo, il faut un électronicien. Pour y implanter un logiciel de reconnaissance de forme, il faut un informaticien. On peut tenter d'utiliser l'un ou l'autre pour faire les deux, mais alors il ne faut pas se plaindre si le projet n'aboutit pas.

Tout à fait d'accord. Je voulais juste faire comprendre que dans certains cas, en embarqué par exemple, la frontière était parfois ténue.

A+

[invitef2181dcc]

@PA5CAL, Un véritable informaticien n'écrit jamais dans des registre il ne se soucie gère du bas niveau, il utilise l'OS comme base de travail qui fait une abstraction du hardware. Un informaticien fait de la POO (programmation orienté objet) ce qui n'est pas le cas d'un ingénieur systèmes embarqué. Un ingénieur systèmes embarqués quand à lui doit se soucier du hardware d'autant plus qu'il a souvent à apporter des corrections au hardware.

si tu est ingénieur depuis 20 ans il s'avère que les définitions ont évolué depuis, l'informaticien d'il y a longtemps travaillait avec des OS rudimentaire et était amené à se soucier du hardware, ce qui n'est plus le cas aujourd'hui. Ce que fait l'informaticien aujourd'hui n'a absolument rien à voir avec le hardware, il s'occupe du haut niveau avec des interface graphique, communique à l'aide de drivers existants, et microsoft s'occupe de faire le reste avec la couche HAL (hardware abstraction layer), tout ce qu'il fait aujourd'hui c'est de la POO, des bases de données et du réseau !!! Donc pas de µC ni de DSP ni d'asm.

C'est électronicien qui saura faire communiquer un µC avec d'autre composants électroniques notamment des transistors, des leds. C'est un électronicien qui pourra faire du traitement de signal avec un µC ou un DSP, c'est aussi un électronicien qui saura utiliser le convertisseur analogique numérique d'un dsPIC16F et le configurer.

Ce travail n'a rien d'un travail d'informaticien (pur).

Quand au VHDL langage de description hardware certes mais ce n'est qu'un language plus bas niveau que l'assembleur, puisqu'il est compilable synthétisable dans un FPGA. Sur un FPGA tu peut monter un Coeur8051 écrit en VHDL, ce même coeur tu peut le programmer en assembleur, ou en C.

Quand au C ou l'asm quand tu écrit dans un registre tu ne fait qu'envoyer un train de bit (l'opcode correspondant à l'instruction) avec un autre train de bit représentant la donnée. De plus quand tu écrit dans un registre, il se peut qu'à la lecture tu obtiennent autre chose, car l'architecture hardware à modifié son contenu, ou parce que le registre X est en fait composé de deux buffer un en lecture et un autre en écriture. Il se peut que le registre en soit accessible qu'en lecture ou qu'en écriture, il se peut que le registre en question se vide dès qu'il est lu. Un tas de contraintes dues à l'architecture hardware du composant. Qqun qui programme un µC doit connaitre l'archtecture hardware de la carte pour savoir commander un muttiplexeur un transistor ou d'autres composants analogiques ou numérique.

Un tas de chose qui fait qu'un informaticien NE PEUT PAS programmer un µC !!!

[PA5CAL]

...

Un tas de chose qui fait qu'un informaticien NE PEUT PAS programmer un µC !!!

Il me semble que tu ferais bien de te renseigner sur les cours d'informatique prodigués aujourd'hui.

Tu sembles prendre les informaticiens pour des ânes, incapables de coder pour un µC. Pourtant l'exploitation des spécifications d'une architecture et la programmation en assembleur font aussi partie de leur formation.

Quand on doit développer un OS ou optimiser un logiciel pour une architecture matérielle particulière, c'est à pourtant eux qu'on fait appel, pas aux électroniciens.

Les problèmes de cache, de pipeline, d'interruptions, de modes d'arrondis, de branchements prédictifs, etc. ils s'y connaissent, c'est leur métier ! C'est du très bas niveau, mais ça reste toujours de l'informatique.


Le développement informatique ne se réduit pas à la POO, loin de là.

[PA5CAL]

... Par ailleurs, si je suis ingénieur depuis plus de vingt ans, ça ne veut pas dire que j'ai arrêté il y a vingt ans, mais au contraire que je m'informe et me forme et que je pratique activement depuis vingt ans, y compris jusqu'à aujourd'hui.

C'est justement mon expérience qui me permet d'appréhender ces sujets et d'en parler.