В общем имеется зверь на данном ядре (LM3S3826 если кому вдруг интересно) и для него требуется написать жалкое подобие ОС. От ос требуется только переключать потоки по таймеру, а так же и в случаях если поток решил повисеть на семафоре или поспать некоторое время. А непонятно на данный момент использование main_stack/process_stack и NVIC. Можно ли забить на использование process_stack? Разумно ли переключение потоков вынести в отдельный низкоприоритетный обработчик, чтобы его можно было активировать из других прерываний/основной программы?
Black_mirror, поглядите про обработку прерываний здесь: http://ru.osdev.wikia.com/wiki/Обработка_прерываний_в_архитектурах_ARMv6-M_и_ARMv7-M. В документации АРМовской описано действительно довольно плохо; похоже, тамошние авторы нормальным английским не владеют, поэтому предпочли заменить вменяемые описания на быдлопсевдокод... Я сохраняю контекст прерванного потока в обработчике PendSV, а он, в свою очередь, вызывается из обработчиков других прерываний в случае, если выявилась нужда в длительной обработке (для чего нужно разрешить прерывания, чтобы не возникало неприятностей) или в доступе к общесистемным данным. Если обработчик некоего прерывания способен выполниться быстро и не нуждается в общесистемных данных, то и сохранения контекста потока не требуется: при неходимости дополнительные регистры сохраняются в текущем стеке, а перед возвратом из прерывания -- восстанавливаются, и всё. У PendSV выставлен самый низкий приоритет, поэтому его обработчик вытесняется обработчиками любых других прерываний (т.е. не мешает обрабатывать срочные вещи). Если желаете глянуть код, выполняющий переключение потоков -- см. http://armada-os.org/projects/armada-kernel/repository/show/trunk/Kernel, модуль Interrupts.asm (он большой, поскольку рассчитан на любую архитектуру, ну а выбор конкретной осуществляется с помощью условной трансляции). Там же в Control_Blocks.inc можно глянуть нынешние форматы управляющих блоков, в т.ч. ThCB (блок управления потоком, в котором хранится большая часть контекста для M-версий архитектуры и весь контекст для "настоящих" АРМов). Отдельная документация пока в стадии написания, находится на http://wiki.armada-os.org. Однако должен сказать, что поддержки LMxxx у меня нет и не предвидится за отсутствием означенных МК (по работе или сам по себе имею дело с другими, их хватает пока выше крыши).
В scmRTOS нужно переписать только один файл. Т.е. только функцию переключения контекста. Все остальное написано С++.
SII Спасибо, с прерываниями действительно стало яснее. a9d Если очень интересно, могу объяснить подробнее почему не нужна готовая ОС. Имеется некоторое устройство очень странной организации: загрузочный код в нем объединен с уже готовой ОС(платной), экспортирует для основной программы порядка сотни различных функций, причём десяток это функции ОС. Требуется сделать упрощенную версию этого безобразия для другого контроллера. Чтобы оставить там существующую ОС, нужно покупать дополнительную лицензию. Чтобы засунуть другую ОС, скорее всего придётся написать десяток функций переходников. Есть ли смысл допиливать "готовый" велосипед другую ОС из-за десятка функций?
От сложности зависит. Иногда проще бывает купить и допилить, чем лепить своё. Другое дело, что качество даже фирменного ПО оччень сомнительное. Тут приятель пишет одну прогу, ну так решил сэкономить, использовав готовые библиотеки от STM (прога для STM32). Долго трахался с отладкой; потом путём трассировки выполняемого кода понял: индус-быдлокодер, делая эту библиотеку, где-то там перепутал логические операции, ну и делалось совсем не то, что нужно... Ну а послушался бы меня и писал бы все эти библиотечные функции сам -- ошибок было бы поменьше, а главное, их куда легче найти было бы.
