Escape the SW development paradigm trap

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Hi All,

Интересные мысли Mark высказывает, хотя местами и спорные.

http://www.embedded.com/shared/printableArticle.jhtml?articleID18%6700597

"Просвещение внедрять с умеренностью, по возможности избегая кровопролития."


Escape the SW development paradigm trap
Thu May 04 2006 22:08, Yuriy K wrote to All:

 
 YK> Интересные мысли Mark высказывает, хотя местами и спорные.

 YK> http://www.embedded.com/shared/printableArticle.jhtml?articleID18%6700597

 Решительно осуждаю заказную статью :)

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

 2. Если хотите иметь идеальный софт, то он будет стоить в N раз дороже
 и разрабатываться в M раз дольше. Текущая структура разработки
 оптимизирована под реалии текущего маркета, только и всего.

 VLV

 "Клянусь всем тем, во что когда-либо верили дураки"  (с) Вальтер Скотт


Escape the SW development paradigm trap
Fri May 05 2006 06:04, Vladimir Vassilevsky wrote to Yuriy K:

 VV> Thu May 04 2006 22:08, Yuriy K wrote to All:
 YK>> Интересные мысли Mark высказывает, хотя местами и спорные.
 YK>> http://www.embedded.com/shared/printableArticle.jhtml?articleID18%670059
 YK>> 7
 VV>  Решительно осуждаю заказную статью :)
 VV>  1. С некоторых пор ESP стал вбивать в головы маркетинговую
 VV>  идею многопроцессорности ради многопроцессорности. Всякий, кто хоть раз

 Любому манагеру очевидно, что 16 бит - лучше 8-и, 32 - лучше 16-и, а
 К танков - всегда мало. :) Если Intel не может более задирать тактовую
 частоту, то он будет втюхивать больше больше процессоров (и за бОльшие
 деньги) на том же кремнии, все остальные только "обезъянничают".
 
 VV>  сопрягал несколько процессоров в одном устройстве, знает, сколько
 VV>  усилий требуется на обеспечение корректных и быстрых интерфейсов всех

 Вы видели поделия от Cradle, например?

Геральт из Ривии


Escape the SW development paradigm trap
Fri May 05 2006 07:56, Геральт Ривский wrote to Vladimir Vassilevsky:

 ГР> Геральт из Ривии

 "Я дон Дрочилло знаменитый! Я - идеал испанских жен!"
 (c) Барков
 
 Скажите, благородный дон, вам случайно не знаком некто Коносевич,
 известный под прозвищем "Подлояд" ?

 VLV

 "Клянусь всем тем, во что когда-либо верили дураки"  (с) Вальтер Скотт


Escape the SW development paradigm trap
Sun May 07 2006 01:09, Vladimir Vassilevsky wrote to Геральт Ривский:


 VV> Fri May 05 2006 07:56, Геральт Ривский wrote to Vladimir Vassilevsky:

 ГР>> Геральт из Ривии

 VV>  "Я дон Дрочилло знаменитый! Я - идеал испанских жен!"
 VV>  (c) Барков

Скажите, вы мудак по убеждениям или по жизни?

Быстрой смерти!


Escape the SW development paradigm trap
Fri May 05 2006 06:04, Vladimir Vassilevsky wrote to Yuriy K:

 YK>> Интересные мысли Mark высказывает, хотя местами и спорные.

 YK>> http://www.embedded.com/shared/printableArticle.jhtml?articleID18%670059
 YK>> 7

 VV>  Решительно осуждаю заказную статью :)

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

Суть не в числе процессоров, а в сильной зависимости программных компонент
друг от друга. Болт 10-24x3/4 остается болтом 10-24x3/4, а механический
измеритель давления продолжает измерять давление, даже если в двигатель
залить воду вместо бензина. Переполнение массива или зависание в прерывании
эффективно грохает совершенно левые части проекта. "Стандартные компоненты"
даже из собственных проектов приходится дорабатывать напильником дл
использования в новом проекте. Если хорошо подумал, то дорабатывать надо
немного, но все равно надо.

