Чи вбудоване програмування ближче до електротехніки чи розробки програмного забезпечення? [зачинено]

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

Зазвичай я б знищив можливість написати вбудований код, оскільки не вважаю себе інженером-електриком. Це погане припущення? Чи я можу написати цікаве і корисне програмне забезпечення для вбудованих систем, або буду кидати себе за падіння занадто низького рівня на стек програмного забезпечення?

Я пішов до школи з інформатики і дуже любив писати компілятор, думаючи про паралельні алгоритми, проектування структур даних та розробку фреймворків. Однак я зараз працюю як веб-розробник, який не кричить цікавих речей, які я щойно описав. (Зараз я займаюся такими питаннями, як: "цей прапорець повинен бути на 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 роки, і пішов лише тому, що мене пограбували за дійсно фантастичну можливість.

Як і все, він вимагає збалансованого підходу. Я люблю працювати з вбудованими системами на своїй щоденній роботі. Вони роблять мене кращим в електротехніці. Фізичні обчислення та автоматизація дуже захоплюючі. З іншого боку, створення веб-додатків та взаємодія з хмарними обчисленнями є приголомшливим.

Якщо ви зробите це правильно, програмне забезпечення з боку вас шукатиме способи зробити розумніші та кращі речі. Апаратна частина вас дозволить вам пам’ятати про ресурси та надзвичайно ефективно.

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

Для всіх речей, де мені потрібно було грати з сигналізацією, читати значення з вхідних даних, подавати дані на вихідні дані, і всі подібні речі, я вважаю, що це концептуально відрізняється від того, що я роблю щодня як хороший старомодний розробник програмного забезпечення. Написання програмного забезпечення насправді є тим, що воно є. Саме тоді, коли вам потрібно вийти за межі власне програмного забезпечення, я знаходжу речі, які стають непростими, бо я не маю знань, щоб безпосередньо возитися з обладнанням. Зазвичай це відбувається при спробі налагодження або тестування коду. Якщо у вас дійсно чудова ланцюг інструментів, можливо, у вас є інтегрована середовище налагодження та імітаційного моделювання, щоб позбавити більшу частину болю, але навіть незважаючи на все, що вам допоможе, вам іноді потрібно повернутися до основ та перевірити свій код на якийсь аналізатор, і реальність така, що більшість вбудованих платформ не '

З цієї точки зору, я не вважаю, що бути інженером-електриком є ​​важливим для вбудованого програмування, якщо завдання прості, а фактичні вимоги до обладнання є мінімальними. Крім того, я думаю, що створення ЕЕ значно полегшить життя при роботі у вбудованому середовищі, особливо коли потрібна реальна наука, щоб з’ясувати, де проблеми.

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

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

Але я відступаю; Я б сказав, що вищезазначені відсотки досить близькі до реальних робочих місць, оскільки наші викладачі мають свої підприємства, а також зазначили, що вони намагатимуться зробити це максимально реалістичним. У нас навіть були випадкові повороти на 180 градусів у вимогах середини проекту, хе-хе.

Щодо стека. Знання вбудованого програмування дасть вам величезні шанси на створення власних і дуже реальних апаратних виробів, які ви могли б виготовити на реальних заводах в Азії, а потім зібрати їх у своїх приміщеннях (будь то вдома або у власної компанії). Це дуже цікаво! Ви також можете зробити багато пристосувань, які будуть корисні в домашніх умовах, наприклад, домашні світильники, керовані рухом, таймер для кавоварки для автоматичного приготування ранкового джоу, тощо. Захоплюючі речі справді!