Easyelectronics.ru

Электроника для всех
Текущее время: 23 мар 2017, 09:22

Часовой пояс: UTC + 5 часов



    • Изготовление печатных плат
    • Создание принципиальных схем и проектирование печатных плат
    • Симуляция работы на spice моделях
    • Просмотр GERBER файлов

Начать новую тему Ответить на тему  [ Сообщений: 80 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 10 сен 2016, 07:50 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 648
dosikus_2 писал(а):
А по теме и С с крестами и форты в эмбедде путь в никуда...

Насчет форта не скажу, а С++ это единственный имеющийся на сегодняшний момент рациональный путь развития в эмбэде.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОС для МК в академических целях.
СообщениеДобавлено: 10 сен 2016, 07:53 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 648
AVI-crak писал(а):
https://www.segger.com - даёт каждой задаче разное время - аналог приоритета.

Время ну ни разу не может быть "аналогом приоритета", поскольку время и приоритет ортогональны.
Цитата:
Время может быть от 1мкс до 1мс, когда время выйдет -задача переключится автоматически. Если в самой задаче стоит команда "шев, усё готово" - то ос сама переключает контекст, и не через диспетчер задач - а моментально.

Господи, они тоже додумались до yield()? Аффигеть достижение...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 10 сен 2016, 08:05 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 648
Menzoda писал(а):
Да, был такой вариант, но я его отмел в пользу варианта номер 2, где я дергаю пользовательскую функцию, а он уж там может сам реализовать такой буфер и выдавать мне из него память сколько я запрошу. Мне кажется это не намного сложнее будет, но значительно гибче, потому что дает пользователю выбор, как именно реализовать выделение памяти.

Ох уж эти "мегагибкие" дизайнерские подходы... Если хотите сделать гибко в этом месте, сделайте менеджер памяти отдельным "плагином", который можно заменить на что-то другое переопределив один дефайн в процессе компиляции самой оси. Заставлять пользователя предоставлять вам какой-либо интерфейс это не гибкость, а способ увеличения ненужных связей в программе и потенциальный источник ошибок. Усложнять просто, упрощать куда сложнее...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 10 сен 2016, 08:10 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 648
AVI-crak писал(а):
Всё верно, но сама суть операции упущена.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 10 сен 2016, 10:39 
Старожил

Зарегистрирован: 27 мар 2015, 01:22
Сообщения: 899
AVI-crak писал(а):
То-есть, если не обращать внимание на скорость реакции - вытесняющая ос вполне быстрая, но назвать её осью реального времени уже нельзя.
А я бы ещё и осями эти экзокернелы не назвал )
evsi писал(а):
Насчет форта не скажу, а С++ это единственный имеющийся на сегодняшний момент рациональный путь развития в эмбэде.
Может уже сразу в вальхаллу? )


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 10 сен 2016, 13:33 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 648
vt340 писал(а):
А я бы ещё и осями эти экзокернелы не назвал )

Предлагаете устроить тут филиал ru.os.cmp ? :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 10 сен 2016, 23:34 
Старожил
Аватара пользователя

Зарегистрирован: 30 мар 2015, 23:56
Сообщения: 346
Ink писал(а):
AVI-crak, вот я читаю и чет не понимаю. программирование под ос - это немного не так ~~
~~ все это за известное время, никак не привязанное к 1мс.

Вам наверное нужно ознакомится с современными FreeRTOS и ChibiOS. Костыль на костыле.
Насчёт правильного программирования - да без проблем.

Например разовая передача данных по физике:
Запускается задача, ей в параметрах передаётся адрес буфера, задача опрашивает занятость периферии, если не свободно - впадает в ожидание, либо сразу настраивает периферию (когда в первый раз). Потом резервирует канал дма и настраивает под конкретную передачу, пинает его, и уходит в ожидание пинка от дма. По окончанию рапортует в структуру связи, и если там не установлен флаг конвейера - то освобождает канал дма и полностью самоубивается из системы.
Подобная связь по физике не требуется каждую секунду. Возможно что за всё время от включения мк до выключения - такая задача не потребуется вовсе.
Сложно? Однако в FreeRTOS и ChibiOS будет затык уже на стадии резервации канала дма, там подобной функции просто нет. Держать подобную задачу в неактивном запущенном состоянии - просто не выгодно, так-же как и выделять под эту задачу память стека и данных.

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