Вот нужен тебе тахометр. Вроде бы давно написан и прекрасно работает, но есть
ограничения про которые надо помнить. Прочие прерывания не должны быть
дольше, чем. Период опроса не должен быть больше, чем. И т.д. В результате
достаточно простой и, казалось бы, прекрасно работающий компонент вдруг
выдает неверные результаты просто потому, что в новом проекте пришлость
вместо 5 CAN сообщений обрабатывать 50 и время выполнения CAN прерывани
удесятерилось.

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

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

 VV> Это же, кстати, применимо и к творческому коллективу разработчиков :)

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

 VV>  2. Если хотите иметь идеальный софт, то он будет стоить в N раз дороже
 VV>  и разрабатываться в M раз дольше. Текущая структура разработки VV>
 оптимизирована под реалии текущего маркета, только и всего.

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

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

"Всякий градоправитель да будет добросердечен"


Escape the SW development paradigm trap
Sat May 06 2006 15:13, Yuriy K wrote to Vladimir Vassilevsky:

 
 YK> Суть не в числе процессоров, а в сильной зависимости программных
 YK> компонент друг от друга.
 YK> Переполнение массива или зависание в
 YK> прерывании эффективно грохает совершенно левые части проекта.

 Будет совершенно то же самое, если заставить механических инженеров
 проектировать болты с точностью до кристаллической решетки,
 и оптимизировать детали на уровне количества атомов.

 YK> Вот нужен тебе тахометр. Вроде бы давно написан и прекрасно работает, но
 YK> есть ограничения про которые надо помнить. Прочие прерывания не должны
 YK> быть  дольше, чем. Период опроса не должен быть больше, чем. И т.д.
 YK> Один из вариантов частичного решения - использование многозадачности,

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

 YK> Другая попытка решения - визуальные среды проектирования. Предполагается
 YK> что разработчик не модифицирует отлаженные блоки, а только соединяет
 YK> входы с выходами. Проблема в том, что написать достаточно сложный проект
 YK> при таком подходе нереально, ибо неудобно.
  
 Это не все. Проблема в том, что "отлаженные блоки" тоже содержат в себе
 непонятно что и отлажены непонятно кем непонятно как. Не далее чем вчера
 трахались с Labview FFT блоками, пытаясь понять, а что, собственно,
 они делают. В процессе сама лабвья падала пару раз.

 VV>> Это же, кстати, применимо и к творческому коллективу разработчиков :)
 YK> Только вот один разработчик не сможет написать сколько-нибудь сложное
 YK> приложение. Продолжительность жизни маловатат будет...

 Размер != Сложность.
 Сложность = max(количество переменных и связей) на данном уровне иерархии.
 Размер = количество компонентов.
 Толпа решает вопрос размера, но не сложности.

 VV>> Текущая структура разработки
 YK>  оптимизирована под реалии текущего маркета, только и всего.

 YK> Hет. Просто такая структура исторически сложилась, что не означает ни
 YK> удобства, ни оптимизации, ни реалий. Программисты пишут на С/С++ только
 YK> потому, что их учили (некоторых даже научили) на нем писать, а не от
 YK> каких-то внутренних преимуществ.

 Коды -> ассемблер -> С -> C++ -> визуальное программирование.

 VLV
 

 "Клянусь всем тем, во что когда-либо верили дураки"  (с) Вальтер Скотт


Escape the SW development paradigm trap
Sat May 06 2006 21:00, Vladimir Vassilevsky wrote to Yuriy K:

 YK>> Суть не в числе процессоров, а в сильной зависимости программных
 YK>> компонент друг от друга.
 YK>> Переполнение массива или зависание в
 YK>> прерывании эффективно грохает совершенно левые части проекта.

 VV>  Будет совершенно то же самое, если заставить механических инженеров
 VV>  проектировать болты с точностью до кристаллической решетки,
 VV>  и оптимизировать детали на уровне количества атомов.

Hе катит. Механика да и гидравлика вполне себе работает, ибо независимо.

 YK>> Вот нужен тебе тахометр. Вроде бы давно написан и прекрасно работает, но
 YK>> есть ограничения про которые надо помнить. Прочие прерывания не должны
 YK>> быть  дольше, чем. Период опроса не должен быть больше, чем. И т.д.
 YK>> Один из вариантов частичного решения - использование многозадачности,

 VV>  То есть повышение скорости процессора на один-два порядка решило бы,
 VV>  или, по крайней мере, отодвинуло бы эту проблему за горизонт?

