Начи имам следното чудене. Имам един таск, на който основната роля му е да прибира съобщения от едно Queue и ги отработва по съответния начин. Реално таска спи докато не дойде ново съобщение, но с някакъв тайм-аут. Който ако изтече си прави някой вътрешни операции и пак заспива, чакайки ново съобщение. Нищо сложно като архитектура.

Когато го правя в някакъв отностително прост ОС - обикновенно имам message_receive с тайм аут. Ако има съобщение го вади, ако не, спи с тайм-аут и после излиза. Хубаво де, ама в POSIX такова животно нема. Има три варианта:

1. Спри форевър докато не дойде съобщението... или сигнал. Що са омешани сигнали и съобщения в POSIX немам идея, ама аз съм си тъп, а и не това е въпроса.
2. Не спи въобще - т.е. ако няма съобщение излиза и продължаваме.
3. Спи с тайм аут в абсолютно време. Те това ми се вижда ептен тъпо. Не, че не мога да си калкулирам таймаута като абсолютно време, ама... що?

И ако искам да реализирам мойта простичка конструкция, трябва да го направя със заобиколки - например да не спи въобще, а след него да има sleep(). Или да навивам таймер дето да го буди със сигнал... Или да си калкулирам тайм-аута като абсолютно време (което засега ми се вижда най-смисленото решение).

Направи ми впечатление, че не само това е така и другите синхронизиращи примитиви са на тоя принцип (семафорите например). Аз ли нещо не схващам POSIX концепцията? Т.е. виждам как да си реша проблема, ама нещо ми се види нелогично и да не бъркам концептуално, за това питам.

pthread_cond_timedwait() ей тъй на първо четене от чичко гугъл... иначе да си призная не зная, разучавал съм го преди доста време и не помня подробности. Но помня, че се отказах от съвместимост точно щото беше малко тегаво

За съжаление обаче не познавам по-добър стандарт и ако това ти е целта ще трябва да стискаш зъби. Поне няма да ти е за сефте

И това чака на абсолютно време. Явно така са всичките....

Зъби стискам, ама викам, чакай да питам, да не би да не съм схванал нещо...

Q: Изобщо за embedded ли говорим ? Кой контролер ? Кой OS/RTOS ?
A: В зависимост от контролера, но модерните 32бит имат software IRQ, с което може да будиш таска. Ако няма с timer IRQ, gpio level change IRQ (като ти РЪЧНО правиш промяната на нивото) и горе-долу е същото.

Или за POSIX x86/x64 OS ли говорим ?

Проблем ли е да прочетеш абсолютното време ?

В Posix има select() с който се правят тия работи - още ми е мъгла що са избрали това безумно име де ...
Виж тука http://linux.die.net/man/2/select
Тъпото е, че трябва да направиш queue-то като file/socket stream.

Мдам, ама select() изисква да се работи на файлови дескриптори, а това май създава приличен овърхед в системата. Всъщност незнам, ама така ми изглежда, на мен съобщенията са ми по 10 тина байта... И нямам много тръби, просто еднa, за чии да ходя, чак на select().

Обаче това още повече ме вкарва в размисли, аз си мислех, че POSIX би следвало да води до някаква подреденост, а там кашата е още по-голяма. Ей на при селект времената се задават като интервал, а не като абсолютно, за разлика от опашките със съобщения.

Както и да е, аз виждам как да го направя, просто питах, за да не се окаже, че тотално не схващам концепцията. Дето вика Миро, стискам зъби и газя.

Така и не се похвали коя мотика си тръгнал да настъпваш?

mq_timedreceive() и преобразуване от абсолютно в релативно е решението при мен.
Иначе има известна логика да е абсолютно, примерно за tick-less режими на шедулъра. То и за tick-ed има логика. Не съм спец в тази област, но разсъждавам на глас:
В крайна сметка на OS-а му трябва лист от времевите събития, които да са му удобни за сравнение. С релативни времена на API-то кърнела ще трябва да преобразува от релативно в абсолютно. В posix излиза че ти трябва да преобразуваш - така че е логично да ти експортират ефективния вариант, а ти да си добавиш ако ти трябва спецификата. Не съм спец в тази област, но разсъждавам на глас.

