Программист или инженер, куда двигаться дальше Опции

[binom]

Доброго всем времени суток.

Хотельсь бы узнать мнение специалистов по следующему вопросу:

При изготовлении микропроцессорной техники по моему мнению можно выделить две роли - это программист и инженер(скажем схемотехник).

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

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



Насколько глубоко каждый из этих специалистов должен обладать знаниями другого.
Насколько это вообще реально быть специалистом в обоих областях.

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

[yornik]

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

2) Сложные устройства не могут быть разработаны одним человеком - следует из определения.

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

Да, по поводу темы топика.
Имхо, программные части систем сейчас гораздо сложнее схемотехнических. Или так: по крайней мере, все сложные цифровые схемы сейчас описываются в стиле программирования (VHDL/Verilog/SystemC). Т.е. к выбору Вас в !какой-то небольшой! мере может подтолкнуть, что Вас привлекает больше (сложность -> ближе к программированию и работе в коллективе) или простота. Но помнить, что любая простота в любом деле еще должна быть доказана практикой, и на кону - Ваша жизнь как разработчика (ну или разочарование заказчика ;) ) И программирование, и схемотехника - подмножества гораздо более могучего термина "конструирование". Если Вы на начальном этапе выберете схемотехнику и Вас заинтересует сложность, Вы непременно придете и (или) к тепловым расчетам, и (или) к оптическим схемам, акустике, ..., да чему угодно еще. Если начнете с программирования, то его может хватить и одного ("программирование есть процесс управления сложностью" - не помню, чей (с) ); возможно, Вы придете к (условно!) "программированию людей" - управлению коллективом разработчиков.

[Mirabella]

И программирование, и схемотехника - подмножества гораздо более могучего термина "конструирование".

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

D2MS

[SM]

Между программированием и схемотехникой есть "одна большая разница" - уровень неопределенности исходных данных и способов достижения цели.

Тут я с Вами не согласен. Может быть в частных случаях это и так, а в большинстве случаев (опять же моих, т.е. с которыми я непосредственно сталкивался) програмиирование, схемотехника и описание RTL на HDL это теснейшим образом связанные задачи. И я сам решаю, что мне будет выгоднее - решить данную подзадачу методами аналоговой схемотехники, или программно с помощью цифровой обработки сигналов, или смешанно, а если ЦОС - то куда его, в ПЛИС или в процессор. И какова будет ориентировочная стоимость того или иного решения при серийном производстве изделия. Итого уже на этапе разработки схемы я определяю ориентировочную загрузку процессора, пишу все мат-модели работающих в схеме программных модулей, пишу RTL, и смотрю куда это все и как укладывается. И только потом выбираю подходящие компоненты.

Даже текущая моя задача - разработка SOC, состоящего из микропроцессора и кучи периферии, включая аналоговые модули. Я уже прикидываю алгоритмы, которые будут работать в этом SOC, и анализируя потребление, площадь и быстродействие разных подходов к их реализации, выбираю что сделать чисто программно, а для чего может быть добавить какую-то полезную инструкцию в ядро МП, а что-то может быть выгоднее сделать аналогом. Да, я сам не пишу эти программы, времени на все не хватит. Я разрабатываю математику, программу пишет программист (время оно не бесконечно, и я нуждаюсь в помощи при решении задачи), и потом мы вместе ищем пути оптимизации, и что и как можно решить железно, чтобы выиграть либо копейку площади, либо микроватт энергии, либо бит ОЗУ... Кстати - разработка СБИС это простая задача на Ваш взгляд? Или сложная?

Т.е. Исходные данные одни - это ТЗ. Далее надо произвести оптимизацию, согласно какому-то критерию оптимальности разложив большую задачу в связанные мелкие, решаемые каждая отдельно либо программно, либо схемотехнически, либо как-то еще (например в ПЛИС, я не уверен, что это больше - схемотехника или программирование).


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