Escape the SW development paradigm trap

Loading thread data ...

Thu May 04 2006 22:08, Yuriy K wrote to All:

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

YK>

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

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

VLV

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

Reply to
Vladimir Vassilevsky

Fri May 05 2006 06:04, Vladimir Vassilevsky wrote to Yuriy K:

VV> From: "Vladimir Vassilevsky" snipped-for-privacy@fullnet.net VV> Thu May 04 2006 22:08, Yuriy K wrote to All: YK>> Интересные мысли Mark высказывает, хотя местами и спорные. YK>>

formatting link
YK>> 7 VV> Решительно осуждаю заказную статью :) VV> 1. С некоторых пор ESP стал вбивать в головы маркетинговую VV> идею многопроцессорности ради многопроцессорности. Всякий, кто хоть раз

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

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

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

Reply to
invalid unparseable

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

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

Reply to
Vladimir Vassilevsky

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

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

Reply to
Vladimir Vassilevsky
Reply to
George Shepelev

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

ГР> From: "Геральт Ривский" snipped-for-privacy@ispey.com ГР> Геральт из Ривии

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

VLV

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

Reply to
Vladimir Vassilevsky

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

VV> From: "Vladimir Vassilevsky" snipped-for-privacy@fullnet.net

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

ГР>> From: "Геральт Ривский" snipped-for-privacy@ispey.com ГР>> Геральт из Ривии

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

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

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

Reply to
Carnivore Shakespeares
Reply to
George Shepelev

П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аслина. :)

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

Reply to
Pavel Grishin

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

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

Reply to
Vladimir Vassilevsky
Reply to
Michael Belousoff

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

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

Reply to
Vladimir Vassilevsky

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

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

Reply to
Kirill Frolov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.