Что нужно иметь и знать дабы прогарммировать PIC и AVR?

[Murav]

А конкретно: обсуждение проекта с заказчиком, сбор требований и пожеланий, ранжирование их по степени важности, планирование задач, ведение Wiki по проекту, регистрация багов и отслеживание их исправлений, форум поддержки пользователей продукта и т.д.

Только зачем всё это в небольших проектах?
И мы вроде говорим об одном программисте, у которого заказчик - или он сам или кто-то из знакомых.

Конечно, все это можно пытаться держать в голове (лично в моей это все точно не умещается, неоднократно проверено) или записывать в тетрадке, но я предпочитаю напрягать компьютер.

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

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

Какая часть из обнаруживаемых им ошибок - ложные срабатывания и какую часть можно легко увидеть просто просматривая код?

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

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

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

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

Даже без паяльника можно обойтись, наверное.

Так же как и без компилятора.
Тут важно, что будет проще - разобраться и использовать(в том числе поддерживать) данную вещь или обойтись без неё. И вот в случае паяльника и компилятора проще первое, а в случае управления проектом(в небольших проектах) - второе.

Заказчик нынче ушлый пошел. Ему и Zigbee подавай, и встроенный в прибор WWW-сервер, и массу прочих вкусностей, а все это требует массу кода.

Только в случае с программистом-одиночкой(да ещё и не достаточно опытным) получается так, что либо удастся найти готовую библиотеку(а то и вообще взять линукс) для реализации этой функции либо заказчику придётся обойтись без этого.
В случае, если удастся найти библиотеку, то код конечно в мегу8 не влезет, только вот размер кода, который пишет программист, не изменится.
Хотя в случае линукса или другой системы которую нужно допиливать - это уже участие в большом проекте.

А вот цивильное программирование в больших проектах далеко не сводится к правильному структурированию программы

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

Да и структурное программирование уже вроде как в историю ушло, на повестке дня объектно-ориентированные проектирование и программирование, под них все современные методики заточены.

Тем не менее там необходимость правильной структуры программы никуда не делась, а даже стала ещё важнее.

По системе контроля версий прочитал пару учебников - и практически уже эксперт (могу даже порекомендовать такую пару)

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

Хотя все равно есть шанс, что на голову свалится ракета, спроектированная большинством. Или, не дай господь, вживят кардиостимулятор, софт которого не тестировали для экономии сил и времени.

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

Ну почему же явно к команде? "Разработка, управляемая тестами" - это очень интересный метод разработки софта, при котором сначала пишутся тесты, а потом код. На первый взгляд выглядит парадоксально (как тестировать то, чего еще нет?), но на самом деле в этом есть глубокий смысл. Куда глубже, чем кажется с виду.

И в каких случаях такое использовать целесообразно?

Опять же, совсем не факт. Посмотрите, например, сколько в datasheet на ту же Mega занимает полное описание системы команд. А теперь положите рядом, скажем, текст стандарта
ISO/IEC 9899:1999 по языку C (554 страницы). Ведь нельзя же всерьез утверждать, что человек, не удосужившийся даже проштудировать стандарт, умеет хорошо программировать на языке C.

Важен не полный размер спецификации языка, а сложность программировать на нём.

[Murav]

Диалекты разные бывают.

Судя по всему с ними ситуация такая, что в одних есть объявления переменных с инициализацией, в других можно записывать несколько операций в одной строке, а в третьих - писать код для AVR.

Скажем, в этом.

А в нём вообще для AVR или PIC прошивки можно писать?

[Мурик]

А в нём вообще для AVR или PIC прошивки можно писать?

Нет. Он для компа.
Хотя на оф. форуме поднимался вопрос о создании компилятора для ARM'ов, но пока тишина.

[Jack_A]

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

Приходилось. Тут самое тонкое - ущучить и придушить эту ошибку в первой версии ( приводимый мегасервис тут не помощник ), а уж протащить результат по последующим версиям - дело техники. я так думаю.
Вот ляснулся у меня винт после довольно серьезной правки, когда я пошел тестить новый вариант, а копию не сдублировал ( хотя до этого делал это регулярно - неприятность приходит тогда, когда от нее наибольший вред, закон Мерфи). Чем бы мне помогли эти самые - они бы накрылись вместе с исходником, а простая копия решила бы дело. Пришлось неделю потратить на дурку - по новой HEX и старой ASM восстанавливаться.

