On me propose un travail pour écrire du C intégré sur des micro-contrôleurs. Au début, j'aurais pensé que l'intégration de la programmation est trop basse dans la pile logicielle pour moi, mais j'y pense peut-être mal.
Normalement, je n'aurais pas eu l'occasion d'écrire du code intégré, car je ne me considère pas comme un ingénieur électricien. Est-ce une mauvaise hypothèse? Suis-je capable d'écrire des logiciels intéressants et utiles pour les systèmes embarqués, ou vais-je me vanter de tomber trop bas sur la pile de logiciels?
Je suis allé à l'école en informatique et j'ai beaucoup aimé écrire un compilateur, réfléchir aux algorithmes concurrents, concevoir des structures de données et développer des cadres. Cependant, je suis actuellement employé en tant que développeur Web, ce qui ne crie pas les choses intéressantes que je viens de décrire. (Je traite actuellement des questions telles que: "cette case à cocher doit avoir 4 pixels à gauche" et "cette date est mal formatée".)
J'apprécie la contribution de chacun. Je sais que je dois prendre la décision moi-même. Je voudrais juste quelques éclaircissements sur ce que signifie être un programmeur embarqué, et si cela correspond à ce que je trouve intéressant.
la source
La réponse de @ tcrosley est excellente. Vous n'avez pas besoin d'être un ingénieur électricien, mais connaître les bases peut vous aider.
Je ne pense pas que vous ayez à craindre d'être "trop bas sur la pile de logiciels". En tant qu'ingénieur intégré, j'ai dû résoudre de nombreux problèmes très intéressants. Vous mentionnez une liste de tâches qui vous ont plu:
Algorithmes simultanés - Le traitement des interruptions de niveau matériel asynchrones présente autant de défis intéressants que l'utilisation d'un modèle de thread de système d'exploitation.
Conception de structures de données - Vérifier. Conception compacte et accès efficace.
Développer des frameworks - Check. Sur des systèmes simples, vous pouvez concevoir un mini-système d'exploitation.
Écrire un compilateur - peut-être pas, mais vous pouvez vous retrouver à faire une optimisation de code de bas niveau similaire à l'étape de génération d'assemblage d'un compilateur.
Je choisirais de travailler sur des systèmes embarqués plutôt que de coder des interfaces utilisateur tous les jours. Vous n'oublierez jamais la première fois que vous regardez une machine commencer à se déplacer comme vous l'avez programmée. C'est beaucoup plus satisfaisant que de pousser des pixels.
la source
En tant que programmeur intégré, mon travail consiste à faire fonctionner du matériel personnalisé. En règle générale, j'ai développé un ensemble de logiciels sur une carte de développement, ou une version antérieure de matériel. Lorsque le nouveau tableau entre en jeu, mon travail consiste à installer mon logiciel sur le tableau et à démontrer que tout fonctionne.
Comme il y a presque toujours un problème, les compétences de débogage sont essentielles. Si le périphérique externe ne fonctionne pas, s'agit-il d'une mauvaise puce, d'une mauvaise connexion à la puce, d'un code de bug ou d'une utilisation incorrecte du périphérique intégré? Le seul moyen de le savoir est de procéder à un débogage étendu. Cela signifie être à l'aise avec les oscilloscopes, les analyseurs de réseau, les analyseurs logiques et les débogueurs de cible. Le processus de débogage devient presque scientifique. Je développe une hypothèse, conçois une expérience pour fournir des preuves pour ou contre mon hypothèse et teste.
Lors de l'évaluation de stagiaires ou de nouveaux ingénieurs intégrés, cette compétence est la plus critique. Tous les logiciels ont des problèmes, mais une fois que vous commencez à vous connecter au monde physique, la variété de ces problèmes augmente de manière exponentielle. L’essence de mon travail est de résoudre la longue série de problèmes entre concept et réalité.
la source
D'après mon expérience, on obtient de meilleurs résultats en abordant le développement de logiciels de systèmes intégrés avec un chapeau de "développeur de logiciels" plutôt qu'un chapeau "d'ingénieur en électronique". (les pratiques telles que TDD et CI sont moins courantes en ingénierie matérielle)
D'autre part, je pense que l'expérience de développer pour un système embarqué en fait un meilleur; développeur de logiciels plus complet.
la source
J'étais dans une situation similaire il y a environ 8 ans. À ce moment-là, j'avais 7 ans de développement logiciel dans des environnements d'applications et de serveurs. Ma seule expérience dans le traitement de bas niveau de matériel auparavant était l'écriture d'assembleur Z80 à l'adolescence sur un spectre ZX.
C'était certainement un défi. J'ai trouvé le traitement des jeux de puces dans l'assembleur très agréable et j'ai certainement beaucoup appris sur le matériel. Une partie importante de mon rôle consistait à tester le matériel à l'aide d'un logiciel. Apprendre à gérer la programmation et à reconnaître que le bogue de votre logiciel est en réalité un bogue du matériel. En fait, parfois, il faut un peu de travail de la part des personnes travaillant avec les logiciels et le matériel informatique pour déterminer si un bogue concerne un matériel ou un logiciel.
Un aspect que je n'ai pas réussi à livrer était le travail de pilote de périphérique. Je n'ai jamais vraiment compris cela, ce qui est une chose pour laquelle moi-même et ce chef d'entreprise n'a jamais compris pourquoi. C'est devenu un fait accepté.
Il est essentiel de se familiariser avec un occiloscope et un ion de soudure. en se rappelant que lorsqu'un gars au matériel dit le nombre 26, il signifie TOUJOURS que 0x26 est utile. Se rendre compte que les ingénieurs en matériel trouvent très frustrant de gérer un logiciel, mais ensuite, un projet matériel qui ne fait pas appel à un logiciel s'appelle un câble.
Je suis resté dans ce rôle pendant 4 ans et je ne suis parti que parce que j'étais braconné pour une opportunité vraiment fantastique.
la source
Comme tout, cela nécessite une approche équilibrée. J'aime travailler avec des systèmes embarqués dans mon travail quotidien. Ils me rendent meilleur en génie électrique. L'informatique physique et l'automatisation sont très excitantes. D'autre part, la création d'applications Web et le bricolage avec le cloud computing sont géniaux.
Si vous le faites bien, le côté logiciel cherchera des moyens de faire les choses plus intelligemment et mieux. Le côté matériel de vous gardera conscient des ressources et super efficace.
la source
Je ne suis pas ingénieur électricien, pourtant, j'ai développé un petit nombre de logiciels embarqués. Le plus gros problème que j'ai constaté est que j'ai une formation beaucoup plus élémentaire en mathématiques et que je ne sais pas comment décomposer facilement une série complexe d'algorithmes mathématiques avancés en code sans beaucoup d'aide.
Pour toutes les tâches pour lesquelles j'ai eu besoin de jouer avec la signalisation, de lire les valeurs des entrées, de soumettre les données aux sorties, etc., je l'ai trouvée peu différente conceptuellement de ce que je fais au quotidien. développeur de logiciels à l'ancienne. Le logiciel d'écriture est vraiment ce qu'il est. C'est lorsque vous avez besoin d'aller au-delà du logiciel actuel que les choses se gâtent parce que je n'ai pas les connaissances nécessaires pour manipuler le matériel directement. Cela se produit généralement lorsque vous essayez de déboguer ou de tester du code. Si vous avez une très bonne chaîne d'outils, vous avez peut-être intégré un environnement de débogage et de simulation pour alléger le problème, mais même avec tout cela pour vous aider, vous devez parfois revenir à l'essentiel et tester votre code. une sorte d'analyseur, et la réalité est que la plupart des plates-formes intégrées ne
De ce point de vue, je ne pense pas que le fait d'être ingénieur électricien soit essentiel à la programmation intégrée si les tâches sont simples et si les exigences spécifiques au matériel sont minimes. Au-delà de cela, je pense qu’être un EE faciliterait beaucoup la vie lorsque je travaille dans un environnement intégré, en particulier lorsque la vraie science est nécessaire pour déterminer où sont les problèmes.
la source
Je n'ai pas fait de programmation embarquée au niveau métier, mais mon baccalauréat portait principalement sur les systèmes embarqués, pour lesquels j'ai quelques années d'expérience réelle. Nous avons utilisé C sur Atmel AVR et touché quelques puces Texas Instruments avec VHDL, et quelques notions théoriques sur ARM.
Dans ce que nous avions, il s’agissait d’environ 50 à 60% de programmation (C), 20% de planification / conception (UML) et le reste était constitué d’électronique physique (soudure, mesure, câblage, fabrication de câbles, etc.). Je conviens également que c'était très intéressant et amusant à faire, et j'aimerais vraiment avoir une carrière dans les systèmes embarqués. Hélas, avec un très petit marché de systèmes embarqués, je devais avoir recours au vieux Java EE.
Mais je m'égare; Je dirais que les pourcentages mentionnés ci-dessus sont assez proches des emplois du monde réel, car nos enseignants ont leurs propres entreprises et ont également mentionné qu'ils essaieraient de le rendre aussi réaliste que possible. Nous avons même eu des virements aléatoires de 180 degrés dans les exigences du milieu du projet, heh heh.
Quant à la pile. En connaissant la programmation intégrée, vous aurez de grandes chances de créer vos propres produits matériels que vous auriez pu fabriquer dans de véritables usines en Asie, puis de les assembler dans vos locaux (chez vous ou dans votre propre entreprise). C'est très intéressant! Vous pouvez également créer de nombreux gadgets utiles à la maison, tels que des lumières contrôlées par les mouvements, une minuterie pour une machine à café pour préparer automatiquement votre joe du matin, etc. Des choses passionnantes en effet!
la source