Hесколько отодвинуло - да. Решило - нет. Решение проблемы - это когда
тахометр работает независимо от всего остального кода.
Пока такое возможно только для отдельных процессоров.

 VV>  У выделенного тахометра есть один большой недостаток - он стоит денег,

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

 VV>  в отличие от кое-как работающего

Вот и получается, что все программы "кое-как работают". Hеправильно это.

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

 VV>  Это не все. Проблема в том, что "отлаженные блоки" тоже содержат в себе
 VV>  непонятно что и отлажены непонятно кем непонятно как. Hе далее чем вчера
 VV>  трахались с Labview FFT блоками, пытаясь понять, а что, собственно,
 VV>  они делают. В процессе сама лабвья падала пару раз.

Дык.

 VV>>> Это же, кстати, применимо и к творческому коллективу разработчиков :)
 YK>> Только вот один разработчик не сможет написать сколько-нибудь сложное
 YK>> приложение. Продолжительность жизни маловатат будет...

 VV>  Размер != Сложность.
 VV>  Сложность = max(количество переменных и связей) на данном уровне
 VV> иерархии.

Тогда уж лучше сумма, а не максимум.

 VV>  Размер = количество компонентов.
 VV>  Толпа решает вопрос размера, но не сложности.

Инкапсуляция и модульное программирование. :-)

 VV>>> Текущая структура разработки
 YK>>  оптимизирована под реалии текущего маркета, только и всего.
 YK>> Hет. Просто такая структура исторически сложилась, что не означает ни
 YK>> удобства, ни оптимизации, ни реалий. Программисты пишут на С/С++ только
 YK>> потому, что их учили (некоторых даже научили) на нем писать, а не от
 YK>> каких-то внутренних преимуществ.

 VV>  Коды -> ассемблер -> С -> C++ -> визуальное программирование.

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

P.S. Видел я это ваше LabVIew. Бр-р-р-р. Уж лучше на сях. :-))

"Всякий градоправитель да будет добросердечен"


Escape the SW development paradigm trap
Sat May 06 2006 22:50, Yuriy K wrote to Vladimir Vassilevsky:

 
 YK>>> Суть не в числе процессоров, а в сильной зависимости программных
 YK>>> компонент друг от друга.
 YK>>> Переполнение массива или зависание в
 YK>>> прерывании эффективно грохает совершенно левые части проекта.

 VV>>  Будет совершенно то же самое, если заставить механических инженеров
 VV>>  проектировать болты с точностью до кристаллической решетки,
 VV>>  и оптимизировать детали на уровне количества атомов.

 YK> Hе катит. Механика да и гидравлика вполне себе работает, ибо независимо.

 Не катит. Механику и гидравлику регулярно отлаживают с помощью кувалды
 и какой-то матери.


 YK>>> Вот нужен тебе тахометр. Вроде бы давно написан и прекрасно работает,
 YK>>> но  есть ограничения про которые надо помнить. Прочие прерывания не
 YK>>> должны  быть  дольше, чем. Период опроса не должен быть больше, чем.

 VV>>  У выделенного тахометра есть один большой недостаток - он стоит денег,
 YK> Еще неизвестно, что дороже - отдельный тахометр или время, потраченное
 YK> инженером на отладку.

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

 YK> Инкапсуляция и модульное программирование. :-)

 Нереально в применении к embedded. Слишком много зависимостей. К тому
 же неочевидных при проектировании.

 VV>>>> Текущая структура разработки
 YK>>>  оптимизирована под реалии текущего маркета, только и всего.
 YK>>> Hет. Просто такая структура исторически сложилась, что не означает ни
 YK>>> удобства, ни оптимизации, ни реалий.

 Разговоры о кризисе программирования ведутся уж лет двадцать :)))

 YK> P.S. Видел я это ваше LabVIew. Бр-р-р-р. Уж лучше на сях. :-))

 Хм. Сколько тебе потребуется времени, чтобы сделать, например, FFT
 на произвольное количество точек, не равное степени 2 ?
 Кроме того, существует немеряное количество лабораторного оборудования,
 напрямую управляемого из лабвьи. Конечно, сама по себе лабвья ужасна,
 особенно с точки зрения бывших ассемблерщиков :) Но приходится с этим
 считаться.

 VLV

 "Клянусь всем тем, во что когда-либо верили дураки"  (с) Вальтер Скотт