Задачи которые должны что-то успеть посчитать к определённому моменту времени. Можно конечно всё свалить в один громадный конвейер, но это уже получится собственная ос внутри оси. Можно сделать попытку поднять приоритет в FreeRTOS и ChibiOS, но тогда основной алгоритм вообще никогда не будет запущен. Можно сделать всё в прерывании, и потерять математику.
Вариантов очень много, самый щадящий - использование разного рабочего времени цикла активности задачи.

Повторюсь, когда задач две-три - FreeRTOS и ChibiOS более чем подходит. Но когда количество задач переваливает за сотню - ос уровня segger единственный вариант.
Сотня разных задач легко набирается в проекте музыкального центра. Просто потому что алгоритмы там разные, и все хотят памяти, и одновременно не могут быть запущены.

Menzoda писал(а):
Мне хочется над этим поработать из чистого интереса, чтобы новый опыт получить, не более.

Для начала попробуй найти строчки кода переключающие контекст. То-есть с самого простого.
У меня это на асме в открытом виде.
В segger в закрытом виде в готовом бинарнике - который необходимо подключать к своему проекту.
В ChibiOS это в открытом виде, но найти у вас не получится, даже в режиме отладки этот код на дифлайнах на отображается в отладчике. Так-что если не знать где копать - можно и не найти.
В FreeRTOS тоже вроде как открыто, и даже можно конкретно указать на нужные файлы. Но вот какой из кусков кода под дебрями дифлайнов будет исполняться, а какой будет пропущен - узнать можно только под отладкой.

Ну и в качестве учебника по созданию собственной ос на асме - http://badembed.ru/assembler-pereklyuchenie-konteksta/
Ос на чистом С, учебный вариант http://chipenable.ru/index.php/programm ... schik.html
Ещё немного по ос, общего плана http://www.pvsm.ru/c-3/52568

_________________
Потоковая OS


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 00:14 
Свой человек

Зарегистрирован: 29 сен 2011, 12:23
Сообщения: 96
Откуда: Санкт-Петербург
AVI-crak писал(а):
У меня это на асме в открытом виде.
В segger в закрытом виде в готовом бинарнике - который необходимо подключать к своему проекту.
В ChibiOS это в открытом виде, но найти у вас не получится, даже в режиме отладки этот код на дифлайнах на отображается в отладчике. Так-что если не знать где копать - можно и не найти.
В FreeRTOS тоже вроде как открыто, и даже можно конкретно указать на нужные файлы. Но вот какой из кусков кода под дебрями дифлайнов будет исполняться, а какой будет пропущен - узнать можно только под отладкой.

Какой кошмар, сверхсекретные 10 строк на ассемблере.
Вот, нашел с трудом (за минуту) https://github.com/scmrtos/scmrtos/blob ... _asm.s#L79


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 00:46 
Старожил
Аватара пользователя

Зарегистрирован: 30 мар 2015, 23:56
Сообщения: 346
tugo писал(а):
Вот, нашел с трудом (за минуту) /scmrtos/

Стоило-ли так надрываться, яж написал что у меня это в открытом виде, да ещё и ссылку дал на материал для опытов.

_________________
Потоковая OS


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 04:41 
Старожил

Зарегистрирован: 22 мар 2010, 22:54
Сообщения: 3883
AVI-crak писал(а):
Сложно? Однако в FreeRTOS и ChibiOS будет затык уже на стадии резервации канала дма, там подобной функции просто нет. Держать подобную задачу в неактивном запущенном состоянии - просто не выгодно, так-же как и выделять под эту задачу память стека и данных.

а с чего там должна быть такая функция? понадобилось что-то специфичное - написал. и я не уверен, что под это нужна отдельная задача. пока кто-то отправил данные и ждет ответа - он что делает? ничего? тогда зачем отдельная задача? вызвал подпрограмму и готово. создание-удаление задач на мк - это нонсенс. у меня стойкое ощущение, что вы делаете какой-то костыльный дизайн софта и жалуетесь на ос.
AVI-crak писал(а):
Сотня разных задач легко набирается в проекте музыкального центра. Просто потому что алгоритмы там разные, и все хотят памяти, и одновременно не могут быть запущены.

а можно пример вот этих вот хотя бы 15 задач в муз центре?
и если они не могут быть запущены одновременно - почему всё это отдельные задачи?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 09:38 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 648
AVI-crak писал(а):
Но вот какой из кусков кода под дебрями дифлайнов будет исполняться, а какой будет пропущен - узнать можно только под отладкой.