Мы напрасно спорим - каждый работает так, как ему удобней. А стартертопик спросил : что ему нужно для начала, его огорошили целым каталогом, он плюнул и ушел пить пиво

[Goldsmith]

Какая часть из обнаруживаемых им ошибок - ложные срабатывания и какую часть можно легко увидеть просто просматривая код?

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

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

У меня лишь два вопроса:
- вы когда-нибудь реально видели результат работы Doxygen?
- если да, то сильно ли он был похож на вынесение комментариев в отдельный файл?

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

Я скажу больше: в больших проектах объем тестового кода зачастую не сравним, а в полтора-два раза больше, чем у целевого кода. И без них написать программу действительно гораздо быстрее. Только вот написание кода в жизненном цикле программного продукта занимает не такую большую часть, примерно процентов 25 (многие авторитеты, включая Брукса, уверяют, что еще меньше, примерно 1/6 общего времени). Так что экономим фактически на спичках.

На всякий случай еще раз напоминаю, что речь идет не о программах класса "Hello World", а о реально полезных продуктах.

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

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

Тем не менее там необходимость правильной структуры программы никуда не делась, а даже стала ещё важнее.

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

Объективно оценить качество кода можно стандартными метриками, а метрики вычисляют специально заточенные для этого инструменты. И тут тоже на глазок не катит.

[Goldsmith]

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

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

К бытовой электронике это явно не относится - там есть некоторая надёжность, выше которой делать нецелесообразно. А в небольших проектах она легко достигается и так.

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

Важен не полный размер спецификации языка, а сложность программировать на нём.

Вы и правда всерьез считаете, что программировать на C действительно просто?

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

Ну если это вершина карьеры, тогда конечно. Зачем нотная грамота и сольфеджио музыканту, у которого слушатель - или он сам, или кореш-собутыльник? Главное - растягивать меха поширше и при этом не порвать баян.

Мои советы исключительно для тех новичков, кто планирует в перспективе стать профи в разработке firmware. Бывают ведь и такие, с амбициями. Вовсе не значит, что все перечисленное нужно тут же кидаться осваивать одновременно, но иметь в виду необходимо.

А вообще в целом, конечно, все определяется конечной целью. Это все равно что спросить строителя: "Как построить дом?". Тот начинает с жаром рассказывать о сваях и фундаменте, о расчете несущих колонн и балок... Его выслушивают с недоумением и говорят: "Дядя, ты о чем? Какой сопромат, какой бетон марки М200? Нам дом для Барби нужен, розовый такой". Поэтому неплохо бы уточнить у топикстартера его цель, если он еще следит за своей темой. Если "чиста лампочками помигать для прикола", то я действительно очень неправ. Если нет - примите сказанное к сведению.

[Goldsmith]

Приходилось. Тут самое тонкое - ущучить и придушить эту ошибку в первой версии ( приводимый мегасервис тут не помощник )

Смотря кто из "мегасервисов". Если речь о системе управления версиями, то щучить ошибки - это совсем не по ее части. Ждать от нее этого так же бесполезно, как от редактора текстов. А вот другой мегасервис, система модульного тестирования, тут не просто помощник, а друг, товарищ и брат. И нащучит, и придушит, а главное - гарантирует, что эта же ошибка не вылезет при дальнейших манипуляциях с кодом.

а уж протащить результат по последующим версиям - дело техники. я так думаю.

Совершенно верно. И имя этой техники - слияние изменений с каждой из версий. Одна из основных обязанностей VCS, с которыми они справляются на отлично.

Вот ляснулся у меня винт после довольно серьезной правки, когда я пошел тестить новый вариант, а копию не сдублировал ( хотя до этого делал это регулярно - неприятность приходит тогда, когда от нее наибольший вред, закон Мерфи).

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

Чем бы мне помогли эти самые - они бы накрылись вместе с исходником, а простая копия решила бы дело.

