Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Вс май 28, 2017 5:35 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 18 сообщений ]  На страницу 1 2 След.
Автор Сообщение
СообщениеДобавлено: Вс апр 24, 2011 6:31 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Поскольку дискуссия по теме "Колибри в робототехнике" становится всё более нервной,
предлагаю обсуждать аппаратные, кинематические и электромеханические проблемы в этой ветке.

Напоминаю, что для облегчения анализа, дополнения и критического осмысления
некоторые дискуссионные материалы вынесены на Вики для совместного редактирования:

http://wiki.kolibrios.org/wiki/Embedded_Platforms/ru
(список будет дополняться)

Чтобы сильно не растекаться мыслью по сабжу, советую время от времени сверяться с двумя центральными вопросами:

1) если в робототехнике - то почему на платформе x86 ?
2) если х86 - то почему именно в Колибри ?

Серьёзые ответы на эти вопросы позволяют сразу же очертить (очень узкий) круг перспективных применений Колибри в робототехнике и не отвлекаться на другие темы.


Вернуться к началу
СообщениеДобавлено: Вс апр 24, 2011 6:45 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пн апр 16, 2007 6:38 pm
Сообщения: 1222
"1) если в робототехнике - то почему на платформе x86 ?" - адекватный ассемблер с кучей документации имеет место быть
"2) если х86 - то почему именно в Колибри ?" - ну хотя бы вот тут, много причин

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!


Вернуться к началу
СообщениеДобавлено: Пн апр 25, 2011 12:44 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Gluk писал(а):
"1) если в робототехнике - то почему на платформе x86 ?" - адекватный ассемблер с кучей документации имеет место быть
"2) если х86 - то почему именно в Колибри ?" - ну хотя бы вот тут, много причин
Очень неглубокие ответы. Особенно улыбнуло насчет адекватного ассемблера.
И вообще причем тут ассемблер? Выбор платформы определяется требованиями ТЗ, причём решение принимает не программист после детального анализа всех возможных вариантов.

Первый вопрос - самый важный. Каким может быть предмет ТЗ, чтобы разработчик остановился именно на платформе PC х86 ?
Да еще в робототехнике, где не должно быть ничего лишнего, избыточного ?

разумных вариантов ответов немного:
а) промышленные роботы.
Здесь нет ограничений по стоимости, массе и энергопотреблению, да и по габаритам они не очень жёсткие. Важна производительность и надёжность, простота наладки и апгрейда. Однако для Колибри в этом секторе ниши нет и не будет.

б) автопилоты и системы дистанционного управления транспортными средствами.
Интересная и весьма перспективная область применения для (х86 + Колибри), только с робототехникой как-то слабо связана.

в) быстрые колёсные и плавающие роботы
с достаточными бортовыми энергоресурсами. Несмотря на некоторые массогабаритные ограничения, перспективы здесь очень заманчивы.

г) машины с динамической поддержкой равновесия (шагающие роботы, скутеры и т.п).
- ?

д) дроны
проблемы с массой и габаритами.

е) (добавлено по совету VaStaNi) если существующие схемы управления требуют наличия в системе отлаженных на х86-архитектуре специфических аппаратных ресурсов (устройств, контроллеров, мостов и системных шин), причем эффективной поддержки этих ресурсов в других системах нет.

ё) и кое-что ещё


Последний раз редактировалось art_zh Вт апр 26, 2011 5:57 pm, всего редактировалось 1 раз.

Вернуться к началу
СообщениеДобавлено: Пн апр 25, 2011 10:18 am 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
Тема мутная, какая то. Считаю, что возникла на эмоциях.
Либо название нужно другое, более конкретное...
Либо "рамки" ее нужно, как то более прорисовать...
У Колибри вообще исторически-архитектурно многие проблемы...

Роботы и иже с ними, например АСУ ТП, и т.д. это вообще частный случай совокупности проблем. Об этом надо сразу оговорить наверное.
Очертить типа "тематический круг проблем" хотя бы. Системотехнические проблемы, как то это вообще типа.
x86 я бы оставил в покое, как де факто.
Мне видится важным, например, тут сконцентрировать взгряд на аппаратную ограниченность платформы PC (от неё никуда не деться) и что можно действительно с этим НЕбогатством решить по сути и по факту, если опираться на сложившееся "сегодня".
Выявление существенных проблем, является важным для правильного приложения сил в развитии любой оси.
Ну как быстрый пример - видеозрение.


