[Mirabella 0]

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

 

Думаю, что это не так.

Конструирование -это конструирование: в общем случае - формирование облика.

Схемотехника (в смысле создания новых схем) -это разработка -в общем случае- разрешение совокупности неопределенностей.

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

 

D2MS

[SM 0]

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

 

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

 

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

 

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

 

 

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

[binom 0]

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

 

Embedded Systems Design: An Introduction to Processes, Tools, and Techniques

by Arnold S. Berger ISBN: 1578200733

 

Просмотрел ее бегло: там идет разделение труда программистров и разработчиков железа.

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

 

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

 

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

[SM 0]

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

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

[MaslovVG 0]

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

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

Нельзя ограничивать свою деятельность узкими рамками. Жизнь требует мобильности.

Изменено 20 января, 2007 пользователем MaslovVG