Колибри для встроенных систем?

Using Kolibri in embedded systems
  • У меня лично вопросов больше нет, - в принципе, все достаточно ясно.
  • 2Ghost Что еще следует сказать некому граматею, чтобы до столь продвинутого developer-а доехало, что именно понимание того, что KoOS не является RTOS и не позволяют согласиться с коллегой "Ты попал абсолютно по адресу.. перед тобой простая, надёжная, гибкая система, с поддержкой всего, чего тебе надо"
    И ведь что удивительно, все почему-то с этим были согласны.
    А не согласные - грамотеи оказываются.
    Наоборот все, как мне представляется. И это у Вас проблемы с пониманием, а не у меня
    А про объясняют: реальные объяснение проблем дал Serge (за что и спасибо), хоть и по второму разу
    Ваши объяснения про необходимость планировщика мне совершенно понятны (с чего Вы решили обратное - не возьму в толк), но НЕ показались (пока) принципиальной проблемой.
    Про XP объяснять не было необходимости - это отличие KoOS от винды и есть основная причина моей заинтересованности.
    Ну не хотим, так не хотим - нет проблем.
    Только способность мою понимать оставьте в покое... Если есть такая возможность. Не нуждается она ни в чьей оценке.



    2Serge Ну хорошо, давайте не будем никого ни за кого принимать

    Но это же не отменяет того факта, что (назовем это так) реальной ясности по некоторым вопросам не внесено
    Как только она внесена - тут надо делать выбор: либо нечего здесь делать, либо надо начинать соответствующую работу.

    1) Если коды оси могут закрыть прерывания на 5-50 секунд, это вообще-то называть не десктопом надо, а обыкновенным беспределом в кодинге.
    Вопрос: эдакая бесконтрольность будет существовать всегда, или все-таки стратегией команды является постепенное внесение ясности в этот вопрос
    Нет, вопрос не стоит в каких-то микросекундах, или в том что это нужно к завтра. А вот какова стратегия у команды - знать таки следует.

    2) Соответственно, и при дальнейшем развитии, наверное, должен существовать же какой-то критерий по соблюдению "определённых требований"
    Будет он выполняться или нет - откуда я знаю...
    Скажем, введение системы приоритетов аля в винде, уведет сегодняшние 2.56 сек в реальную бесконечность... Возможно такое или нет в последствии ???
    Про общение с видео ОЗУ - был такой топик. И логичный вариант буферизации Вами (кажется) и был предложен. А вот по какому пути будет развиваться ось, извините, увидеть крайне затруднительно.
    Неужели требования "отсутствия временного хвоста не контролируемой длины" - настолько рушат всю концепцию.
    Ну если рушат - так прямо и скажите: "не, не для нас это". Это же опять прямо не сказано ведь....

    3) Понятно и естественно, чьих рук делом является спасение утопающих.
    При этом помощь может быть оказана, а может и нет - это разные трудозатраты и эффективность как работы, так и результата (не сказано, кстати, тоже ничего)
    Кроме этого, еще более интересным становится, будет ли внесено в дистрибутив нечто с "не контролируемым временным хвостом" после того, как у меня будут отлажены некие технические решения с супер-пупер-планировщиком
    Честное слово, "мы не против" - не совсем тот ответ для такой ситуации

    4) Не исключаю, что полной определенности со стратегией просто еще у команды нет... Так давайте продумаем какую-то ее часть - надо же когда-то этим заниматься
    Никто не призывает безусловно экономить наносекунды. Призыв состоит в том, что бы не заниматься "беспределом"
    В том смысле, что если закрыл прерывания, то это безобразие просто можно было именно подсчитать для конкретного компа.
    Естественно, без фанатизма...

    Как бы это еще понятнее........
    Поймите, для разработчика системы с реальным железом, существование "временных хвостов в бесконечность", это примерно то же самое что для Кодера: Существует не нулевая (хотя и очень маленькая) вероятность, что "первый jmp не сработает"
    Можно ли после этого написать коды, которые будут работать всегда :?:
  • Galkov wrote:Если коды оси могут закрыть прерывания на 5-50 секунд, это вообще-то называть не десктопом надо, а обыкновенным беспределом в кодинге
    Это не беспредел, а недостаток системы на данный момент. И этот недостаток необходимо устранить, т.к. допустимое время запрета прерываний, на мой взгляд, должно измеряться (принимая во внимание производительность существующих на данный момент компьютеров) микросекундами. Вопрос, как всегда, кто будет делать?

    Если ОС не должна допускать использования процессора одним процессом более 10мс, то это должно выполняться всегда, не зависимо от того, какой это код: пользовательский или системный. Ясно, что прервать выполнение мы можем только если это пользовательский код. А системный код должен сам контролировать объём выполняемых им работ для текущего процесса. Так вот, этот контроль - это дополнительные трудозатараты системного программиста, которые никто (по разным причинам) не хочет на себя брать. И с этим приходится мириться. Либо делать самому. Если можешь.
  • tsdima, блин, ты тоже считаешь, что у меня проблемы с пониманием ???
    Так я тебя поправлю немного:
    1) Беспредел он и в Африке беспредел. И является обычно реализацией знакомой тебе идеологии: "пока это допустимо"
    2) Пока я не прочитал о конкретном наличии таких неустранимых недостатков, НО прочитал о том, что никто не даст гарантии об отсутствии таковых. Не одно и то же, между прочим.

    Что из это... А два варианта:
    а) Все договорились, что это уже все-таки "не очень допустимо", и, ни шатко ни валко, постепенно ликвидируется обнаруженное в процессе тестирования, по мере возможности естественно. Но без диспупутов из серии "если вы все там такие умные, что же вы строем не ходите".
    Нормальный адекватный вариант, ИМХО. В котором можно начинать работу.
    б) А нас все и так устраивает. Тогда, как я уже отмечал - ну и наслаждайтесь. Только про применимость для embeded - не вспоминайте лучше.
    И, возьмусь утверждать, что здесь я грамотнее многих буду, как бы это не было противно окружающим.
    Комп в таком случае будет не более, чем отражающей, информативной системой, но уж никак не управляющей.

    Ну что, очень сложные вопросы для понимания что ли :?:
  • Galkov wrote:Только про применимость для embeded - не вспоминайте лучше.
    Да мы, в общем, и не вспоминаем, более осуществимых, но не сделанных вещей хватает.
    Galkov wrote:Комп в таком случае будет не более, чем отражающей, информативной системой, но уж никак не управляющей.
    Всё правильно, про то и речь идёт.
    P.S. "Ты попал абсолютно по адресу" - это слова не ядерщиков, между прочим.
    Ушёл к умным, знающим и культурным людям.
  • А не спорю, не ядерщиками
    Но они и не думали возражать этому, до появления неких грамотеев, неспособных понять банальные объяснения

    Так вопрос-то в чем: противоречат ли "более осуществимые, но не сделанные вещи" постепенному и не торопливому удалению кодов с "не контролируемым временем исполнения" из ядра ???
    Или наоборот: таковые коды будут только появляться ???
    Ну не может это быть безразличным (например, для экспериментов с неким планировщиком), как можно не понимать таковое....

    Вот, конкретно, Serge вспоминал про чтение из видео-памяти. И был топик, в котором сие было признано как зло. И не сделано. Может просто руки не дошли, а может потому, что "нам и так хорошо". Разве введение двойной буферизации, это напряги ради RT ???
    А мне так кажется, что устранение блымания курсора (да и остального - тоже), обмен с железом только по инвалидным областям - это просто хороший код, и рациональное функционирование для любой оси...

    Ответа-то нет, а вместо этого - воспоминание про некого Вилле, и про грамотеев.
    Впрочем, отсутствие ответа, есть тоже ответ... Если подумать :wink:
  • 1,2. Могут закрыть, а могут и не закрыть. Цифры взяты с потолка. Я не знаю точно и потому не могу гарантировать что не закроют. Речь ведь шла о гарантиях "вообще". А гарантировать можно только после тестов в кокретной конфигурации и на конкретной машине. Как например сделал Дедок. Настроили, проверили - устроило.

    Стратегия развития это отдельная тема. У меня, и не только, есть желание постепенно превратить ядро в микроядро. Желание это успешно компенсируется сложностью задачи. Вообще история Колибри показывает что все изменения в ядре происходят когда находится человек готовый их сделать. Так было с драйверами, vfs и ntfs, чтением СD и вообще всем остальным. Если у Вас есть желание сделать для Колибри планировщик - делайте, все будут рады. Ждать что сделает кто-то ещё можно очень долго.
    В конце концов стратегию развития определяет тот кто пишет код.

    3. и всё остальное
    Никто не даст таких гарантий потому что система до сих пор развивалась и развивается как десктопная. Если хочется сделать RTOS то придётся самому контролировать код потому что сейчас все проверки идут по принципу работает - не работает.

    P.S. 118 cli в ядре и драйверах
  • Galkov

    С чего всё началось...
    Ищу ОС для реализации нескольких встроенных систем, как коммерческих, так и не очень. Основные требования - удобство кодинга на асме (критично, так как я сам, кроме асма, ни на чем толком не кодирую), прямая быстрая работа юзерского софта с железом (необходимо в случае втыкания карт расширения собственной разработки); поддержка файловой системы (FAT достаточно); поддержка работы в текстовом и графическом режиме (1024*768 достаточно); поддержка RS232, и, желательно USB; работа с большими массивами данных в памяти (десятки Мб), поддержка SB16, AC97. Быть может, возникнут и еще некие потребности, но это пока основное.
    В общем случае нужна "дубовая" система, из которой легко вырезать все ненужное, оставить только то, что необходимо.
    Об RTOS речь вообще не шла. Всё остальное вполне применимо к Колибри. Я делал драйвера для АС97 на ICH/nForce, SIS и AMD Geode. Курсоры, 2D и kms на Радеонах. Сейчас тестирую PCI/PCIE GART чтобы свободно работать с текстурами из системной памяти. Ещё время от времени занимаюсь uhci.
    Всё это к тому что у меня достаточный опыт работы с железом в Колибри на асме и в последнее время на С. И Колибри действительно прекрасно для этой работы подходит. О чём и написал Дедок. Так что Антон действительно попал по адресу.
  • Galkov
    Под грамотеем с Вилли видимо имелся в виду я.
    Собственно я и вопроса не вижу, про то что с текущим планировщиком можно все адекватно обсчитать я говорил. Но откуда познания про 2,56 секунды и некие большие хвосты в системе мне не понятно. Да в ядре есть сотня cli, но половина из них содержит по 10 команд без переходов до sti, остальные тоже можно оценить в явном виде.
    Также профессиональный разработчик выдвигает требывания детерминизма и полной верификации всего ядра (иначе тяжко железки продавать...). Защишался я учась по теме неклассических логик, используемые мной алгоритмы предназначались для верификации программ, по опыту скажу что удовольствие это очень дорогое, помнится какая то контора (QNX Software Systems ?) пару лет назад обещала представить математически безошибочную систему, ждемс...
    Это я к тому что аппетит конечно приходит во время еды, но я уже просил сформулировать требования, ничего внятного так и не увидел, кроме "2,56 - это зло!"
  • Дело в том, что у меня имеется несколько задач, - как реалтаймовых (о них я тоже здесь писал), так и не особо критичных к скорости реакции системы (сохранение и отображение статистики по данным, - например, графиков температур/расходов и тд.) Не критичные ко времени задачи - и под виндой вполне осуществимы.

    Относительно реалтайм-задач вопрос снят, с этим все ясно, - там многозадачка по большому счету и не требуется. Опорный вариант кода, грузящийся из голого ДОСа, уже есть. Примитивную графику под VESA/LFB сделать вполне можно, как и запись на HD. Более того, часть рутинных задач уже решено перенести на локальные контроллеры, те же atmega или msp430.
  • Ghost wrote:Но откуда познания про 2,56 секунды...
    Видимо Galkov имеет в виду, что при 256 активно работающих процессах в системе и при 100 Гц таймере, переключение на конкретный процесс будет занимать не менее 2,56 секунд.
  • Maxis вот теперь понял. Но процессов может быть только 255, но даже если 256, получать управление каждый процесс будет с задержкой в 2,55 секунды, но повторюсь это худщий сценарий - если процесс полностью использует свой квант времени, если нет - то время уменьшится, кроме того это как никак та самая точка опоры, худше её небудет, кроме того запускать в жестком реальном времени 255 процессов - не самая лучшая идея.

    Anton ИМХО для случая с реакцие в 15мсек (я так понимаю даже меньше, так как в это время входит и время считывания данных), ещё и синхронизация с промышленной сетью (не T10 устройства случаем?) лучше реализовывать аппаратно/программно (пиков и атмелов сейчас на любой вкус), хотя бы в виде буфера (а потом забирать данные например по Ethernet пусть большими объемами но медленнее), должно получится надежнее и дешевле.
    Или например (фантазии на тему...) использовать какие нибудь miniITX платы на Geode, там есть куча GPIO входов, по крайней мере реакция на эти входы встроена в архитектуру камней, а вот на этих платах пускать перепиленную колибри )
    На самом деле не ясно каким образом доставляются сигналы? Прерывания? RS422? Свой разработки? Если прерывания то ускорить реакцию на них можно, если опрос портов - то сложнее, но в любом случае 15мсек - ИМХО не для мультизадачной системы на PC.
  • Serge wrote:Если у Вас есть желание сделать для Колибри планировщик - делайте, все будут рады
    Я надеюсь, не надо повторять, что при наличии вероятности запрета прерываний на 5-50сек никакой планировщик не поможет? По-моему, достаточно свести эту вероятность к нулю, переделав соответсвенно критические участки в ядре, может тогда и планировщик не понадобится.
  • Who is online

    Users browsing this forum: No registered users and 1 guest