«Ну так отсчеты отправляются в очередь сообщений, ISR тут же завершается» – плюс накладные расходы на переключение контекста. Лучше – копить отсчеты в буфер и поднимать задачу, когда буфер заполнился (2 буфера пинг-понгом или один наполовину). Если нужно быстро реагировать на численное значение одного отсчета – делать это в прерывании.
Так или иначе, потенциальная проблема существует: если прерывание вызывается с определенной периодичностью, то в итоге стек переполняется
Дык у тебя почти рекурсия получилась, чего ж ты хотел. Задача еще не начала обработку одного прерывания а уже возникло другое. Еще раз – это проблема не TNKernel (по сути эту «проблему» ты увидишь в любой вытесняющей оси), а архитектуры твоего ПО.
Чем именно не нравится? RAM в МК вечно мало, а вот скорости обычно хватает (ну по крайней мере в моих проектах). RAM экономится реально, поэтому мне этот подход нравится.
ХЗ, интуитивно. Не прозрачно, не понятно, как профилировать.
Но при переносе проекта на другие платформы/порты - таки гемор. ;)
Наоборот, я организовал код так, что переносить стало гораздо проще. Гемор с поддержкой оригинальных апдейтов, но только последний апдейт был год назад и ничего не предвещает новых.
Alex B. (24.08.2014 18:01, просмотров: 229) ответил dimonomid на "Хорошие мальчики в таких случаях в прерывании отсчеты в буфер складывают" - Ну так отсчеты отправляются в очередь сообщений, ISR тут же завершается. Вся работа по обработке отсчетов производится в задаче. Поделись, как сделать лучше?