Это вы наверно имеете в виду либы от Microchip-а

Да, Microchip никогда не использовал RTOS, у него всегда все работало в суперцикле.
И наверняка есть тысячи разработчиков пишущих сейчас в том же стиле.
В конце концов все ардуинщики так делают, они же тоже программисты

Но только не надо продвигать это как некий прогресс.
Со своим AKOП-ом перед RTOS вы в такой же ситуации как C-и перед C++

Сейчас по аналогии, уже уместно начать доказывать, что RTOS далеко не так медлительна как тут представляется.
Что там есть прерывания ядра, которые работают быстрее прерываний АКОП-а
И если уж делать гибрид RTOS с другим механизмом, то лучше чистый автоматный метод применять, а не АКОП.
Чистые автоматы можно хотя бы строго верифицировать в симулинке.

не знаю что там у них за супер-цикл, лично у меня этот суперцикл выглядит следующим образом:

И он единственный во всем проекте. sleep - это обертка ассемблерной инструкции проца, если что, больше она ничего не делает.


Глупо сравнивать одно с другим глипо в таком дуге. Тут скорее надо проводить аналогию Java и Javascript. Оба мощные языка и позволяют решать одни и те же задачи, но стиль программирования у них совершенно разный.


Чистый автомат во первых очень сложный получится и его развивать будет невозможно. Да еще и его скорость будет зависить от компилятора, на сколько грамотно он все это разместит в jump-tables. А на SST можно запросто делать масштабируемые приложения, как это делается на Javascripte


Kak это они могут быть быстрее, если в SST прерывание - это голый обработчик железного прерывания?
Мало того, он ведет себя точно так же, как и обычный пользовательский код. В нем можно выполнять все те же функции, что и в юзере, а не иметь 2 версии функций под прерывания и под треды.

А может sleep это волшебный супервизор?
или sleep() на самом деле переопределенный вызов суперцикла.
А у меня к сведению тогда главная задача в RTOS выгдядит вот так -




Java и Javascript.., хм. Я бы тогда сказал Java Me Embedded и Jave SE это точнее отразит разницу в масштабе.

Кстати для любителей экзотики уже вышел Java ME Embedded 8.3 . Вот где масштабируемость в истинном смысле слова по полной программе!

Может и супервизор, меня это не волнует, для меня это просто инструкция процессора.
ME/SE стиль похож, а в JS он другой, не похожий на типичную Java.

А вот это выдает подход к программированию, на мой взгляд.

Люди мало программирующие обращают внимание на стиль и синтаксис.
А люди много программирующие обращают внимание только на API и либы.

ME и SE - земля и небо c точки зрения API.

Кстати ваш пустой цикл со sleep-ом может говорить о том, что вы не знаете и не следите за реальной нагрузки своего процессора, т.е. на самом деле не занимаетесь риалтаймом.
Какой-то любительский гаджет со звуком?
А ? Угадал?

За загрузкой проца я слежу отдельным событием по таймеру, использую встроенные средства в проц для подсчета тактов.
Проектов много разных, в том числе и на DSP, где код должен отрабатывать быстро.

А еще SST - это путь к функциональному программированию - где все переменные const(а значит нет side-эффектов), где нет циклов, но есть сборка мусора и рекурсия, где компилятор сам может менять порядок вызова функций местами(мало того - может выполнять разные функции параллельно на разных процессорах/ядрах), когда это не влияет на результат, например:

Так вот компилятор может запросто поменять местами шаги 2 и 3, или группу {2,3,4} поменять с 1 - то есть на экран сначала напечатается y,z, а потом уже x. Но не может поменять, скажем 3,4 тк 4 требует окончания выполнения 3.
Это очень продвинутое программирование, и для императивщика, а тем более блокинг-императивщика оно непонятное и непосильное
Но программы в функциональном стиле короче, чем в императиве и имеют кучу преимуществ. Каких - читайте в гугле.

В SST тоже вещи могут происходить не в том порядке, в котором написано, тоже очень много констант и мало циклов - это уже шаги к функциональному стилю.
Например в SST вот этот код скорее всего выполнится наоборот(а точнее практически одновременно):
printf("Sending 'hello' over SPI\n");
spi->write("hello");
Сначала начнется отправка по spi, а потом уже printf.