Вернуться к началу
СообщениеДобавлено: Вт апр 26, 2011 11:43 am 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
art_zh писал(а):
Первый вопрос - самый важный. Каким может быть предмет ТЗ, чтобы разработчик остановился именно на платформе PC х86 ?
ну ладно, уболтал, немного пройдемся танковыми треками по твоему "самый важный" :mrgreen:

- совместимость кода ПО, как такового, как до проектирования, так и после. И все что из этого вытекает в плюсах выбора. Собствненно тут, как бы известная классика предпроектного анализа и выбора.
Сюда попадает и среда разработки и либы и отладка + отладчики и дальнейшее сопровождение и т.д. Т.е. все аналогично ТЗ на "обычное ПО" на РС платформе

- специфические вещи, которые на x86 выполнены и решены успешно и альтернативы либо нет, либо дорого, либо неудобно, неперспективно на другом. Пусть, как пример видеозахват 16 камер видеонаблюдения (MPEG потоков) их реальный скан на движение, "складирование" и сигналы тревога, опасность, с учетом категорийности опасности присвоенные по факту видеоанализа картинки типа.
Вот на чём можно решить сейчас? Я думаю мысли почти автоматически "поплывут" в x86 сторону и в готовые или полуготовые либы, исходники.....

- производительность, которая требуется для решения задачи. Современные шины PC архитектур. Все это тоже в x86 укажет. Несмотря на то, что гонка за PC, например со стороны все того же ARM происходит, но в ряде условий выбор в сторону x86, будет гарантирован
Сюда же можно отнести и грамотное использование многоядерности, распределительных механизмов эффективных вычислений, требование по "гарячему резервированию" вычислительного процесса(ов) другими ядрами на аппаратном уровне, 100% дублирование, троирование и т.д.

- наличие в x86 4 кольцевого защищенного режима, потенциально позволяет делать очень надежные системы.
Просто не надо тупить и преврашать проц и ОСь в полное полено, используя только ринг 0 и ринг 3!
Я давно против этого. Лично мои планы давно "простираются" на все 4-ре уровня защиты. Неубиенная ОСь пока не создана никем.
Не вижу проблем, чтобы ядро работало на уровне 1, а на уровне 0 работал супервизор! Не забываем и про SMM!!!
(тут полезно вспомнить для наглядности, например, как оживал терминатор, оценивая и "подымая" подсистемы, которые еще что то могут делать, будучи "совсем убитым", растерзанным на куски...)

Хватит в качестве преамбулы в пользу x86? :D


Вернуться к началу
СообщениеДобавлено: Вт апр 26, 2011 12:18 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Вт авг 25, 2009 4:45 pm
Сообщения: 788
SMM - глючный легаси набор костылей.
Да и еще огромная дыра в безопасности:

http://tracker.coreboot.org/trac/coreboot/ticket/42
http://www.ssi.gouv.fr/fr/sciences/fich ... duflot.pdf
http://www.securityfocus.com/columnists/402


Вернуться к началу
СообщениеДобавлено: Вт апр 26, 2011 3:05 pm 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
XVilka писал(а):
SMM - глючный легаси набор костылей.
Да и еще огромная дыра в безопасности:
не-е-е-е-е-е-е... не туда! Штатный BIOS обработчик SMI нужно "гасить ногами" в нормальной ОСи! Имхо.
ACPI и прочая "идиотическая виртуальность", мониторинг платы и типа USBклавки и мыши соответственно автоматически идут "лесом".
А свой обработчик SMI в своей ОСи это норма. похоже мелкософты так ведь и навешивают при загрузке свой.
В настоящее же время это да, дыра, причем на аппаратном уровне! Если можно так выразиться.
Доки рулят, статьи тоже...

Для спецов по ОСРВ, ОСЖРВ, робототехники, АСУ ТП... SMM в виде уродского SMI нафиг не нать, об этом очень хорошо и откровенно, для думающих челов пишут, например, здесь

