abutorin 0 8 марта, 2015 Опубликовано 8 марта, 2015 · Жалоба Доброго времени суток. Пробую использовать TEventFlag для оповещения основного цикла программы о завершении передачи даннных через SPI на STM32F103. В основном цикле очищаю флаг события, записываю данные в регистр, начинаю ждать событие. В обработчике прерывания взвожу флаг события методом signal_isr. Все работает, но остается одна проблема, процесс ожидающий этого события пробуждается только после следующего планирования процессов по системному таймеру, т.е. только примерно через 1мс. Мне казалось что такой задержки быть не должно. Я что-то делаю не так, или непонимаю как это должно работать. Подскажите кто чем может. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DmitryM 0 9 марта, 2015 Опубликовано 9 марта, 2015 · Жалоба Доброго времени суток. Пробую использовать TEventFlag для оповещения основного цикла программы о завершении передачи даннных через SPI на STM32F103. В основном цикле очищаю флаг события, записываю данные в регистр, начинаю ждать событие. В обработчике прерывания взвожу флаг события методом signal_isr. Все работает, но остается одна проблема, процесс ожидающий этого события пробуждается только после следующего планирования процессов по системному таймеру, т.е. только примерно через 1мс. Мне казалось что такой задержки быть не должно. Я что-то делаю не так, или непонимаю как это должно работать. Подскажите кто чем может. Каким образом ожидаете событие? TEventFlag.wait()? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 9 марта, 2015 Опубликовано 9 марта, 2015 · Жалоба Подскажите кто чем может.В обработчике прерывания создается объект класса TISRW_SS? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
abutorin 0 9 марта, 2015 Опубликовано 9 марта, 2015 · Жалоба В обработчике прерывания создается объект класса TISRW_SS? Создается объект TISRW. Как я понял для Cortex-M3 можно использовать его. Каким образом ожидаете событие? TEventFlag.wait()? Да, именно так. Вот код: OS::TEventFlag SPIRE_Event; uint8_t SPI_data; OS_INTERRUPT void SPI2_IRQHandler(void) { OS::TISRW TISRW_O; if (SPI_I2S_GetITStatus(SPI2, SPI_I2S_IT_RXNE) != RESET) { SPI_I2S_ClearITPendingBit(SPI2,SPI_I2S_IT_RXNE); //эта строка необязательна SPI_data = SPI_I2S_ReceiveData(SPI2); SPIRE_Event.signal_isr(); } } int8_t ReadWrite(uint8_t data) { /* Loop while DR register in not emplty */ while (SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_TXE) == RESET); /* Send byte through the SPI1 peripheral */ SPI_I2S_SendData(SPI2, data); SPIRE_Event.wait(); SPIRE_Event.clear(); return SPI_data; } Обработчик прерывания включен только для события RXNE. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 9 марта, 2015 Опубликовано 9 марта, 2015 · Жалоба Создается объект TISRW. Как я понял для Cortex-M3 можно использовать его.Все верно. Должно работать. В деструкторе этого объекта взводится запрос перывания PendSVC. После выхода из текущего прерывания должен вызваться обработчик PendSVC, в котором собственно и должна произойти перепланировка. Причем с системным тиком механизм идентичный, а симптомы один-в-один напоминают забытый TISRW. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
abutorin 0 9 марта, 2015 Опубликовано 9 марта, 2015 · Жалоба Все верно. Должно работать. В деструкторе этого объекта взводится запрос перывания PendSVC. После выхода из текущего прерывания должен вызваться обработчик PendSVC, в котором собственно и должна произойти перепланировка. Причем с системным тиком механизм идентичный, а симптомы один-в-один напоминают забытый TISRW. Похоже я где-то что-то напутал. Сейчас еще раз проверил, и все работает корректно. Видимо я не ту прошивку в железо залил. Спасибо за ответы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SergNK 0 18 января, 2017 Опубликовано 18 января, 2017 · Жалоба Доброго дня! Решил поднять тему вот таким вопросом. Создаю ПО под Freescale M0+ с использованием scmRTOS. Четыре процесса: typedef OS::process<OS::pr0, 512> TProc1; typedef OS::process<OS::pr1, 512> TProc2; typedef OS::process<OS::pr2, 512> I2C0_TASK; typedef OS::process<OS::pr3, 1024> TBackgroundProc; Есть прерывания: TRTC rtc; OS_INTERRUPT void RTC_second_Handler() { OS::TISRW TISRW_O; rtc.RtcSecondIrqHandler(); OneSecondFlag.signal_isr(); } Устанавливаю флаг в прерывании и ловлю его в процессе TProc1: template<> OS_PROCESS void TProc1::exec() { for(;;) { OneSecondFlag.wait(); // while (!rtc.getNewSecondFlag()); led_bl.Cpl(); sleep(5); } } Вылетает по HardFault. Если закомментировать OneSecondFlag.signal_isr(); то не вылетает. Ковыряюсь уже довольно долго. Накопал, что при восстановлении контекстов из критических секций происходит лишнее действие, которое затирает правильно восстановленный контекст. Если использовать флаг rtc.getNewSecondFlag(), вызываемый из объекта, то всё ОК. Куда копать? Вдогонку: Вылетает при выполнении кода: bool OS::TEventFlag::wait(timeout_t timeout) { TCritSect cs; if(Value) // if flag already signaled { Value = efOff; // clear flag return true; } else { cur_proc_timeout() = timeout; suspend(ProcessMap); if(is_timeouted(ProcessMap)) return false; // waked up by timeout or by externals cur_proc_timeout() = 0; <== вылетает при попытке выполнить эту инструкцию - обращение к несуществующей памяти return true; // otherwise waked up by signal() or signal_isr() } } Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 18 января, 2017 Опубликовано 18 января, 2017 · Жалоба Вылетает при выполнении кода: Смотрим, во что выливается этот код: Kernel.ProcessTable[Kernel.CurProcPriority]->Timeout = 0; Давайте начнем с того, чему равен Kernel.CurProcPriority до вызова wait() и перед падением. Потом посмотрим, куда указывает ProcessTable[Kernel.CurProcPriority]. И дальше надо искать, кто портит одну из этих переменных. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SergNK 0 18 января, 2017 Опубликовано 18 января, 2017 · Жалоба Ща попробую Контекст портится после suspend(ProcessMap); Я поставил точку останова на if(is_timeouted(ProcessMap)), а там уже запорчено. Я так понимаю: suspend останавливает процесс, а потом перепланировщик его возобновляет. И при восстановлении контекста что-то происходит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SergNK 0 20 января, 2017 Опубликовано 20 января, 2017 · Жалоба Словил за хвост эту проблему. Словами или кодом описывать тяжеловато, поэтому сделал скриншоты практически пошагового прохождения. Из-за большого объёма топика всё спрятал в прикреплённом файле. Doc1.zip Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SergNK 0 22 января, 2017 Опубликовано 22 января, 2017 · Жалоба Весь день просидел и пытался подобраться поближе к источнику проблемы. Точно не обнаружил, но у меня складывается впечатление, что происходит то, что написано в руководстве о планировщике и о нарушении целостности системы. В связи с этим подскажите, как исследовать эту часть так, чтобы можно было в режиме реального времени обнаружить источник. Пошаговое прохождение не приводит к фатальному исходу. Можно ухитриться словить только хвост проблемы, да и то самый кончик. Я это выложил в виде скриншотов. Когда-то код, связанный с перепланировкой, наверняка подвергался отладке, иначе в руководстве не уделяли подробному описанию проблемы, которая очень похожа на эту. Либо как вариант использовать планировщик с прямой передачей управления. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 22 января, 2017 Опубликовано 22 января, 2017 · Жалоба Извините за банальность, но не пробовали ли вы выключить и снова включить увеличить стеки задач? И нет ли у вас какого-нибудь ещё прерывания, которое может портить память? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SergNK 0 23 января, 2017 Опубликовано 23 января, 2017 · Жалоба Это было сделано в первую очередь. Я не новичок в осях и понимаю подводность камней. Лет 10 назад починил PicOS18. Там при определённых условиях стек Idle восстанавливался не полностью, из-за чего происходило переполнение стеков. Тяжёлая ошибка. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 23 января, 2017 Опубликовано 23 января, 2017 · Жалоба Не обижайтесь, но раз вы этого явно не написали, кто-то должен был спросить :) Ещё банальный вопрос: укажите использованную версию оси, и используемый компилятор. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SergNK 0 23 января, 2017 Опубликовано 23 января, 2017 · Жалоба scmRTOS v5.1 IAR 7.70 Windows 10 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться