Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Ликбез по портированию ОС на МК
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > FreeRTOS
Goofy
Не имея опыта в портировании и построения системы на RTOS возникает ряд вопросов по безопасности.
Портировал FreeRTOS на sam7s и кейл. С переключением контекстов вроде как разобрался, простые задачи переключаются, с непростыми пока проблемы.

На что следует обратить особое внимание при написании задач (tasks), упуская вопросы обработчиков прерываний. Просто в моей системе они отсутствуют.

Проблема с одновременным доступом решается вроде как queue.

CS ряда чипов на шине SPI работают программным ногодрыганием, все участки обращения по SPI короткие. Обращения может идти в задачах разных приоритетов. Поможет ли тут enter_CRITICAL, exit_CRITICAL от ситуаций когда несколько CS могут оказаться низкими?

Проверял и судя по всему не спасает...
zltigo
Цитата(Goofy @ Dec 3 2008, 20:42) *
С переключением контекстов вроде как разобрался, простые задачи переключаются, с непростыми пока проблемы.

Постановка вопроса с простыми "не" совершенное непонятна. Принципиально задачи с точки зрения системы все одинаковы по "сложности".
Цитата
На что следует обратить особое внимание при написании задач (tasks), упуская вопросы обработчиков прерываний. Просто в моей системе они отсутствуют.

Ну для начала один присутствует smile.gif. Посему проблема одна - дабы не переключили задачу по таймеру, когда нельзя.
Цитата
Проблема с одновременным доступом решается вроде как queue.

Как один из вариантов.
Цитата
Поможет ли тут enter_CRITICAL, exit_CRITICAL от ситуаций когда несколько CS могут оказаться низкими?

Поможет, если эти функции написаны праввильно в Вашем порте. В штатных, если мне память не изменяет, это работает на __disable/enable_interrupt, что дубово, но (если опять-таки обеспечена компенсация документированных багов работы с CPSR в части запрета прерываний)обеспечивает непрерываемость критической секции.
Goofy
Цитата
Постановка вопроса с простыми "не" совершенное непонятна. Принципиально задачи с точки зрения системы все одинаковы по "сложности".


Процессор сваливается в дАборт когда работает процесс, где имеется процедура с длительными (в маштабах периода цикла системы) вычислениями: плавающая запятая, тригонометрия, матричные операции. Признаки переполнения стека отсутствуют. Там нет даже никаких обращений к переферии, математика одна.

Цитата
Ну для начала один присутствует . Посему проблема одна - дабы не переключили задачу по таймеру, когда нельзя.


Этот один не считается, ему всё можно и вроде не создаёт проблем... smile.gif

Цитата
Как один из вариантов.


По поводу "очередей".
Тк пока я просто перестраиваю уже имеющуюся систему, то IPC пока идёт у меня напрямую через глобальные переменные. Не касаясь адекватности обработки данных, насколько безопасен такой подход?

Цитата
Поможет, если эти функции написаны праввильно в Вашем порте. В штатных, если мне память не изменяет, это работает на __disable/enable_interrupt, что дубово, но (если опять-таки обеспечена компенсация документированных багов работы с CPSR в части запрета прерываний)обеспечивает непрерываемость критической секции.


Пока что в обрамлении критической секции у меня только отключение\включение прерываний. А можно по-подробнее про дубовость и баги ? smile.gif В том же контексте ликбеза smile.gif

Сейчас я диагностировал у себя две проблемы: неадыкватная работа SPI в силу неясности работы ЧипСелектов (зацикливается в ожидании окончания передачи SPI), падение в датаАборт одной из процедур.
Sergey Reva
Цитата(Goofy @ Dec 3 2008, 22:06) *
Процессор сваливается в дАборт ... Там нет даже никаких обращений к переферии, математика одна.

Деление на 0 тоже вызывает abort, правда это было под iar
Goofy
Цитата(Sergey Reva @ Dec 4 2008, 14:19) *
Деление на 0 тоже вызывает abort, правда это было под iar


Проверил в Кейле, не вылетает. Возвращает бесконечность. ( по крайней мере так пишет симулятор )
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.