Это смотря где держать "эти самые" и где - "простую копию".

Если простая копия - это подкаталог на том же диске, пользы от нее при почившем диске минимум. А сервер управления версиями у меня крутится на пожилом, но еще вполне бодреньком компьютере, на котором живут и прочие серверные инструменты (управление проектом, технологический www, wiki и еще много всякой лабуды, я ведь не только firmware пишу). Ядерную атаку эта система вряд ли переживет, а вот вылет винта - неприятность, но поправимая.

Мы напрасно спорим - каждый работает так, как ему удобней.

Я бы уточнил - как умеет и может себе позволить. Лично мне определенно было бы удобней работать на собственной вилле в Майами в роскошном кабинете с оборудованием от HP, Tectronix и иже с ними. Но на небесах решили, что лично для меня сойдет и кладовка в Южной столице, набитая купленным у местных барыг оборудованием времен позднего СССР. Давайте будем реалистами.

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

А стартертопик спросил : что ему нужно для начала, его огорошили целым каталогом, он плюнул и ушел пить пиво

Давайте все же будем оптимистами и верить в светлую человеческую сторону

Может, он распечатал каталог, скачал все инструменты и сейчас помечает карандашом в списке, что уже пройдено, а что еще предстоит изучить. Конечно, ему не до нашей возни тут. А вы обижаете человека необоснованными подозрениями

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

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

P.P.S. Содержимое P.S. адресовано, разумеется, не лично Jack_A, а всем заинтересованным читателям топика.

[urry]

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

[Goldsmith]

я, наверное, единственный, кто поддержит Goldsmith

С одной стороны, это должно быть грустно. А с другой - значит, долго еще не останемся без работы, коллега. Заказчики начинают умнеть и деньги за воздух уже не платят, их уже не купишь на аргумент: "а чё, видишь, пимпу нажали - неонка замигала? Это значит, что все работает."

если об этих инструментах имел понятие раньше, сейчас мне было бы значительно легче.

Не беда, было бы желание разобраться. Главное - вы уже на правильном пути. Искренне желаю успехов!

ведь литературы, как в мастере мигалку накидать - море, а как профессионально работать- намного меньше.

Профессиональной литературы вообще единицы, приходится собирать по одной книге, как скупой жемчужины. Умную книгу вообще писать трудно и долго, куда проще наспех перевести даташит и клонировать его из года в год, добавляя по паре новых микросхем - "Все о микроконтроллерах Mega", "Все о микроконтроллерах Tiny" и прочая конвейерная штамповка. Это и денег куда больше принесет, и дутого авторитета.

[Murav]

Мы напрасно спорим - каждый работает так, как ему удобней. А стартертопик спросил : что ему нужно для начала, его огорошили целым каталогом, он плюнул и ушел пить пиво

Полностью согласен.

У меня лишь два вопроса:
- вы когда-нибудь реально видели результат работы Doxygen?
- если да, то сильно ли он был похож на вынесение комментариев в отдельный файл?

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

Только в реальной жизни никто большой проект переписывать не даст, ибо это многие человеко-годы.

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

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

Во время написания этой части программы он ещё не может определить насколько правильно сделана структура, а вот через некоторое время, если структура программы неправильная, то это станет ему понятно. Но только в этом случае часто переделать её в правильную сложнее чем переписать всё с нуля.

Ну если это вершина карьеры, тогда конечно.

Только зачем сразу пытаться разбираться не только с компилятором, но и с системой контроля версий, управлением проектом, созданием документации и проверкой кода?

[Goldsmith]

Только зачем сразу пытаться разбираться не только с компилятором, но и с системой контроля версий, управлением проектом, созданием документации и проверкой кода?

Разве в моих рекомендациях где-то прозвучало слово "сразу"? Разве я действительно велел топикстартеру вызубрить это все назубок за день/неделю/месяц? Я лишь перечислил основную часть того, что, как показывает практика, просто необходимо знать программисту, и в том числе программисту микроконтроллеров (а они ничем не хуже остальных, а кое в чем даже и получше).

