Jump to content

    

simark1979

Участник
  • Content Count

    88
  • Joined

  • Last visited

Community Reputation

0 Обычный

About simark1979

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

Информация

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

Recent Profile Visitors

1425 profile views
  1. Я действительно никогда не пользовался гитхабовским поиском, даже в голову не приходило.... Огромное спасибо за подсказку и ссылки)
  2. Пытаюсь разобраться с micromenu-v2, идет туго. Никакой документации. Ни у кого случайно не завалялся любой собираемый проект с меню под IAR/KEIL для любого stm32?
  3. Спасибо, сейчас буду разбираться
  4. Всем привет) К stm32 прикрутил glcd с разрешением 128*64 и библиотеку u8g2. Теперь встал вопрос по созданию меню. Когда-то для строчного экрана писал меню сам, но получилось довольно громоздко. Поделитесь опытом, кто как делал меню, может посоветуете готовые библиотеки. Гугление особо ничего не дало, кроме ардуинных решений особо ничего не накопал.
  5. Из моего поста не следовало, что я им не пользуюсь, пользуюсь уже лет 6-7 (ранее github, теперь gitlab) Я вас наверное удивлю, многие действительно не используют и более того не знают об этом. Некоторые не могут освоить смартфоны, некоторые до сих пор только на ассемблере пишут, Люди разные и способность к обучению с возрастом теряется.
  6. Не понятно, чего Вы пристали к месту и способу резервирования данных. Хоть на флэшку, хоть на HDD, хоть на SSD, хоть в git/svn. Какое это имеет значение в конце концов, пост был о другом.
  7. Во-первых, нет), а во-вторых - использование систем контроля версий не гарантирует, автоматические коммиты)
  8. Не помню, лучше не рискуйте.
  9. После открытия для себя функций по работе с группами бит, вот что придумалось: В потоке вызываем 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);}
  10. Хммм, интересная тема https://www.freertos.org/xEventGroupSync.html
  11. Сейчас вот на что нарвался https://www.freertos.org/xEventGroupWaitBits.html Может можно будет и прикрутить. Кто-нибудь сталкивался с этими функциями?
  12. Если честно, я не в теме, что такое TCB, нужно изучить)
  13. Сделаю очереди в них и буду хранить
  14. А как такой вариант? В своём цикле каждая задача обновляет свой индивидуальный таймстамп (taskX_timestamp), который равен xTaskGetTickCount() , И есть task_watchdog, которая проверяет чтобы разница между xTaskGetTickCount() и taskX_timestamp, не превышала какой-то порог Если этот порог по какой-то задаче превышен, застреваем в бесконечном цикле, и не дергаем IWD, который потом сбросит контроллер. Естественно, данные о времени между задачами передаем правильным способом Дополню: если какую либо задачу нужно прибить, пишем в его timestamp значение намного больше текущего xTaskGetTickCount() либо где-то сбрасываем флаг слежения за данным потоком, это не даст ложно сбросить контроллер
  15. А что вы понимаете под пингованием задачи? И как вы это делаете? Разумеется, собака не для поиска багов, но может спасти...всё-таки не случайно родились трейсеры для RTOS, иногда баги бывают крайне сложные и неочевидные, редко проявляющиеся. Еще слышал, что программа может сбиться в результате влияния электромагнитных помех на RAM и "ходить" по ложному пути, хотел бы узнать, есть ли такая опасность или выдумки?