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

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

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

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

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



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

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

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

Вопрос - а зачем это нужно? Схемотехника настолько разнообразна, что быть специалистом во всём просто нереально, а работа в команде всегда более эффективна, чем одиночное плавание.

[/quote]
Вопрос - а зачем это нужно? Схемотехника настолько разнообразна, что быть специалистом во всём просто нереально, а работа в команде всегда более эффективна, чем одиночное плавание.
[/quote]

Зачем нужно, ну вот пример:

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

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

На мой взгляд разработка устройства должна производится одним человеком. От схемы и до сдачи. Пусть это не система в целом, пусть это ее модуль, но для лучшего качества продукта разработчик должен сам отлично представлять себе, что и как будет работать, должен сам распределять задачу между аналоговой частью, если таковая есть, процессоров, ПЛИСов, и т.п. Если с чем-то не в силах справиться, то либо разобраться в этом вопросе, либо попросить другого разработчика помочь. Не раз видел, как программист разбирается с ПЛИСоделом, один говорит другому "да тебе это раз плюнуть", и в ответ слышит то-же. И полдня споров, типа что лучше - фифо или двухпортовку. Когда делает один человек, пусть даже с периодическим привлечением сторонних сил, такого не бывает никогда, и получается наиболее сбалансированная система. Не спорю, всего не узнаешь, например в RF/Microwave я не лезу, там для меня темный лес. Однако припрет - придется и туда вникать.

Сам так работал всегда, беря ТЗ и сдавая модуль/девайс. И по другой системе работать не желаю. Если знаешь схемотехнику (аналог), то и цифра не проблема, и далее ПЛИС. В общем - самосовершенствование должно иметь место. Вчера не знал, как работает импульсный DC/DC, сегодня-завтра почитал книжки, вник в математику и физику процессов, послезавтра разработал схему, через неделю, после пары взрывов, заработало. Зато в следующем проекте уже уверенно подходишь к аналогичной задаче. И так всегда. Через года два-три уже мастер на все руки в схемотехнике. Не надо бояться поставленных задач. Надо сразу смотреть с оптимизмом - "я справлюсь!"
Если умеешь программировать - то все равно какой процессор... Новых ядер не бояться, их надо с интересом разбирать на части и применять. С каждым новым процом приходит опыт, знания, и, самое главное, появляется возможность выбирать в следующей разработке из бОльшего списка. Да и пятое ядро дается на порядок быстрее второго. И еще считаю, что программист ОБЯЗАН знать все тонкости функционирования ядра и периферии того МП, с которым имеет дело, и обязательно уметь программить на ассемблере. Т.е. первое - это всегда ассемблер, не знаешь его - не допускаешься к работе с данным ядром. С/C++ это желаемая опция, если надо для проекта.

[quote name='binom' date='Jan 14 2007, 13:27' post='196725']
[/quote]
Вопрос - а зачем это нужно? Схемотехника настолько разнообразна, что быть специалистом во всём просто нереально, а работа в команде всегда более эффективна, чем одиночное плавание.
[/quote]

Зачем нужно, ну вот пример:

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

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

Есть такая специальная профессия - системный инженер. Он выбирает шины, коды. Он проводит разбиение системы на куски и он же определяет ТЗ к профильным разработчикам (программистам, схемотехникам, конструкторам), и он же следит за всеми стыковками и не стыковками этих специалистов.
Вот он должен быть ШИРОКО подкованным во всех областях, которые есть у него в проекте+специальные знания по проектированию систем. Но он не должен (и не может) быть ГЛУБОКО подкованным в профильных дисциплинах.
Соответственно, что бы широко и качественно подковаться нужно поработать во всех этих областях самому (но конечно профильный разработчик будет знать предмет много глубже системного уровня).
Ну это вроде системным подходом называется: один и тот же предмет одновременно и системой является и объектом, как смотреть.

P.S. Уметь паять (особенно, хорошо паять) инженеру совсем не обязательно для этого есть монтажник, у меня вот вроде 7 лет стажа инженера, а нормально паять не умею (только командую чего и куда ), нужно делать то, что ты умеешь делать хорошо, схемы разрабатывать.

[quote name='currant' date='Jan 14 2007, 14:05' post='196732']
[/quote]

Есть такая специальная профессия - системный инженер. Он выбирает шины, коды. Он проводит разбиение системы на куски и он же определяет ТЗ к профильным разработчикам (программистам, схемотехникам, конструкторам), и он же следит за всеми стыковками и не стыковками этих специалистов.
[/quote]

Я так понимаю, что системные инженеры так же вырастают из каких то профильных специалистов.

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

[quote name='binom' date='Jan 14 2007, 16:44' post='196773']
[quote name='currant' date='Jan 14 2007, 14:05' post='196732']
[/quote]

Есть такая специальная профессия - системный инженер. Он выбирает шины, коды. Он проводит разбиение системы на куски и он же определяет ТЗ к профильным разработчикам (программистам, схемотехникам, конструкторам), и он же следит за всеми стыковками и не стыковками этих специалистов.
[/quote]

Я так понимаю, что системные инженеры так же вырастают из каких то профильных специалистов.
[/quote]


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

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

С какой целью выбираете? Если там, где больше денег - то это изначально неизвестно.
Если с целью более быстрой и качественной разработки - мнения на этот счет тоже диаметрально противоположны. Например, руководитель разработки а-ля Mirabella предпочитает специально обученных людей, а я напротив, полностью разделяю мнение SM.
И только если Ваша работа Вам по душе и Вы стремитесь к самосовершенствованию - однозначно прислушайтесь к мнению SM.
Кстати, SM, мой Вам

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

P.S.
Может быть обменяемся пониманием термина "разработка"?

D2MS

Я, тоже, полностью разделяю подход SM к разработке.
Замечу лишь, что подход "Разработку делает один человек" - не означает, что он обязательно все делает своими руками и, даже, своей головой! Большие проекты тоже должен "делать" один человек - главный конструктор изделия (системы). Другие участники проекта должны быть "эффективным продолжением его рук, ног и головы". Иначе успех не гарантирован. Я, лично, другие подходы к разработке не признаю и другим не советую!

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

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

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

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

Уважаемая Mirabella, если я задел Вас своим а-ля, прошу прощения.
И если Вы были столь любезны, что простили мне это, надеюсь Вы простите меня и за то, что я не намерен обмениваться с Вами пониманиями термина "разработка", ибо занят сейчас более серьезным делом - непосредственно ей самой.

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

D2MS

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

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

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


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

Я тут поработал, в некотором смысле, по теме заданного мной вопроса и нашел интересную книгу

Embedded Systems Design: An Introduction to Processes, Tools, and Techniques
by Arnold S. Berger ISBN: 1578200733

Просмотрел ее бегло: там идет разделение труда программистров и разработчиков железа.
НО!, написаны такие строки(общий смысл конечно, не дословно):

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

Так что, как ни крути изучения требуют оба направления.

Ну не то, чтобы "как не крути", а если есть желание в будущем самому распределять задачу между "просто программистами" и "просто электронщиками", то надо знать оба направления, чтобы грамотно взвешивать все "за" и "против" каждого из вариантов решения. И не оба направления, а еще больше. Еще неплохо ориентироваться в HDL/ПЛИС, и всегда быть готовым за день-два хотя бы поверхностно, но вполне достаточно для принятия решения разобраться с вдруг появившимся вопросом, ответ на который до такого момента для Вас был тайной за семью печатями.

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