ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Пятница
19 апреля
1256086
Связанные сообщения
Embedded-OsFreertos
ничего сверхъестественного. будет время - попробую натянуть порт FreeRTOS, для GD32VF103 получилось жеж... прикладываю2023-03-03
Два вопроса за раз хочу спросить, смежные в каком-то смысле: 1) есть литература или цикл статей может, по которым можно навести ...2022-06-28
RTOS для этой архитектуры. Список от 2016 года, но интересно.2020-08-23
Есть мысль перейти на RTOS для снижения временных затрат на реализацию программной части, отладку и профилировку. Важна поддержк...2020-06-18
Есть ли "нормальный mutex" в IAR ARM ?2020-06-09
ESP32, приём строки по SPI в задаче (FreeRTOS)2020-05-16
Доброго дня.2020-04-13
CTL (CrossWorks Tasking Library) Written in plain, portable C, Complete source code, No per-product or other runtime roy...2019-10-20
Выскажу ещё раз: FreeRTOS сырая недоделка, смысла особого, без реализации ряда перечисленного (см. ниже) не имеет и, хуже того, ...2019-10-18
"В контексте МК" никаких задач не должно быть! :) Контроллер рассчитан на обслуживание периферии, а потому никаких других событи...2019-09-20
Кооперативную не хотите попробовать? Написана на С, без ассемблера2019-09-02
Смотря какая ОС. В основном ОС делятся по типу: бывают корпоративные ОС и любительские.2019-03-20
Обновлено: трехколесный вялошипет с квадратными колесами (многозадачка на Си). Рожалось в муках, труд всей жизни :)2015-11-16
Задача в принципе решима... Но для начала следует понимать некоторые вещи, после чего придёт также понимаение, что не стоит пыта...2014-01-02
Для этого ОС не нужна. Понимаю, закат солнца вручную... Против FreeRTOS у меня сильно предубеждение, после того как прочитал, чт...2013-11-26
VVB (07.11.2022 12:36, просмотров: 4528) Evgeny_CD
Подскажите про FreeRTOS. Можно ли её настроить на работу с вложенными прерываниями? Если что, архитектура ARM9. 

Эта недо-ос, оказывается, не имеет возможности вложенных прерываний (из которых возможен вызов сервисов RTOS).

Мне надо сделать так, чтобы обработчик CAN мог получить управление как можно раньше (не более 5 мкс от взведения запроса на прерывание).


Я очень прифигел, увидев в коде порта EHCI обработчика прерывания USB стека CherryUSB такую фигню, вызываемую в нескольких циклах:


for (uint32_t i = 0; i < 0xfff; i++) {
__asm volatile("nop");
}

То есть на пустом месте увеличивается время работы прерывания. Это мне абсолютно не подходит, есть мысль сделать обработчик EHCI менее приоритетным чем обработчик CAN, и использовать вложенные прерывания (чтобы обработчик CAN смог прервать обработчик EHCI). Посмотрел на сайте FreeRTOS её документацию, понял, что это в принципе невозможно.

Единственный вариант: глубокие изменения архитектуры программы так, чтобы многие обработчики приёма пакетов CAN не использовали сервисы RTOS, и перевод прерывания CAN с IRQ на FIQ. Не хочу (ленюсь).