Перечитайте внимательно тему: "Что нужно иметь и знать, дабы программировать PIC и AVR?". Здесь ни слова не сказано о том, что человек - полный новичок в программировании, и ему нельзя давать в руки серьезные инструменты - а вдруг порежется. Может, он, как и я, математик, которому просто захотелось поиграть с паяльником. Нигде также не сказано, что проекты непременно будут пожизненно маленькими . Может, поначалу и будут, а потом придет пора вырасти из памперсов и заняться взрослым делом. Встанет вопрос, чему учиться дальше, а тут уже и списочек готов.

И как-то все время упорно пытаетесь свернуть на собственную личность: "я никогда не не пользовался и впредь не буду", "я считаю ненужным", "я", "мне"... Безусловно, это личное дело каждого, мы ведь живем в свободной стране - имеете полное право и от столовых приборов отказаться, и без носового платка обходиться. Только зачем представлять это как норму для всех? Вот urry , например, уже кое-что из рекомендованного мной пригодилось - повезло человеку с новой работой.

Прямо как с поэзией Пастернака: широкие народные массы, которые о ней слыхом не слыхивали, гневно ее порицают. Ну вот не нужна она народу, и все тут. А кому нравится, тот диссидент или вовсе извращенец.

Во время написания этой части программы он ещё не может определить насколько правильно сделана структура, а вот через некоторое время, если структура программы неправильная, то это станет ему понятно. Но только в этом случае часто переделать её в правильную сложнее чем переписать всё с нуля.

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

Просто удивительно, почему вы так не уважаете программистов? Так и рисуете образ кретина, который пишет код левой задней ногой, периодически изумляясь: "Надо же, какая фигня вышла... Авось в следующий раз лучше получится". А ведь программирование - это один из разделов прикладной математики.

[Jack_A]

А ведь программирование - это один из разделов прикладной математики.

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

[Goldsmith]

А ведь программирование - это один из разделов прикладной математики.

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

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

Прикладные задачи решаются программистами уже более полувека. И компьютеры начали управлять объектами отнюдь не вчера. Факт, что сегодня умельцы запихивают на кристалл вычислительный комплекс с возможностями СМ-3/СМ-4, вовсе не делает программистов МК какой-то уникальной породой, живущей по своим особым законам. Все уже было лет 30 назад - и по регистрам устройств лазили, и байтики памяти экономили... Да и 40-50 лет назад тоже было. Единственная разница - было это не с ноготок размером, а занимало неколько шкафов и весило несколько тонн. Принципиально ничего не изменилось.

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



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

Один математик ( фамилию, жаль, не вспомню - но большой любитель парадоксов ) сказал : математика - это всего лишь раздел теории вероятностей.

Афоризмы - штука, конечно, поучительная, только вот подтвердить ими можно практически любую точку зрения. Пожелавший остаться неизвестным гений-парадоксов друг считает так, Эдсгер Дейкстра - несколько иначе:

Программирование - одна из наиболее трудных отраслей прикладной математики: слабым (poor) математикам лучше оставаться чистыми (pure) математиками.

Ну и раз уж пошла такая пьянка с цитатами - тот же Дейкстра в ту же тему:

Провозглашая себя работающими в области программного обеспечения (software), слабые (soft) ученые делают себя еще более смешными (но не менее опасными). Вопреки своему названию, software (буквально: мягкое оборудование) требует [жесточайше] твердой научной дисциплины для своей поддержки.

[Jack_A]

А если применить это толкование, скажем, к программированию PC, фактор электроники не игнорируется полностью (и вообще той предметной области, для которой программа предназначена - бухгалтерии, медицины etc)? В персоналке нет вычислительного ядра, регистров периферии, ОЗУ, для нее не нужно писать драйверы? А если есть, то в чем принципиальное отличие от МК, кроме конструктивного?

