dxp 53 31 марта, 2010 Опубликовано 31 марта, 2010 · Жалоба а) расход процессорного времени по процессам В чем измерять? В тиках системного таймера? Канал вообще не нужен, имхо. Нужны функции для получения требуемых данных, типа TBaseProcess.GetFreeStack(), TBaseProcess.GetTimes()... етц. А уж как их вызовет пользователь - его дело. Да, пожалуй надо только сами внутренние средства приделать и интерфейс к ним, а там уж видно будет, как лучше. Можно хоть по отдельности юзать, хоть какой-нить класс монитора написать и подключать к любому доступному каналу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 132 31 марта, 2010 Опубликовано 31 марта, 2010 · Жалоба В чем измерять? В тиках системного таймера?Возможно. Как вариант - что-то поточнее. Вплоть до тиков таймера, на прерывании которого висит системный таймер. Ибо частенько процесс работает меньше тика системного таймера. Пользователя чаще интересует отношение загрузки между процессами, поэтому размерность не важна. Самый простой вариант (применялся на моей предыдущей работе в другой операционке) - в прерывании системного таймера инкрементируется счетчик в активном процессе. Раз в несколько сотен прерываний накопленные значения переносятся в результат, счетчики обнуляются. Такой подход не учитывает время, потраченное на прерывания. Для его учета надо вклиниваться в точку переключения процессов и обертку прерываний. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 53 31 марта, 2010 Опубликовано 31 марта, 2010 · Жалоба Самый простой вариант (применялся на моей предыдущей работе в другой операционке) - в прерывании системного таймера инкрементируется счетчик в активном процессе. Если какой-то процесс работает малое количество времени, то он вообще может не пересекаться с прерыванием системного таймера, и тогда он будет вообще казаться полностью неактивным. Наверное правильнее всего делать отсечки при переключении контекста - прямо в тактах, которыми тактируется системный таймер (реализация должна быть простой - через считывание значения таймера. Хотя тут есть трудности на некоторых платформах - например, у MSP430 системным таймером удобно взять сторожевого барбоса, а из него значения взять, насколько помню, нельзя :( ). Для каждой платформы тут должна быть своя функция (в порте), которая возвращает количество тактов (не тиков) частоты, тактирующей системный таймер. Иначе, имхо, смысла мало в таком сервисе. Еще, наверное, имеет смысл ввести счетчик переключения контекста в каждом процессе - тоже интересно посмотреть, с какой частотой щелкает процесс. Иногда такое может помочь выловить нефатальные косяки в программе (например, если процесс переключается слишком часто по сравнению с тем, как должно быть по замыслу). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 31 марта, 2010 Опубликовано 31 марта, 2010 · Жалоба Если какой-то процесс работает малое количество времени, то он вообще может не пересекаться с прерыванием системного таймера, и тогда он будет вообще казаться полностью неактивным. Ну и пусть себе кажется неактивным, счётчик переключений контекста процесса покажет, что это не так. Тут, имхо, важно не переборщить. Размер стека нужно вычислять точно. А количество процессорного времени - всё равно получится приблизительным. Хотя, если в порте доставать тики таймера не накладно, то можно и их конечно:) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
a9d 0 11 марта, 2011 Опубликовано 11 марта, 2011 · Жалоба А можно как нибудь код процессов разнести по разным файлам? У меня файл main.cpp на APM раздулся нешуточно. Уже надоедает его по полчаса листать в поисках процесса. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 11 марта, 2011 Опубликовано 11 марта, 2011 · Жалоба А что мешает? :) Например, выносим процесс TProc1: Создаём файл proc1.h: #ifndef PROC1_H_INCLUDED #define PROC1_H_INCLUDED #include <scmRTOS.h> typedef OS::process<OS::pr3, 1200> TProc1; extern TProc1 Proc1; #endif // PROC1_H_INCLUDED И затем proc1.cpp: #include "proc1.h" namespace OS { template <> OS_PROCESS void TProc1::Exec() { for (;;) { Sleep(100) } } } TProc1 Proc1; Везде, где надо обращаться к Proc1 - пишем сначала #include "proc1.h" Или же, чтобы не запутаться в приоритетах, вынести все объявления процессов в один файл, типа procs.h: #ifndef PROCS_H_INCLUDED #define PROCS_H_INCLUDED #include <scmRTOS.h> typedef OS::process<OS::pr0, 1200> TProc0; typedef OS::process<OS::pr1, 1200> TProc1; typedef OS::process<OS::pr2, 1200> TProc2; extern TProc0 Proc0; extern TProc1 Proc1; extern TProc2 Proc2; #endif // PROCS_H_INCLUDED Как-то так. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
a9d 0 11 марта, 2011 Опубликовано 11 марта, 2011 (изменено) · Жалоба Спасибо. То, что доктор прописал. Я пробовал разнести по разным файлам, но у меня компилятор вечно матерился. ЗЫ: Закоментил в main.cpp namespace OS и все процессы. Вместо этого вставил инклуд #include "process/process.h". В #include "process/process.h" описания процессов. И дальше в каждом отдельном файле код процесса. Все компилится но компилятор никак не реагирует на ошибки в коде процесса и не включает этот код в прошивку. Т.е он собирает прошивку без процессов. Изменено 11 марта, 2011 пользователем a9d Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 12 марта, 2011 Опубликовано 12 марта, 2011 · Жалоба Ну, эта проблема уже не связана scmRTOS. Нужно добавить новые *.cpp файлы к проекту, то есть указать компилятору, что их надо тоже компилировать. Способ зависит от компилятора (и IDE). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yuragv 0 12 марта, 2011 Опубликовано 12 марта, 2011 · Жалоба Подскажите пожалуйста: Исходные данные. Ядро CortexM3. scmRTOS_CONTEXT_SWITCH_SCHEME 1 Как передать управление другому процессу без использования SetSleep ? Получается что процесс с высоким приоритетом не отдает управление процессу с низким приоритетом. Вставка SchedISR() в обработчик сис. таймера не помогает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 132 12 марта, 2011 Опубликовано 12 марта, 2011 · Жалоба Получается что процесс с высоким приоритетом не отдает управление процессу с низким приоритетом. И правильно. На то у него и более высокий приоритет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yuragv 0 12 марта, 2011 Опубликовано 12 марта, 2011 · Жалоба ну я в принципе разобрался. можно в самом низкоприоритетном процессе не отдавать управление. высокоприоритетные заберут сами. только в них надо ставить время ожидание не меньше 2 тиков. а то не перепадет низкоприоритетному ничего. жалко что нельзя два и более процесса сделать с одинаковым приоритетом. Хотелось бы писать допустим чисто интерфейсные процессы, не думая где отдавать управление Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 53 14 марта, 2011 Опубликовано 14 марта, 2011 · Жалоба жалко что нельзя два и более процесса сделать с одинаковым приоритетом. Хотелось бы писать допустим чисто интерфейсные процессы, не думая где отдавать управление При использовании вытесняющей ОС нужно программу строить как управляемую по событиям (event-driven). И интерфейсные процессы отлично ложатся под эту идеологию. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IgorKossak 0 14 марта, 2011 Опубликовано 14 марта, 2011 · Жалоба ... не думая где отдавать управление В привычке думать, где отдавать управление, чувствуется опыт работы с кооперативными ОС. Ломайте привычки, меняйте идеологию. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
a9d 0 18 марта, 2011 Опубликовано 18 марта, 2011 · Жалоба У меня состоит задача в том, чтобы по запросу возвращать самые актуальные данные. У меня два процесса один постоянно опрашивает датчики, обрабатывает показания записывает их в структуру и отсылает меседж. Второй процесс опрашивает трансивер и если пришел запрос, то проверяет is_non_empty() меседжа, и если там что-то есть, то отправляет данные. 1) Это нормально многократно перезаписывать сообщение не получая его? 2) Процесс может отправить сам себе сообщение? Иногда такое, тоже требуется. 3) Используя is_non_empty(), нужно ли потом вручную вызывать reset()? 4) При использовании wait() флаг наличия сообщения сбрасывается сам? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 53 18 марта, 2011 Опубликовано 18 марта, 2011 · Жалоба 1) Это нормально многократно перезаписывать сообщение не получая его? Можно, только прежние тела сообщения будут затёрты. Насколько это вас устраивает, я не знаю. 2) Процесс может отправить сам себе сообщение? Иногда такое, тоже требуется. А зачем? Ведь тут никакой асинхронщины нет. И когда процесс отправляет сообщение, он не может его ждать. Проще и дешевле (в смысле накладных) передавать информацию локально, синхронизируя через локальный флажок. 3) Используя is_non_empty(), нужно ли потом вручную вызывать reset()? Можно. Почему нельзя? 4) При использовании wait() флаг наличия сообщения сбрасывается сам? А в исходник посмотреть? :) Если на момент посылки уже были ожидающие процессы, то флаг наличия и не будет установлен, ибо незачем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться