Является ли встроенное программирование ближе к электротехнике или разработке программного обеспечения? [закрыто]

Ко мне подошла работа по написанию встроенного C на микроконтроллерах. Сначала я подумал бы, что встраивание программирования слишком мало для программного стека, но, возможно, я ошибаюсь.

Обычно я бы упустил возможность написать встроенный код, поскольку я не считаю себя инженером-электриком. Это плохое предположение? Могу ли я написать интересное и полезное программное обеспечение для встраиваемых систем, или я пну себя за то, что слишком низко опустился на программный стек?

Я пошел в школу компьютерных наук, и мне очень понравилось писать компилятор, думать о параллельных алгоритмах, проектировать структуры данных и разрабатывать фреймворки. Однако в настоящее время я работаю веб-разработчиком, который не кричит о том, что я только что описал. (В настоящее время я имею дело с такими вопросами, как «этот флажок должен быть на 4 пикселя слева» и «эта дата отформатирована неправильно».)

Я ценю вклад каждого. Я знаю, что должен принять решение для себя, я просто хотел бы получить некоторые пояснения о том, что значит быть программистом на встраиваемых системах, и соответствует ли это тому, что я считаю интересным.

Если вы хотите хорошо работать со встроенными системами, то да, вам иногда нужно думать как EE. Обычно это происходит при написании кода для взаимодействия с различными периферийными устройствами (последовательными шинами, такими как UART, SPI, I2C или USB), 8- и 16-разрядными таймерами, тактовыми генераторами, а также АЦП и ЦАП. «Таблицы данных» для микроконтроллеров часто встречаются на сотнях страниц, поскольку они описывают каждый бит каждого регистра. Это помогает уметь читать схему, чтобы вы могли исследовать плату с помощью осциллографа или логического анализатора.

В других случаях это просто написание программного обеспечения. Но при жестких ограничениях: часто у вас не будет официальной ОС или другой инфраструктуры, и у вас может быть всего несколько КБ ОЗУ и, возможно, 64 КБ памяти программ. (Эти ограничения предполагают, что вы программируете на небольших 8- или 16-битных микросхемах; если вы работаете со встроенным Linux на 32-битном процессоре, у вас не будет таких же ограничений памяти, но вам все равно придется иметь дело с любыми пользовательскими периферийное оборудование, для которого ваш дистрибутив Linux не предоставляет драйверы.)

