Выпущена scmRTOS 4.0., Ура, товарищи! :) Опции

[AHTOXA]

Собственно, субж.
Ссылки:

• Что нового (en);
• Migration Guide;
• Download;
• svn (trunk).
• User Manual (русский)
• User Manual (en)

Кроме того, незадолго до этого была выпущена версия 3.11. Это завершающая, багофиксная версия 3.x. Ссылки:

• Download;
• svn.

[dxp]

Правда, было пару случаев, когда я высказывал авторам свои хотелки, но при этом серьёзно и обстоятельно их обосновывал.

Одну я помню - про принудительное завершение работы процесса (с последующим перезапуском), это в v4 реализовано. А какая вторая?

Но только чтобы это было без этой SomeISR(). Вот как только аппаратное прерывание возникло, так с точки за ef.wait() и продолжить. А как в другом месте поднимется флаг прерывания, кторого ждёт более приоритетный процесс, так чтобы так же без отдельного обработчика и флага сразу туда. А если менее приоритетный, то чтобы «оно» ждало.

Ну, а системе-то надо как-то "объяснить", по какому конкретно прерыванию в какой код переходить. Т.е. всё равно тут должно быть для того средство. Вот описание такого ISR и является по сути этим средством. Но выраженным штатными возможностями программных пакетов и предоставляющем дополнительную функциональность (можно внутри обработчика какой-то "неотложный"/служебный код выполнить). А сам такой обработчик, если он ничего, кроме сигнала флага не делает, можно вообще в одну строку записать без потери читабельности.

И технически можно было бы сделать так, чтобы при возникновении аппаратного прерывания передача управления сразу была в нужный код (забивать адрес, на который переходить), только учитывая, что всё равно имеет место вытеснение и приоритетность, без переключения контекста и выяснения приоритетности не обойтись. Поэтому эта хотелка вырождается именно в то, что имеем сейчас, практически в чистом виде, ничего лишнего у нас там нет: в ISR делается 1) активизация ожидающего процесса; 2) вызов планировщика, где обрабатываются приоритеты с последующим переключением контекстов (если необходимо).

[ReAl]

Ну, а системе-то надо как-то "объяснить", по какому конкретно прерыванию в какой код переходить. Т.е. всё равно тут должно быть для того средство.

Так я об этом и говорю. Даже если налепить «синтаксический сахар» OS::wait_TRUE_hardware_interrupt(TIMER1_IRQ); (толи допиливанием языка, как во всяких DynamicC, толи внешним препроцессором), всё равно в микроконтроллере — частично аппаратно, частично программно — будет произведена та же самая последовательность действий.

• Возникновение аппаратного прерывания — тут с приоритетами и т.п. все в железе.
• Переход (возможно, через некоторое время) на обработчик — это тоже в железе.
• В обработчике программно (ну где-то же надо, а аппаратно не реализовано) решить
  
  • ждёт ли данный процесс этого события или он и так выполняется, но занят чем-то другим — нужно пометить, что потом ему не нужно ждать,
  • имеет ли право данный процесс выполняться сразу — переключиться на него сразу,
  • если права не имеет — пометить, что на него нужно перейти как только он право получит.
• Если процесс ждал и звёзды благосклонны к данному процессу — переключить на него. Может быть частично поддержано/ускорено аппаратно.

Всё это во всех современных микроконтроллерах, в документацию на которые я заглядывал, будет одинаково молотиться программно. Если и можно что-то возложить на ПДП, то по прерыванию об окончании его работы всё равно пойдут те же процессы.
Ну никакой надежды на то, чтобы «C++ наконец-то заработал на современных чипах»

Причём, как уже было сказано не раз, нужно просто один из методов «драйверного» класса вызывать непосредственно в прерывании и реакция будет максимально быстрая. Если отталкиваться от точки зрения, что вызов метода есть посылкой сообщения объекту, то вызов метода из ISR становится посылкой аппаратного сообщения тем образом, которым «современный чип» только и может это сделать.

Кстати, Cortex-M3 таки молодчинка. Если глянуть табличку времён переключения процесса (по 1-EventFlag, от поднятия лапки в прерывании до опускания в приоритетном процессе), состоящее из перепланирования и переключения контекста, взять оттуда и перемножить микросекунды на мегагерцы, то получим
BlackFin: 360 (ну тут, наверное, контекст большой)
AVR: ~320 (контекст великоват да и push/pop выполняются по два такта)
ARM7, MSP430: ~250
Cortex-M3: 195 (а с учётом последней поправки — 180 ?)

p.s[0] STM8/IAR — собственно переключение контекста немного короче, чем у AVR, перепланирование немного длиннее, но в целом немного быстрее.
p.s[1] Вот же ж зараза, вместо того, чтобы ещё абзац родить для странички STM8 Port в вики scmRTOS, сижу и, как и во времена RU.EMBEDDED, пишу не так для того, с кем формально «дискутирую», как для других — чтобы ему не поверили :-)
p.s[2] побежал я на работу...