Board.KolibriOS.org

Какое неверное движение ?

Mario:
Если монитор не держит, то и не будет.

-у монитора стандартное (рекомендуемое) разрешение 1920х1200. Видюха держит такое. В нем Колибри также не работает. Я думал это нормально, и потому как о баге не сообщал.

to Gluk
видяха держит такое разрешение в режиме Vesa х.х ? Какое разрешение у тебя максимальное в blue screen ?

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

to <Lrz>
сейчас проверю. После ребута поправлю этот же пост, дабы не разводить оффтоп сверх меры.

проверил. Максимальное разрешение (вся последняя строчка):

при попытке загрузиться с последней строчкой видно что выводится обычный загрузочный текст, но остальной экран в артефактах, и через секунду-другую происходит ребут.

Давно хотел положить свои пять копеек про Embeded, да все повода не было

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

И вот чего я скажу: еще не полностью KoOS катит под эти задачи
Не хватает маленького шажка в сторону осей реального времни.
Далее, абсолютно конкретно - мое последнее запущенное в экспуатацию изделие
Есть координатный стол (3 координаты, метровые размеры, микронная точность со скоростями типа 0.5 м/сек), который как бы двигает луч CO2-лазера по продукту... Типа режет, варит, гравирует, и т.п., обыкновенное производство, в общем.
Оператор, естественно, сидит за компом, который накачивает траекторию движения в контроллеры (а они уже делают 12-параметрическую ОС с частотой 16 кГц).
Каковы при этом основные задачи для оси ???
Получить данные с компов дизайнеров, которые и делают чертежи резки по требованиям заказчика
Предоставить оператору возможность разобраться с файлами: старые выкинуть, или наоборот - сохранить на всю жизнь
Может какой-нибудь калькуль запустить... Мало ли какие проблемы с устным счетом могут оказаться
Ну и конечно, основная программа - управляющая станком...

Так вот, про основную программу: вообще-то, задача, которой она занимается - эта задача реального времени
Конечно, при разработки я напрягся очень сильно, и мои контроллеры имеют буфер данных на 3 секунды работы.
Но я совершенно не уверен, что другой разработчик сумел бы выйти на аналогичные параметры ((btw: у меня стоят банальные Atmega8-16 за 50 рублёв, аж с целым килобайтом памяти на борту))
Что все это означает ???
Это значит, что (с ПРОФЕССИОНАЛЬНОЙ точки зрения) я должен иметь гарантии, что моя "основная" прога получит управление не позже чем через 2 секунды (ну люфт то какой-то должен же быть: слежу за "заполненностью очереди", на границе 2-х секунд набиваю ее до 3-х), от последнего сеанса общения с осью

А что мы имеем на KoOS ???
Если говорить именно про гарантии, то это 2.56 сек.
Не фонтан, между прочим...

Нет я конечно все понимаю про то, что все нормальные люди 99,9% времени "спят".
И прекрасно понимаю, что в KoOS все значительно более предсказуемо, чем в винде
Я лично - понимаю.
Но, в свою очередь, я прошу понять и коллег, что сделать так, чтобы оно просто работало, и сделать так, чтобы оно работало всегда - это две разные задачи.
Вторая - многократно сложнее.
Но именно умение решать вторую - и называется профессионализмом.

И много ли надо, чтобы KoOS попала в инструменты профессионалов ???
Да нет же, вроде....
Скажем, речь же не идет о полном зверинце требований и примочек для осей реального времени
Мне лично, было бы достаточно существования запроса к ядру, типа "хочу иметь гарантированный полный тик не реже, чем каждые 10"
Получила прога такие гарантиии от оси - все прекрасно. Не получила - пускай пользователь (оператор) сносит глючные процессы.
Нужно просто хоть какая-то гарантированная "точка опоры", чтобы я (разработчик) смог разработать и сделать изделие с гаранированными же характеристики.
Кстати говоря, со мной (как с разработчиком железа) вопросы "отсутствия гарантий" никто и не обсуждает
Просто, отсутствие таковых принято называть неумением работать, и все тут....

Вот, если бы была такая маленькая Real Time фишка (которая, между прочим, нужна и для гарантированной работы оси и с типовым оборудованием компа) - я перый бы присоединился к коллеге:

ДедОк wrote:Ты попал абсолютно по адресу.. перед тобой простая, надёжная, гибкая система, с поддержкой всего, чего тебе надо

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