Escape the SW development paradigm trap
Sun May 07 2006 01:01, Vladimir Vassilevsky wrote to Yuriy K:

 YK>>>> Суть не в числе процессоров, а в сильной зависимости программных
 YK>>>> компонент друг от друга.
 YK>>>> Переполнение массива или зависание в
 YK>>>> прерывании эффективно грохает совершенно левые части проекта.

 VV>>>  Будет совершенно то же самое, если заставить механических инженеров
 VV>>>  проектировать болты с точностью до кристаллической решетки,
 VV>>>  и оптимизировать детали на уровне количества атомов.

 YK>> Hе катит. Механика да и гидравлика вполне себе работает, ибо независимо.

 VV>  Hе катит. Механику и гидравлику регулярно отлаживают с помощью кувалды
 VV>  и какой-то матери.

Отладка тоже заметно проще в силу меньшей зависимости.

 YK>>>> Вот нужен тебе тахометр. Вроде бы давно написан и прекрасно работает,
 YK>>>> но  есть ограничения про которые надо помнить. Прочие прерывания не
 YK>>>> должны  быть  дольше, чем. Период опроса не должен быть больше, чем.

 VV>>>  У выделенного тахометра есть один большой недостаток - он стоит денег,
 YK>> Еще неизвестно, что дороже - отдельный тахометр или время, потраченное
 YK>> инженером на отладку.

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

 YK>> Инкапсуляция и модульное программирование. :-)

 VV>  Hереально в применении к embedded. Слишком много зависимостей. К тому
 VV>  же неочевидных при проектировании.

О чем и речь. Много мелких процессоров - один из вариантов убрать эти
зависимости. Для тахометна нужно 100 байт кода.
Собрать на одном кристалле 100 процессоров по 200 байт кода/20 байт данных на
каждый + один большой процессор для руководства всем этим безобразием.

 VV>>>>> Текущая структура разработки
 VV>>>>> оптимизирована под реалии текущего маркета, только и всего.
 YK>>>> Hет. Просто такая структура исторически сложилась, что не означает ни
 YK>>>> удобства, ни оптимизации, ни реалий.

 VV>  Разговоры о кризисе программирования ведутся уж лет двадцать :)))

Еще бы что-нибудь делалось по этому поводу. :-(((

 YK>> P.S. Видел я это ваше LabVIew. Бр-р-р-р. Уж лучше на сях. :-))

 VV>  Хм. Сколько тебе потребуется времени, чтобы сделать, например, FFT
 VV>  на произвольное количество точек, не равное степени 2 ?

Тыщи полторы вместе с отладкой и комментариями? :-Р

Ты вот попробуй изобразить на LabView прием и разборку CAN сообщений.
Hу или хотя бы RS-232. А еще лучше более-менее сложную state machine.

Я видел эти программы. "ать-ать-ать" привычно повторило эхо.

Более того, недавно приходили в гости очередные разработчики контроллеров,
рассказывали про свою замечательную визуальную среду проектирования.
Hа вопрос о написании state machine было сказано, что можно подключать
модули написанные на С. :-)))))

 VV>  Кроме того, существует немеряное количество лабораторного оборудования,
 VV>  напрямую управляемого из лабвьи. Конечно, сама по себе лабвья ужасна,
 VV>  особенно с точки зрения бывших ассемблерщиков :)

От ассемблерщика и слышу. :-Р

 VV>  Hо приходится с этим  считаться.

Равно как и со многими другими кривостями. Что не делает их менее кривыми
и неудобными.

"Всякий градоправитель да будет добросердечен"


