ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
28 марта
467639 Топик полностью
Связанные сообщения
Freertos
ничего сверхъестественного. будет время - попробую натянуть порт FreeRTOS, для GD32VF103 получилось жеж... прикладываю2023-03-03
Подскажите про FreeRTOS. Можно ли её настроить на работу с вложенными прерываниями? Если что, архитектура ARM9.2022-11-07
ESP32, приём строки по SPI в задаче (FreeRTOS)2020-05-16
Доброго дня.2020-04-13
Выскажу ещё раз: FreeRTOS сырая недоделка, смысла особого, без реализации ряда перечисленного (см. ниже) не имеет и, хуже того, ...2019-10-18
Задача в принципе решима... Но для начала следует понимать некоторые вещи, после чего придёт также понимаение, что не стоит пыта...2014-01-02
fk0, легенда (26.11.2013 15:49, просмотров: 807) ответил ASDFS на Под впечатлением фейла Тоеты захотелось спросить: какие доступные мелкие оськи делают контроль стеков, контроль взаимной залочки задач и прочие ненужные вещи?
Для этого ОС не нужна. Понимаю, закат солнца вручную... Против FreeRTOS у меня сильно предубеждение, после того как прочитал, что TLS у них нет и библиотека C там, практически -- минное поле с граблями. Как с такими особенностями её (FreeRTOS) http://www.youtube.com/watch?v=0_lc81P-R8k
где-то использовать -- не понимаю. Вообще это задача не ОС. Попробую пояснить: если процессор не предусматривает контроля стека, например, то и ОС мало чем поможет. А если предусматривает, то в любом случае будет какой-то обработчик исключений, т.е. контроль стека есть. Только одно но... это уже обнаружение ошибок. А нужно скорей исключение на этапе проектирования. И я здесь не знаю хорошего подхода, кроме как оценить какой-либо методикой, приближенно, требуемый размер стека и умножить, как минимум, на Pi потом. С контролем залочки задач -- аналогично. Здесь вообще FreeRTOS может оказаться АК-47 в руках обезьяны. Нужна в первую очередь методика проектирования алгоритмов в какой-либо форме. Хоть в виде конечных автоматов им. Шалыто. А потом уже кодирование. Обычно же подход "возьмём RTOS, там же всё само, всё автоматически, всё в кайф (а при коммунизме, наверное, вообще не нужно будет умирать), и как-нибудь закодируем"... Ещё проблемой большинства так называемых RTOS является невозможность ожидания более чем одного события одновременно. За этим теряется смысл RTOS вообще (в терминах конечных автоматов возможная только линейная структура переходов между состояниями: 1->2->3->4... без вариантов). Максимум, таймауты обычно есть. Более-менее отличаются только *TRON-подобные RTOS (tnkernel), где есть концепция событий. В "больших" (windows, linux) ОС, замечу, такого ограничения нет (есть select(), WaitForMultipleEvents(), есть асинхронные сигналы или обработка событий в отдельном потоке). По-моему проблема "залочки" в таком случае становится более актуальной. Когда программистом из головы создаётся 11 тысяч ненужных примитивов синхронизации и т.п. Вместо предшествующего проектирования на бумаге. А в последнем случае, моё мнение, удобнее была бы событийно-ориентированная система программирования, однопоточная и синхронная по-возможности (проблема залочки сразу делится на 11000). С небольшим числом независимых процессов (а-ля юникс), где действительно нужно вытеснение.
[ZX]