- posted
17 years ago
Escape the SW development paradigm trap
- Vote on answer
- posted
17 years ago
Thu May 04 2006 22:08, Yuriy K wrote to All:
YK> Интересные мысли Mark высказывает, хотя местами и спорные.
YK>
- С некоторых пор ESP стал вбивать в головы маркетинговую идею многопроцессорности ради многопроцессорности. Всякий, кто хоть раз сопрягал несколько процессоров в одном устройстве, знает, сколько усилий требуется на обеспечение корректных и быстрых интерфейсов всех со всеми. Гораздо проще раскладывать задачи на один процессор, чем делить ресурсы между несколькими. Это же, кстати, применимо и к творческому коллективу разработчиков :)
- Если хотите иметь идеальный софт, то он будет стоить в N раз дороже и разрабатываться в M раз дольше. Текущая структура разработки оптимизирована под реалии текущего маркета, только и всего.
VLV
"Клянусь всем тем, во что когда-либо верили дураки" (с) Вальтер Скотт
- Vote on answer
- posted
17 years ago
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>>
Любому манагеру очевидно, что 16 бит - лучше 8-и, 32 - лучше 16-и, а К танков - всегда мало. :) Если Intel не может более задирать тактовую частоту, то он будет втюхивать больше больше процессоров (и за бОльшие деньги) на том же кремнии, все остальные только "обезъянничают". VV> сопрягал несколько процессоров в одном устройстве, знает, сколько VV> усилий требуется на обеспечение корректных и быстрых интерфейсов всех
Вы видели поделия от Cradle, например?
Геральт из Ривии
- Vote on answer
- posted
17 years ago
- Vote on answer
- posted
17 years ago
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
"Клянусь всем тем, во что когда-либо верили дураки" (с) Вальтер Скотт
- Vote on answer
- posted
17 years ago
- Vote on answer
- posted
17 years ago
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
"Клянусь всем тем, во что когда-либо верили дураки" (с) Вальтер Скотт
- Vote on answer
- posted
17 years ago
- Vote on answer
- posted
17 years ago
Fri May 05 2006 07:56, Геральт Ривский wrote to Vladimir Vassilevsky:
ГР> From: "Геральт Ривский" snipped-for-privacy@ispey.com ГР> Геральт из Ривии
"Я дон Дрочилло знаменитый! Я - идеал испанских жен!" (c) Барков Скажите, благородный дон, вам случайно не знаком некто Коносевич, известный под прозвищем "Подлояд" ?
VLV
"Клянусь всем тем, во что когда-либо верили дураки" (с) Вальтер Скотт
- Vote on answer
- posted
17 years ago
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) Барков
Скажите, вы мудак по убеждениям или по жизни?
Быстрой смерти!
- Vote on answer
- posted
17 years ago
- Vote on answer
- posted
17 years ago
- Vote on answer
- posted
17 years ago
П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аслина. :)
-= Брест. Павел Гришин =-
- Vote on answer
- posted
17 years ago
- Vote on answer
- posted
17 years ago
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
"Клянусь всем тем, во что когда-либо верили дураки" (с) Вальтер Скотт
- Vote on answer
- posted
17 years ago
- Vote on answer
- posted
17 years ago
- Vote on answer
- posted
17 years ago
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
"Клянусь всем тем, во что когда-либо верили дураки" (с) Вальтер Скотт
- Vote on answer
- posted
17 years ago
Почему бы не пойти с другого конца. Инаписать HAL под конкретную задачу. А какой там будет таймер с какими режимами -- вопрос этого HAL. Таймер меняется путём смены всего HAL. Практически нужно HAL под целевое железо и один под эмуляцию.
Это не снимает необходимость написания -его либо, зато вводит совсем не единый и не совместимый, но понятный интерфейс. Что по сути более правильно. Разный HAL для разной аппаратной реализации и одинаковая логика во всех случаях. Тот же тахометр. Функция сложить и поделить -- она аппаратно-независима.
- Vote on answer
- posted
17 years ago