Также SST - путь к декларативному программированию. У меня много задач оформлены в декларативном виде.
Рано или поздно императив уйдет, как устаревшая техника, но legacy код ессно будут поддерживать еще очень долго.

По таймеру?
Очень интересно. Прямо сейчас придумали?

Вот лучше это покажите в своей демке.

Да, по высоко-приоритетному таймеру беру за определенный промежуток времени количество тактов из регистра(для кортекс это DWT_xx) и прогоняю через фильтр.
На процах, где этого нет, приходится считать вручную, если это нужно, ценой энергопотребления.

На демке не получится, она под PC.

Вещи на самом деле совершенно обычные, если действительно отбросить всю мишуру. Я к такому пришел первый раз несколько десятков лет назад, когда плотно занимался телефонией и городить многие тысячи процессов со своими стеками да и еще блокировками было просто нереально, посему и естественно получались и очереди и отсутствие (в пределах оговоренных пиковых нагрузок) блокировок. Второй раз лет 15 назад, пришел к этому, когда занялся FreeRTOS. В ней всякие семафоры и иже с ними, были реализованы, КАК МАКРОСЫ НА ОЧЕРЕДЯХ. Подумал я подумал и решил, что лишние сущности плодить незачем и попробовать на нативных очередях все и делать, но, естественно, в "классической" операционной системе.



Нет, на второе "обращают внимание" люди, кторые НЕ занимабтся программированием, а занимаются сшиванием чего-то из кубиков. Их можно называть прикладными программистами.



Да, типа автоматов.

Вот и опять подтверждается то, что я всегда и говорил: оба подхода существуют не просто так. Там где надо - значит надо. А наш проповедник всех тотально на один стек пересадить хочет )) Не зависимо от задачи и процессора.

Используете DWT_SLEEPCNT ?
Отсюда ссылку взяли http://stm32f4-discovery.net/2015/05/cpu-l...-for-stm32f4xx/?

Но в высоконагруженных embedded системах нету slеep-а.




Так потому и обсуждаем чтобы узнать где надо.

Пока все идет к тому, что метод TC годен для очень мелких микроконтроллеров в парой тройкой задач, которые автор в состоянии полностью написать сам не используя сторонний софт.
Ниша очень узкая.
Удобнее полностью перестроится под RTOS, и портировать ее даже на самые мелкие микроконтроллеры.

Странно. Я вижу человека, который рассказывает, как он делает и объясняет, почему он так делает и зачем. И еще толпу, которая пытается ему доказать, что он все делает неправильно. Причем некоторые из этой толпы вообще не понимают, о чем идет речь.

Эт Сергей такой добрый пока brag на ScmRTOS не покатил бочку.

Не оттуда, взял из документации на ARM. Но смысл тот же.
sleeр у меня есть всегда и мониторит загрузку проца отлично. Там, где подобного механизма нет - считаю загрузку вручную через хуки.
Я не любитель загружать проц по максимуму, всегда оставляю резерв на будущее.


Я никого не пересаживаю. Если нужны legacy блокинг-либы, либо коллектив/заказчик хочет блокинг, либо просто работаете над проектом, где уже все написано в блокинг и переход на нонблокинг будет очень сложным и бессмысленным - тогда ССТ Вам не подходит. Вы жестко привязаны к платформе, либам, языку, стилю и технике.
ССТ это для тех, кто хочет развиваться, осваивать и делать что-то новое.
Подход да, очень стар, даже РТОС тогда наверное не было. Но он имеет кучу своих преимуществ и удобств, особенно, если есть хороший мощный высокоуровневый язык.


А че там катить, нормальная ОС, да еще и на плюсах. Хотя есть к чему придраться. Но и к любому коду можно придряться(моему в том числе). Но этот топик про SST, а не про ScmRTOS

Мы рассматриваем ССТ в техническом аспекте, его возможности и недостатки. Вопросов совместимости его из блокинг-либами касаться смысла нет - он с ними не совместим. Можете считать это недостатком. Для кого-то он решающий, а для кого-то - несущественный.

brag, с такими устремлениями вам надо копать в сторону ERLANG - там есть всё, что вы хотите: [настоящий, честный, а не приближение] функциональный язык, легковесные процессы и прочее. Очень эффективен для решения ряда задач. Притом сугубо прикладной, не академический.