С твоих слов - "Транслятор такой эффективности этого куска дать не может даже сейчас - не говоря уж про середину 90х."Maxi wrote: А почему они должны быть связаны именно так как ты себе представил связь?
Это лучше авторам документа рассказать ... А владелец и тип сообщения определены и так, - "... так как фактический контекст процесса известен." ... так что мимо.не сокращает это ничего. Все равно на уровне offline должен быть определен владелец и тип. Это сокращает глюки и ошибки.
SSC - не разделяемый ресурс! Им почти всегда монопольно владеет задача его обслуживания. И висит там кот наплакал чего - eeprom тупо кешируется на чтение сразу. А любая запись кешируется обычным стеком на уровне уже задачи. Еще я один раз встречал разделение на уровне ЗАДАЧ. когда задачи блокируют друг друга - но никак не сам ресурс. Потому что это просто глупо. Причем такое возможно только для неотвественных кусков (тот же SSC - в общем случае если его вообще отрезать и все его задачи убить - ничего страшного не произойдет)... То что ты там мог видеть какое то другое разделенное - это полная изоляция отдельных несвязанных кусков кода.
SSC - разделяемый ресурс! А о блокировке именно ресурса не может идти и речь - это крах системы. Реализовано разделение доступа к рессурсу - если ресурс занят, задача не получит его в использование и завершится. Если отрезать SSC, например, в вазовском m7 ничего страшного не произойдет, тупо двигатель остановится, так как банально не будет управление ХХ.
действительно, кооперативный планировщик работает по системному таймеру (как и все в системе), я это и не оспариваю, но запуск кооперативного планировщика осуществляется с помощью службы динамического таймера. Читай внимательно.ерунда кооперативный планировщик работает от системного таймера и никакого отношения к динамическому таймеру он не имеет - у него жесткое заданное offline поведение.
Где - что? Я полагаю структура shedulelist'а тебе известна, если конечно планировщик ты разобрал. header (последнии четыре слова в shedulelist) не опишешь? А теперь сравни хедеры для всех таймслотов.Это где такое?
c каких пор там контролируется пользовательский стек и время выполнения задач?! и главное ЗАЧЕМ?
ты вообще не путаешь с отладкой сейчас?
Ничего я не путаю ...
mainTask (normal mode) -
... start count executing time for task
... check stack filling (пользовательский/системный, через раз)
... ETS monitoring concept, что то связанное с контролем правильности реакции системы
... DFPM
... ETS monitoring concept, URROM
... ETS monitoring concept, что то связанное с контролем правильности реакции системы
... ETS monitoring concept, контроль времени выполнения всех задач в системе
... добавление mainTask в список готовых к выполнению задач (по сути loop mainTask)
... taskResume (предача управления планировщику)
mainTask (nachl mode) -
... check stack filling (пользовательский/системный, через раз)
... ETS monitoring concept, URROM
... HLS
... DMDMIL
... DFPM
... DMIL
... ATM
... BBKHZ
... добавление mainTask в список готовых к выполнению задач (по сути loop mainTask)
... taskResume (предача управления планировщику)
Внимательное прочтение выложенного мной документа (претит читать перевод - есть оригинал) снимет вопрос ЗАЧЕМ, чуть более чем полностью.
Это только контроль времени выполнения описанный как задачи, есть еще контроль на уровне ртос - некоторые задачи (назовешь?) в конце выполнения устанавливают таймера - если не успеют установить к следующиму циклу - безаппеляционный srst ... едакий wachdog на уровне ртос ...