Вообще-то для этого есть препроцессор.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 10:34 
Старожил

Зарегистрирован: 24 янв 2011, 23:26
Сообщения: 347
AVI-crak писал(а):
Ink писал(а):
AVI-crak, вот я читаю и чет не понимаю. программирование под ос - это немного не так ~~
~~ все это за известное время, никак не привязанное к 1мс.

Вам наверное нужно ознакомится с современными FreeRTOS и ChibiOS. Костыль на костыле.


Там и кроме костылей проблем куча. Например FreeRtos. Не знаю как сейчас, но раньше были разные вызовы для, по сути, одного и того же. противотанковая мина для проекта. Почему программист должен заниматся разруливанием состояния ОС? Что, нельзя сделать это внутри? Ах да, тогда надо больше платформозависимого кода.
Задача не может сама завершится. Все, с этого момента мы уже несовместимы с многими ОС. Значит код уникальный, либо костыли. И еще много таких требований. Которые делают невозможной миграцию на эту ось и с нее. В идеале задачи вообще не должны зависеть от оси, только вызовы которые либо стандартны либо легко переопределяются. Ах да, инкапсуляция и слабое сцепление, нет не слышали.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 14:53 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 648
Mekong писал(а):
И да, они таки додумались до сопрограмм. Правда в их реализации это копрограммы.

coroutine это и есть "сопрограмма" в переводе на российский. Если кто-то перевел это как "копрограммы", то это его проблема.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 16:29 
Старожил

Зарегистрирован: 24 янв 2011, 23:26
Сообщения: 347
evsi писал(а):
Mekong писал(а):
И да, они таки додумались до сопрограмм. Правда в их реализации это копрограммы.

coroutine это и есть "сопрограмма" в переводе на российский. Если кто-то перевел это как "копрограммы", то это его проблема.


Если их так реализовали, то это чья проблема?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 16:58 
Старожил
Аватара пользователя

Зарегистрирован: 30 мар 2015, 23:56
Сообщения: 346
Ink писал(а):
а можно пример вот этих вот хотя бы 15 задач в муз центре?
и если они не могут быть запущены одновременно - почему всё это отдельные задачи?

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

AVI-crak писал(а):
создание-удаление задач на мк - это нонсенс.

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

Написание и использование собственного менеджера дма под ос типа FreeRTOS и ChibiOS - невозможно по простой причине, сами ос юзают дма своими встроенными драйверами периферии, бесконтрольно.

_________________
Потоковая OS


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 17:16 
Старожил

Зарегистрирован: 22 мар 2010, 22:54
Сообщения: 3883
Mekong писал(а):
Например FreeRtos. Не знаю как сейчас, но раньше были разные вызовы для, по сути, одного и того же.

пример?
Mekong писал(а):
Задача не может сама завершится. Все, с этого момента мы уже несовместимы с многими ОС.

а зачем нужна эта совместимость в эмбеддед? запускать юниксовые программы? цели слишком разные у юниксов и встраиваемых ос.
встраиваемая ос всего лишь упрощает написание некоторого вида программ, не более того. она и не должна быть универсальной или совместимой. вас же не смущает, что она не умеет загружать бинарники как задачи и запускать (как это делают взрослые ос)? так и удаление - не всегда оно обязательно, полюбому можно обойтись без него, чуть иначе построив программу.
ну а если очень надо такие костыли - сделал небольшую обертку и хромай скока хошь.
AVI-crak писал(а):
Любая современная магнитола на андроиде.
Для маленьких ос те-же проблемы, нехватка памяти и эксклюзивная реконфигурация имеющийся памяти под текущую задачу.
я просил список из 15 задач, а не тип задачи.
на счет памяти, нужно понимать, что если речь идет о флеше, так он будет занят одинаковым кодом в любом из случаев. если об озу, так когда вы запускаете доп. задачу, она динамически на время работы выделяет себе память. то же может делать и подпрограмма, приблизительно в тех же кол-вах, а то и меньше. если параллельность не нужна (а по вашим словам это именно так), не нужны и отдельные задачи.
если параллельность типа нужна, то где гарантия, что не запустятся все задачи одновременно? (а так им не хватит памяти)
опять все ваши проблемы сводятся к дизайну структуры проекта.
AVI-crak писал(а):
Запуск одноразовой задачи, которая должна выполниться параллельно текущему процессу, и уничтожится после - это не тоже самое что вызов подпрограммы.

