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

D2MS

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

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

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


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

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

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

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

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

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

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

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

Сообщение отредактировал MaslovVG - Jan 20 2007, 08:29