|
|
Дело в том, что RTOS для DSP в общем-то нет. Большинство RTOS написаны на языке Си, а есть даже и на С++. Ожидать большой скорости от них нереально. Кроме того существуют множество и прочих неприятностей. Например на ZSP400 есть порт для uCOS. Но Си на этом процессоре GNUтый, с ошибками (GNU 3.30 имеете свои собственные ошибки), соответственно, геморрой состоит в том, чтобы их обходить. Это не сложно, но раздражат. Про DSP/BIOS как-то даже вспоминать не хочется.
Вообщем, я пришел к выводу, что если в системе памяти меньше одного метра, то писать планировщик надо самому. Читать, откровенно говоря нечего. Все, что мне удалось узнать интересного - это из даташитов на конкретные RTOS. Книжки же на RTOS пока не написаны (хорошие). Поэтому существует масса противоречивых определений, терминов... Например, можно встретить очень разные определения для троицы флаг, мьютекс и семафор. А термин "мягкий реалтайм" меня вообще веселит. Как говаривал Карл Маркс "нельзя быть слегка беременным" :)
=== каждой задаче выделялся квант по таймеру, но задача сама решала использовать его полностью, либо вернуть управление.
Я раньше делал то же самое, но потом решил, что отдавать управление шедулеру до окончания кванта не стоит. Представьте, что Вы передали управление шедуллеру, он начал работать, а тут квант закончился. Управление по прерыванию снова передается тому же шедулеру.
Т.е. возникает коллизия. Она решается, но за счет дополнительных накладных расходов. Зачем? Пусть уж до конца кванта задача отстаивается как-нибудь...
=== Кроме того голый переключатель задач оказалось ничего не стоит без некоторых дополнений, первым из которых было - правила составления программ-задач, а второе - симуляция некоторой дополнительной архитектуры, как например, я, пожертвовав одним таймером, сделал 8 независимых программных 16 разрядных таймера.
А что, есть Оси где такого не наблюдается? Я таких не знаю. Например exe файл составлен именно по таким правилам. Просто там этот процесс (придание структуры программы) автоматизирован.
=== После упорных испытаний рабочих программ высянилось, что оказывается ;) есть очень тонкая штука, называемая критической секцией и вставлять её надо практически везде, где есть обращение напрямую к аппаратуре. Ну и ещё много чего, на асме просто труднее писать. На си полегче.
Ну для обращения к аппаратуре критических секций не нужно. На это драйверы есть. Критические секции возникают при захвате рессурса. Допустим, Вы смотрите флаг привязанный к массиву. Флаг говорит - массив свободен. Вы пытаетесь захватить массив (установить флаг в "занято") но тут влезает другая задача и изменяет массив... А Вы - то не знаете этого, т.к. у Вас уверенность в том, что массив только Ваш, а реально идет двойной доступ к рессурсу.
Кстати, Си не решает задач с критическими секциями. Он вообще индиферентен к прерываниям. Можно, конечно, самому написать ф-кции открытия и закрытия критической секции.
|
|
E-mail: 
info@telesys.ru