У меня есть опыт как в EE, так и в CS, поэтому мне нравятся обе стороны медали. Я также занимаюсь веб-программированием (в основном PHP) и настольными приложениями (C # и Delphi), но мне всегда больше всего нравилось работать над встроенными проектами.

Ответ @ tcrosley отличный. Вам не нужно быть инженером-электриком, но знание основ помогает.

Я не думаю, что вам нужно бояться быть «слишком низким в программном стеке». Мне пришлось решить много очень интересных задач в качестве инженера по встраиванию. Вы упоминаете список задач, которые вам понравились:

• Параллельные алгоритмы. Работа с асинхронными аппаратными прерываниями имеет столько же интересных проблем, сколько и использование модели потоков ОС.

• Проектирование структур данных - Проверка. Дизайн для компактности и эффективного доступа.

• Разработка фреймворков - Проверка. На голых системах вы можете создать мини-ОС.

• Написание компилятора - возможно, нет, но вы можете в конечном итоге выполнить низкоуровневую оптимизацию кода, аналогичную шагу генерации сборки компилятора.

Я бы выбрал работу над встроенными системами, а не программирование пользовательского интерфейса в любой день. Вы никогда не забудете, когда в первый раз увидите, как машина начинает двигаться так, как вы ее запрограммировали. Это намного приятнее, чем подталкивать пиксели.

Как программист по встраиванию, моя работа заключается в том, чтобы заставить работать нестандартное оборудование. Как правило, я разработал кучу программного обеспечения на плате разработчика или предыдущую версию аппаратного обеспечения. Когда приходит новая плата, моя задача - поставить на плату свое программное обеспечение и продемонстрировать, что все работает.

Поскольку почти всегда есть какая-то проблема, навыки отладки необходимы. Если внешняя периферия не работает, это плохая микросхема, плохое соединение с микросхемой, глючный код или неправильное использование встроенной периферии? Единственный способ сказать это с помощью обширной отладки. Это означает, что вы должны быть знакомы с осциллографами, сетевыми анализаторами, логическими анализаторами и целевыми отладчиками. Процесс отладки становится почти научным. Я разрабатываю гипотезу, планирую эксперимент, чтобы предоставить доказательства для или против моей гипотезы, и проверяю.

При оценке стажеров или новых инженеров по встраиванию этот навык является наиболее важным. У всех программ есть проблемы, но как только вы начинаете взаимодействовать с физическими мирами, разнообразие этих проблем увеличивается в геометрической прогрессии. Суть моей работы - решить длинный ряд проблем между концепцией и реальностью.

По моему опыту, можно достичь лучших результатов, приближаясь к разработке программного обеспечения для встроенных систем с помощью шляпы «разработчик программного обеспечения», а не шляпы «инженер-электронщик». (такие практики, как TDD и CI менее распространены в аппаратной инженерии)

С другой стороны, я думаю, что опыт разработки для встроенной системы делает ее лучше; более всесторонний разработчик программного обеспечения.

Я был в похожей ситуации около 8 лет назад. На тот момент у меня было 7 лет разработки программного обеспечения в прикладных и серверных средах. Мой единственный опыт работы с оборудованием на низком уровне - до того, как я начал писать на ассемблере Z80 в подростковом возрасте на спектре ZX.

Это было определенно проблемой. Мне очень понравилось работать с чипсетами в ассемблере, и я, конечно, многое узнал об аппаратном обеспечении. Существенная часть моей роли заключалась в тестировании аппаратного обеспечения с использованием программного обеспечения, поэтому я учился справляться с программированием и осознавал, что ваша программная ошибка на самом деле является аппаратной ошибкой. На самом деле иногда программным и аппаратным специалистам может потребоваться немало усилий, чтобы определить, является ли ошибка аппаратной или программной.

Одним из аспектов, который мне не удалось реализовать, была работа с драйвером устройства. Я никогда не понимал этого, и это то, что я и директор компании никогда не понимали, почему. Это просто стало общепризнанным фактом.

Ознакомление с оксилоскопом и пайкой-ионом будет необходимо. Помните, что когда аппаратный парень говорит число 26, он ВСЕГДА означает, что 0x26 полезно. Понимание того, что аппаратные инженеры находят работу с программным обеспечением очень разочаровывающим, помогает, но тогда аппаратный проект, который не включает программное обеспечение, называется кабелем.

Я оставался в этой роли в течение 4 лет и ушел только потому, что меня брали за действительно фантастическую возможность.

Как и все, это требует взвешенного подхода. Я люблю работать со встроенными системами на моей повседневной работе. Они делают меня лучше в электротехнике. Физические вычисления и автоматизация очень увлекательны. С другой стороны, создание веб-приложений и работа с облачными вычислениями - это круто.

Если вы все сделаете правильно, программная сторона будет искать способы сделать что-то умнее и лучше. С аппаратной стороны вы будете помнить о ресурсах и быть супер эффективными.

Я не инженер-электрик, но я немного разработал встраиваемое программное обеспечение. Самая большая проблема, которую я обнаружил, заключается в том, что у меня гораздо более базовые знания по математике, и поэтому я не знаю, как легко разбить сложную серию сложных математических алгоритмов на код без большой помощи.

Для всего, что мне нужно было поиграть с сигнализацией, прочитать значения с входов, отправить данные на выходы и все такое, я концептуально немного отличался от того, что я делаю изо дня в день, как хороший старомодный разработчик программного обеспечения. Написание программного обеспечения действительно то, что оно есть. Когда вам нужно выйти за рамки реального программного обеспечения, я нахожу вещи рискованными, потому что у меня нет знаний, чтобы напрямую связываться с оборудованием. Обычно это происходит при попытке отладки или тестирования кода. Если у вас действительно отличная цепочка инструментов, возможно, вы интегрировали среду отладки и моделирования, чтобы снять с себя большую часть боли, но даже несмотря на все это, вам иногда нужно вернуться к основам и проверить свой код на соответствие какой-то анализатор, и реальность такова, что большинство встроенных платформ не

С этой точки зрения, я не думаю, что быть инженером-электриком необходимо для встроенного программирования, если задачи просты, а фактические требования к оборудованию минимальны. Кроме того, я думаю, что EE значительно облегчит жизнь при работе во встроенной среде, особенно когда реальной науке требуется выяснить, где проблемы.

Я не занимался встроенным программированием на бизнес-уровне, но мой бакалавр был в основном о встроенных системах, из которых у меня есть несколько лет реального опыта. Мы использовали C на Atmel AVR и прикоснулись к некоторым чипам Texas Instruments с помощью VHDL, и имели некоторые теоретические знания по ARM.

В нашем случае это было примерно на 50-60 процентов программирование (C), 20 процентов планирование / проектирование (UML), а остальное - физическая электроника (пайка, измерение, подключение, изготовление кабелей и т. Д.). Я также согласен с тем, что это было очень интересно и интересно, и я бы хотел сделать карьеру во встроенных системах. Увы, с очень небольшим рынком встраиваемых систем мне пришлось прибегнуть к простой старой Java EE.

Но я отвлекся; Я бы сказал, что вышеупомянутые проценты очень близки к реальной работе, так как у наших учителей есть свои предприятия, а также упомянули, что они попытаются сделать это как можно более реалистичным. У нас даже были случайные развороты на 180 градусов в требованиях к середине проекта, хе-хе.

Что касается стека. Знание встроенного программирования даст вам большие шансы для создания ваших собственных и очень реальных аппаратных продуктов, которые вы могли бы изготовить на реальных заводах в Азии, а затем собрать их у вас (будь то дома или в вашей собственной компании). Это очень интересно! Вы также можете сделать множество гаджетов, которые будут полезны дома, например, прожекторы с управлением движением, таймер для кофемашины, чтобы автоматически готовить утреннее джо, и так далее. Действительно захватывающие вещи!