это то же самое, если запустить 2ю задачу - менеджер подзадач (подпрограмм), который будет вызывать то, что вам нужно.
AVI-crak писал(а):
Написание и использование собственного менеджера дма под ос типа FreeRTOS и ChibiOS - невозможно по простой причине, сами ос юзают дма своими встроенными драйверами периферии, бесконтрольно.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 17:33 
Старожил

Зарегистрирован: 24 янв 2011, 23:26
Сообщения: 347
Ink писал(а):
Mekong писал(а):
Например FreeRtos. Не знаю как сейчас, но раньше были разные вызовы для, по сути, одного и того же.

пример?


Навскидку
xQueueSendToBack(),
xQueueSendToBackFromISR()
Делают одно и то же, но задача пользователя разруливать состояние. Раньше такого там было много, сейчас не скажу, может что то пофиксили.
Это должно быть проблемой операционки. А тут так старательно разложены грабли.
Так же как и завершение работы задачи по фигурной скобке.

Ink писал(а):
Mekong писал(а):
Задача не может сама завершится. Все, с этого момента мы уже несовместимы с многими ОС.

а зачем нужна эта совместимость в эмбеддед? запускать юниксовые программы?


Если вы с самого начала пишете legacy код, то вопросов нет.
А совместимость нужна чтобы в дальнейшем использовать написанные программные модули без использования бубна. И при чем здесь юникс?
Вы выросли как специалист или перешли на другой проект где по требования стоит например uOS. И все, ваши модули туда не подключишь так просто.
Или проект free rtos забросили и встал вопрос миграции.

Ink писал(а):
цели слишком разные у юниксов и встраиваемых ос.


Я понимаю что вы совместимость видите как то по своему. Это в мире больших компов зависимость от оси сильная. В эмбедд куда сильнее от железа. И если написанные модули от оси не зависят, а слой HAL выделен аккуратно и не содержит острых зависимостей от железа (например использование какого то особого функционала конкретного МК), то перенос на другую ОС вообще незаметен, а на другое железо - все равно только слой HAL переписать.

ОС должна решать задачи организации работы программных модулей и зависимость от нее должна быть минимальной.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 18:45 
Старожил
Аватара пользователя

Зарегистрирован: 30 мар 2015, 23:56
Сообщения: 346
Ink писал(а):
это то же самое, если запустить 2ю задачу - менеджер подзадач (подпрограмм), который будет вызывать то, что вам нужно.

И что будет делать этот менеджер подзадач во время прямого вызова подпрограммы? А ничего, он будет выполнять подпрограмму. Как ни крути, смысл не меняется.

Ink писал(а):
"в советские времена" не было во фриртосах никаких встроенных дров для периферии. были примеры, например, для уарт, но и те были куцие


А теперь есть, и это часть общей системы, при попытке выкинуть либо сократить код - всё разом ломается.

Кстати, насчёт 15 задач для муз центра, исключительно физика:
0 общий менеджер ресурсов энергосбережения, он-же общий менеджер состояния магнитолы.
1 драйвер физики экрана
2 экранный менеджер слоёв "видео", он-же общий рисовальщик интерфейса, отрисовка по поступающим командам от других тасков.
3 нечто типа прямого доступа к экранной области, полуаппаратное решение, аналог draw режима на современных видеокартах.
4 драйвер флеш носителей, разных чипов и размера.
5 физ драйвер радио, полуаппаратное решение.
6 физ драйвер чипа приёмника телевидения, сразу нескольких стандартов, а так-же аналоговых камер заднего вида.
7 физ драйвер проводного ентернета, для цифровых камер заднего вида и как вариант - регистратора.
8 физ драйвер блюпупа, полуаппаратное решение.
9 физ драйвер вайвая, полуаппаратное решение.
10 физ драйвер спутниковых чипов навигации, и всё что с ними связанно.
11 физ драйвер сотовой связи, и не спрашивайте зачем.
12 драйвер внешней периферии магнитолы, а так-же менеджер сообщений от многочисленных датчиков, начиная от банального стопсигналла, заканчивая прямым подключением к бортовому компу. Ну там голосом человеческим сообщить через колонки - типа масла/бензина/омывайки мало, или явная неисправность не кодом ошибки - а человеческим голосом.
13 есно голосовой синтезатор, как вариант - плеер готовых сообщений.
14 полуаппаратный драйвер звука, с эквалайзером, эффектами, и плюшками.
15 полуаппаратный драйвер вывода цифрового звука на крутые внешние усилители, чтоб бумкало.