Ну все в тему получается.... Кроме одного небольшого штриха... О котором и говорил выше

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

1) Если правильно понял вопрос: сейчас (да хоть прямо в эту минуту) это все дело реально работает сутками под XP-Pro... Собственно, не один день все это делалось, отсюда и 3 сек сделал. Кстати говоря, пришлось ведь выше головы прыгать
Размеры и дискретность назвал, забыл сказать, что трасса у нас квантуется 4-мя мсекундами. Вот и попробуйте забуферизировать, имеея 1024 байта ОЗУ на борту
Ну получилось у меня
Но жизнь на этом не кончается, есть другие задачи...
Может проще будут... А может и сложнее...

2) Слушай, всех подробностей и заморочек при конструировании RTOS не знаю. Я на против, с радостью просвятился бы от Вас. Например: HRT - это куда
Пока я высказал гипотезу, что мне (предположительно - многим) хватило бы самой малости... Даже фиг с ним с прерываниями - хорошо бы, но не самое принципиальное
Принципиальное - это существование хотя бы одной точки опоры, от которой можно начать плясать (разрабатывать изделие), оставаясь в рамках профессиональности.
Бог с ним с мощным железобетонным каркасом, может это совсем иная архитектура...
Т.е., 2.56 сек гарантий - не очень впечатляющая цифра. Скажем, возможность установить 0.1 сек произвела бы гораздо большее впечатление на разработчика системы

3) Дык я догадываюсь, что не HRT, и не SRT ( кстати, чего это такое, а? ). Потому и говорю, что какой-то части этого дела шибко не хватает, чтобы иметь возможность не выходить (разработчику) за профессинальные рамки.
Ну надо это (это основной смысл моих постов), чтобы полноправно въехать в эту нишу применения.

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

Galkov
HRT - hard real time - жесткое реальное время, гарантирует реакцию на событие (например таймер) за определенное время.
SRT - soft real time - мягкое реальное время, гарантирует реакцию на событие за определенное время с заданной вероятностью.

Принципиальное - это существование хотя бы одной точки опоры

ты опиши конкретнее какая точка опоры тебе нужна? что она дулжна уметь делать и что гарантировать? А то мы в общих терминах пытемся решить частный случай и несколько недопонимаем друг друга.

P.S. XP-Pro вообще не дает никаких гарантий на реакцию, так что если она справляется с вашими задачами то Колибри тоже справится.

1) Ага, спасибо
Получается да, нужна реакция на событие за гарантированное время.
Ненулевая вероятность "проспать" важную встречу - не премлимо
И ведь ЕСТЬ сегодня таковая гарантия, просто это время довольно большое - 2.56 сек.

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

Хотя (мне кажется), что планировщик мог бы и поменять стратегию и "на ходу", по запросу от соответствующего потока, и при его закрытии
В смысле, кажется, что так было бы удобнее, менее заметнее для остальных пользоватей оси, но это не принципиально.

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

И все, KoOS может утверждать, что embeded - это точно ее ниша.


3) Как раз вся беда в том и состоит, что я это прекрасно знаю.
У нас это первое изделие, которое под виндой работает.
До этого операторы ничего кроме ДОС-а и не видели. Ну так "до коле"

Serge

Какое неверное движение ?

Я же писал - все связанное с MAIN LOOP, если уж мы отбрасываем вызов сервисов GUI через Int 0x40, как не сильно влияющий фактор.
Например пользователь пошевелил мышкой - ты можешь со 100% вероятностью предсказать, что случится при этом в текстовом режиме? Обработчик то висит и рассчитывался он для графических режимов, а никак не для текстового.
И потом не имея сервисов вывода в текстовом режиме - слишком много ложится на плечи программы, как ни банально это звучит.
Я всего лишь подвожу к понятию, что сделать преход в текстовый режим лишь бы работало не является хорошей альтернативой. Большие сомнения у меня, что те кто давно и упорно требуют тестовый режим готовы самостоятельно решать те пролемы которые появятся. Если сервисов не будет для текстового режима то все скорее всего закончится большим пшиком...

Gluk

у монитора стандартное (рекомендуемое) разрешение 1920х1200

+

1920x1440@32 SVGA VESA

