[addi II 0]

Здравствуйте!

Подскажите пожалуйста, кто знает, действительно ли МАКС такая же бесплатная как FreeRTOS?

Думаю попробовать ее на миландре

Если есть у кого подобный опыт (миандр и бесплатная  ОСРВ), то пожалуйста поделитесь.

Спасибо! 

[Сергей Борщ 119]

Хоть бы ссылку дали. Впервые про такую слышу.

[Alex77 4]

ТС - либо сам себя рекламирует, либо лентяй по жизни.

Достаточно открыть сайт и почитать русские буквы, а если и там не понятно  можно там же и спросить...

[arhiv6 14]

26 минут назад, Сергей Борщ сказал:

Хоть бы ссылку дали. Впервые про такую слышу.

https://www.astrosoft.ru/products/development/rtos-macs/

 + Обзоры были на хабре: https://habr.com/ru/post/336308/

[HardJoker 12]

7 часов назад, addi II сказал:

Подскажите пожалуйста, кто знает, действительно ли МАКС такая же бесплатная как FreeRTOS?

Думаю попробовать ее на миландре

Во-первых, ОС МАКС сырая и недоделанная, во-вторых, ее как раз на Миландре неформальнмо рекламируют. У нас была потребность в использовании ОСРВ, рассматривали МАКС с небольшими доработками по нашему ТЗ, но разработчик в итоге выкатил совершенно неадекватный ценник. Все решилось выбором FX-RTOS - https://www.eremex.ru/products/fx-rtos/.

[addi II 0]

Всем спасибо, теперь понятно что она бесплатно не рабочая, жаль, ..., что нашей альтернативы FreeRTOS нет

Писать им не стал чтобы не попасть на расспросы какой заказчик ,какое изделие итд, потом там где продажники(у них на сайте), может быть подвох

[arhiv6 14]

А что имеется в виду, под "нашей альтернативой FreeRTOS" ? Если нужна RTOS от "наших" разработчиков, то посмотрите:

• Embox  https://github.com/embox/embox   + много их статей на хабре:  https://habr.com/ru/company/embox/
• scmRTOS  https://github.com/scmrtos/scmrtos   + раздел на форуме https://electronix.ru/forum/index.php?app=forums&module=forums&controller=forums&id=188
• https://github.com/dimonomid/tneo   +  https://habr.com/ru/post/267573/
• https://github.com/alexeyk13/rexos
• https://github.com/sergev/uos-embedded
• и т.д.

[juvf 10]

01.12.2020 в 10:15, arhiv6 сказал:

scmRTOS  https://github.com/scmrtos/scmrtos 

Цитата

Releases 14

v5.1.0 Latest

on 20 Apr 2016

Дохлая лошадь?

[arhiv6 14]

В ветке develop последний коммит 6 месяцев назад.

[seabus 0]

В 30.11.2020 в 22:49, addi II сказал:

Всем спасибо, теперь понятно что она бесплатно не рабочая, жаль, ..., что нашей альтернативы FreeRTOS нет

Добрый день! Имею отношение к разработке FX-RTOS, к сожалению, наткнулся на этот пост только сейчас. Если не трудно, не могли бы припомнить, с какой проблемой столкнулись?

P.S. На гитхабе есть исходники и примеры использования: https://github.com/Eremex

Есть чат в телеге, можно спрашивать там: https://t.me/fxrtos

[Vasily_ 45]

2 часа назад, seabus сказал:

Имею отношение к разработке FX-RTOS

На вашем сайте почему-то нет цен. Цены зависят от фазы луны ? Может огласите ценник ?

[dxp 34]

Почитал статейку с хабра (про ядро: https://habr.com/ru/post/336696/). Обратил внимание на следующее (выделено в тексте мной):

Цитата

Вытесняющая многозадачность

Данный вид — самый привычный для многих программ, более того, вытесняющая многозадачность похожа на ту, что применяется в ОС общего назначения. Планировщик даёт каждой задаче фиксированный квант времени (задаётся при помощи константы MAKS_TICK_RATE_HZ, по умолчанию равной 1000 Гц, то есть, квант по умолчанию равен одной миллисекунде), после чего вытесняет эту задачу, ставя на исполнение следующую. Принцип перебора задач рассмотрим чуть ниже, здесь же просто отметим, что задачи исполняются по очереди, согласно системному таймеру. В целом, данная схема выглядит достаточно симпатичной (не зря же она применяется в ОС общего назначения), пока не начинаются битвы за аппаратуру.

 

Цитата

Порядок переключения задач

При описании ОС общего назначения обычно данный раздел имеет огромный размер, при этом авторы добавляют, что описывают механизм кратко, так как от версии к версии механизм меняется. Это связано с тем, что ОС общего назначения должна постараться обеспечить работу всех потоков всех процессов. В случае с ОС реального времени всё просто. Задачи переключаются по алгоритму Round Robin, схема представлена Рис. 3. Суть этого алгоритма заключается в том, что задачи списка выполняется по порядку, а при достижении конца, ОС переключается на начало списка. Внутри списка при выборе задачи на исполнение берётся задача, следующая далее в списке. Если у неё состояние ready, она ставится на исполнение. Если bloсked — переходим к следующей задаче.

Т.е. получается, что по событиям периферии оно работать не умеет, и пока таймер не дёрнет, реакции нет. Например, пришёл символ по UART, и вместо того, чтобы сразу реагировать на событие, задача будет ждать своей очереди? Что-то как-то странная логика. Не соглашусь с автором статьи, что "данная схема выглядит достаточно симпатичной". Время реакции на события является важнейшей характеристикой RTOS.

В других статьях тоже есть моменты, к которым вопросы, но не хочется развозить. Зато ФСТЭК, сертификаты и прочее.

[tgruzd 11]

6 часов назад, dxp сказал:

Например, пришёл символ по UART, и вместо того, чтобы сразу реагировать на событие, задача будет ждать своей очереди?

В любом случае, ждать символ в задаче - плохой вариант.  Что мешает в прерывании (или с помощью дма) забивать буфер символами, а в таске разгребать буфер?

Изменено 15 января, 2023 пользователем tgruzd

[dxp 34]

1 минуту назад, tgruzd сказал:

В любом случае, ждать символ в задаче - плохой вариант.  Что мешает в прерывании (или с помощью дма) забивать буфер символами, а в таске разгребать буфер?

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

UART — это просто как пример. Случаев, где промедление критично, много. Зачем делать передачу управления только по таймеру, а не по событиям, не понятно. По сложности и накладным это примерно одно и то же, но динамика в случае event-driven значительно лучше.

[Nixon 3]

Round-robin обычно идет всегда в довесок к обычной схеме реакции RTOS на событие.