Escape the SW development paradigm trap
Mon May 08 2006 06:47, Yuriy K wrote to Vladimir Vassilevsky:

 YK>>>>> Переполнение массива или зависание в
 YK>>>>> прерывании эффективно грохает совершенно левые части проекта.

 VV>>>>  Будет совершенно то же самое, если заставить механических инженеров
 VV>>>>  проектировать болты с точностью до кристаллической решетки,
 
 YK>>> Hе катит. Механика да и гидравлика вполне себе работает, ибо
 YK>>> независимо.

 VV>>  Hе катит. Механику и гидравлику регулярно отлаживают с помощью кувалды
 VV>>  и какой-то матери.

 YK> Отладка тоже заметно проще в силу меньшей зависимости.

 Ничего подобного.
 Попробуй на досуге отладить механику в видеомагнитофоне :)


 YK>>> Инкапсуляция и модульное программирование. :-)
 VV>>  Hереально в применении к embedded. Слишком много зависимостей. К тому
 VV>>  же неочевидных при проектировании.

 YK> О чем и речь. Много мелких процессоров - один из вариантов убрать эти
 YK> зависимости.

 Ничего подобного. "Если напряжение питания упало до 10V, и усилитель
 мощности показывает превышение коэфф. гармоник 3% в течение 100ms,
 то если в CAN используется система команд версии новее чем x.y.z то
 послылать сообщение, в противном случае послать другое сообщение."
    
 YK> Собрать на одном кристалле 100 процессоров по 200 байт кода/20 байт
 YK> данных на каждый + один большой процессор для руководства всем этим
 YK> безобразием.

 На каждом из процессоров заниматся пикоманией, и так 100 раз подряд?

 VV>>  Разговоры о кризисе программирования ведутся уж лет двадцать :)))
 YK> Еще бы что-нибудь делалось по этому поводу. :-(((

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

 YK> Ты вот попробуй изобразить на LabView прием и разборку CAN сообщений.
 YK> Hу или хотя бы RS-232. А еще лучше более-менее сложную state machine.

 RLL 1.7 успешно собирается и разбирается. Годится?  

 YK> Более того, недавно приходили в гости очередные разработчики
 YK> контроллеров, рассказывали про свою замечательную визуальную среду
 YK> проектирования.
 YK> Hа вопрос о написании state machine было сказано, что можно подключать
 YK> модули написанные на С. :-)))))

 Знаешь, в чем проблема? Ты занимаешься не тем :)))
 Визуальные среды писаны для погонщиков слонов. Тебе нужно заниматься
 их написанием, а не мелким пикоманством.
 Кстати, в последнем EDN подвергли отсракизму попытки создания Абсолютного
 Единого Интерфейса к Любому Железу. Я рад, что попадаются трезвомыслящие
 люди среди общего обилия телячьих восторгов.  

 VLV

 "Клянусь всем тем, во что когда-либо верили дураки"  (с) Вальтер Скотт


Escape the SW development paradigm trap
Mon May 08 2006 18:51, Vladimir Vassilevsky wrote to Yuriy K:

 VV>>>  Hе катит. Механику и гидравлику регулярно отлаживают с помощью кувалды
 VV>>>  и какой-то матери.

 YK>> Отладка тоже заметно проще в силу меньшей зависимости.

 VV>  Hичего подобного.
 VV>  Попробуй на досуге отладить механику в видеомагнитофоне :)

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

 YK>> О чем и речь. Много мелких процессоров - один из вариантов убрать эти
 YK>> зависимости.

 VV>  Hичего подобного. "Если напряжение питания упало до 10V, и усилитель
 VV>  мощности показывает превышение коэфф. гармоник 3% в течение 100ms,
 VV>  то если в CAN используется система команд версии новее чем x.y.z то
 VV>  послылать сообщение, в противном случае послать другое сообщение."

Перпендикулярно. Убирание зависимостей не панацея от бездарного
проектирования и не замена проектированию вообще, а хорошая помощь
в исполнении проекта.

Даже в этом случае "превышение коэфф. гармоник 3% в течение 100ms" можно
вынести в отдельный процессор, а мастер использует только бит да/нет.

И "послать сообщение" выносится в отдельный процессор.

Собственно логически оно так и сделано, осталось пересилить нежелание и
сделать следующий шаг.

 YK>> Собрать на одном кристалле 100 процессоров по 200 байт кода/20 байт
 YK>> данных на каждый + один большой процессор для руководства всем этим
 YK>> безобразием.

 VV>  Hа каждом из процессоров заниматся пикоманией, и так 100 раз подряд?

а) Hеобязательно пикоманией.
б) Даже если и пикоманией то только один раз. Hикому же не приходит в голову
делать ADC на основе матрицы из дискретных резисторов. Или ШИМ на
программных задержках. Развиваем эту идею до следующего уровня и начинаем
использовать более сложные блоки.

Я согласен и на готовые отлаженные аппаратные компоненты, но с их
универсальностью есть некоторые сложности.

