Mario
Да не будет никаких проблем с курсором. Всё будет как обычно рисоваться в видеопамять и окошко будет, только мы его не увидим потому что в текстовом режиме. Кстати Радеоны рисуют графический курсор и в текстовом режиме. Получается довольно забавно.
display_data это карта окон и размер сохранился ещё с допотопных времён.
Колибри для встроенных систем?
Serge
Если ты реально запускал и можешь продемонстрировать - поверю, иначе нет.
З.Ы. Неужели все время кто-то рыжий должен почесаться, блин че за люди - все требуют и сами ниче не делают. (Сергей это не к тебе).
Если ты реально запускал и можешь продемонстрировать - поверю, иначе нет.
Ну, дык вот еще одно направление для оптимизации!display_data это карта окон и размер сохранился ещё с допотопных времён.
З.Ы. Неужели все время кто-то рыжий должен почесаться, блин че за люди - все требуют и сами ниче не делают. (Сергей это не к тебе).
Mario
Вот Фома неверующий...
Вот Фома неверующий...
- Attachments
-
-
dos2009.7z (72.52 KiB)
- Ядро с минимальными правками и лаунчер с клавиатурным вводом.
Downloaded 413 times
-
Вот переварил я немножечко Вами всеми сказанное....Ghost wrote:tsdima
"скорее всего будут работать менее 0,02сек" - это и есть мягкое реальное время, и то только если мы знаем меру этого "скорее всего" и она нас устраивает.
И вот какие мысли возникли в результате:
1) Готов согласиться, что сделать супер-универсальный планировщик, вытаскивающий ресурсы компа по полной программе - не самая простая задача. И эта "полная программа" вряд ли вдохновит Kernel Developers, для которых таковая потребность несколько абстрактна
2) Но я вернусь к "одной точке опоры", которая должна оказаться проще в исполнении, чем "железобетонный фундамент". НО!!! Позволит мне (вообще-то - профессиональному разработчику) сотворять корректное проектирование оборудования.
Пусть задача упрощена до предела: мы позволяем только один такой поток в системе. Если некий второй обратится к ядру с таким запросом для себя, то получит наш революционный отлуп, типа: "ресурс уже занят"
И ведь даже такое уже позволит решать целый спектр задач реального времени. Например, вышеприведенную мной выше - позволит.
3) И вот, если БЫ разработчикам ядра таковая упрощенная задача показалось бы достаточно простой, что бы выложить демку за разумное время, то глядя на коды (вообще-то, на диффы с релизом) развитие этой системы уже могли бы продолжить и более заинтересованные пользователи. Те, для кого таковая потребность - не абстракция, а великая сермяжная правда.
Конечно, я себя имею в виду в первую очередь. Для меня на сегодня, сделать такой первый шаг - значительно более сложная задача (если не сказать - непосильная). А в такой схеме работы, количество "познавательных" вопросов (с моей стороны) сократилось бы на порядок.
4) Ну хорошо (это я на будущее уже рассуждаю), пусть у нас 5 таких потоков, и каждый заказал срабатывание через 10 тиков
В чем проблема?
В том, что они могут скоррелировать, и все одновременно запросить один и тот же квант времени. Который мы конечно отдадим только кому-то одному... И так далее еще 4 раза
Что получается... ДА, мы НЕ имеем гараний в 100 мсек
НО!!! Разве мы не имеем при этом гарантий в 150 мсек
Пока мне кажется, что имеем, и что это настоящие гарантии, никаких 160 и больше мсек -- уже не будет
Какое же это мягкое RT... Очень даже жесткое, мне кажется....
Может я еще не все понял... Поправьте меня пожалуйста, если что...
Далее, предположим, некий слот запрашивает, а планировщик в ответ - всей толпе "изохронных" слотов уменьшает этот "таймаут" на единицу, если получилось - и себе уменьшает на "объем этой толпы"
Опять же, в случае успеха -- возвращем "усё тип-топ".
Не получилось -- вот вам наш, ранее указанный, отлуп
А
Serge
Хорошо, заценю. Спасибо.
Galkov
Был у нас на форуме человек (вообщето был и до пеерезда на этот ресурс, есть он и сейчас но появляется исключительно редко), со столь же бешеной энергией описывающий свое видение ситуации и методов по ее исправлению, а раньше он писал код...
Хорошо, заценю. Спасибо.
Galkov
Был у нас на форуме человек (вообщето был и до пеерезда на этот ресурс, есть он и сейчас но появляется исключительно редко), со столь же бешеной энергией описывающий свое видение ситуации и методов по ее исправлению, а раньше он писал код...
Mario
Читаешь мысли, тот писал в такой же манере.
Galkov
Я думаю, ради тебя и твои прогрессивных идей никто систему переписывать не будет. Если я не прав, пусть кто-то возразит мне!
Читаешь мысли, тот писал в такой же манере.
Galkov
Я думаю, ради тебя и твои прогрессивных идей никто систему переписывать не будет. Если я не прав, пусть кто-то возразит мне!
Из хаоса в космос
Для начала - поблагодарю всех за высказанные мнения.
Теперь некоторые мысли по поводу:
1. Относительно реального времени. Есть задача, требующая реакции системы за время до 15мсек (это наиболее жесткий случай, - обработка сигналов с АЦП, выдача сигналов на выходные порты). Точнее, в течение этих 15мсек информация из буферов АЦП должна быть обработана, решения приняты, сигналы должны быть гарантированно выданы; процесс цикличный, жестко синхронизирован с частотой сети 50Гц с точностью до фазы, данные уникальные, то есть повторить из-за опоздания нет возможности. Периодически данные должны архивироваться на HDD с метками времени. Частота цикла может плавать в некоторых пределах из-за нестабильности частоты сети.
В другой задачке (система аналого-цифрового синтеза звука реального времени), - время реакции на асинхронное событие требуется порядка 30-40мсек, лучше-меньше. Заикания звука, тормоза при опросе переменных резисторов (более 100шт) мне здесь не нужны совершенно.
Вывод напрашивается единственный - оставлять только один поток, прибивать все остальное. Или вообще вернуться к своей "однозадачной системе", где единственная рабочая программа крутится на нулевом кольце, дисковые и графические функции же можно вынести просто в подпрограммы.
1а) Таймер. Как я понял, в КоОС таймер настраивается на 100Гц и эта частота фиксирована, то есть юзерский код не имеет права и привилегий ее дергать?
2. Относительно текстового режима, - меня это интересовало исключительно в плане удобства кодинга. Ради этого "огород городить" и шаманить над обманом функций ядра - большого смысла нет, ибо проще уж тогда под ДОСом или виндой кодировать.
3. Напрягает неудобство ковыряния системы по одной простой причине: все файлы забиты в дискеточный образ.
4. Возможно, действительно имеет смысл сделать однозадачный вариант системы для реалтайм- приложений.
Теперь некоторые мысли по поводу:
1. Относительно реального времени. Есть задача, требующая реакции системы за время до 15мсек (это наиболее жесткий случай, - обработка сигналов с АЦП, выдача сигналов на выходные порты). Точнее, в течение этих 15мсек информация из буферов АЦП должна быть обработана, решения приняты, сигналы должны быть гарантированно выданы; процесс цикличный, жестко синхронизирован с частотой сети 50Гц с точностью до фазы, данные уникальные, то есть повторить из-за опоздания нет возможности. Периодически данные должны архивироваться на HDD с метками времени. Частота цикла может плавать в некоторых пределах из-за нестабильности частоты сети.
В другой задачке (система аналого-цифрового синтеза звука реального времени), - время реакции на асинхронное событие требуется порядка 30-40мсек, лучше-меньше. Заикания звука, тормоза при опросе переменных резисторов (более 100шт) мне здесь не нужны совершенно.
Вывод напрашивается единственный - оставлять только один поток, прибивать все остальное. Или вообще вернуться к своей "однозадачной системе", где единственная рабочая программа крутится на нулевом кольце, дисковые и графические функции же можно вынести просто в подпрограммы.
1а) Таймер. Как я понял, в КоОС таймер настраивается на 100Гц и эта частота фиксирована, то есть юзерский код не имеет права и привилегий ее дергать?
2. Относительно текстового режима, - меня это интересовало исключительно в плане удобства кодинга. Ради этого "огород городить" и шаманить над обманом функций ядра - большого смысла нет, ибо проще уж тогда под ДОСом или виндой кодировать.
3. Напрягает неудобство ковыряния системы по одной простой причине: все файлы забиты в дискеточный образ.
4. Возможно, действительно имеет смысл сделать однозадачный вариант системы для реалтайм- приложений.
Anton, Galkov
Колибри - десктопная система. Если ваши задачи требуют систем реального времени то их огромное количество - платных и бесплатных на С и ассемблере, на все случаи жизни.
Колибри - десктопная система. Если ваши задачи требуют систем реального времени то их огромное количество - платных и бесплатных на С и ассемблере, на все случаи жизни.
Ну вот, простой и понятный ответ на вопрос из сабжа
Остались неясности насчет целевого пользователя, но это уже не самое принципиальное
Just for fun ведь всю жизнь продолжаться не может
Остались неясности насчет целевого пользователя, но это уже не самое принципиальное
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.
Ну, я считаю, что АНМ-операционках такого 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 прав - Колибри унаследована от системы, которая изначально задумывалась как десктопная, и продолжает развиваться, как десктопная.
Serge прав - Колибри унаследована от системы, которая изначально задумывалась как десктопная, и продолжает развиваться, как десктопная.
Ушёл к умным, знающим и культурным людям.
diamond, мне кажется, Вы путаете твердое с холодным...
Никто не ставит вопрос о конкретных микросекундах
Мне, к примеру, давно понятно, что 16-МГц-вый 8-битный камень легко справляется с 16КГц-вым управлением, а на 2ГГц-вом проце об этом даже и мечтать не приходится
Так ведь никто и не мечтает
Нет смысла даже говорить про времена, не квантованные нашими 10 мсекундами, мне кажется
Ровно в тот момент, как речь зашла применении KoOS в embeded - мы будем иметь дело с реальным временем.
Нравится это кому-то или нет, а просто все реальные задачи, это задачи реального времени, по большому счету-то
Просто потому, что это жизнь уже реальная
Если в системе произошло событие, то на него надо реагировать за какое-то разумное время.
Сегодня ситуация такая: типовая реактивность - 10-20 мсекунд с вероятностью 99%. А оставшийся процент - вплоть до 2.5 секунд (про винды я уже и не говорю).
Это возможно допустимо только в виртуальной жизни, где заикание плэера является также допустимым
А в реальной - это совсем не так
Да, особенности архитектуры софта, железа - не позволят делать микросекунды и единицы милисекунд
Да ну и фиг с ними.
Важно отсутствие вероятностного хвоста в "бесконечность" (которая конкретно на KoOS равна 2.56 сек).
diamond, вот привели Вы ссылку...
Даже не буду вспоминать, что на одну милисекунду никто и не претендует
Ибо главное в том, что даже самое глючное железо не дает этих "хвостов", а просто немного ухудшит реактивность, на которую может рассчитывать разработчик некой реальной системы
Т.е., разработчик получает инструмент, и исходя из его характеристик разрабатывает систему
Не реально замкнуть ОС в компе -- значит я делаю по своему контроллеру на каждую координату...
И т.д., возможно вплоть до разработки своего компьютера и оси, коль скоро на это хватит денег и здоровья
И возможности (и выбор) разработчика будут разные при реактивности 2.56 сек, и (например) 100 мсек
И все - нет микросекундных претензий.
Конечно, я не могу исключать (не хватает пока образования), что магическое слово "десктопность" ставит крест на возможной реактивности в 50 мсек (при кванте 10).
Так обяснить этот факт было бы гораздо приличней, ехидных воспоминаний про неких незнакомых мне людей.
Или это у Вас не очень принято???
Ну можно и не объяснять конечно, закройте тему и продолжайте наслаждаться своей псевдокрутостью
Периодически ударяясь в поиски наиболее адекватных областей применения...
Никто не ставит вопрос о конкретных микросекундах
Мне, к примеру, давно понятно, что 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. Слишком много факторов и особенностей ядра и железа надо учесть чтобы можно было дать хоть какие-то честные гарантии.
Не надо принимать нас за личных врагов и противников 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