zltigo 1 21 мая, 2006 Опубликовано 21 мая, 2006 · Жалоба Просто команда выполнится в холостую. Для этого и проверка, чтобы у USER-проги и желания такого не возникало. А посмотреть на исходник и почитать Аtmel-овский AN (кстати посвященный отнюдь не ядру а периферии ) Хотя в FIQ делать что-то сложное и вызывать систему вообще не рекомендуется. Так, по-быстренькому обратиться к портам или переменным и назад. C чего-бы это вдруг (это если безотносительно к ограничениям конкретной реализации чего-либо). Совершенно нормальный источник. Даже "Быстрый". По крайней мере приоритетный и со своим стеком, что позволяет без дополнительных наворотов вложенность в обычные IRQ реализовывать. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 21 мая, 2006 Опубликовано 21 мая, 2006 · Жалоба 2) FIQ не запрещется ибо предполагается что на то оно и быстрое чтобы из него сервисы ОС не вызывались. 4) Не разобрался до конца со SWI но мне кажется что если его вызвать внутри обработчика IRQ то проц уйдет в исключение SWI если не сразу то в момент переключения в System mode при разрешении вложенных прерываний. Буду изучать детальнее. 5) Идея при входе в критическую секцию запрещать не все прерывания а только прерывание переключения контекста была мною предложена автору scmRTOS недели 2-3 назад, он ее пока думает. 2) Я тоже склонился к такой мысли в процессе "подгонки под себя" FreeRTOS. Однако при этом остался открытый вопрос с ритуальными плясками от Atmel :-( пока оставлены из исходя принципа "береженого бог бережет". 4) Сразу. А какие проблемы предполагаются? 5) Это я, как вариант, у себя сделал, тем более во FreeRTOS были уже заложены два отдельных, но одинаково определенных вызова. Но использовать скорее всего не буду - у меня чаще всего источник системного прерывания переключается на внешний в процессе работы. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 21 мая, 2006 Опубликовано 21 мая, 2006 (изменено) · Жалоба А посмотреть на исходник и почитать Аtmel-овский AN (кстати посвященный отнюдь не ядру, а периферии ) У-у-у. А с каких пор CPSR стал периферией? Хотя если дадите ссылку, то прочту. Совершенно нормальный источник. Даже "Быстрый". По крайней мере приоритетный и со своим стеком, что позволяет без дополнительных наворотов вложенность в обычные IRQ реализовывать. Для таких как вы, придётся делать ещё одну критическую секцию "spatial for FIQ". Изменено 21 мая, 2006 пользователем GetSmart Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 21 мая, 2006 Опубликовано 21 мая, 2006 · Жалоба У-у-у. А с каких пор CPSR стал периферией? Хотя если дадите ссылку, то прочту. Не стал, но завязан :-( А AIC уже в официальных Atmel-овских бумагах выступает как периферия ядра. Ссылка на единственный источник: http://www.atmel.com/dyn/resources/prod_do...nts/DOC1156.PDF Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 21 мая, 2006 Опубликовано 21 мая, 2006 · Жалоба Не стал, но завязан :-( А AIC уже в официальных Atmel-овских бумагах выступает как периферия ядра. Ну и ничего нового не узнал. :-( Смысл ПДФ-а в том, что внутри обработчиков исключений нужно осторожно анализировать/менять регистр SPSR, или по-другому - писать нормально обработчики прерываний. Там вообще ситуация, когда внутри обработчика в регистре SPSR какой-то дурень принудительно разрешает прерывания. Это делать просто не надо. Ни у меня, ни у Сергея Борща такого изврата нет. Глюк-то не периферийный, а программный. Точнее криво-программный. Кстати, это не только для Атмела, но и в LPC такая же бяка. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 21 мая, 2006 Опубликовано 21 мая, 2006 · Жалоба Ну и ничего нового не узнал. Тем не менее как-то Ваши обьяснения на мой взгляд совсем не совпадали с причинами изложенными в документе, ну да бог с ними. Первопричина - в задержке блокировки прерываний на такт после изменения CPSR. В этот такт может попасть обработчик прерывания, что не страшно, ну обработается. Проблемы если обработчик разрешит и не запретит по выходу прерывания. Такое просто делать не надо. Выводы - на прибамбасы в __disable_interrupts() наплевать и забыть..... Кстати, это не только для Атмела, но и в LPC такая же бяка. Похоже :-(. Косвенное подтверждение этому можно получить из описания процесса организации вложенных прерываний на LPC. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
amusin 0 22 мая, 2006 Опубликовано 22 мая, 2006 · Жалоба Есть классная функция, оптимизированная для ARM, которая выдает номер младшего установленного бита в 32-разрядном слове (она используется в Linux’e и TNKernel). Вот ее текст: ... Очевидно имеем констатное время поиска номера младшего установленного бита в слове. Думаю полезно эту функцию использовать вместо стандартного решения. Мысль (именно в приложении к шедулингу) очень здравая. Только приведенный код можно реализовать и на Си (например, первые 2 команды - выделение младшей единички на Си x&(-x)) C точки зрения алгоритмов здесь суть найти число нулей справа (при #define scmRTOS_PRIORITY_ORDER 0 конечно). Реализаций этой функции - море: http://www.hackersdelight.org/HDcode/ntz.cc Для другого порядка приоритетов в карте #define scmRTOS_PRIORITY_ORDER 1 надо использовать функции из http://www.hackersdelight.org/HDcode/nlz.cc Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
amusin 0 22 мая, 2006 Опубликовано 22 мая, 2006 · Жалоба Отлично! Гарри как раз спрашивал, если такая аппаратная функция в ARM. Обязательно добавлю. Нет в АРМ такой инструкции. Взгляни, например, на команду PRIOR в C166 http://www.keil.com/dd/docs/datashts/infineon/c166ism.pdf Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 22 мая, 2006 Опубликовано 22 мая, 2006 · Жалоба Отлично! Гарри как раз спрашивал, если такая аппаратная функция в ARM. Обязательно добавлю. Нет в АРМ такой инструкции. Я так и ответил :-) Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 22 мая, 2006 Опубликовано 22 мая, 2006 · Жалоба Нет в АРМ такой инструкции. Взгляни, например, на команду PRIOR в C166 http://www.keil.com/dd/docs/datashts/infineon/c166ism.pdf Есть у ARM такая инструкция, правда, начиная с архитектуры V5 - CLZ называется. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 22 мая, 2006 Опубликовано 22 мая, 2006 (изменено) · Жалоба Спасибо всем, кто подсказал функцию поиска наиболее приоритетного процесса. Просмотрел все варианты на http://www.hackersdelight.org/HDcode/ntz.cc, наиболее эффективно компилится вариант подсказанный sergeeff за счет замены + на |. Теперь пытаюсь разобраться как оно работает чтобы написать такую же но для x = 8 и 16 бит. Кто-нибудь такое делал? Изменено 22 мая, 2006 пользователем Сергей Борщ Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
amusin 0 22 мая, 2006 Опубликовано 22 мая, 2006 (изменено) · Жалоба Теперь пытаюсь разобраться как оно работает чтобы написать такую же но для x = 8 и 16 бит. Кто-нибудь такое делал? А нафиг? GetHighPriority() лежит в порте ОС, т.е. предназначена именно для ARM. Сделать внутри этой функции static_cast аргумента для ntz (на взгляд профана в С++) - из большей корзины не выпадет, а для nlz из результата вычесть 8 или 24 внутри препроцессорных #if #else. Изменено 22 мая, 2006 пользователем amusin Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 22 мая, 2006 Опубликовано 22 мая, 2006 · Жалоба Теперь пытаюсь разобраться как оно работает чтобы написать такую же но для x = 8 и 16 бит. Кто-нибудь такое делал? А нафиг? GetHighPriority() лежит в порте ОС, т.е. предназначена именно для ARM. Сделать внутри этой функции static_cast аргумента для ntz (на взгляд профана в С++) - из большей корзины не выпадет, а для nlz из результата вычесть 8 или 24 внутри препроцессорных #if #else. Просто в зависимости от количества процессов аргумент для ntz 8, 16 или 32 бит. Или не морочить голову - вроде много тут уже не наэкономить? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IgorKossak 0 22 мая, 2006 Опубликовано 22 мая, 2006 · Жалоба Просто в зависимости от количества процессов аргумент для ntz 8, 16 или 32 бит. Или не морочить голову - вроде много тут уже не наэкономить? Вот именно! Вознёй с 8 и 16-битными вариантами можно только замедлить работу. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sergeeff 1 22 мая, 2006 Опубликовано 22 мая, 2006 · Жалоба Да, конечно, для ARM надо сделать количество процессов - 32. Будет проще и быстрее. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