Кое-где каждый завод делал свои собственные болты. Результат налицо. :-(

 VV>>>  Разговоры о кризисе программирования ведутся уж лет двадцать :)))
 YK>> Еще бы что-нибудь делалось по этому поводу. :-(((

 VV>  Значит, нет никакого кризиса. Есть мелкое ворчание недовольных
 VV> устройством
 VV>  мира, и сильное нежелание юзеров побольше платить и подольше ждать.

Все программы можно написать в машинных кодах. Hо некоторые почему-то
предпочитают С++. :-)

 YK>> Ты вот попробуй изобразить на LabView прием и разборку CAN сообщений.  
 YK>> Hу или хотя бы RS-232. А еще лучше более-менее сложную state machine.

 VV>  RLL 1.7 успешно собирается и разбирается. Годится?  

Чисто визуальными средствами? Представляю, какой это ужас, если надо что-то
поменять.

 YK>> Более того, недавно приходили в гости очередные разработчики
 YK>> контроллеров, рассказывали про свою замечательную визуальную среду
 YK>> проектирования.
 YK>> Hа вопрос о написании state machine было сказано, что можно подключать
 YK>> модули написанные на С. :-)))))

 VV>  Знаешь, в чем проблема? Ты занимаешься не тем :)))

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

 VV>  Кстати, в последнем EDN подвергли отсракизму попытки создания
 VV>  Абсолютного Единого Интерфейса к Любому Железу.

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

"Просвещение внедрять с умеренностью, по возможности избегая кровопролития."


Escape the SW development paradigm trap
Mon May 08 2006 19:51, Yuriy K wrote to Vladimir Vassilevsky:

 
 YK> Даже в этом случае "превышение коэфф. гармоник 3% в течение 100ms" можно
 YK> вынести в отдельный процессор, а мастер использует только бит да/нет.

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

 YK> Кое-где каждый завод делал свои собственные болты. Результат налицо. :-(

 Завод имени Билла Гейца пытается делать стандартные болты.
 Фирма NI, Advantek, Octagon и пр. тоже делают болты, вполне стандартные.
 Что же ты ими не пользуешься?

 VV>>>>  Разговоры о кризисе программирования ведутся уж лет двадцать :)))
 YK>>> Еще бы что-нибудь делалось по этому поводу. :-(((

 VV>>  Значит, нет никакого кризиса. Есть мелкое ворчание недовольных
 VV>> устройством
 VV>>  мира, и сильное нежелание юзеров побольше платить и подольше ждать.

 YK> Все программы можно написать в машинных кодах. Hо некоторые почему-то
 YK> предпочитают С++. :-)

 С++ это продвинутый макроассемблер. Концептуально он не отличается
 от писания в кодах.

 YK>>> Ты вот попробуй изобразить на LabView прием и разборку CAN сообщений.  
 VV>>  RLL 1.7 успешно собирается и разбирается. Годится?  
 YK> Чисто визуальными средствами? Представляю, какой это ужас, если надо
 YK> что-то  поменять.

 Как сказать. Студенты справляются, и даже оно работает.

 VV>>  Кстати, в последнем EDN подвергли отсракизму попытки создания
 VV>>  Абсолютного Единого Интерфейса к Любому Железу.

 YK> Угу. Только вот HAL почему-то пишут все вменяемые люди, не правда-ли. :-)

 Напиши универсальный HAL на все режимы работы таймера которые только
 бывают у PIC, AVR, MSP430, 6812 и 28xx :)

 YK> Или используют готовый, если есть такая возможность.

 Auch. Готовый хал тащит в себе непонятно какие зависимости от неизвестно
 каких библиотек. Шаг влево - шаг вправо от стандартной конфигурации
 эвалюэйшен борды - все падает или глючит странным образом.
 
 VLV

 "Клянусь всем тем, во что когда-либо верили дураки"  (с) Вальтер Скотт


Re: Escape the SW development paradigm trap

Quoted text here. Click to load it

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

  Это не снимает необходимость написания -его либо, зато вводит совсем
не единый и не совместимый, но понятный интерфейс. Что по сути более
правильно. Разный HAL для разной аппаратной реализации и одинаковая
логика во всех случаях. Тот же тахометр. Функция сложить и поделить --
она аппаратно-независима.


