caxapa.ru :: Очередная погоня за мипсами

Alex B. (15.04.2009 00:37, просмотров: 31766)

Очередная погоня за мипсами - новая RTOS для PIC24/PIC32 http://www.quasarsoft.com/performance.html
в этой ветке потому что приколол метод лицензирования - неким алгоритмом у продавца генерируется четыре 32-битных ключа, которые используются в функции инициализации для проверки количества объектов, которое можно использовать. Утверждают, что объектники одинаковые для демо и для коммерческой версии. http://www.quasars ….com/faqs.html#license Интересно, сколько часов уйдет на ломание такой защиты и написание альтернативного кейгена? =) Кстати. Эт уже вторая мелкая RTOS (о которой я знаю), сервисы которой вообще не запрещают прерывания. Естественно для этого используются специальные методы, более подробно описанные тут Кто-нибудь имеет мысли по этому поводу? Мне как-то классический вариант ближе...

Согласуйте импеданс!

Ответить

- А ускорение то за счет чего? Ну будет отложенный вызов, как производительность системы в целом возрастет? abivan(610 знак., 21.04.2009 09:51)
  - фишка в том, что при высокой интенсивности прерываний ты в первом варианте можешь что-то потерять (пока в критической секции находишься - флаг то один) Alex B.(125 знак., 21.04.2009 10:02)
    - При высокой интенсивности появления запросов вся секция атомарного доступа с сохранением статуса и запрещением прерываний может (скорее предпочтительно должна) быть соизмеримо мала со временем входа/выхода в/из обработчик. Т.е. если работаем хотя бы с Vit(471 знак., 21.04.2009 19:02)
    - чего потерять? Если отклик на прерывание должен быть "мгновенным", то его не нужно доверять ОС, а обрабатывать своим обработчиком. У меня по крайней мере нет таких задач, где нужно мнгновенно реагировать, всегда можно чутка подождать. Поэтому критерием abivan(446 знак., 21.04.2009 11:26)
      - Тсс! Запрещать прерывания под ОС нельзя! :) - Сергей Борщ(21.04.2009 17:26, ссылка)
        
        и что там противоречит тому что написал abivan? - Alex B.(21.04.2009 17:56)
