Является ли низкоуровневое/встроенное системное программирование сложным для разработчиков программного обеспечения?

Ответ 1

В конце дня все это API.

Нужно написать код для периферии SPI внутри микроконтроллера? Ну, возьмите руководство по техническим данным или аппаратным средствам и посмотрите на периферию SPI. Это один, большой, сложный API.

Проблема заключается в том, что вам необходимо понять аппаратное обеспечение и некоторые основные основы EE, чтобы понять, что означает API. Спецификация не написана разработчиками SW и для разработчиков, она была написана для инженеров-технологов и, может быть, для разработчиков программного обеспечения.

Итак, все это с точки зрения аппаратного обеспечения (лицом к лицу - компания микроконтроллеров - это аппаратная компания, заполненная инженерами аппаратного и программного обеспечения).

Это означает, что переход отнюдь не является простым и понятным.

Но это не сложно - это просто немного другой домен. Если вы можете реализовать учебную программу, начните с Rabbit Semiconductor. Там достаточно программного обеспечения, поэтому парень SW может действительно поработать с небольшим усилием, и HW легко справиться, потому что все обернуто в красивые небольшие библиотеки. Когда они хотят сделать что-то сложное, они могут копаться в прямом доступе к аппаратным средствам и играть на более низком уровне, но в то же время они могут делать довольно интересные вещи, такие как малое создание webservers или панорамирование/наклон сетевых камер. Есть другие компании с подобными предложениями, но Rabbit действительно сосредоточен на том, чтобы сделать аппаратное обеспечение простым для разработчиков программного обеспечения.

В качестве альтернативы запустите их в платформу Android. Для них это похоже на систему unix, пока они не захотят делать что-то интересное, и тогда у них будет желание атаковать эту небольшую проблему, и они узнают об оборудовании.

Если вы действительно хотите прыгнуть в глубокий угол, перейдите с arduino kit - дешевые, бесплатные компиляторы и библиотеки, довольно легко начать но вам нужно подключить провода, чтобы сделать что-то интересное, что может быть слишком большим препятствием для неохотного инженера-программиста. Но небольшая помощь и несколько подталкиваний в правильном направлении, и они будут абсолютно взволнованы тем, что у вас есть небольшой светодиодный дисплей, который wibbles *, как ночные огни...

-Adam

* Да, это технический термин.

Ответ 2

Лучшие внедренные программисты, с которыми я работал, обучаются EE и изучают SW на работе. Худшими внедренными разработчиками являются недавние выпускники CS, которые считают, что SW - единственный способ решить проблему. Мне нравится думать о встроенном программировании как о нижней части пирамиды SW. Это стабильный уровень абстракции/основы, который делает жизнь легкой для разработчиков приложений.

Ответ 3

"Жесткий" - чрезвычайно относительный термин. Если вы привыкли мыслить жестким, иногда запутанным способом, для небольшого встроенного кода (например, вы разработчик драйверов), то, конечно, это не "сложно".

Не для "bash" (не предназначенных для каламбуров) сценариев оболочки, но если вы пишете скрипты perl и shell весь день, то это может быть очень тяжело.

Аналогично, если вы пользователь UI для Windows. Это другой вид мышления.

Ответ 4

Это очень субъективно, я думаю, его причин было бы много. Но если он, как я, я знаю, откуда он. Позвольте мне объяснить.

В моей карьере я посвятил 6 лет телекоммуникационной отрасли, много работая с внедрением промежуточного ПО SDK в мобильные телефоны низкого класса и т.д.

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

Я тот, кто чувствует, что это ограничивает мое творчество.

Мне нравится возвращаться в среду рабочего стола Windows и закрывать свои крылья сложными конструкциями классов, растягивать мои ноги на несколько часов, дополнительно использовать ненужные объемы памяти для диагностики и т.д.

В некоторых встроенных модулях в прошлом я почти не имел поддержки fseek() (стандартная файловая функция ANSI C). Если повезет, "сторожевая собака" может дать подсказку, где что-то разбилось. Не говоря уже о боли в общении с пользователем в однопоточных упреждающих болотах.

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