Собственно наличие работающего SMI из BIOSа после загрузки ОСи - зло в виде непроизводительного убиения процессорного времени, причем хаотическим, непредсказуемым почти, образом!
Как кто то на ромбае сказал, кажись ,что ваш двухголовый супер-пупер проц запросто в i286 превращается...
Реальные замеры потери тактов CPU ужасают и заставляют думать, размышлать.


Последний раз редактировалось VaStaNi Чт май 05, 2011 8:37 am, всего редактировалось 1 раз.

Вернуться к началу
СообщениеДобавлено: Вт апр 26, 2011 5:22 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
VaStaNi писал(а):
art_zh писал(а):
Первый вопрос - самый важный. Каким может быть предмет ТЗ, чтобы разработчик остановился именно на платформе PC х86 ?
ну ладно, уболтал, немного пройдемся танковыми треками по твоему "самый важный" :mrgreen:

- совместимость кода ПО, {...}. Сюда попадает и среда разработки и либы и отладка + отладчики и дальнейшее сопровождение и т.д.

- специфические вещи, которые на x86 выполнены и решены успешно и альтернативы либо нет, либо дорого, либо неудобно, неперспективно на другом.

Вот на чём можно решить сейчас? Я думаю мысли почти автоматически "поплывут" в x86 сторону и в готовые или полуготовые либы, исходники.....

Угу. А теперь попробуй прогнать эти два (вполне резонных) соображения через вопрос №2 - и окажется, что Колибри тут стоит даже не в стороне, а вообще где-то за углом.

Во всяком случае, качество и полнота имеющихся средств разработки, отладки и поддержки для ARM и PowerPC гораздо выше, чем Колибри может предложить в ближайшей перспективе. А про х86 - и говорить нечего.
И если есть код, готовый к прошивке в робота - то не разумнее ли делать это в родной операционной системе?

VaStaNi писал(а):
- производительность, которая требуется для решения задачи...

Согласен полностью. Предложенные выше варианты б)-д) относятся именно к этой категории.
VaStaNi писал(а):
Современные шины PC архитектур. Все это тоже в x86 укажет. Несмотря на то, что гонка за PC, например со стороны все того же ARM происходит, но в ряде условий выбор в сторону x86, будет гарантирован
Сюда же можно отнести и грамотное использование многоядерности, распределительных механизмов эффективных вычислений, требование по "гарячему резервированию" вычислительного процесса(ов) другими ядрами на аппаратном уровне, 100% дублирование, троирование и т.д.

С этим можно долго и нудно спорить, но я не буду. Считай, что согласен. Попробую вставить этот пункт перед буквой ё)

VaStaNi писал(а):
- наличие в x86 4 кольцевого защищенного режима, потенциально позволяет делать очень надежные системы.
Просто не надо тупить и преврашать проц и ОСь в полное полено, используя только ринг 0 и ринг 3!
Я давно против этого. Лично мои планы давно "простираются" на все 4-ре уровня защиты. Неубиенная ОСь пока не создана никем.
Не вижу проблем, чтобы ядро работало на уровне 1, а на уровне 0 работал супервизор! Не забываем и про SMM!!!
(тут полезно вспомнить для наглядности, например, как оживал терминатор, оценивая и "подымая" подсистемы, которые еще что то могут делать, будучи "совсем убитым", растерзанным на куски...)

Опять же, причем тут Колибри? Кто вообще сейчас с этим делом готов экспериментировать (не говоря уже о реальных применениях)?


Вернуться к началу
СообщениеДобавлено: Вт апр 26, 2011 9:24 pm 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
вот потому и "мутное", что разночтение получается...

Получается ты написал (я это читаю, понимаю так), что п.1. НЕ касается Колибри, а именно поставлено под вопрос соответствие робототехника и x86 и все. Безотносительная констатация только этих двух вещей.
А уж п.2 это типа если п.1 имеет место, то что с Колибри тогда?
Может хотел сформулировать иначе, не знаю.

Ты же их смешиваешь и п.1 и п.2 в своем последнем посте.
Не разделяя на два отдельных пласта и две кучки проблем.
"Сводить" их вместе это отдельное занятие, разговор...
Надо как то "последовательно сливать их в кучу" что ли, раз уж написал порознь. Или сразу очертить одно и точка.

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


