Помощь в определении назначения схемы

[omercury]

"О загадочном дефекте электроусилителя рулевого управления «Калины»"
http://forums.drom.ru/piter/t1151123906.html

22.12.2008 09:55 #13
ski_ner


P.S. - и на такие авто нас хочет пересадить Путин ?! Он че ? - идиот ???!

Нет.
Он страну от идиотов чистит.

[KGN]

Я ответил всего лишь на утверждение, что применение именно динамических компонентов цифровой техники "опускает отказоустойчивость", в отличие от статической логики, ниже плинтуса.

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

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

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

А о "Калине" не надо. Это Вы опять теплое с мягким сравнивать начинаете.

[suriCat]

Вставлю свои 5 копеек. Несколько лет назад был на семинаре Atmel в Rainbow. Несколько человек пристали к фирмачу с вопросом, почему иногда слетает прошивка? В конце концов фирмач признался, что такое имеет место быть, но это возникает из-за применения FLASH памяти, причем не только у Atmel, но и у других производителей. Разработчики чипов здесь не причем. Программисты - тем более. Поэтому для ответственных применений применяют однократно программируемые МК (в сети можно найти информацию по этому поводу).

[mikaleus]

Ко мне как-то приезжал (года 3 назад, после того как приобрел это средство передвижения) дружище с проблемой электроусилителя руля - типа тянет в одну сторону. Причина оказалась банальной - лопнул SMD диод типа LL4148 или LL 4448. Был установлен на то место BAS32... Всё до сих пор работает.

[KGN]

это возникает из-за применения FLASH памяти, причем не только у Atmel, но и у других производителей. Разработчики чипов здесь не причем. Программисты - тем более. Поэтому для ответственных применений применяют однократно программируемые МК

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

[avp94]

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

Хочу пример этой однозначности в случае реализации функции инверсии ("не")!.

[KGN]

Хочу пример этой однозначности в случае реализации функции инверсии ("не")!.

Да елки ж палки!
Может сначала научимся читать все, а не выборочно? И говорить по существу? А уж потом хотеть примеры?
Или мне чего, в каждом свое посте заново и заново повторять все то, что я уже говорил во многих предыдущих?!
Русским по белому уже было сказано о том, что данное мое утверждение относится к тем логическим схемам, где присутствует динамика! А не к чистой статике!

[omercury]

Да елки ж палки!

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

[avp94]

Русским по белому уже было сказано о том, что данное мое утверждение относится к тем логическим схемам, где присутствует динамика! А не к чистой статике!

А что такое динамика в логических схемах в Вашем понимании?

[KGN]

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

Нравится/не нравится - это больше в оценках девушек подходит, а не схемных решений
В конце 70-х и в 80-х годах прошлого века мне очень нравилось конструировать схемы на "жесткой" логике. Таких монстров на 133-й и 564-й сериях рожали - о-го-го! Но факт есть факт - сейчас схемы на МК таки надежнее. И чем сложнее функционал схемы, тем больше у устройства на МК отрыв в надежности от его аналога на рассыпухе.
Если не согласны, то приведите хотя бы один внятный и обоснованный аргумент, подтверждающий Вашу позицию. Подтвердите ее хоть чем-то.

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