Привет

Роберт

Ответ 5

Почему встроенная разработка "жесткая":

1) Контекст может переключиться на прерывание между каждой машинной инструкцией. Поскольку конструкции языка высокого уровня могут отображаться в нескольких инструкциях по сборке, это может быть даже в пределах строки кода, например. long var = 0xAAAA5555. При доступе в подпрограмме обслуживания прерываний в 16-битном процессе var var может быть установлен только наполовину.

2) Видимость в системе ограничена. Вы даже не можете выводить на Hyperterm, если вы не напишете его сами. Эмуляторы не всегда работают так хорошо или последовательно (хотя они намного лучше, чем раньше). Вам нужно будет знать, как использовать осциллографы и логические анализаторы.

3) Операции требуют времени. Например, скажем, ваш последовательный передатчик использует прерывание для сигнала, когда пришло время отправить другой байт. Вы можете записать 16 байт в буфер передачи, затем очистить прерывания и задаться вопросом, почему ваше сообщение никогда не отправляется. Сроки в целом - сложная часть встроенного программирования.

4) Вы подвержены тонким условиям гонки, которые встречаются редко и очень трудно отлаживать.

5) Вы должны прочитать руководство. Много. Вы не можете заставить его работать, обманывая себя. Иногда нужно правильно настроить 20 вещей, чтобы получить то, что вам нужно.

6) Аппаратное обеспечение не всегда работает или легко повреждается, и требуется некоторое время, чтобы понять, что вы его сломали.

7) Ремонт программного обеспечения во встроенных системах обычно очень дорог. Вы не можете просто обновить веб-страницу. Отзыв может удалить любую прибыль, которую вы сделали на устройстве.

Есть, вероятно, больше, но у меня есть это условие гонки, чтобы решить...

Ответ 6

Существует очень реальная разница в мышлении от разработки приложений на уровне пользователя (например, ПК общего назначения или веб-приложений) до жесткого срока, разработки приложений ответа в реальном времени (то есть интерфейса аппаратного/программного обеспечения).

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

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

Аналогично, люди, которые были в аппаратной области (например, инженеры), часто испытывают трудности с предположениями и языком разработки программного обеспечения.

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

Ответ 7

Ему нужно быть комфортно с низкоуровневым материалом, но в основном для отладки и полевых проблем. В зависимости от архитектуры существует серьезная кривая обучения, но не невозможна. С другой стороны, низкоуровневый код принимает (в общем) больше времени и отладки, чем код более высокого уровня. Поэтому, если вам нужно постоянно возвращаться на низкоуровневое, возможно, что-то не так в дизайне. Даже для встроенных элементов управления, которые я построил, я трачу огромное количество времени на высокоуровневый код. Хотя, когда у вас есть проблемы, очень выгодно иметь очень хорошие знания на низком уровне.

Ответ 8

Я - инженер-программист, работающий в EE. Я предпочитаю программировать низкий уровень. Большинство разработчиков программного обеспечения, которые, как я знаю, не хотят работать на этом уровне, они хотят, чтобы apis звонил. Поэтому для меня это победный выигрыш, я создаю драйвер низкого уровня и api для их использования. Существует "новая" степень, по крайней мере, новая, так как я пошел в колледж, назвал компьютерного инженера. Хм, это может быть степень электротехники, а не компьютерная наука, но это хорошее сочетание программного и цифрового аппаратного обеспечения. Люди, с которыми я работал в этой области, гораздо более удобны с низким уровнем.

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

Я также думаю, что им понравится, когда они преодолеют горб, свободу, которую вы на этом уровне, не мешают операционным системам и т.д. Недавно я стал свидетелем нескольких сотрудников, впервые увидев их запуск программного обеспечения под моделированием. Каждая сеть внутри процессора и других периферийных устройств микросхемы. Нет, у вас нет таблицы на gui (отладчике), показывающей текущее состояние памяти, вам нужно посмотреть на шину памяти, искать интересующий вас адрес, искать сигнал чтения или записи и шину данных. Я беспокоюсь о том, что приходит кремний, и у них больше нет такого уровня видимости. Будет как наркоман в детоксикации.