- Причем обе не дают в исходниках :) Похоже, идеи Adam Dunkels Protothreads -> , они же Stackless Threads, они же Fibers, они же Coroutines --> пошли в народ. Evgeny_CD(700 знак., 15.04.2009 01:08, ссылка, ссылка)
  - не, вы не поняли. Дело не в кооперативности - это вытесняющая RTOS. Alex B.(244 знак., 15.04.2009 01:18)
    - Да понял я, что у нее гибрид - и кооперативка, и вытеснение. Грамотно, ничего не скажешь. - Evgeny_CD(15.04.2009 01:16)
      - не. Я там выше пояснил. Основная фишка не в этом, кооперативную надстройку сейчас многие имеют. - Alex B.(15.04.2009 01:18, ссылка)
        
        Ок. Кстати, есть целая книга на тему "Coroutines: A Programming Methodology, a Language Design and an Implementation" -> - Evgeny_CD(15.04.2009 01:20, ссылка)
        
        По дороге попалось "Coroutines in Lua" - Vit(15.04.2009 08:34, ссылка)
        
        блин. да не в этом дело! - Alex B.(15.04.2009 01:21)
        
        На самом деле все в конечном итоге сводится к понятию некого "виртуального объекта" Вот там у нас уже была дискуссия -> А вот там --> ссылка на TinyTimber, которую дал Vit. А также к обсуждавшейся недавно идее организации FSM чрез макросы и т.д. Evgeny_CD(540 знак., 15.04.2009 01:41, ссылка, ссылка)
        
        вы либо издеваетесь, либо не понимаете. Alex B.(568 знак., 15.04.2009 01:50)
        
        Автор написал, что используется Segmented interrupt architecture - как понял не вход в обработчик окучивается, а в эпилоге вызываются системные дела, т.е. просто в приоритетной секции. И если латентность считаем по входу, то скорость покажем выше крыши - Vit(48 знак., 16.04.2009 13:10, ссылка)
        
        Чудес не бывает. Например, если проц 8-и-битный, то атомарность при работе с указателями обеспечить без критических секций нереально. А в тех же 16-и-битниках обычно уже другая картина. Тем более с PIC24, в которых можно ещё и повысить приоритет, не Vit(469 знак., 15.04.2009 08:13)
        
        критическими секциями будем называть те моменты времени, в которых запрещены такие прерывания, которые могут переключить контекст (в которых вызываются сервисы) - Alex B.(15.04.2009 10:01)
        
        Порылся в линках от Евгения - и возник вопрос - где почитать о недостатках кооперативного планирования? И хотелось бы узнать мнения ув. All. Vit(172 знак., 15.04.2009 12:24, ссылка)
        
        Например, есть задачи: поддержки протокола обмена, расчета отклика ЦФ. amusin(268 знак., 15.04.2009 12:44)
        
        Примерно понял. Получается, что я нарезать уже привык;) благо есть несколько механизмов удобных - Vit(15.04.2009 12:54)
        
        ну, нарезать не всегда получается. например, если используется библиотечная функция или сторонняя либа в объектнике. Один из способов решения - использовать счетный семафор в прерывании - хотя бы точно будет известно, сколько событий было. Конечно, не Alex B.(38 знак., 15.04.2009 13:03)
        
        А может, это ближе к конкретному случаю, чем к общему? Например, если либа попадётся нереентерабельная, то и вытеснение может не спасти. Vit(305 знак., 15.04.2009 13:17)
        
        дык общий случай - это непредсказуемая задержка между возникновением прерывания и запуском задачи (пусть и наиболее приоритетной), которая его ждет Alex B.(160 знак., 15.04.2009 13:27)
        
        ..вот ты здесь мучаешься, а некий бакалавр "готов рассказать про построение ОС реального времени с гарантированным откликом" -=> blackbit(104 знак., 19.04.2009 19:02, ссылка)
        
        да я не мучаюсь - я хотел просто спросить, кто и что по этому поводу думает - Alex B.(20.04.2009 09:38)
        
        ..вот что думаю: blackbit(257 знак., 21.04.2009 01:11)
        
        да эт все понятно... хотелось обсудить именно такой подход к планированию в обработчике прерываний - Alex B.(21.04.2009 09:51)
        
        У меня пока не было задач с требованием фиксированной задержки. Требования к минимизации критичных ко времени частей были и есть, но так же есть разные масштабы времени и, соответственно, есть очень разные требования к отклику. Поэтому бывает, что Vit(115 знак., 15.04.2009 13:45)
        
        хм, дак вы наверное и так их знаете эти недостатки Alex B.(97 знак., 15.04.2009 12:30)
        
        ~~а конкретный пример где такое надо можно попросить описать?~~ отбой, спасибо. выше простой примерчик дали. - Vit(15.04.2009 13:01)
        
        Т.е. не когда запретили программно все прерывания, а когда программно запретили те, которые могут переключить контекст или когда выполняется более приоритетная секция, т.е. все менее приоритетные запрещены аппаратно. Или есть ещё варианты? Эти Vit(470 знак., 15.04.2009 12:03)
        
        Зачем вводить двусмысленность? Запрет прерываний и запрет перепланирования - не одно и то же. amusin(135 знак., 15.04.2009 10:14)
        
        Хммм, а нет ли где примера реализации? А то я что-то не догоняю, как это можно сделать. Прерывания ведь на то и прерывания, чтобы прерывать задачи. Что-то тут попахивает кооперативностью а не вытесняемостью. - =AlexD=(15.04.2009 06:41)
        
        У меня в стартовом посте ссылка не очень заметна на статью. Вот она Alex B.(167 знак., 15.04.2009 09:59, ссылка)
        
        Сноску увидел - Q-Kernel Cooperative Scheduling is based on Light Weight Threads or Fibers - почитаю - Vit(15.04.2009 08:25, ссылка)
        
        это совсем другое, просто названия похожие - Alex B.(15.04.2009 09:56)
        
        Ладно, непонятно выразился. Прошу прощения. Потом как-нибудь объясню. - Evgeny_CD(15.04.2009 01:52)
        
        Ну и теперь "задача на засыпку" - придумать удобный для программера способ работы с этими виртуальными объектами. - Evgeny_CD(15.04.2009 01:48)
  - Кстати, я что-то информации про объем памяти для этой Q-Kernel не нашел. Странно как-то это... - Evgeny_CD(15.04.2009 01:13)
    - оно только сегодня вылезло на микрочиповском родном форуме. - Alex B.(15.04.2009 01:21)

Средства и методы разработки