AHTOXA 25 April 7, 2010 Posted April 7, 2010 · Report post Что-то с ходу не соображу. У меня для вывода в отладочную в качестве буфера передачи используется OS::channel. Соответственно, если я пытаюсь что-то выдать до вызова OS::Run(), то всё наглухо зависает... Пока придумалось определять, запущена ли ось, и, если нет, то выдавать напрямую в регистр передачи, в обход OS::channel. Короче, субж:) Quote Share this post Link to post Share on other sites More sharing options...
jorikdima 0 April 7, 2010 Posted April 7, 2010 · Report post Зачем же пользоваться средствами ОС до ее запуска? Не делайте ничего до запуска, а всю инициализацию в самом приоритетном потоке. Quote Share this post Link to post Share on other sites More sharing options...
AHTOXA 25 April 7, 2010 Posted April 7, 2010 · Report post Конструкторы глобальных/статических объектов вызываются до запуска оси. А для них желательно уже иметь инициализированной всю периферию. Так, имхо, идеологически правильнее (и гораздо удобнее, что даже важнее :) ) Quote Share this post Link to post Share on other sites More sharing options...
zltigo 4 April 7, 2010 Posted April 7, 2010 · Report post Что-то с ходу не соображу. Да, проблема :( для простых OS создающих задачи статически. У меня периферии обычно много + PnP + диагностика... Посему система с динамически создаваемыми задачами поднимается постепенно ядро, idle, консолька с буфером, который в случае чего можно и принудительно разгрузить. Потом отдельная задача медленно и печально читает конфигурацию, продолжает инициализировать перефирию, создает нужные задачи и кончает жизнь самоубийством. В процессе работы тоже могут возникать задачи типа калибровок, заказной диагностики.... Может пора подумать о других системах? Quote Share this post Link to post Share on other sites More sharing options...
AHTOXA 25 April 7, 2010 Posted April 7, 2010 · Report post Да, проблема :( для простых OS создающих задачи статически. Да на самом деле не так чтоб очень, можно просто флажок добавить и взводить его в OS::Run() :) Просто думал, может есть более легитимное решение, без внесения добавлений в исходники оси. Посему система с динамически создаваемыми задачами поднимается постепенно ядро, idle, консолька с буфером, который в случае чего можно и принудительно разгрузить. Потом отдельная задача медленно и печально читает конфигурацию, продолжает инициализировать перефирию, создает нужные задачи и кончает жизнь самоубийством. В процессе работы тоже могут возникать задачи типа калибровок, заказной диагностики.... Всё это решаемо, вместо динамически создаваемых задач - статическая задача (или несколько), вызывающая нужные функции - "подзадачи". Может пора подумать о других системах? Мне плюсы нравятся. И scmRTOS пока вполне покрывает мои потребности. Чего нет - добавим. Да и компания душевная, а это немаловажно для меня:) Quote Share this post Link to post Share on other sites More sharing options...
zltigo 4 April 7, 2010 Posted April 7, 2010 · Report post Всё это решаемо, вместо динамически создаваемых задач - статическая задача (или несколько), вызывающая нужные функции - "подзадачи". Гениально :( следующим шагом останется выбросить систему. Чего нет - добавим. :) В рамках концепции не разгуляешся. Quote Share this post Link to post Share on other sites More sharing options...
dxp 218 April 8, 2010 Posted April 8, 2010 · Report post Гениально :( следующим шагом останется выбросить систему. Напрасный сарказм. Делегирование действий одной задачи другой (с иным приоритетом) - мощный паттерн проектирования, и на плюсах получается красиво и безопасно. Конечно, это полностью не покрывает функционала, достигаемого честным созданием и удалением объектов-задач, но позволяет достичь изрядной части целей, ради которых обычно затевается вся эта кухня. Кроме того, делегирование действий позволяет эффективно бороться с проблемами, для решения которых применяется инверсия приоритетов (в mutex'ах). :) В рамках концепции не разгуляешся. В определенном смысле да. Но смена концепции - другая цена. Т.ч. везде компромиссы. Короче, субж:) Не очень понял - тебе надо, чтобы оно работало до запуска оси, или чтобы, если ось не запущена, то чтобы можно было это на рантайме диагностировать и не запускать соответствующий код, чтобы программа не падала? Если второе, то действительно, задача решается просто добавлением флажка, взводимого при старте. Quote Share this post Link to post Share on other sites More sharing options...
zltigo 4 April 8, 2010 Posted April 8, 2010 · Report post Напрасный сарказм. Делегирование действий одной задачи другой (с иным приоритетом) - мощный паттерн проектирования.... Читаем первоисточник вызвавший "сарказм": статическая задача (или несколько), вызывающая нужные функции - "подзадачи" Но смена концепции - другая цена. О чем и речь :(. Т.ч. везде компромиссы. Вопрос в оценке (можете считать субъективной :) )предлагаемого scmRTOS уровня компромиссов. Quote Share this post Link to post Share on other sites More sharing options...
AHTOXA 25 April 8, 2010 Posted April 8, 2010 · Report post Не очень понял - тебе надо, чтобы оно работало до запуска оси, или чтобы, если ось не запущена, то чтобы можно было это на рантайме диагностировать и не запускать соответствующий код, чтобы программа не падала? Если второе, то действительно, задача решается просто добавлением флажка, взводимого при старте. Мне нужно чтоб работало, поэтому нужно не запускать соответствующий код, а запускать вместо него осенезависимый вариант:) Уже сделал флажок. Вечером тормозил, не сообразил, что его совершенно необязательно запихивать внутрь оси:) Quote Share this post Link to post Share on other sites More sharing options...
dxp 218 April 8, 2010 Posted April 8, 2010 · Report post его совершенно необязательно запихивать внутрь оси:) Действительно! Тоже об этом не подумал. :) Стереотипы мышления давят. Quote Share this post Link to post Share on other sites More sharing options...