Можно придумать ещё несколько отдельных задач под физику, но для средней магнитолы - это уже перебор.
Далее полностью программный уровень:
0 отдельный фоновый таск микшера звука.
1 отдельный таск декодеров разных форматов сжатия музыки и видео.
2 отдельный таск сжатия видео и звука.
3 отдельный "графический" визуальный таск менеджера музыкальных и видео файлов, с поддержкой создания, переименования, удаления, и группировкой в плейлисты.
4 таск для работы с навигацией - отображение, поиск маршрута, подсчёт экономии бензина и прочие плюшки.
И так далее, ещё штук 20 задач - которых нет смысла запускать одновременно.

Самое прикольное - это всё есть в стандартной двухдимовой китайской магнитоле стоимостью в 15к, в которой в качестве центрального чипа стоит мк фирмы st. Это конечно отличается от стандартных примеров из интернета, где средний уровень заканчивается морганием светика.

_________________
Потоковая OS


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 18:52 
Старожил
Аватара пользователя

Зарегистрирован: 30 мар 2015, 23:56
Сообщения: 346
Mekong писал(а):
ОС должна решать задачи организации работы программных модулей и зависимость от нее должна быть минимальной.

Мне нравится ваш ход мыслей, а также склонность к убийству лишних тасков.
Если у вас будет отдельный проект собственной ос - будет интересно взглянуть на код.

_________________
Потоковая OS


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 20:37 
Старожил

Зарегистрирован: 22 мар 2010, 22:54
Сообщения: 3883
Mekong писал(а):
Навскидку
xQueueSendToBack(),
xQueueSendToBackFromISR()
Делают одно и то же, но задача пользователя разруливать состояние.
я так и думал. но ведь вы понимаете, почему именно так сделано? и вы понимаете, ЧТО нужно, чтобы использовать только одну точку входа и для задачи и для прерывания? (как минимум обернуть каждый обработчик в свои костыли, не так ли? это не лишний гемор для кодера?)
Mekong писал(а):
Это должно быть проблемой операционки. А тут так старательно разложены грабли.
Так же как и завершение работы задачи по фигурной скобке.
для мира больших машин - согласен. там ресурсов дофига, можно сделать всё ради удобства, хоть 100500 оберток. правда опять же из-за этих оберток тоже кто-то будет ныть, что все тормозное и он не может в данной оси обрабатывать 100500 прерываний в секунду. не бывает ничего идеального.
про завершение задачи по выходу из функции - соглашусь, странно, что этого нет. но это не должно быть большой проблемой. эта проблема указывает скорее всего на косяки в дизайне проекта.
Mekong писал(а):
Если вы с самого начала пишете legacy код, то вопросов нет.
А совместимость нужна чтобы в дальнейшем использовать написанные программные модули без использования бубна. И при чем здесь юникс?
Вы выросли как специалист или перешли на другой проект где по требования стоит например uOS. И все, ваши модули туда не подключишь так просто.
Или проект free rtos забросили и встал вопрос миграции.

