Easyelectronics.ru

Электроника для всех
Текущее время: 27 фев 2017, 16:33

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



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

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

Зарегистрирован: 28 янв 2010, 20:18
Сообщения: 348
AVI-crak писал(а):
Ink писал(а):
"в советские времена" не было во фриртосах никаких встроенных дров для периферии. были примеры, например, для уарт, но и те были куцие


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


Нет, я даже не заметил где оно там есть.

Странные, какие-то необоснованно резкие у вас претензии к freertos.

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


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


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

Зарегистрирован: 23 янв 2012, 00:31
Сообщения: 1738
Откуда: Новокузнецк
Mekong писал(а):
Запрет так то можно явно прописать для отдельных функций. А для вызвавшего однозначно вернуть код ошибки.

Тогда это будет ошибка выполнения. Лучше вываливать ошибку еще на этапе компиляции. Ну и получается неоднозначное поведение функции: иногда она работает, иногда не работает. Лишние неочевидные сущности о которых нужно помнить.
Mekong писал(а):
Кроме того, я написал, что это пример навскидку. Там много несуразностей. Повторно анализировать эту ОС как то нет смысла. По крайней мере пока не допилят.

Согласен, да, там есть свои косяки.
Mekong писал(а):
Насчет понимания контекста - в большинстве случаев да, но как понимание скажется на том что один обработчик должен вызываться в разных условиях? Ах, ну да переключатели ставить. Другие ОС справляются.

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

_________________
elisey.su


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

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

Тогда это будет ошибка выполнения. Лучше вываливать ошибку еще на этапе компиляции. Ну и получается неоднозначное поведение функции: иногда она работает, иногда не работает. Лишние неочевидные сущности о которых нужно помнить.


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

Mekong писал(а):
Насчет понимания контекста - в большинстве случаев да, но как понимание скажется на том что один обработчик должен вызываться в разных условиях? Ах, ну да переключатели ставить. Другие ОС справляются.

Ну тут уже компромисс. Получаем либо одно, либо другое. Возможность вызывать функции ОС в разных контекстах дает и плюсы и минусы. И "правильного" решения нет.[/quote]

Правильное решение - каждый делает то что должен по логике разделения обязанностей. ОС отрабатывает свои внутренние процессы не вываливая их на пользователя. Возвращает результат действия. Пользователь занят прикладной задачей. При адекватном интерфейсе все прозрачно и не надо гадать где там грабли заботливо разложены, может и что опасней забыто.
В пример приведу код FatFS от Элм Чана. Описан интерфейс, который нужно обеспечить. Там всего то запись, чтение, получение необходимой информации. Очень корректно разделены интерфейсы.

Я понимаю что все правила хорошего кода чисто рекомендательные. Но многие из них вполне обоснованны.


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

Зарегистрирован: 28 мар 2013, 11:01
Сообщения: 71
А вот расскажите мне за разрешение/запрет прерываний, они же критические секции. Часто вижу, что при запрете прерываний (входе в критическую секцию) сохраняется текущее состояние запрета, а соответственно при разрешении прерываний (выходе из критической секции) данное состояние восстанавливается. Это вместо того, что бы просто запретить/разрешить. У меня возникло два объяснения данному поведению.

Первое. Это нужно для того, чтобы можно было делать вложенные запреты/разрешения прерываний. По мне, использовать вложенные запреты - весьма сомнительное решение. Критические секции должны быть максимально короткими и строго ограниченными, а не размазываться по всему коду. Существует ли какая-нибудь ситуация, при которой без вложенных критических секций не обойтись?

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

Я это все к чему? Реализовывать поддержку вложенных критических секций несколько сложнее, работают они чуть медленнее, использовать их не так удобно (нужно каждый раз объявлять переменную, в которой будет храниться текущее состояние). Стоят ли они того? Я считаю, что нет, но что вы думаете?


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

Зарегистрирован: 28 янв 2010, 20:18
Сообщения: 348
Мне нравится идея отказа от явного запрета прерываний. Вместо этого, отправляем в некую очередь сообщение и вызываем прерывание. А в прерывании уже делается вся обработка. И вот так все вызовы к ОС. Очередь должна быть способна корректно принимать сообщения отправленные асинхронно из разных задач и прерываний, не блокируя их выполнение. Реализация такой очереди не слишком проста. Еще возможно, контекст переключать не очень удобно, находясь уже в прерывании. Но думаю решение есть.

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

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