Вернуться к началу
СообщениеДобавлено: Вт май 03, 2011 3:40 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1593
Я, конечно, в курсе, что это оффтоп, но не могу удержаться.
VaStaNi, "А свой обработчик SMI в своей ОСи это норма. мелкософты так ведь и навешивают при загрузке свой." - не соблаговолите сообщить, что вы курили откуда информация? Возможность проникнуть в SMM после BIOSовской инициализации - это дыра, которая когда-то была, но которую уже несколько лет старательно закрывают в новых BIOSах и обновлениях BIOS.

_________________
Сделаем мир лучше!


Вернуться к началу
СообщениеДобавлено: Вт май 03, 2011 10:48 pm 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
курили многие, и я в том числе практическими исследованиями занимался... маны и чипсеты юзабельные под эту тему.

Фраза не про дыру, собственно+контекст осдева.

ссылался выше где и еще на паре точек где то видел, но давно... может ][akep...


Вернуться к началу
СообщениеДобавлено: Вт май 03, 2011 11:55 pm 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
art_zh, а как быть с системами АСУ ТП разного масштаба, тем и возможностей?
Не затрагивать вообще, или интегрировать в твой перечень?

Ну вот навеяло тут понимаешь..., кумекаю типа "умный дом" (чем не АСУ?) взаться ли и забабахать или ну его нафиг.
Хотябы пока стартово-рекламно, как: простейшие охранные датчики, логистика + отправка по мобиле SMSок хозяину(COM порт+ATкоманды), это же типа тоже "под робот косит", как направление?

Пункт б) или ё) ?
art_zh писал(а):
б) автопилоты и системы дистанционного управления транспортными средствами.
Интересная и весьма перспективная область применения для (х86 + Колибри), только с робототехникой как-то слабо связана.
......
ё) и кое-что ещё

Вроде если взять Колибри, то можно по быстрячку и просто и нагладно и логировать события тоже вроде... Можно и по тырнету слать че нить тоже, рулить процессами дома.
Тут реалтайм не нать по сути, замороки с этим не будет.
Тут типа "пощелкать релюхами" удаленно и в комнатах загорается/тухнет свет (эффект присутствия)...
Датчики присутствия завести типа "сухой контакт" вообще пустяки...
Много чего выдумать можно.
Че то фильмец "Один дома" вспоминается... попутно. :mrgreen:

Думаю, что как раз на базе GPIO очень просто получается во всех аспектах включая схемотехнику периферий. В принципе это "конструкция одного выходного дня" если все в масть покатит. Ну а повторить сие в описанном виде + готовая прога, то это вообще дело просто "правильно растущих рук" наверное. :wink:
Вполне даже дешево думаю тоже.Сравнить провда мне не с чем.
Если взять из той таблицы базовую плату типа VDX-DIP-ISA
то даже на аккумуляторе (типа ТЗ, реальность случаев) она протянет весьма долго (аварийные ситуации + сознательные обесточивания при проникновении на объект...). Ну емкость тут определиться надо, конечно.
А вот на других платформах (контроллерного типа) все очень туманно в плане визуализации объекта + датчики ну и сроков реализации, и вообще перспектив развития и усовершенствования...

"А не замахнуться ли нам на Вильяма....,
на нашего...
на Шекспира?..."
(с) "Берегись автомобиля"
:lol:


Вернуться к началу
СообщениеДобавлено: Ср май 04, 2011 12:23 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1593
Ясно, сложные конструкции не воспринимаются, надо быть проще.
VaStaNi, подтвердите чем-нибудь свои слова "мелкософты так ведь и навешивают при загрузке свой."


Вернуться к началу
СообщениеДобавлено: Ср май 04, 2011 2:16 pm 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
Все умничать пытаешься?

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


Вернуться к началу
СообщениеДобавлено: Ср май 04, 2011 4:08 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1593
Я просто интересуюсь разными вещами, в том числе словами умных людей, в целях расширения своего кругозора. Итак, вы можете подтвердить чем-нибудь свои слова "мелкософты так ведь и навешивают при загрузке свой"?


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 18 сообщений ]  На страницу 1 2 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB