AHTOXA 0 Posted October 24, 2018 · Report post Я делал так: создал класс-задание: struct Task { char query[20]; char response[20]; int errorCode; OS:TeventFlag flag; } У процесса, который отвечает за обмен (CommunicationProcess), есть очередь заданий (указателей на задания): OS::channel<Task*, 4> tasks; Когда какой-то другой процесс желает совершить обмен, он делает следующее: int Process2::doSomething() { Task t; strcpy(t.query, "GET VAR1"); communicationProcess.execCommand(&t); return t.errorCode; } CommunicationProcess::execCommand выглядит так: void CommunicationProcess::execCommand(Task* t) { tasks.push(t); t->flag.wait(); } Ну и сам главный цикл коммуникационного процесса: OS_PROCESS void CommunicationProcess::exec() { for(;;) { Task* t; if (tasks.pop(t, 10)) // достаём задание { // выполняем его (схематично) uart.send(t->query); if (uart.receive(t->response)) t->errorCode = 0; else t->errorCode = 24; t->flag.signal(); // сигнализируем, что задание выполнено } else { // заданий нет, делаем фоновую работу } } } Quote Ответить с цитированием Share this post Link to post Share on other sites
AlexG 0 Posted October 27, 2018 · Report post On 10/24/2018 at 5:08 PM, AHTOXA said: Я делал так: Спасибо! Именно то что нужно. Quote Ответить с цитированием Share this post Link to post Share on other sites
AlexG 0 Posted September 3, 2020 · Report post Переделываю для работы с scmRTOS библиотеку, рассчитанную на uC/OS-II. Понадобился счетный семафор. Поглядывая на recursive mutex пробую сейчас написать свой, но может быть кто-то это уже делал и я изобретаю велосипед? Quote Ответить с цитированием Share this post Link to post Share on other sites
dxp 0 Posted September 4, 2020 · Report post Если нужен счётный семафор, то лучше сразу сделать свой - там для этого есть штатный путь: отнаследоваться от TService и написать свою логику, подсматривая, как сделаны другие сервисы межпроцессного взаимодействия. Имхо, это будет прямой путь: проще и без костылей. За основу возможно подойдёт тот же TMutex, только вместо простого флага там счётчик завести. Quote Ответить с цитированием Share this post Link to post Share on other sites
Сергей Борщ 0 Posted September 4, 2020 · Report post 3 часа назад, dxp сказал: За основу возможно подойдёт тот же TMutex, только вместо простого флага там счётчик завести. Может я чего-нибудь не понял, но вы описали TRecursiveMutex. Quote Ответить с цитированием Share this post Link to post Share on other sites
AlexG 0 Posted September 4, 2020 · Report post 3 hours ago, Сергей Борщ said: Может я чего-нибудь не понял, но вы описали TRecursiveMutex. У TRecursiveMutex логика работы противоположная. Его можно залочить несколько раз, а мне нужен "Mutex" который можно несколько раз разлочить. Quote Ответить с цитированием Share this post Link to post Share on other sites
AlexG 0 Posted September 5, 2020 · Report post Я правильно понимаю, что нет способа получить любой идентификатор текущего выполняемого процесса не наследуясь от TService или TKernelAgent? Все закрыто от посягательств: TService.cur_proc_prio_tag(), TKernelAgent.cur_proc_priority(), TKernelAgent.cur_proc(), Kernel.CurProcPriority. Только через класс типа Public Морозов? Quote Ответить с цитированием Share this post Link to post Share on other sites
Сергей Борщ 0 Posted September 5, 2020 · Report post Да, правильно. Quote Ответить с цитированием Share this post Link to post Share on other sites