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

Using Kolibri in embedded systems
  • Serge
    Если ты реально запускал и можешь продемонстрировать - поверю, иначе нет.
    display_data это карта окон и размер сохранился ещё с допотопных времён.
    Ну, дык вот еще одно направление для оптимизации!

    З.Ы. Неужели все время кто-то рыжий должен почесаться, блин че за люди - все требуют и сами ниче не делают. (Сергей это не к тебе).
  • Mario

    Вот Фома неверующий...
    Attachments
    dos2009.7z (72.52 KiB)
    Ядро с минимальными правками и лаунчер с клавиатурным вводом.
    Downloaded 413 times
  • Ghost wrote:tsdima
    "скорее всего будут работать менее 0,02сек" - это и есть мягкое реальное время, и то только если мы знаем меру этого "скорее всего" и она нас устраивает.
    Вот переварил я немножечко Вами всеми сказанное.... :)
    И вот какие мысли возникли в результате:

    1) Готов согласиться, что сделать супер-универсальный планировщик, вытаскивающий ресурсы компа по полной программе - не самая простая задача. И эта "полная программа" вряд ли вдохновит Kernel Developers, для которых таковая потребность несколько абстрактна

    2) Но я вернусь к "одной точке опоры", которая должна оказаться проще в исполнении, чем "железобетонный фундамент". НО!!! Позволит мне (вообще-то - профессиональному разработчику) сотворять корректное проектирование оборудования.
    Пусть задача упрощена до предела: мы позволяем только один такой поток в системе. Если некий второй обратится к ядру с таким запросом для себя, то получит наш революционный отлуп, типа: "ресурс уже занят"
    И ведь даже такое уже позволит решать целый спектр задач реального времени. Например, вышеприведенную мной выше - позволит.

    3) И вот, если БЫ :idea: разработчикам ядра таковая упрощенная задача показалось бы достаточно простой, что бы выложить демку за разумное время, то глядя на коды (вообще-то, на диффы с релизом) развитие этой системы уже могли бы продолжить и более заинтересованные пользователи. Те, для кого таковая потребность - не абстракция, а великая сермяжная правда.
    Конечно, я себя имею в виду в первую очередь. Для меня на сегодня, сделать такой первый шаг - значительно более сложная задача (если не сказать - непосильная). А в такой схеме работы, количество "познавательных" вопросов (с моей стороны) сократилось бы на порядок.

    4) Ну хорошо (это я на будущее уже рассуждаю), пусть у нас 5 таких потоков, и каждый заказал срабатывание через 10 тиков
    В чем проблема?
    В том, что они могут скоррелировать, и все одновременно запросить один и тот же квант времени. Который мы конечно отдадим только кому-то одному... И так далее еще 4 раза
    Что получается... ДА, мы НЕ имеем гараний в 100 мсек
    НО!!! Разве мы не имеем при этом гарантий в 150 мсек :?:
    Пока мне кажется, что имеем, и что это настоящие гарантии, никаких 160 и больше мсек -- уже не будет
    Какое же это мягкое RT... Очень даже жесткое, мне кажется....
    Может я еще не все понял... Поправьте меня пожалуйста, если что...

    Далее, предположим, некий слот запрашивает, а планировщик в ответ - всей толпе "изохронных" слотов уменьшает этот "таймаут" на единицу, если получилось - и себе уменьшает на "объем этой толпы"
    Опять же, в случае успеха -- возвращем "усё тип-топ".
    Не получилось -- вот вам наш, ранее указанный, отлуп

    А :D :?:
  • Serge
    Хорошо, заценю. Спасибо.

    Galkov
    Был у нас на форуме человек (вообщето был и до пеерезда на этот ресурс, есть он и сейчас но появляется исключительно редко), со столь же бешеной энергией описывающий свое видение ситуации и методов по ее исправлению, а раньше он писал код...
  • Mario
    Читаешь мысли, тот писал в такой же манере.

    Galkov
    Я думаю, ради тебя и твои прогрессивных идей никто систему переписывать не будет. Если я не прав, пусть кто-то возразит мне!
    Из хаоса в космос
  • Для начала - поблагодарю всех за высказанные мнения.

    Теперь некоторые мысли по поводу:

    1. Относительно реального времени. Есть задача, требующая реакции системы за время до 15мсек (это наиболее жесткий случай, - обработка сигналов с АЦП, выдача сигналов на выходные порты). Точнее, в течение этих 15мсек информация из буферов АЦП должна быть обработана, решения приняты, сигналы должны быть гарантированно выданы; процесс цикличный, жестко синхронизирован с частотой сети 50Гц с точностью до фазы, данные уникальные, то есть повторить из-за опоздания нет возможности. Периодически данные должны архивироваться на HDD с метками времени. Частота цикла может плавать в некоторых пределах из-за нестабильности частоты сети.

    В другой задачке (система аналого-цифрового синтеза звука реального времени), - время реакции на асинхронное событие требуется порядка 30-40мсек, лучше-меньше. Заикания звука, тормоза при опросе переменных резисторов (более 100шт) мне здесь не нужны совершенно.

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

    1а) Таймер. Как я понял, в КоОС таймер настраивается на 100Гц и эта частота фиксирована, то есть юзерский код не имеет права и привилегий ее дергать?

    2. Относительно текстового режима, - меня это интересовало исключительно в плане удобства кодинга. Ради этого "огород городить" и шаманить над обманом функций ядра - большого смысла нет, ибо проще уж тогда под ДОСом или виндой кодировать.

    3. Напрягает неудобство ковыряния системы по одной простой причине: все файлы забиты в дискеточный образ.

    4. Возможно, действительно имеет смысл сделать однозадачный вариант системы для реалтайм- приложений.
  • Anton, Galkov

    Колибри - десктопная система. Если ваши задачи требуют систем реального времени то их огромное количество - платных и бесплатных на С и ассемблере, на все случаи жизни.
  • Ну вот, простой и понятный ответ на вопрос из сабжа :D

    Остались неясности насчет целевого пользователя, но это уже не самое принципиальное
    Just for fun ведь всю жизнь продолжаться не может
  • Google-RUSSIAN:
    Ну, я считаю, что АНМ-операционках такого Kolibri должны быть направлены ДКПКы...

    Как уже отмечалось в других должностей / форумы Было бы замечательно использовать АНМ мощность для тяжелых вычислительных задач, таких, как декодирования / кодирования: Я считаю, что это не невозможно достичь реального BD резервного Дирака или Theora (к примеру) на встроенный Фанменее системы, пмсм.

    ENGLISH:
    Well, I believe that ASM-OSes such Kolibri should target HTPCs...

    As already suggested in other posts/forums It would be great to use the ASM power for heavy computing tasks, such as decoding/encoding: I believe that it's not impossible to achieve realtime BD backup to Dirac or Theora (for example) on a embedded fanless system, IMHO.
    Last edited by forart.eu on Sat Feb 07, 2009 1:51 pm, edited 1 time in total.
  • Serge, спасибо. Ситуация, в принципе, ясна.
  • Вообще мы выбросили из системы все приложения, кроме тех, что реально необходимы, и получили достаточную вероятность отклика за 1 сек, чего с головой для наших задач хватило...:) но, для коротких промежутков времени, надо что-то придумать...:)
    *****:
    ;дух машины, мой бубен сильнее твоей тупости

    *****:
  • Если требуемая точность идёт на микросекунды, то будут большие проблемы при любом раскладе. Само переключение потоков (с переключением таблиц страниц => сбросом TLB-буферов, скажем) занимает какое-то время. Платформа PC вообще плохо подходит под системы реального времени. Одна из причин, например, - неблокируемое SMI в моменты времени, которые могут быть совершенно неподходящими (http://www.wasm.ru/forum/viewtopic.php?id=28456&p=1).
    Serge прав - Колибри унаследована от системы, которая изначально задумывалась как десктопная, и продолжает развиваться, как десктопная.
    Ушёл к умным, знающим и культурным людям.
  • diamond, мне кажется, Вы путаете твердое с холодным...
    Никто не ставит вопрос о конкретных микросекундах
    Мне, к примеру, давно понятно, что 16-МГц-вый 8-битный камень легко справляется с 16КГц-вым управлением, а на 2ГГц-вом проце об этом даже и мечтать не приходится
    Так ведь никто и не мечтает :!:
    Нет смысла даже говорить про времена, не квантованные нашими 10 мсекундами, мне кажется

    Ровно в тот момент, как речь зашла применении KoOS в embeded - мы будем иметь дело с реальным временем.
    Нравится это кому-то или нет, а просто все реальные задачи, это задачи реального времени, по большому счету-то
    Просто потому, что это жизнь уже реальная
    Если в системе произошло событие, то на него надо реагировать за какое-то разумное время.
    Сегодня ситуация такая: типовая реактивность - 10-20 мсекунд с вероятностью 99%. А оставшийся процент - вплоть до 2.5 секунд (про винды я уже и не говорю).
    Это возможно допустимо только в виртуальной жизни, где заикание плэера является также допустимым
    А в реальной - это совсем не так

    Да, особенности архитектуры софта, железа - не позволят делать микросекунды и единицы милисекунд
    Да ну и фиг с ними.
    Важно отсутствие вероятностного хвоста в "бесконечность" (которая конкретно на KoOS равна 2.56 сек).

    diamond, вот привели Вы ссылку...
    Даже не буду вспоминать, что на одну милисекунду никто и не претендует
    Ибо главное в том, что даже самое глючное железо не дает этих "хвостов", а просто немного ухудшит реактивность, на которую может рассчитывать разработчик некой реальной системы
    Т.е., разработчик получает инструмент, и исходя из его характеристик разрабатывает систему
    Не реально замкнуть ОС в компе -- значит я делаю по своему контроллеру на каждую координату...
    И т.д., возможно вплоть до разработки своего компьютера и оси, коль скоро на это хватит денег и здоровья
    И возможности (и выбор) разработчика будут разные при реактивности 2.56 сек, и (например) 100 мсек
    И все - нет микросекундных претензий.


    Конечно, я не могу исключать (не хватает пока образования), что магическое слово "десктопность" ставит крест на возможной реактивности в 50 мсек (при кванте 10).
    Так обяснить этот факт было бы гораздо приличней, ехидных воспоминаний про неких незнакомых мне людей.
    Или это у Вас не очень принято???
    Ну можно и не объяснять конечно, закройте тему и продолжайте наслаждаться своей псевдокрутостью
    Периодически ударяясь в поиски наиболее адекватных областей применения...
  • Galkov

    Не надо принимать нас за личных врагов и противников RTOS на основе Колибри. Мы совсем не против. Но нельзя назвать систему RTOS просто так, без серьёзной проверки кода и испытаний в различных конфигурациях.
    Термин "RTOS" предъявляет к ядру определённые требования и подразумевает что эти требования выполняются. Так вот я не могу гарантировать что максимальная латентность обработчика irq будет не больше 50 миллисекунд или 5 секунд, а может 50 секунд.
    Если кто-то хочет сделать RTOS на основе Колибри - замечательно, дерзайте. Но современные RTOS не случайно пишутся на микроядрах. Колибри монолит. Значительная часть кода ядра и драйверов выполняется с маскированными прерываниями. Это и есть "десктопность". Плюс особенности железа. Например usb мышь и клавиатура эмулируются биос как ps/2 при помощи SMM. Или чтение из видеопамяти с маскированными прерываниями. Максимальная скорость чтения 10Мб/с. У меня 5.6 Мб/с. Теперь посчитайте разброс по времени при чтении битмапа с маскированными прерываниями 64*64*24bpp и 1280*1024*32bpp. Слишком много факторов и особенностей ядра и железа надо учесть чтобы можно было дать хоть какие-то честные гарантии.
  • Who is online

    Users browsing this forum: No registered users and 5 guests