Оба случая обрабатываются одним механизмом, разница лишь в назначении приоритетов.


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

Зарегистрирован: 22 мар 2010, 22:54
Сообщения: 3837
Mekong писал(а):
Кого волнует гемор кодера free rtos? А так сейчас гемор для кодера который пользуется ОС.

кодер там был - не автор фриртос, а юзер фриртос. это именно ему придется каким-то особым образом оформлять теперь обработчики прерывания. а что если... он забудет и сделает обычный обработчик? он ведь будет работать, только неправильно в некоторых случаях. ах, надо тогда делать по доке, чтобы правильно было? на это коммент ниже.
Mekong писал(а):
Да ладно? А зачем я тогда так подробно объяснял раз вы не читаете? И что Вы называете модными словечками?

все я читаю, а главное - пытаюсь вникнуть, в отличие от. модные словечки - это legacy код, к сути оно сильно не относится, это просто то, что обычно называется говнокодом или говнодизайном. и как следствие, от говно-* вы получите говнорезультат, с вообще любой осью, даже идеальной. к чему тогда была реплика про тип кода в контексте сравнения осей - не понятно.
Mekong писал(а):
Работало все в нормальной ОС. Мигрируем например на Free RTOS. Цепляем код. Опа, проблемы. Трудноуловимые. Читаем мануал, оказывается теперь надо отловить вызовы функций ОС и заменить, потому что они зависят от ого откуда вызываются. Ладно, заменили. Проект не работает. Опа, и завершение по скобке нельзя. Таак, сколько там еще граблей...
Это Вы называете легкой миграцией?

я это называю RTFM. если вы кинулись портировать проект под другую ось, не ознакомившись с ней - это только ваши проблемы, зачем вы их перекладываете на кого-то еще? потом, когда вы изучите новую ось, у вас опять что-то будет не так, потому что вы доку на новый компилятор не прочитали. потом еще и еще удивительные открытия. давно пора понять, что идеала не существует, всегда и везде - если не косяки, то компромиссы. их надо знать ДО того, как начинаешь работу. у фриртос еще 8 лет назад была ОЧЕНЬ ясная дока, с кучей примеров, с обьяснениями. как можно было не знать, что для прерываний свои функции? вы вот возьмите и посчитайте процент ваших "нормальных ос", которые не разделяют контекст юзерспейс и прерываний/ядра. даже такие гиганты как линукс и виндовс, имея огромный запас (вычисл.) ресурсов, не делают то, что вы тут яро защищаете.

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

я в обычном мире. я просто пытаюсь следить за нитью разговора, а вы читаете от точки до точки, без контекста. я объяснил, причем там был юникс, не хотите вникать - не надо.
AVI-crak писал(а):
Эти функции как вы говорите, имеют жёсткую привязку к времени исполнения.

и что это меняет?
AVI-crak писал(а):
У вас получается что весь девайс должен ждать ответа от одного мелкого контролёра физики, просто ждать и ничего не делать при этом.

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

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


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

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


Вот странные люди. Legacy имеет только одно значение - устаревший. На самом деле объяснять другими словами несколько долго, но в контексте имелось в виду, ч код который устаревает в момент создания, поскольку его дальнейшее использование в других проектах может быть затруднено. Каким образом Вы подумали иначе, не знаю. Зато теперь мне понятно на что Вы так обиделись.
На остальное смысла отвечать не вижу, там сплошные наезды.


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

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

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

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

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

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


Ink писал(а):
я конечно не люблю этот прием, но спрошу: когда от вас ждать релиз идеальной ос?

Не скажу за автора топика, но у меня есть своя ос. И пока её не было в планах - приходилось есть общедоступный кактус.

А у вас?

_________________
Потоковая OS


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