эти ваши модные словечки... за деревьями не видите леса;)
если вы в курсе про HAL, откуда же у вас проблемы с миграцией на другую (но похожую!) ось? если эти ваши модули грамотно отделены друг от друга, от железа, от оси - они легко переделаются под другую платформу. это называется кроссплатформенность и она уж никаким боком не относится к оси.
тот проект, который я в 2008м мутил на фриртос под арм, он у меня легко собирался под винду в мсвс, ибо там было куда проще отлаживать. там работали и lwip, и efsl, и еще несколько разных штук задач. просто потому, что код был написан так, что он легко переносился. в железе у меня была и работа с таймерами, с уарт, спи, кучи разного другого железа, но проблемы запустить это под виндой - не было (думаю, ясно, что аппаратная часть была полностью заэмулирована, но основной код задач был без изменений).
если у вас проблемы с этим - не перекладывайте ответственность на ось, разберитесь, что именно вы делаете не так.
а юникс здесь был при том, что вы либо сравниваете разного масштаба системы (все мы знаем что запускать 100500 ПРОЦЕССОВ и связывать их пайпами - нормальный такой юникс-вэй), либо... неправильно проектируете свой софт, раз проблема мигрировать.
Mekong писал(а):
ОС должна решать задачи организации работы программных модулей и зависимость от нее должна быть минимальной.
так и что не так с фриртос в этом плане-то? работа с железом и обработчики прерываний - это абсолютно аппаратные вещи, всегда разные на разных платформах. апи у всех осей тоже разное (имена функций, параметры и все такое). вы заранее это знаете и иначе не будет. изолируйтесь от этого и проблем с миграцией не возникнет. а суть шедулеров и примитивов синхронизации - одна.
AVI-crak писал(а):
И что будет делать этот менеджер подзадач во время прямого вызова подпрограммы? А ничего, он будет выполнять подпрограмму. Как ни крути, смысл не меняется.
технический смысл очень даже меняется - не надо запускать и останавливать задачи, чего вам так "не хватало". а вот по смыслу именно что все то же самое.
AVI-crak писал(а):
Кстати, насчёт 15 задач для муз центра, исключительно физика:
я примерно так и думал:) драйвер драйвер драйвер... вы описали набор ФУНКЦИЙ, а не задач. функции - суть подпрограммы. задачи - параллельные ветви исполнения. я не спорю, можно сделать велик с треугольными колесами, он даже поедет. может и дорогу под него можно подобрать идеальную, что поедет нормально, но блин зачем? сделайте круглые колеса и он поедет везде.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 20:52 
Старожил
Аватара пользователя

Зарегистрирован: 04 окт 2011, 10:19
Сообщения: 745
Наверное инициатор топика уже давно всё написал и толку в дискуссиях этих == 0.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 21:12 
Старожил

Зарегистрирован: 24 янв 2011, 23:26
Сообщения: 347
Ink писал(а):
Mekong писал(а):
Навскидку
xQueueSendToBack(),
xQueueSendToBackFromISR()
Делают одно и то же, но задача пользователя разруливать состояние.
я так и думал. но ведь вы понимаете, почему именно так сделано? и вы понимаете, ЧТО нужно, чтобы использовать только одну точку входа и для задачи и для прерывания? (как минимум обернуть каждый обработчик в свои костыли, не так ли? это не лишний гемор для кодера?)


Кого волнует гемор кодера free rtos? А так сейчас гемор для кодера который пользуется ОС. Ну да, пришлось бы функции выяснять откуда она вызвана и применять правильный метод. Добавился бы платформозависимый кусочек.

Ink писал(а):
Mekong писал(а):
Это должно быть проблемой операционки. А тут так старательно разложены грабли.
Так же как и завершение работы задачи по фигурной скобке.
для мира больших машин - согласен. там ресурсов дофига, можно сделать всё ради удобства, хоть 100500 оберток. правда опять же из-за этих оберток тоже кто-то будет ныть, что все тормозное и он не может в данной оси обрабатывать 100500 прерываний в секунду. не бывает ничего идеального.
про завершение задачи по выходу из функции - соглашусь, странно, что этого нет. но это не должно быть большой проблемой. эта проблема указывает скорее всего на косяки в дизайне проекта.


Так откуда возмется такое количество оберток? Кроме того, единый вызов отвечает таки правилам хорошего кода и убирает кучу оберток со стороны программиста. И кучу граблей. Собственно это все косяки. Возможны сначала это все были костыли. Потом остались и выросли в грабли.

Ink писал(а):
Mekong писал(а):
Если вы с самого начала пишете legacy код, то вопросов нет.
А совместимость нужна чтобы в дальнейшем использовать написанные программные модули без использования бубна. И при чем здесь юникс?
Вы выросли как специалист или перешли на другой проект где по требования стоит например uOS. И все, ваши модули туда не подключишь так просто.
Или проект free rtos забросили и встал вопрос миграции.

эти ваши модные словечки... за деревьями не видите леса;)


Да ладно? А зачем я тогда так подробно объяснял раз вы не читаете? И что Вы называете модными словечками?

Ink писал(а):
если вы в курсе про HAL, откуда же у вас проблемы с миграцией на другую (но похожую!) ось? если эти ваши модули грамотно отделены друг от друга, от железа, от оси - они легко переделаются под другую платформу. это называется кроссплатформенность и она уж никаким боком не относится к оси.


