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

Using Kolibri in embedded systems
  • Ghost

    Кажется это была одна из модификаций L4. QNX для этого уже слишком "толстая".
  • tsdima

    Я не могу гарантировать что таких задержек нет. Но это не значит автоматически что они есть и будут вылезать всё время.
  • Serge угу, OKL4 от Open Kernel Labs. Называется по умному formally-proven bug-free microkernel - микроядро с математически доказанным отсутствием ошибок.
  • Ghost

    В этом много лукавства. Микроядро L4 настолько ужато что все ошибки выдавливаются в user-mode. Вот безошибочная система...
  • 2tsdima:
    Достаточно не отсутствия таковых "фокусов", а согласия коллег преодолевать эти проблемы по мере поступления.
    Согласен :?:


    2Ghost:
    От те раз... :shock:
    А я думал наоборот, что это про меня... Ну ладно, это лирика
    Конкретно

    1) Давайте понимать существование 3-х уровней
    Первый - это функционирование ядра (пусть условно это команда KoOS)
    Второй - это разработчик системы (настолько же условно - это я)
    Третий - это пользователи системы (это оператор и сисадмин в каком-нибудь Урюпинске)

    2) Если система работает под моим чутким наблюдением - тоже нет вопросов. Как справедливо отметил коллега ДедОк - сносим все лишнее, и при запуске сторонних приложений я все понимаю про количество потоков
    И совершенно спокойно можно работать с гарантиями реактивности в 100 мсек (ну не будет у меня больше 10 активных не спящих потоков).
    И ни про какую винду мы такого сказать не сможем
    Это тот случай, про который можно сказать "Да, вы попали по назначению"
    Но согласитесь коллеги, это же не общий случай - это конкретная индивидуальная заточка

    3) Другой разговор - в Урюпинске. Да, сегодня врядли народ найдет нечто ресурсоемкое да запуска на KoOS. Но это только сегодня, а мы же пытаемся говорить о нише применения. Там возможно абсолютно все, даже то, чего мы сегодня и не предполагаем.
    Это закон природы такой, многократно практически проверенный
    Вплоть до тупого многократного нажатия на иконку какой-нибудь проги (про которую я слыхом не слыхивал).
    И ведь следов никаких не будет... Разовор будет: "А у нас ка-а-ак врезалось!!!!"
    Вот тут-то и возникает цифра 2.56 (не путать с п.2, где мною все контролируется) - это количество потоков, которые физически сможет запузырить пользователь, хоть из трусов он выпрыгни.

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

    5) Слушай, ну а чем не конкретная постановка в таком виде:
    5.1) Появляется сис ф-я запроса параметра изохронности потока. Это одно целое - количество квантов, через которое гарантировано получение управления
    5.2) Ось позволяет только один такой с системе. Новая сис. ф-я возвращает в результате успех или неуспех запроса
    5.3) Ось крутит карусель штатным образом, пока не наступает время изохронного потока. Тут и происходит отклонение от штатного планирования понятным образом. При получении управления потоком - его счетчик устанавливается на ранее заданный максимум. На каждом временном кванте - счетчик уменьшается

    Вроде и все...
    Понятно, что конкретность - вещь субъективная. Ну давай уточним, делов-то
    Может это и слишком упрощенная постановка...
    Но в чем фокус: сделать этот стартовый шаг самостоятельно, сегодня, после 2-х месяцев знакомства с кодами - не хватает у меня еще наглости. Через полгодика - хватило бы, наверное...
    А на продолжить, усложнить, экстремальные эксперименты - уже хватает
    Но даже эта упрощенная постановка - дала бы мне средство для борьбы с шаловливыми ручками из Урюпинска
    Может не для абсолютно любой задачи, но дала бы
    Это же бы ли бы принципиально отличающиеся ситуации
  • Galkov

    Наглость - второе счастье.
    P.S. Вышел R300 Gallium3D так что я пока занят.
  • Запуск "под моим чутким наблюдением" - это встроенная система, запуск в Урюпинске - это десктопная система? Раз опреатор может делать на ней все что угодно - то да. Если ты хочеш поставять свою систему в Урюпинск, то как вариант стартуеш свой процесс первым и просто не даеш возможности оператору запускать сторонние программы, это решаемая задача уже сейчас, в таком случае ты фактически получаеш систему запущенную "под моим чутким наблюдением".
    Про изохронность. Для случая с только одним изохронным процссом задача легко решается грубыми методами, в виде правки core->shed.inc->irq0, добавляем туда условие и счетчик, первый запущенный процесс быдет иметь PID 1 (0 - система).
    В таком виде для встройки решение оправдывается, для системы общего назначения нет.
    Но согласитесь коллеги, это же не общий случай - это конкретная индивидуальная заточка
    конкретное применение RTOS (HRT) это всегда заточка, я писал уже что для таких применений планирование просчитывается вручную потом применяется. (под "вручную" здесь понимается "зарание").
  • 2Serge:
    Это бесспорно... Но я привык таки сначала понимать полностью происходяще (хотя бы на этом экране) , а потом уже делать нечто.
    Метод тыка - это не очень мое искусство... Да и глаз дурной...
    Честное слово, пару месяцев, это не очень большой срок для такового... Ну не профессиональный программист я (ну разве что AVR-ки), не идет оно у меня так быстро. Тем более, что пришлось таки еще и Forth познать (были свои причины).
    Так что, если кому интересно, могу свое понимание подробно изложить в соответствующем топике. Ибо с разговорчивостью у фортеров - как-то не очень
    Не, ну и до наглости дело дойдет, куда оно денется.... Не, не завтра...

    2Ghost:
    Да оба дестопа, вообще-то. Как-то уже не очень ДОС-варианты продаются... Все уже избалованы дружественным интерфейсом
    Да, захочется, в процессе резки разобраться и в файлах заказов, может посчитать чего, может отчет написать, или описание каких-нибудь проблем передать по смене...
    Т.е., это все процессы не связанные напрямую с задачей
    А где одна-две, там и много.... 21-й век на дворе.

    А чем я отличаюсь?
    Да тем, что если, к примеру, при копировании файла в KFAR, он у меня вдруг "пропал" (он же не занимается рисованием в процессе копирования), то я не буду запускать его еще сотню раз и повторять содеянное
    Наконец у меня хватит ума и в CPU заглянуть.
    ((если совсем честно, то именно KFAR, и именно второй раз, и именно по этой причине - уже запускал))
    А на разумность оператора из Урюпинска я профессинально рассчитывать просто не имею права, хотя и знаю, что по настоящему тупых не так уж и много...

    Про "вручную", и много изохронов - пощупать надо, подумать, попроверять. Может существуют варианты не настолько навороченные, как в продвинутых осях, но зато "автоматические"...
    Ну мало ли... В смысле, автоматические - в плане оси. А конкретные цифры уставок на каждый изохрон - это просто предмет разработки системы.
    Да, и я совершенно согласен с автором по приведенной Вами ссылки RemarksOnTheMargins: взамодействия потоков, их самоблокировки, и т.п. - это вообще не дело оси, а разработчика системы.
    Головой думать надо, и понимать происходящее, а не на некоторые механизмы (типа инверсии приоритетов) в оси рассчитывать.
    Глупости все это, наверное :)
  • Galkov
    Насчет ехидности моего замечания - ничего ехидного. Просто за 5 лет людей рассуждающих: "как бы было зашибись, если бы все было зашибись" было очень много, людей предлагавших решения было меньше, а вот людей бравшихся за реализацию было совсем чуть-чуть, а тех кто реализовал что-либо совсем "кот наплакал".

    Я согласен с тем что проблемы есть и они требуют решения, но:
    1) Люди работают не за деньги, соответственно "пинать" их по какому либо поводу не имеет смысла.
    2) Вытекает из п.1 - каждый реализует, то что считает интересным и нужным для себя, как справедливо заметил Сергей.

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

    Сергей когда начал работать четко сказал, что он собирается делать и взялся за дело. За что ему большое спасибо. Если ты пойдешь тем же путем, то сложностей не возникнет, если нет... ну, думаю я уже достаточно написал.
  • 2Galkov
    Если есть внешнее устройство, то должен быть и драйвер для него. Твоё внешнее устройство подключается скорее всего к параллельному порту, а если это так, то твоё устройство всегда может генерировать прерывание от параллельного порта, хоть тыщу раз в секунду. Чтобы обработать прерывание придётся написать драйвер, но если твоё устройство только принимает данные, то это больше похоже на драйвер принтера (данные выдаются и стробируются драйвером и квитируются устройством). Если ты напишешь драйвер параллельного порта (принтера), который принимает от приложения большой кусок данных, а потом побайтно выдаёт через параллельный порт, тебе будут только благодарны. А если твоё устройство имеет более хитрый протокол обмена, то придётся писать более специфичный драйвер, только для себя. Но принцип тот же, так что заодно и драйвер принтера можешь состряпать :)
  • tsdima, если ты помнишь благодатные времена 98-й, то нафиг никакие драйверы не нужны были для обращения к портам. Работала бы она еще, до сих пор на ней сидел бы... Посмотри коды IoPorts.pas - делов-то.
    И в KoOS драйверы тоже не нужны для обращения к портам, вроде
    И это есть очень хорошо, между прочим
    Ибо под XP, у меня среднее время обмена с портом около 5 мксек. А цикл ISA меньше микросекунды, вообще-то...

    Да, именно на ём (LPT) у меня камень и сидит. Но это больше от отсутствия образованности.
    Все одно придется в USB врезаться рано или поздно :(
    Правда сидит очень удачно: двунаправленный режим в LPT (т.е., не очень уже и LPT), по-байтный обмен с камнем, у камня на шине данных целиком PortB, на котором же и линии егойного программирования.
    В общем, "брюки могут превратиться"... даже и без легкого движения руки

    Получилась простенькая многофункциональная карта (вообще-то у меня сегодня в ней пока всего 3 функциональности: TWI для вышеупомянутой системы, программатор InCircuitProgramming для моей периферии, и некий "драйвер" для отладки на мегах). Все это дело (8-я mega + несколько резисторов/диодов) спокойно умешается в корпусе DB-25 (прямо тот, который в комп и втыкается)
    Функциональности остальных ног камня - для меня так выше крыши... Там и АЦП 8 входов (т.е., проблем с принятием и буферизацией 10кГц-ого аналогового сигнала у меня вообще никаких), COM, I2C (у них это правда это называется TwoWireInterface), не считая просто цифровых входов/выходов...
    Вот по последнему все мои "думатели" меж собой и общаются.
    Опять же, не потому, что я его считаю самым продвинутым, а потому-что он уже есть встроенный, "сеть" многомастерная даже, 500 кбит/сек мне вполне хватает, из дополнительных деталей для создания "сети" - по ферритовому колечку на линию для "гальваноразвязки" по высоким частотам

    Т.е, у меня настолько все дешево и сердито, что страшное слово Драйвер - даже и вспоминать не очень хочется :D
    Ты же помнишь, что является наилучшим средством от перхоти.....

    Хм... Прерывания....
    Если помнишь, в нашей VICX.sys такой функциональности просто нет.
    Поэтому я и обхожусь без этого.
    И, сказать честно, не очень пока (опять - дефицит образования) представляю, какому INT-у в защищенном режиме соответствует IRQ7 (или 9 - не помню точно, сейчас дома на буке LPT уже отсутствует напрочь)
    Есть, конечно, идеи расширения функциональности, при использовании такового...
    tsdima, но ведь в KoOS сесть на INT - тоже ведь драйвер не нужен :!:

    А вот консультация коллег НУЖНА была бы, как оно работает, синхронно, или асинхронно :?:
    В смысле: вектор int-а на 0-м кольце сразу (асинхронно) передает управление нужному потоку, или откладывает сие важное действо до времени срабатывания карусели (синхронно) :?:

    P.S. если я чего-то не совсем точно (или совсем не точно) понимаю - буду благодарен, если коллеги меня поправят.
    Ну и прошу прощения за некоторый offtop....
    ((типа: открою кодекс на любой странице, и не могу - читаю до конца))
  • Galkov wrote:не очень пока (опять - дефицит образования) представляю, какому INT-у в защищенном режиме соответствует IRQ7
    Ну, это как товарищи ядростроители настроят.
    Galkov wrote:А вот консультация коллег НУЖНА была бы, как оно работает, синхронно, или асинхронно :?:
    В смысле: вектор int-а на 0-м кольце сразу (асинхронно) передает управление нужному потоку, или откладывает сие важное действо до времени срабатывания карусели (синхронно) :?:
    Насколько я понимаю, драйвер может работать внутри ядра не зависимо от того, какой процесс является текущим. После того, как твоё приложение передаст все данные (от начала и до конца) драйверу и он сохранит их в "ядрёной" памяти, ему (драйверу) уже будет по барабану, какой процесс выполнялся в тот момент, когда возникло прерывание (т.е. адресное пространство какого процесса лежит ниже границы 2Гб), т.к. сам драйвер не обращается к какому-либо процессу, а работает сам по себе. Как максимум, он может установить какой-нибудь семафор/мьютекс, которого, например, ждёт твоё приложение. А вот когда ОС даст поработать твоему приложению, тогда-то оно и обраружит это событие, и отреагирует соответственно. Т.е. драйвер работает по принципу: его попросили - он сделал, и поставил галочку. А сам он никуда кроме ядра не обращается.
  • Все, этот вопрос снят.... По ассоциациям писал (во пень), перечитывание Руководящих Технических Материалов сняло все вопросы.
    Драйвер - ну да, можно, но это уже особо тонкое извращение.
    Насколько я понял, сидя на прерывании он может бесстыдно украсть время у любого потока, хоть сверх-изохронного.
    В нем-то и можно порушить по-дурости все ядро вообще, и всю концепцию "rt-планирования" в частности.

    Мне как-то понятнее использовать старшие 16 бит маски событий.
    Если действительно перехватывать вектор драйвером, тогда (видимо) придется и с 59-м общаться - да видал я его в гробу в белых тапках.
    Last edited by Galkov on Mon Feb 09, 2009 9:55 pm, edited 1 time in total.
  • 2Ghost
    Коллега, Вы не так давно намекали, что "с гарантиями" поток получает не 10 мсек, а примерно половину...
    Не могли бы Вы подробнее остановиться на этом вопросе :?:
    открыть глаза, так сказать :oops:
  • Who is online

    Users browsing this forum: No registered users and 7 guests