Зарегистрирован: 27 мар 2015, 01:22
Сообщения: 899
Однажды одна компания забахала урезанную, но зато сертифицированную freertos в rom, в смысле не просто в бинарник, а намертво в мк, cortex-m3 кстати.
Ни компании, ни мк уже нет, я думал, что и мануал затерялся, но оказалось не затерялся - http://www.ti.com/lit/ug/spmu040a/spmu040a.pdf
Как вам такая идея - "rtos" в отдельном готовом к употреблению бинарнике?


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

Зарегистрирован: 04 окт 2011, 10:19
Сообщения: 737
Не плохое описание.
В принципе если freertos запихать в system flash - ничего плохого не будет. Не хочешь - не пользуйся. Но если использовать - часть флэша освободится. Процесоор точно известен - так с настройками проблем нет.


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

Зарегистрирован: 30 мар 2015, 23:56
Сообщения: 346
vt340 писал(а):
Как вам такая идея - "rtos" в отдельном готовом к употреблению бинарнике?

Вот о чём я и говорил, там где большие деньги - всегда найдётся обиженный. Но сама идея хороша.
Если в том-же направлении , то вот http://forum.ixbt.com/topic.cgi?id=48:11835
Человек в домашних условиях создаёт новый проц, есно на фпга.
Отличие от стандарта - ос на уровне ядра, общение тасков на уровне спец команд на асме - напрямую, ну и переключатель полностью аппаратный.

_________________
Потоковая OS


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

Зарегистрирован: 27 янв 2012, 17:24
Сообщения: 525
В академических целях я бы посоветовал обратить внимание на TinyOS.
А сам бы (если бы, конечно :) ) попытался реализовать транслятор, который бы перекладывал функционал шедулера и сервисов RTOS на голый NVIC и DMA (в STM32)


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

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 607
AVI-crak писал(а):
Некую очередь... Уже это подразумевает отложенное исполнение, а значит медленную реакцию системы.

Это совершенно не обязательно. Вполне возможно, что даже наоборот, поскольку позволяет минимизировать время с запрещенными прерываниями. И, что весьма полезно, минимизировать риск потери прерывания.


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

Зарегистрирован: 22 мар 2010, 22:54
Сообщения: 3837
Mekong писал(а):
Legacy имеет только одно значение - устаревший. На самом деле объяснять другими словами несколько долго
ну да, ты его только пишешь, а ему уже 20 лет. это не так давно "устоявшийся" термин того, что простые люди называли любительским (не промышленным) кодом, write-only кодом или говнокодом. слово "говнокод" даже лучше характеризует это, чем модное слово "устаревший".
Mekong писал(а):
Каким образом Вы подумали иначе, не знаю.
я не думал иначе.
Mekong писал(а):
Зато теперь мне понятно на что Вы так обиделись.
На остальное смысла отвечать не вижу, там сплошные наезды.
я обиделся? фига себе. раскройте тайну - на что?
и да, если отвечать нечего - лучше не отвечать, только не надо заливать про наезды, их там не было.
AVI-crak писал(а):
у меня есть своя ос ... А у вас?
вопрос поставлен несовсем правильно. у меня нет своей ос в том плане, что я ее использую в своих проектах. а вот опыт написания шедулера и простеньких средств синхронизации - есть (правда было это в начале 2000). ассемблер, отсутствие запрета прерываний, страничная память под задачи и прочие низкоуровневые нюансы. когда подобного попишешь, почему-то пропадают вопросы, почему в прерываниях, например, свой аналог функций.
а к чему вопрос? вы думаете, что написать свою микро-ось - это какой-то рокет-сайнс? это далеко не так.


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

Зарегистрирован: 02 июл 2010, 23:41
Сообщения: 324
Menzoda писал(а):
Я вот не хочу совсем уж отрываться от реальности и делать нечто абстрактное.

AVI-crak писал(а):
Но выяснилось что не только мой код, но и код почти всех начинающих писателей собственных ос - никому нафиг не нужен. Война идёт за то что можно получить деньги, честным или чаще всего обманным путём.

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


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

Зарегистрирован: 24 июл 2012, 13:54
Сообщения: 632
А я давно предлагаю обсудить, что все-таки нужно микроконтроллерной ОС.

FreeRtos мягко говоря не дотягивает по уровню.

nuttx, берет курс на упрощенное копирование линукса, что хорошо, но мне как-то печально с этого.
embox, ИМХО, как-то слишком любит статические структуры. Плюс, там как-то понатаскано все из разных мест.

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

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

Очень важен вопрос стека протоколов. Стек TCP/IP неподъёмен и сложен в поддержке, но определенно требуется какая-то унификация каналов связи.

Необходимость файловой системы или нэймспейсов ака QNX

Это все крайне интересные вопросы, товарищи.


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

Зарегистрирован: 18 июл 2016, 21:17
Сообщения: 150
Кооперативная многозадачность это когда процесс сам передает управление? Мне кажется, что это очень неудобно. В крайнем случае можно подумать об одинаковых приоритетах при вытесняющей многозадачности.


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

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 833
Откуда: Германия
Mirmik писал(а):
...
embox, ИМХО, как-то слишком любит статические структуры.
... Уметь, кто бы что ни говорил, работать с динамической памятью.

Бывают такие требования (в критических системах, типа тех, что поддерживают жизнедеятельность организма человека), где нельзя ничего динамического. Самый максимум - это на старте все динамически выделить, и потом работать в статическом режиме.
Так что embos как раз этому требованию удовлетворяет.

_________________
Мои поделки
http://www.fun-electronic.net/


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

Зарегистрирован: 24 июл 2012, 13:54
Сообщения: 632
А что, динамическое считается небезопасным?
Звучит немного нелепо.


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

Зарегистрирован: 24 июл 2012, 13:54
Сообщения: 632
bw429
На самом деле очень сильно зависит от задачи. Для управления движениям робота кооперативная многозадачность вполне естественна.

Я пытаюсь сочинить диспетчер, который умеет кооперацию и форс одновременно. Впринципе работать может.


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

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 833
Откуда: Германия
Mirmik писал(а):
А что, динамическое считается небезопасным?
Звучит немного нелепо.

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

Потом будете рассказывать следователям, что динамическое выделение памяти это не опасно ;-)

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

_________________
Мои поделки
http://www.fun-electronic.net/


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

Зарегистрирован: 27 янв 2010, 18:55
Сообщения: 163
Откуда: Томск
Mirmik писал(а):
Я пытаюсь сочинить диспетчер, который умеет кооперацию и форс одновременно. Впринципе работать может.


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


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

Зарегистрирован: 24 июл 2012, 13:54
Сообщения: 632
MasterAlexei
Это называется "плохое использование хорошего инструмента." Но речь не о том.
Добавляем в список.
-- Структуры ОС должны позволять как динамическое, так и статическое выделение. На самом деле, это не сложно, благо концепция связных списков в стиле linux сильно помогает в статическом формировании слабосвязанных структур.

dmk793
Любопытно. ИМХО, в контексте микроконтроллеров диспетчеризацию следует делать максимально явной и многовариантной.
У меня, например, есть опция процесса, которая говорит диспетчеру, можно ли его вытеснять. Есть процессы, которые не могут быть вытеснены просто потому, что не имеют собственного стека (Автоматные, прям как demiurg1978 любит). Вообще допустимо очень много разных типов процессов. Это, впрочем, мешает строить продвинутые алгоритмы планирования и требует корректного построения каждого процесса. Я не уверен, что это хорошо.


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

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 833
Откуда: Германия
Mirmik писал(а):
MasterAlexei
Это называется "плохое использование хорошего инструмента."


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

И каким бы не было, хорошим или плохим, использование инструмента, им (FDA и Со.) как бы похер.

Ну а, как разработчик, я и Вы все же знаете, что при динамическом выделении памяти нет, не было и не может быть гарантий того, что не наступит такого момента, когда память просто закончится и устройство уйдет в ресет, потому как всегда есть еще внешнее влияние на железку в виде пользователя и прочего большого количества факторов. Кого посадим?

Риторический вопрос, конечно, и на этом можно завершить дискуссию в этом направлении.

_________________
Мои поделки
http://www.fun-electronic.net/


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

Зарегистрирован: 02 июл 2010, 23:41
Сообщения: 324
MasterAlexei писал(а):
Ну представьте ситуацию - устройство поддержки дыхания пациента, когда он сам не дышит...

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


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

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


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

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


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

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

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