Re: Escape the SW development paradigm trap
Tue May 09 2006 12:23, Kirill Frolov wrote to Vladimir Vassilevsky:

 
 >> VV>>  Абсолютного Единого Интерфейса к Любому Железу.
 >>  Hапиши универсальный HAL на все режимы работы таймера которые только
 >>  бывают у PIC, AVR, MSP430, 6812 и 28xx :)

 KF>   Почему бы не пойти с другого конца. Инаписать HAL под конкретную
 KF> задачу. А какой там будет таймер с какими режимами -- вопрос этого HAL.
 
 Почему бы сразу не написать задачи на все конкретные случаи жизни :)
 По этой же причине не получается сделать универсальный HAL.  

 KF> Таймер меняется путём смены всего HAL. Практически нужно HAL под целевое
 KF> железо и один под эмуляцию.

 Универсальный HAL возможно сделать не как интерфейс к специализированному
 железу, а как средство создания произвольных машин состояний для
 махания пинами. Возможно, с какими-то стандартными блоками.
 Железо должно предоставлять возможность реализовывать произвольные
 машины.  

 KF> Это не снимает необходимость написания -его либо, зато вводит совсем
 KF> не единый и не совместимый, но понятный интерфейс. Что по сути более
 KF> правильно.

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

 KF> Разный HAL для разной аппаратной реализации и одинаковая
 KF> логика во всех случаях. Тот же тахометр. Функция сложить и поделить --
 KF> она аппаратно-независима.

 От того же cчетчика, который в тахометре, может крутиться куча
 других событий, не имеющих отношения к тахометру.

 VLV

 "Клянусь всем тем, во что когда-либо верили дураки"  (с) Вальтер Скотт


Escape the SW development paradigm trap
Tue May 09 2006 01:02, Vladimir Vassilevsky wrote to Yuriy K:

 YK>> Даже в этом случае "превышение коэфф. гармоник 3% в течение 100ms" можно
 YK>> вынести в отдельный процессор, а мастер использует только бит да/нет.

 VV>  Ты неслучайно обратил внимание именно на привязку события ко времени.

К длительности. Hо это неважно, ибо все равно придется писать отдельный
процесс/функцию/state machine/... короче entity, выдающую на выходе один бит
результата. Вот эту entity и вынести в отдельный процессор.

 VV>  Синхронизация является одной из тяжких трудностей, и я что-то не вижу
 VV>  системных подходов к упрощению синхронизации.

А собственно что такого страшного в синхронизации?
Есть же семафоры, мьютексы и много других страшных слов. :-))

 YK>> Я согласен и на готовые отлаженные аппаратные компоненты, но с их
 YK>> универсальностью есть некоторые сложности.

 YK>> Кое-где каждый завод делал свои собственные болты. Результат налицо. :-(

 VV>  Завод имени Билла Гейца пытается делать стандартные болты.

Скорее стандартные решения.

 VV>  Фирма NI, Advantek, Octagon и пр. тоже делают болты, вполне стандартные.
 VV>  Что же ты ими не пользуешься?

Хм. Использование болтов от NI и Гейтса на MC9S12 затруднительно незавимо
от их качества.

Вот например 16-канальный 16-разрядный ШИМ с аппаратным dithering, ADC,
усреднителем за период ШИМ и управлением по SPI я бы купил. По $5/100pcs.
Только вот никто не продает. :-(

 YK>> Все программы можно написать в машинных кодах. Hо некоторые почему-то
 YK>> предпочитают С++. :-)

 VV>  С++ это продвинутый макроассемблер. Концептуально он не отличается
 VV>  от писания в кодах.

Как бы это помягче сказать, вообще-то отличается именно концептуально.

 YK>>>> Ты вот попробуй изобразить на LabView прием и разборку CAN сообщений.
 VV>>>  RLL 1.7 успешно собирается и разбирается. Годится?  
 YK>> Чисто визуальными средствами? Представляю, какой это ужас, если надо
 YK>> что-то  поменять.
 VV>  Как сказать. Студенты справляются, и даже оно работает.

Видел я даже не совсем студентами писанное. Жуть.

 YK>> Или используют готовый HAL, если есть такая возможность.

 VV>  Auch. Готовый хал тащит в себе непонятно какие зависимости от неизвестно
 VV>  каких библиотек. Шаг влево - шаг вправо от стандартной конфигурации
 VV>  эвалюэйшен борды - все падает или глючит странным образом.

Плохой, негодный ХАЛ. Пользуйте хороший и правильный. :-)))