В этом случае, я думаю, наблюдается разделение труда. Кончно же, тончайшее знание работы железа разработчикам драйверов необходимо, но они там, на фирмах-производителях периферии, а мы, прикладные программисты, можем не заморачиваться думами о том, какой микроконтроллер стоит в слотах ввода-вывода, достаточно знать форматы команд и сообщений. Начиная с ХР, между железом и программером воздвигнута стена, не позволяющая ему ковыряться в регистрах периферии, хотя в W-98 я этим спокойно занимался. И это правильно. Не навреди ! Но от знания предметной области , для которой пишется прога, никто нас не освобождал. В МК ситуация немножко другая: за меня добрый дядя драйвер не напишет, каждым битиком я должен рулить сам, и знание анатомии МК - обязательное требование к занимающимся этим ремеслом. И тут уже чистая математика отступает на второй план, логика управления подчиняется алгоритмам разрабатываемого устройства.
Кажется, мы и не спорим, говорим об одном и том же, но только с разных сторон

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

Раз уж разбередили мои воспоминания крейтом КАМАК ( польская сборка ), которому отданы лучшие года поздней молодости, позволю пару уточнений. Миллионы рублей оно стоило, когда ЕС-10ХХ, занимая огромные залы с кондишенами и фальшполами, изрыгивала километры дефицитной принтерной бумаги с триллионами цифр никому не нужной АСУ, потому что даже прочесть всю эту цифирь управленческий персонал был не в силах.СМ-4 стоила 75 тысяч ( 3 "Волги" ). Решать же оптимизационные задачи даже и не пытались, потому что нельзя автоматизировать бардак - никакими алгоритмами не опишешь.
Насчет квалификации персонала... Наш НИИ делал АСК для одного оочень серьезного изделия. Когда пришла пора сдавать АСК в эксплуатацию, в цехе опомнились, что помещение не подготовлено. В понедельник приходим - все кругом в кмрпичной пыли, об если не вынести, то хотя бы закутать в пленку многострадальную СМ-4 и мысли никому не пришло. Естественно, при включении все 4 "блина" дисководов протерло до металла. Ремонт.
Начали тестирование. Регулировщики - "белая кость", каждый получал в 2 раза больше меня, ведущего инженера - брезгливо оттопырив губу, наблюдали . "Да что она там может измерить!" Но когда им раз! - раз! - возвраты, взялись за уши и задумались. Видно технология : включил - дыма нет - ставь штампик в паспорт - следующий! -- больше не прокатит , придется включать осцилл, смотреть в него и крутить ручки.
Но наш народ ушлый : когда система встала из-за незначительной поломки, первыми стали трезвонить в отдел именно регули. Они сообразили : АСК из врага можно обратить в союзника : суют ей плату только с монтажа , если не бракует, прямо ее на участок влагозащиты и на склад : есть отрегулированное изделие. А если нет , система терпеливо разъясняет : у вас такой-то канал бракуется по таким-то параметрам. Подкрутили, проверили - готово!
И чтоб поставить точку в рассказе о квалифицированном персонале : через месяц эксплуатации пришлось менять клавиатуру : ВПРАВО - ВЛЕВО - ВВЕРХ -ВНИЗ протерлись до дыр. Этими клавишами управлялась примитивная "стрелялка" на тогда еще алфавитно-цифровом дисплее...
Кажется, в какой-то форум я это уже того.. Если так, то сорри. Вот заведу себе блог, и там уж дам волю "все, что было не со мной, помню".

[Goldsmith]

Кажется, мы и не спорим, говорим об одном и том же, но только с разных сторон

Скорее обмениваемся мнениями по довольно интересному вопросу, который на самом деле куда глубже, чем кажется на первый взгляд. Спорить на эту тему, по-моему, вообще кощунственно: основные возражения сводятся к краткому "Незнание - сила!". Прямо Оруэлл, "1984".

СМ-4 стоила 75 тысяч ( 3 "Волги" ).

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

[Jack_A]

Ну и хорошо набитый модулями КАМАК сам по себе тоже не фунт изюму стоил. Впрочем, это уже оффтопик

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

[Goldsmith]

Хорошо, завязываем с оффтопиком.

Я не к тому, что вообще навсегда завязываем и даем обет молчания. Я про эту конкретную тему, которая от полного отрицалова ("народ не поймет", "народу это не нужно") плавно перешла к приятным мемуарам о былых деяниях. Лично я только за, лишь бы модераторы не высекли за нарушение порядка.

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