Jump to content

    

simark1979

Участник
  • Content Count

    84
  • Joined

  • Last visited

Community Reputation

0 Обычный

About simark1979

  • Rank
    Частый гость
  • Birthday 11/24/1979

Информация

  • Город
    Краснодар

Recent Profile Visitors

1230 profile views
  1. Из моего поста не следовало, что я им не пользуюсь, пользуюсь уже лет 6-7 (ранее github, теперь gitlab) Я вас наверное удивлю, многие действительно не используют и более того не знают об этом. Некоторые не могут освоить смартфоны, некоторые до сих пор только на ассемблере пишут, Люди разные и способность к обучению с возрастом теряется.
  2. Не понятно, чего Вы пристали к месту и способу резервирования данных. Хоть на флэшку, хоть на HDD, хоть на SSD, хоть в git/svn. Какое это имеет значение в конце концов, пост был о другом.
  3. Во-первых, нет), а во-вторых - использование систем контроля версий не гарантирует, автоматические коммиты)
  4. Не помню, лучше не рискуйте.
  5. После открытия для себя функций по работе с группами бит, вот что придумалось: В потоке вызываем xEventGroupWaitBits() с бесконечным ожиданием. Чтобы проскочить эту функцию, нужно выставить все биты в группе. Каждый контролируемый поток с помощью xEventGroupSetBits должен выставить свой уникальный бит в группе. Перед возвратом из xEventGroupWaitBits(), все биты в группе сбросятся автоматом. Таким образом нужно, чтобы все функции: (watchdog_taskAlive__ui(), watchdog_taskAlive__ph_sensor_reader(), watchdog_taskAlive__rx_sensor_reader()) были вызваны хотя бы один раз. Чем чаще будут вызовы этих функций, тем сильнее можно сократить реакцию на зависание. В зависимости от конфига FreeRTOS, в одну группу можно запихать до 32-х бит. по умолчанию CubeMx так и делает, если этого недостаточно, делайте иерархию из групп. Код не оптимизирован для наглядности) #include "watchdog.h" #include "stm32f2xx_hal.h" #include "stm32f2xx.h" #include "stm32f2xx_it.h" #include "cmsis_os.h" #include "string.h" #define BIT_0 ( 1 << 0 ) #define BIT_1 ( 1 << 1 ) #define BIT_2 ( 1 << 2 ) EventGroupHandle_t xTasksWatchdogEventGroup; void task_Watchdog_control(void const * argument) { MX_IWDG_Init(); xTasksWatchdogEventGroup = xEventGroupCreate(); for(;;) { xEventGroupWaitBits( xTasksWatchdogEventGroup, /* The event group being tested. */ BIT_0 | BIT_1 | BIT_2, /* Здесь перечисляем какие биты ждем */ pdTRUE, /* Указываем, что при выходе из функции, биты нужно сбросить */ pdTRUE, /* Указываем, что возврат из функции произойдет, только после выставления всех битов*/ portMAX_DELAY ); /* Выставление битов ждем бесконечно долго */ HAL_IWDG_Refresh(&hiwdg); } } void watchdog_taskAlive__ui() { xEventGroupSetBits(xTasksWatchdogEventGroup, BIT_0);} void watchdog_taskAlive__ph_sensor_reader(){ xEventGroupSetBits(xTasksWatchdogEventGroup, BIT_1);} void watchdog_taskAlive__rx_sensor_reader(){ xEventGroupSetBits(xTasksWatchdogEventGroup, BIT_2);}
  6. Хммм, интересная тема https://www.freertos.org/xEventGroupSync.html
  7. Сейчас вот на что нарвался https://www.freertos.org/xEventGroupWaitBits.html Может можно будет и прикрутить. Кто-нибудь сталкивался с этими функциями?
  8. Если честно, я не в теме, что такое TCB, нужно изучить)
  9. Сделаю очереди в них и буду хранить
  10. А как такой вариант? В своём цикле каждая задача обновляет свой индивидуальный таймстамп (taskX_timestamp), который равен xTaskGetTickCount() , И есть task_watchdog, которая проверяет чтобы разница между xTaskGetTickCount() и taskX_timestamp, не превышала какой-то порог Если этот порог по какой-то задаче превышен, застреваем в бесконечном цикле, и не дергаем IWD, который потом сбросит контроллер. Естественно, данные о времени между задачами передаем правильным способом Дополню: если какую либо задачу нужно прибить, пишем в его timestamp значение намного больше текущего xTaskGetTickCount() либо где-то сбрасываем флаг слежения за данным потоком, это не даст ложно сбросить контроллер
  11. А что вы понимаете под пингованием задачи? И как вы это делаете? Разумеется, собака не для поиска багов, но может спасти...всё-таки не случайно родились трейсеры для RTOS, иногда баги бывают крайне сложные и неочевидные, редко проявляющиеся. Еще слышал, что программа может сбиться в результате влияния электромагнитных помех на RAM и "ходить" по ложному пути, хотел бы узнать, есть ли такая опасность или выдумки?
  12. Да, наверное не совсем точно сформулировал вопрос. Интересует конечно, как контролировать собаку из кода В статье расписано, но хотел бы узнать, кто и как это делает, может есть другие подходы.
  13. У меня ПО работает вроде надежно, сомнений пока не имею. но зарекаться не буду) читал https://barrgroup.com/Embedded-Systems/How-To/Advanced-Watchdog-Timer-Tips с чего решил, что контролировать вотчдог с одного потока не достаточно надежно
  14. С чего вдруг он сбросит? Задача сбрасывающая вотчдог продолжит работу. и ничего об это не узнает
  15. А если заткнется другая задача? ИМХО это не спасет от косяков в ПО