Из твоих слов непонятно:
1) Поддерживается ли у тебя с драйвером в Винде разрешение 1920x1440
2) Есть ли у тебя в списке доступных разрешений, в синем экране Колибри, разрешение 1920х1200

Galkov

Т.е., 2.56 сек гарантий - не очень впечатляющая цифра. Скажем, возможность установить 0.1 сек произвела бы гораздо большее впечатление на разработчика системы

Этого можно достичь перепрограммировав таймер, я такие опыты уже ставил в свое время еще на Колибри 0400.
Однако есть один маленький факт портящий все удовольствие - при переключении задач тратится не мало времени на собственно само преключение (с обновлением кучи данных). Таненбаум в частности рекомендуе выбирать частоту преключения от 20-60 Гц.
На самом деле для RTOS преключение вообще вредно и теоретически там должна быть только одна задача, даже потока ядра не должно быть.
Если ты запустишь в Колибри только один поток - твое приложение то ты получишь гарантированно 0,02 сек в уже существующей ОС. Достаточно поубивать все остальные потоки через CPU и закрыть сам CPU, или как вариант в AUTORUN.DAT прописать только свое приложение все остальнео убрав.
И НЕФИК оператору играть в игры на работающей машине - посторонних задач не должно быть в принципе и об этом четко написано в инструкции, а тех кто этого не понимает обычно наказывают: выговор, строгий выговор, лишение премии, перевод на другую должность (раз уж моск тупой), увольнение. Вот и все решение проблем. Техника должна работать, а не заниматься посторонними вещами - Нефик микроскопом гвозди забивать!

Mario wrote:посторонних задач не должно быть в принципе

Не согласен. Допустим частота переключения 50Гц, и процесс решил "заснуть" на 0,1сек. Почему нельзя сделать планировщик так, чтобы процесс проснулся именно через 0,1сек плюс максимум 0,02сек? Ясно, что если таких спящих процессов будет пять штук, то пришлось бы отдавать процессор только им, но во-первых, они скорее всего будут работать менее 0,02сек после чего гарантированно решат "заснуть" (нафига иначе им "засыпать" вообще), а во вторых, в таких вот условиях нехватки процессорного времени гарантии можно и ослабить, т.е. не плюс максимум 0,02сек, а несколько больше, т.к. выше головы не прыгнешь.

Для ядра работа в текстовом режиме ничем не отличается от работы в графическом. Главное выбрать видеорежим в загрузочном экране чтобы ядро думало что оно в графическом режиме. Запустить всего одно приложение, создать окно на весь экран и спокойно работать. Единственное что надо сделать это получить доступ к текстовой видеопамяти. Если нравится текстовый режим и не нужна ногозадачность
в самый раз. Если многозадачность нужна тогда подойдёт эмуляция при помощи console.obj.

Колибри поддерживает максимум 1280*1024 или не больший по площади потому что размер массива display_data как раз составляет 1280*1024 байт. Дальше начинается сегмент TSS и его затирание вешает систему.

tsdima
Под посторонними задачами я подразумеваю задачи совсем не связанные с выполнением основной работы.
Рабочее же приложение может иметь и несколько потоков.
Рассуждать про продвинутый планировщик конечно весьма познавательно и занимательно, но кто его будет реализовывать?

Serge
Ну, зачем ты так а? Я тебе про горячее, ты мне про соленое! Я же не утверждал что этого нельзя сделать. Я лишь подразумевал, что могут наметится трудности которых мы вовсе не ожидаем - тот же пример с неверно установленным обработчиком курсора. Ладно допустим гипотетически система и не зависнет - но она будет тратить время на пустые операции.

Колибри поддерживает максимум 1280*1024 или не больший по площади потому что размер массива display_data как раз составляет 1280*1024 байт. Дальше начинается сегмент TSS и его затирание вешает систему.

Что-то я видимо где-то что-то проспал, но я думал что под линейный буфер выделяется 8 Мб?
Хотя необходимости расширения массива display_data это не отменяет.
1280*1024*4байта=5 Мб.
1920*1200*4байта=8,79 Мб.
Вообще почему не выделять динамически облатсь для display_data, в зависимости от выбранного режима отображения? За одно еще и память съэкономим.

tsdima
"скорее всего будут работать менее 0,02сек" - это и есть мягкое реальное время, и то только если мы знаем меру этого "скорее всего" и она нас устраивает.