Е зависи как е организиран шедълера. Ако си има обратни каунтери за всеки спящ, релативното време му е по-удобно...
От друга страна, абсолютното дава по-удобна периодичност, щото при буденето можеш да хванеш абсолютното и на следващото заспиване да прибавиш офсета, като по тоя начин изолираш самото забавяне в таска. Може това да им е била идеята, тогава има логика...

Както и да е, ориентирах се.



Тая дето си мислиш... nuttx. Freescale ми изпилиха нервите...

Малко офтопик, разглеждах творенията на АРМ те нали натискат CMSIS + техен os + техен компилатор... Взети поотделно нещата са неизползваеми (аз затова ги ругая), обаче са изградили обща система и имат някаква концепция, която може би ще ти допадне... Пускаш, избираш проц, избираш драйвери, избираш стекове и т.н. Точно както ти го искаш всичко става с няколко клика на мишката, значително по-изчистено спрямо нут-а.
Лошото е, че май е платено и то солено...
Казвам го щото, още не го рекламират много, то и май не е съвсем завършено доколкото разбрах. Но явно са решили да инвестират и освен това натискат производителите на чепове и определено има шанс да се наложат... Като под "наложи" разбирай, че и концепцията им такава. Просто всичките им "стандарти" и библиотеки са така направени, че все едно гледаш публичен търг в България. Вътре само дето не пише кое е победителят... Та ако наложат такъв стандарт аз не мога, а и не само аз, много ще се откажат или няма да успеят. С две думи дребните играчи, включая и нут-а не ни чака светло бъдеще, то не че малките ос-чета някога са имали такова...

Защо искаш да минеш през ОС-а, когато си на MCU ? Направи го, както се прави на MCU - софтуерно, таймерно или gpio прекъсване. Щом си на ARM, а и OS 100% имаш SysTick с добър период, доста кратък, дигай си един флаг там, два реда код, не повече от две инструкции. Обработката после няма да е красива, но съм го правил - флаг на System timer-a и който и да е таск с по-нисък приоритет, докато се изпълнява проверява дали другият няма работа, ако има отива, приключва там, връща се и така. Естествено трябва да си разчетеш времето за всеки таск, но не може и вълка сит и агнето цяло.

Хе-хе, скаута пак успя да ме развесели

Съвсем скоро го ползвах в eCos - не, че няма овърхед, но се трае ... но то и моя зор беше друг - да спя докато не пристигне нещо по серийния порт.

Ако pipes са реализирани читаво са много ефективни (т.е. едно буферче + memcpy през него), все пак идеята им е комуникация между процеси - в твоя случай имаш между нишки и може да ползваш какви ли не други хватки.

Абе личи си как са го добавили по некое време - определено не се вписва особенно елегантно в посикс концепциите. Ма, кво да се прави ...

Ако е за таймаут мисля, че е по удобно да е абсолютно времето - това позволява да направиш няколко итерации без да се налага на всяка една да пресмяташ колко време е останало до таймаута.

Значи незнам точно кое визираш, дай някакъв линк.

Това което съм ползвал тяхно е CMSIS-RTOS (тя си върви в пакета на CMSIS) и това е дословно копиран RTX на Keil (който вече е собственост на АРМ), като само са му спретнали един интерфейсен хедър. Това нещо е примитвен ОС, разбирай - шедълер, синхронизиращи примитиви ( мутекси, семафори и съобщения) и до там. Ползвам го в един проект и работи стабилно, но е наистина много опростено, откъм драйвери няма абсолютно нищо.

Това не мисля, че е платено и не мисля, че някой би дал пари за това. Ако има нещо друго сега излязло, дай да го видя. Апропо, отдавна съм се отказал да търся ОС дето да тръгне с кликания на мишката...

Edit: Сега погледнах на страницата. Излязла е CMSIS 4.2. Като гледам нищо по различно от предишната няма. Кърнела е същия. Има някакъв раздел драйвер... ама там е пустош, само едни празни интерфейсни АПИ-та. Може би разчитат на производителите да си ги разпишат.... Обаче не виждам никаква концепция как тия драйвери ще итерират с ОС-а. Т.е. нищо смислено не виждам.

Абе ако говорим за едно и също нещо - това е на ниво FreeRTOS в момента, само дето комуната му е 1/1000 от на фриито.



Хм, странно, при мен не се получава...