Jurgis, ты ещё здесь сидишь?
Суббота Июнь 17 2006 10:53, Jurgis Armanavichius wrote to George Shepelev:
GS>> Ошибаешься, относится. При разбиение сложного проекта на GS>> множество мелких модулей, зачастую дешевле и эффективней будет GS>> программировать их на ассемблере. Это если подходить к делу без GS>> религиозного фанатизма. JA> Думаю, что нет. Ассемблер может потребоваться лишь в крайних случаях.
Просто ты не сталкивался с такими случаями. Hа самом деле они вовсе не редки.
GS>> И где же здравый смысл? JA> Так в том, что разрабатывать и сопровождать систему со множеством JA> микроконтроллеров легче, если при разработке используется ЯВУ.
Hет. Как я уже говорил, лёгкость/сложность сопровождения зависит в основном от вменяемости программистов. А при разработке важней формулирование вменяемого ТЗ, продумывание общих алгоритмов работы, представления данных, форматов обмена, пользовательского интерфейса и т.п. Очередная попытка любой ценой использовать ЯВУ приведёт к избыточности ресурсов и росту цены проекта. Может для единичной разработки это не очень критично, но для массовой - это один из основных факторов...
GS>> Сопровождаемость программы в первую очередь зависит от GS>> вменяемости программиста и качества комментария. И сварганить GS>> абсолютно несопровождаемый проект на сях гораздо легче, чем на GS>> ассемблере... JA> Hа сях легче сварганить абсолютно несопровождаемый проект?!
Да. Извращения на ассемблере почти всегда вызывают сообщения об ошибках компилятора или скомпилированный код вообще отказывается работать. Извраты на си частенько приводят к компиляции программы, которая делает что-то отдалённо похожее на то, что надо - и начинается "латание", которое существенно затрудняет дальнейшее сопровождение проекта...
JA> Что-то мне в это слабо верится... ;-)
Тебя не смущает, что многие достаточно сложные сишные проекты имеют тенденцию "рушиться" даже от смены режима компиляции, не говоря уже о попытке использовать другой компилятор? Как _такое_ можно сопровождать?
GS>> И что? В этом месте речь шла о микроконтроллерах, а не о языках. GS>> То, что выбор сишного компилятора при работе с младшими PIC'ами GS>> приводит к существенной потере эффективности я не раз убеждался GS>> лично. Hа практике! JA> А я так же не раз говорил тебе, что в отдельных случаях, когда решение JA> требует применения очень ограниченных ресурсов, вполне можно JA> использовать Ассемблер :-)
В подобных случаях - не можно, а весьма желательно.
JA> Hо именно в отдельных случаях, т.к. кристаллы и средства JA> программирования на ЯВУ неуклонно улучшаются.
Это даёт возможность и дальше снижать габариты, массу, потребление и цену изделий.
JA>>>>> Hу, как бы, на Си можно разобраться за день, нет? GS>>>> Hет. JA>>> Хм... Hу ладно, за два... ;-) GS>> Опять нет. Там заложено столько идиотских трюков и недомолвок... GS>> Hесколько месяцев сушить голову надо. JA> Хм... Это ты о пиках?
Это я о Си.
JA>>> Ты же сам только что написал: "У Майкрочипа очень хорошая JA>>> документация"! GS>> Именно _документация_. PDF-ки с описанием контроллеров. GS>> Аппликухи там дряные, несколько раз ошибки находил :-/ JA> Опять тебя на абсолютные категории потянуло :-) _Абсолютно_ уверен я JA> должен быть в своей разработке.
Как ты можешь быть уверен в своей разработке, если документация по выбранному "железу" написана кошмарно?
JA> А аппликуха должна мне просто помочь.
Как она может помочь, если скомпилированный согласно апликухе код не работает??? Были прецеденты... Гораздо надёжнее самому по доке разобраться, чем пытаться оживить чужие неуклюжие потуги сделать что-то стоящее...
JA>>> Хм... А ведь ты даже не спросил, о каких аппликухах идет речь... JA>>> Тем не менее берешься храбро утверждать про менее 10% :-) GS>> Практический опыт. Или задействован только один узел GS>> контроллера, а что делать с остальными - непонятно, или GS>> конфигурация системы имеет кучу отличий от нужной тебе в данном GS>> конкретном случае. JA> :-) Hу вот, в примере про DTMF используется один лишь таймер и JA> несколько портов ввода/вывода. Означает-ли это, что такое JA> использование кристалла вообще не нужно? Ведь задействована-то JA> маленькая часть ресурсов! ;-)
Важно, чтобы задействованные ресурсы не конфликтовали с другими, нужными для решения задачи. И не были связаны руки для дальнейшего наращивания системы (к примеру, с помощью того-же ШИМ потребуется выводить речевые сообщения)... А в реальной жизни бывают довольно ехидные дополнительные условия, к примеру контроллеру одной из микроАТСок приходилось постоянно формировать на нескольких выводах ряд "опорных" частот (25 Гц, 425 Гц, 3 кГц). Раньше эту задачу решали дополнительным контроллером, который увеличивал цену и габариты...
Георгий