Ответ 9

Ну, я порезал свои зубы на аппаратных средствах, когда начал читать Popular Electronics в 14 лет - это было ПЕРЕД персональными компьютерами, на случай, если вам интересно, и если вы werent хорошо, вы все равно знаете. lol

Ive сделал низкоуровневый бит-бит на микропроцессоре 8048/51, сделал ПОС и некоторые другие варианты чипов и, конечно же, Rabbit Semiconductor. (отлично, если вы в C). Это здорово (и весело); Да, есть другой способ взглянуть на вещи - не сложнее, но некоторые из этой информации немного сложнее, так как это не обсуждается как проблемы с программным обеспечением. (Конечно, это зависит от круга друзей, с которыми вы связываете, а).

Но, сказав все это, я хочу напомнить вам о технологии, которая начала устранять пробел для программистов в мире аппаратного обеспечения и с тех пор стала очень ОСНОВНЫМ игроком, и это .NET micro framework. Информацию об этой технологии можно найти по следующей ссылке:

http://msdn.microsoft.com/en-us/embedded/bb267253.aspx

В нем рассматриваются те же проблемы, что и в веб-разработке .NET, в которых вы можете использовать некоторые (на самом деле, немного) существующие знания на базе ПК в новых средах. Некоторая осторожность, конечно, как ваша целевая машина не имеет 4 GIG RAM - у него может быть только 64K (или меньше)

Начиная с версии 2.5 микроструктуры .NET, у вас есть доступ к сетевым и веб-сервисам - путь kewl, а? Это не останавливается... Хотите контролировать свет в своем доме? Как насчет станции регистрации темпа? Все с навыками, которые у вас уже есть. Ну, в основном - Проверьте ссылку.

SDK подключается к вашей среде VisualStudio. Существует ряд "наборов для разработки", доступных для очень разумного количества наличных денег. Теперь, как правило, требуется большая кривая обучения в компонентах, построение печатной платы и подключение "вещи" можно сделать достаточно легко с помощью набора dev и некоторый довольно простой код. Конечно, вам может понадобиться случайная операция бит-банга, но все больше и больше людей-датчиков предоставляют драйверы .NET micro framework - так что аппаратная разработка может быть ближе, чем вы думаете...

Надеюсь, что это поможет...

Ответ 10

Мне нравятся оба. Встроенные вызовы меня и действительно заставляют меня идти висцерально. Сделать что-то, что влияет на физический мир макроса, очень удовлетворительно. Но мне пришлось много догонять на электротехнике/электронике, так как мой холостяк в компьютерной науке. У меня довольно общий фон, где я изучал ai, графику, компиляторы, естественный язык и т.д. Теперь я занимаюсь выпускными работами во встроенных системах. Очень сложная часть - это адаптация к отсутствию средств управления, таких как операционная система.

Ответ 11

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

Ответ 12

Согласовано на "трудный" термин, довольно относительный.

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

Ответ 13

Вы правы в том, что любой человек, обладающий достаточными знаниями, чтобы не чувствовать себя полностью потерянным в области (над горбом?), будет испытывать трудности в изучении чего-то нового.

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

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

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

Ответ 14

Я бы сказал, что это не сложнее, просто требуется другой набор знаний, разные соображения.

Ответ 15

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

Работа над встроенной платформой linux, скажем, намного меньше, чем попытка написать код на 8-битной платформе без операционной системы вообще.

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

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

Как (очень) общий оператор, если они удобны в работе с многопоточными приложениями, они, вероятно, будут в порядке, так как это разделяет некоторые из тех же проблем волатильности данных, которые у вас есть при работе с встроенными проектами.

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

Ответ 16

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

Ответ 17

Я начал работать инженером SW, теперь я HW! важно понять, как это работает и быть мотивированным!