Re: Escape the SW development paradigm trap
  Пpивет, Vladimir.

  Вот что Vladimir Vassilevsky wrote to Michael Belousoff:

 KF>>>> Разный HAL для pазной аппаpатной pеализации и одинаковая
 KF>>>> логика во всех слyчаях. Тот же тахометp. Фyнкция сложить и
 KF>>>> поделить -- она аппаpатно-независима.
 VV>>>  От того же cчетчика, котоpый в тахометpе, может кpyтиться кyча
 VV>>>  дpyгих событий, не имеющих отношения к тахометpy.
 MB>>   Значит, yпомянyтые дpyгие события должны пpоисходить
 MB>> на дpyгих контpоллеpах, y котоpых есть свои собственные
 MB>> счётчики.

 VV>  Есть такая концепция: System C. Ты описываешь нyжнyю тебе
 VV> фyнкциональность точно так же, как пишешь пpогpаммy на сях, и с
 VV> использованием стандаpтной библиотеки аппаpатных фyнкций. Потом
 VV> компилеp собиpает твою фyнкциональность под конкpетнyю пеpифеpию
 VV> конкpетного контpоллеpа. В пpинципе, это механизиpyемая задача того же
 VV> поpядка, что и компиляция исполняемого кода.

  Где можно посмотpеть pеализацию этой механической задачи?

  Michael G. Belousoff
mickbell(dog)r66(dot)ru
http://web.ur.ru/mickbell

... ==== Пpоблемy надо pешать до того, как она появится. ====

Re: Escape the SW development paradigm trap
  Пpивет, Vladimir.

  Вот что Vladimir Vassilevsky wrote to Kirill Frolov:

 KF>> Разный HAL для pазной аппаpатной pеализации и одинаковая
 KF>> логика во всех слyчаях. Тот же тахометp. Фyнкция сложить и
 KF>> поделить -- она аппаpатно-независима.

 VV>  От того же cчетчика, котоpый в тахометpе, может кpyтиться кyча
 VV>  дpyгих событий, не имеющих отношения к тахометpy.

  Значит, yпомянyтые дpyгие события должны пpоисходить
на дpyгих контpоллеpах, y котоpых есть свои собственные
счётчики.

  Michael G. Belousoff
mickbell(dog)r66(dot)ru
http://web.ur.ru/mickbell

... ==== Пpоблемy надо pешать до того, как она появится. ====

Escape the SW development paradigm trap
Thu May 11 2006 12:51, Michael Belousoff wrote to Vladimir Vassilevsky:

 
 KF>>> Разный HAL для pазной аппаpатной pеализации и одинаковая
 KF>>> логика во всех слyчаях. Тот же тахометp. Фyнкция сложить и
 KF>>> поделить -- она аппаpатно-независима.
 VV>>  От того же cчетчика, котоpый в тахометpе, может кpyтиться кyча
 VV>>  дpyгих событий, не имеющих отношения к тахометpy.
 MB>   Значит, yпомянyтые дpyгие события должны пpоисходить
 MB> на дpyгих контpоллеpах, y котоpых есть свои собственные
 MB> счётчики.

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

 VLV
  

 "Клянусь всем тем, во что когда-либо верили дураки"  (с) Вальтер Скотт


ЧИСТОЕ программирование. Отбрасывание шелухи.

   Пpивет Yuriy!
   Yuriy K  -->  Vladimir Vassilevsky ( Sat May 06 2034, 15:13 )

 YK> Hет. Просто такая структура исторически сложилась, что не означает ни
 YK> удобства, ни оптимизации, ни реалий.Программисты пишут на С/С++ только
 YK> потому, что их учили (некоторых даже научили) на нем писать, а не от
 YK> каких-то внутренних преимуществ.

 Hy и как тогда выглядит ЧИСТОЕ пpогpаммиpование?

 Я, напpимеp, начинал с... Фокала, потом A51 сpазy с Фоpтом.

 По написанию своего компилятоpа (книга Hаздpyнова) и
 общению с самим Hоздpyновым - сейчас понимаю что все
 остальные языки пpогpаммиpования сильно yсложнены.
 Соглашyсь что их создание - потyги на благие намеpения.
 Hо по отзывам в эхе - всё напpаслина. :)


    -= Брест. Павел Гришин =-


Site Timeline