Ну тогда зачем вы их смешали? Я специально привел два интерфейса разделения - один от железа, другой от ОС. А проблемы с миграцией возникают как раз таки из-за непродуманности. Работало все в нормальной ОС. Мигрируем например на Free RTOS. Цепляем код. Опа, проблемы. Трудноуловимые. Читаем мануал, оказывается теперь надо отловить вызовы функций ОС и заменить, потому что они зависят от ого откуда вызываются. Ладно, заменили. Проект не работает. Опа, и завершение по скобке нельзя. Таак, сколько там еще граблей...
Это Вы называете легкой миграцией?
Нормальная миграция - вызовы функций ОС осуществляются одинаково, в крайнем случае подмена дефайнами. Действия разрешенные спецификацией языка не должны приводить к проблемам. Как понятно из описания Free Rtos, это все не про нее.

Возможно кто то применяет для совсем простых задач ОСРВ, генерит код кодогенератором, ставит драйвера на светодиод. Но реально в большинстве задач эмбедда ОСРВ избыточна.

Ink писал(а):
если у вас проблемы с этим - не перекладывайте ответственность на ось, разберитесь, что именно вы делаете не так.


У меня нет проблем. Но использовать сырую ОС с некультурно оформленным интерфейсом. Повышать уровень сцепления модулей с ОС. Это глупо.

Ink писал(а):
а юникс здесь был при том, что вы либо сравниваете разного масштаба системы (все мы знаем что запускать 100500 ПРОЦЕССОВ и связывать их пайпами - нормальный такой юникс-вэй), либо... неправильно проектируете свой софт, раз проблема мигрировать.


Вы вообще в своем мире каком то. Я не собираюсь с юникс мигрировать. Я пишу на МК, под задачи МК.

Ink писал(а):
Mekong писал(а):
ОС должна решать задачи организации работы программных модулей и зависимость от нее должна быть минимальной.
так и что не так с фриртос в этом плане-то?


Читать не пробовали? Повторю - разные вызовы одних по сути действий в зависимости от контекста, действия нормальные для языка, запрещены в ОС.

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


Кэп?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 21:40 
Старожил
Аватара пользователя

Зарегистрирован: 23 янв 2012, 00:31
Сообщения: 1756
Откуда: Новокузнецк
Mekong писал(а):
Навскидку
xQueueSendToBack(),
xQueueSendToBackFromISR()

Это кстати логически довольно разные функции. Вторая не может и не принимает параметр таймаута. Если в очередь невозможно сразу поместить элемент - происходит возврат. И это особенность работы прерываний не связаная с конкреной ОС. Во время выполнения нельзя разрешить конфликт, когда в функцию передается ненулевой таймаут из прерывания. Это уже будет неочевидное поведение функции для программиста.

ИМХО правильно, что функции разные для контекста тасков и прерываний, так как в любом случае нужно понимать в каком контексте ты находишься. Более того многие вызовы ОС нельзя вызывать из контекста прерывания, например delay. И обертка над прерыванием уже не поможет, и даже если функция сможет выяснять откуда она вызывается (а она это делает и контролирует assert'ом), это уже будет ошибка на уровне проектирования.

_________________
elisey.su


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 22:03 
Старожил

Зарегистрирован: 24 янв 2011, 23:26
Сообщения: 347
elisey писал(а):
ИМХО правильно, что функции разные для контекста тасков и прерываний, так как в любом случае нужно понимать в каком контексте ты находишься. Более того многие вызовы ОС нельзя вызывать из контекста прерывания, например delay. И обертка над прерыванием уже не поможет, и даже если функция сможет выяснять откуда она вызывается (а она это делает и контролирует assert'ом), это уже будет ошибка на уровне проектирования.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Решил написать RTОS для МК в академических целях.
СообщениеДобавлено: 11 сен 2016, 22:11 
Старожил
Аватара пользователя

Зарегистрирован: 30 мар 2015, 23:56
Сообщения: 346
Ink писал(а):
AVI-crak писал(а):
Кстати, насчёт 15 задач для муз центра, исключительно физика:
я примерно так и думал:) драйвер драйвер драйвер... вы описали набор ФУНКЦИЙ, а не задач. функции - суть подпрограммы. задачи - параллельные ветви исполнения.


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

У вас получается что весь девайс должен ждать ответа от одного мелкого контролёра физики, просто ждать и ничего не делать при этом. Как в винде95 при форматировании флопика :) . При таком подходе использовать ос не обязательно, достаточно шейкера задач на банальном switch.

_________________
Потоковая OS


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 80 ]  На страницу Пред.  1, 2, 3, 4  След.

Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB