RTOS: распространенные заблуждения, Обсудим? |
Здравствуйте, гость ( Вход | Регистрация )
RTOS: распространенные заблуждения, Обсудим? |
11.1.2012, 22:27
Сообщение
#61
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
И исследовать альтернативные подходы. Их суть я и пытался изложить... Вышло не очень. В чем признаю только свою вину. Сравнения требуют рассмотрения большого объема конкретики, и не по "чистой культуре" типовых задач, а по реальным проектам, причем желательно иметь варианты и такой и сякой. Это задача нетривиальная. Не корите себя за зря. Тут надо или на характер, и до хрипоты, но это надо быть сумасшедшим, или должно быть серьезное научное исследование. С бюджетом, кстати. |
|
|
11.1.2012, 23:09
Сообщение
#62
|
|
посіпака Хунти Группа: Мод Сообщений: 20016 Регистрация: 21.11.2009 Из: Vinnitsa Пользователь №: 11 |
А поскольку я свободный художник, то могу себе позволить несколько выпасть из "потока управления". А то отдельный вопрос. Искусство-ремесло. Первое порой не имеет практической ценности, зато изящно. Второе - обязательно да, но бывает облечено в строгую, но порой неэстетичную форму. Работать будет и то и то, но первое - не обойдётся без поддержки автора (или последователей) и без этой поддержки кирдык, второе - будет подчиняться неким формальным законам, время жизни которых м.б. куда подлинней. Там ещё вопрос о сроке жизни продукта, частенько он помирает вместе с автором, ещё чаще раньше, и всё реже бывает, что переживёт. Пока что праздную нечто, написанное по принципам не ремесла (пресловутое впихивание невпихуемого), но это вскоре изменится, заменится, найдут куда впихнуть и ещё место останется. Но момент искусства там будет уже закопан, за ненадобностью. (Что-то сумбуру нагородил перед сном, уточню, если что). |
|
|
12.1.2012, 1:20
Сообщение
#63
|
|
ДИКТАТОР Группа: Мод Сообщений: 23809 Регистрация: 20.11.2009 Из: Житомир Пользователь №: 3 |
Пока что праздную нечто, написанное по принципам не ремесла (пресловутое впихивание невпихуемого) Страшно жить... Во сне может начать сниться, что окружен по жизни копеечными приборами, типа одноразовых стаканчиков. Интересно, какое подешевение камней могло бы заставить не тратить все время на ужимание одного байта, а вместо этого, к примеру, запустить новую линию изделий... Бывает и так, что изделие, к примеру, приносить прибыли $100 на $100 затрат, но доп. затраты на камень в 2 цента могут остановить весь выпуск, и нахер уже тогда те прибыли... Жадность превыше всего. Знал одну фирму, там разработчик просто не мог ничего разрабатывать с тех пор, как не мог найти камней, чтобы надо было ужиматься. Слишком простые задачи, слишком мощные камни. Кроме ужатия программы — он смысла в программировании не видел. Ну, про развитие модификацию уже молчу... Короче, кончился цикл жизни того изделия, и за отсутствием других — уменьшились и доходы у той фирмы... Между прочим, вместо 34063 там были заложены аналоги дороже раз в 10, в общем - суммарная разница цены порядка баков 6, хватило бы на хороший камень...Но смешно не это... Когда тот устаревший уже стал дороже, чем более новые мощные современные — все равно оставили его. Ради гордости, что там так плотно все впихнуто... И невозможности в этом разобраться... Если нужна пламенная речь на эту тему - напишу для Вас, Харбиндер... Вы ж не как тот разработчик, я думаю...Вы ж логичный и деловой... От начальства только отбиться - и вперед, к его же, начальственным, прибылям... |
|
|
12.1.2012, 19:28
Сообщение
#64
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Сравнения требуют рассмотрения большого объема конкретики, и не по "чистой культуре" типовых задач, а по реальным проектам, причем желательно иметь варианты и такой и сякой. Это задача нетривиальная. Не корите себя за зря. Тут надо или на характер, и до хрипоты, но это надо быть сумасшедшим, или должно быть серьезное научное исследование. С бюджетом, кстати. Ну, до серьезного исследования еще далековато. А конкретика имеется, как своя, так и чужая. Беда еще в том, что две основные парадигмы программирования, которые я пытаюсь связать, разошлись между собой уже давно. Сравнивать проекты достаточно сложно. Какие критерии выбирать? На что опираться? Дело усугубляется тем, что изучить до тонкостей и то и другое практически невозможно. Не хватит отпущенного времени. Тем более, уже совершенно ясно, что выбор той или иной парадигмы зависит от особенностей интеллекта и характера индивидуума. Поэтому, я и спорол ерунду, попытавшись, как Вы говорите "до хрипоты". Просто, чтобы было понятно, пример. Кусочек линии не очень большого размера. HMI на PROTOOL от SIEMENS. 2600 различных тэгов. И около 1000 различных сообщений. Все это с картинками, кнопками, свистелками и мигалками. Таких линий 5. Остальные - больше. Есть еще верхний уровень, где все это собрано в кучу, на SCADA Intouch Wonderware 15 летней давности, еще под Windows NT4. Задача простая - оборудование устарело - требуется переделка. При ближайшем рассмотрении выясняется, что практически ничего общего эти тэги между собой не имеют. Конвертирование проекта из PROTOOL в WinCC без глубокой доработки невозможно. Типа того, что конвертировать и сделать заново, практически одно и то же. На всю эту работу планируется 2 человека. Срок - 6 месяцев. И они эту работу сделают. Даже с учетом того, что работы по текущим аварийным ремонтам, заказу запчастей, ППР-ам с них никто не снимает. И при всем этом у этих людей есть еще краткосрочные работы по изменению ряда программ в связи с пожеланиями технологов. |
|
|
12.1.2012, 19:57
Сообщение
#65
|
|
Активный участник Группа: Пользователи Сообщений: 18789 Регистрация: 13.1.2011 Пользователь №: 332 |
На всю эту работу планируется 2 человека. Срок - 6 месяцев. И они эту работу сделают. Даже с учетом того, что работы по текущим аварийным ремонтам, заказу запчастей, ППР-ам с них никто не снимает. И при всем этом у этих людей есть еще краткосрочные работы по изменению ряда программ в связи с пожеланиями технологов. ))) ...а если не сделают?! ...какой спрос с трудников за зарплату ходящих в завод?! ...прально, спрос согласно табеля посещения родной проходной...))) Знакомое-известное заблуждение про : "...сами с усами..."...ага, канешно... |
|
|
12.1.2012, 20:00
Сообщение
#66
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
|
|
|
12.1.2012, 20:04
Сообщение
#67
|
|
Активный участник Группа: Пользователи Сообщений: 18789 Регистрация: 13.1.2011 Пользователь №: 332 |
По той же причине, что и раньше... ...раньше типа прокатывало? ))) ...дык енто не аргумент. ...вы озвучьте санкции к "двое из ларца"...когда по их блажи станет производство стоимостью 60 тыр. за час аренды при 24 часовом графике помноженном на 10 стендофф ?!...и кстати, озвучьте судьбу лищенцев на рук.должностях что допустили сию байду...))) |
|
|
12.1.2012, 20:12
Сообщение
#68
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
...раньше типа прокатывало? ))) ...дык енто не аргумент. ...вы озвучьте санкции к "двое из ларца"...когда по их блажи станет производство стоимостью 60 тыр. за час аренды при 24 часовом графике помноженном на 10 стендофф ?!...и кстати, озвучьте судьбу лищенцев на рук.должностях что допустили сию байду...))) Ничего там не встанет. Все будет хорошо. Никто ничего просто так не меняет. Есть отработанная методика для подобных случаев. И потом, кто Вам сказал, что герои не будут достойно вознаграждены помимо основной пайки? |
|
|
12.1.2012, 20:24
Сообщение
#69
|
|
Активный участник Группа: Пользователи Сообщений: 18789 Регистрация: 13.1.2011 Пользователь №: 332 |
Ничего там не встанет. Все будет хорошо. Никто ничего просто так не меняет. Есть отработанная методика для подобных случаев. И потом, кто Вам сказал, что герои не будут достойно вознаграждены помимо основной пайки? ...вам про белое, вы про кислое..))) ...я про меру ответственности речь веду.... ... к примеру, я как юр.лицо, несу мат.ответственность за реалтаймось... ...а ваши "двое из ларца" ?...чем отвечают??? ...почкой??? ))) ...ну выгонят их...))) ...а убытки хто будет компенсировать??? Про премии лишенцам енто дело последнее... ...хто люлей будет охребать в случае краха??? |
|
|
12.1.2012, 22:36
Сообщение
#70
|
|
посіпака Хунти Группа: Мод Сообщений: 20016 Регистрация: 21.11.2009 Из: Vinnitsa Пользователь №: 11 |
Интересно, какое подешевение камней могло бы заставить не тратить все время на ужимание одного байта, Пятикратное где-то, но оно сработает на шести-семизначных тиражах, а туда пока не дотянуться, 5 десятичных разрядов и то нехило. Запускаем, промежду прочим, новые версии, на авось отчасти. Невсирая на вышесказанное.а вместо этого, к примеру, запустить новую линию изделий... Да ладно, лирика то всё, нашлись и другие варианты, повеселее. |
|
|
13.1.2012, 7:44
Сообщение
#71
|
|
Активный участник Группа: Пользователи Сообщений: 1075 Регистрация: 22.11.2009 Пользователь №: 20 |
вброс "раздели риск без разделения прибыли" не пройдёт
|
|
|
13.1.2012, 8:35
Сообщение
#72
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
Сектер прав, кстати, чем больше контора, тем ужаснее плоды творчества обитающего в нем планктона. Безответственность - это сила
|
|
|
13.1.2012, 13:12
Сообщение
#73
|
|
Активный участник Группа: Пользователи Сообщений: 1075 Регистрация: 22.11.2009 Пользователь №: 20 |
не согласен, для работников есть тк и нечего тут юлить, вот с партнёрами договаривайся как хочешь
|
|
|
13.1.2012, 19:10
Сообщение
#74
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
...Потому как алгоритм внутри просто закручен и просто лёг на прерывания. Вот я и занимаюсь частным образом выяснением причин по которым тот или иной алгоритм ложится или не ложится на систему прерываний МК. У упомянутых ранее итальянских товарищей в PLC на прерываниях существует такое понятие, как "активатор". Это сочетание любых внешних сигналов и внутренних булевых переменных. Активатор может активизироваться фронтом, спадом и уровнями. Когда активатор активен, выполняется кусок кода, приписанный к нему. Прошу прощения за тавтологию. Список активаторов и сопоставленных с ними программных модулей находится в декларативной части программы. Там же находится и способ активизации. При этом временнЫе переменные не имеют отдельной программной сущности в виде отдельных функций для таймаутов или задержек. Впрочем, в отношении PLC такое отношение к переменным времени характерно для всех. Суперлуп в этом PLC не предусмотрен. Входной язык - нечто среднее между Паскалем и С. |
|
|
13.1.2012, 21:08
Сообщение
#75
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
И как это должен выполнять проц? Поллить условие в суперлупе или по-другому? Одно дело, когда активатор простой и аппаратно заложен в проц. Друге дело, когда он (частично) программный. В ОСи есть фичи управления такими активируемыми кусками кода. Хотя что-то похожее я делал на вложенных софтовых прерываниях в нескольких проектах на АРМ7. Там 16 приоритетов мне хватало за глаза и на прерывания и на доп.фишки. Я это делаю следующим образом. В прерывании опрашиваю необходимые переменные. А поскольку имеем дело с автоматами, то можно оперировать с функцией входов того или иного автомата целиком. Вопросы приоритетов при их нехватке решаются программно. Обычно бардак творится в прерывании от системного таймера, где реализуются временнЫе переменные. Особо длинные процедуры выносятся в суперлуп и работают по флагам. К примеру, парсер телеграммы в приведенном примере находится в суперлупе. В оригинале - программно аппаратное решение. Каждый периферийный модуль имеет свой процессор. Все модули связаны сверхскоростной шиной. Связь, специфические функции реализованы на отдельных модулях. Больше ничего не знаю, потому как информации про это в открытой литературе нет. |
|
|
14.1.2012, 9:35
Сообщение
#76
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
В прерывании опрашивать необходимые переменные - значит тормозить обработку автомата не только на часть или полный период таймера, но и тормозить всю систему тем, что постоянно поллить эти переменные в прерывании, в 99% даже когда они не меняются. А в прерывании системного таймера вообще беспредел, как я называю. Вобщем тормоза похлеще ОСи. Все обычные аппараты получается не могут приоритетно прерывать друг друга. Приоритетность получается слишком убогая, как в древнем 580ВН59. То есть работает только на старте автомата. Особо длинные процедуры (хотя dxp уверяет, что функции ) будут вообще писаться через опу. Даже я так стараюсь не проектировать проект, который пишу без оси. У меня хотя бы проц софтово прерывает автоматы в любой момент, когда есть более высокий приоритет другого автомата. Либо аппаратное, либо софтовое прерывание. На эту тему у меня было куча споров с zltigo, который утверждал, что вложенные прерывания есть зло. Но на самом деле это была почти ОСь. И далеко не в том смысле, как говорить, что любой проц есть ОСь. Проц при этом должен обладать аппаратными механизмами прерывания потоков/прерываний. Не могу понять ход Ваших мыслей. В прерываниях никто ничего не поллит. Механизмы совсем другие, относительно того, что Вы привели здесь. Что касается автоматов, то, естественно, они могут прерывать друг друга. Вложенные приоритетные прерывания никто не отменял. Опять же непонятно - откуда взялся вывод о том, что все работает только на старте автомата? Я уже говорил, что автомат распределен по прерываниям. Поэтому все переходы и действия выполняются тут же, если остальные переменные позволяют, иначе следует выход из прерывания. Вам с самого начала говорят, что это все проходили. Но пошли дальше, разбивая все алгоритмы на потоки и не тратя время на тупой поллинг там, где это не нужно. И уж совсем недалеко от этого стоит одна из простых в использовании осей - фриртось. В Вашем случае добавляется возня с очередями и сохранение ненужного контекста задачи. |
|
|
14.1.2012, 12:38
Сообщение
#77
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
В каком моём случае? Без оси или с осью? Я подразумевал вариант с RTOS. Ось это делает сама там, где это захотел программист, разбив алгоритм на треды. Я не совсем понимаю что такое тред применительно к RTOS. Например, в tnKernel речь идет только о задачах-приложениях. Если речь идет о потоках, то я этим пользовался только в Винде. Там все просто - создается новый поток, начиная со стартовой функции. Зная хендл этого потока, им можно управлять. Но там это можно сделать в рамках одного приложения. Без оси вообще никаких очередей. Если текущий приоритет прерывания выше совтово запрошенного, то сначала текущее прерывание полностью завершится, потом запустится запрошенное, если ничего более важного нет. Если же приоритет запрошенного выше, то сразу же улёт в него. Прерывания контекст сохраняют как прерывания, то есть легко и непринуждённо. А уж как разпределить приоритеты - целиком "вина" программера. Здесь у нас логических расхождений нет. Но на "малых" формах кое-что из перечисленного Вами приходится допиливать самостоятельно. Ну, и еще следить на некоторых МК за уровнем вложенности. И еще изменение приоритетов в динамике. Пример на эту тему. Внешнее прерывание по синхронизации с сетью. Происходит раз в 10 мс. Держать это прерывание в списке разрешенных с высоким приоритетом сразу после его обработки в текущий момент времени не имеет смысла. Поэтому оно запрещается на 8 мс (к примеру), что равносильно снижению его приоритета до самого низкого. Но в течение оставшегося времени (временного окна ожидания сигнала) его приоритет будет высоким, поскольку пропускать момент синхронизации нельзя. Забыл ещё главную фичу ОСи. В проге без ОСи основной поток программы только один. Много разных туда можно упихать только в карусели, но с одинаковыми приоритетами. Что-то более сложное приоритетное делать "ручками" мне не приходилось, но почти уверен что это будет опять через жпу. Если же основной поток один и проц аппаратно работает с софтовыми вложенными прерываниями, то и без ОСи всё можно сделать красиво. В системе CoDeSys от 3S software Вы можете создать несколько суперлупов, с разными временами выполнения. Похоже на поток выполнения, насколько я понимаю в этом. Поправьте, если аналогия неверная. По поводу основного потока и вложенных прерываний поверх него - противоречий нет. Что касается Вашего примера. На контроллере прерываний NVIC от ARM или контроллера прерываний от Microchip то, что Вы описали можно реализовать практически аппаратно. |
|
|
14.1.2012, 19:21
Сообщение
#78
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
Происходит раз в 10 мс. Держать это прерывание в списке разрешенных с высоким приоритетом сразу после его обработки в текущий момент времени не имеет смысла. Поэтому оно запрещается на 8 мс (к примеру), что равносильно снижению его приоритета до самого низкого. Но в течение оставшегося времени (временного окна ожидания сигнала) его приоритет будет высоким, поскольку пропускать момент синхронизации нельзя. Вот вот вот. И всё замыкается либо на одном автомате, раскидывающем синхронизацию, скажем, каждые 1мс, либо на кол-ве прерываний у таймеров и их сопутствующей периферии, поскольку городить синхроавтомат с поллингами и счетчиками иногда непозволительная роскошь. Причём, что с осью, что без. И за что борьба? ЗЫ До хрипоты у нас лениво пререкаться, но кой чего из великого множества задач мы все-же обобщим, в неспешном разговоре. Ага, и дровишек подкину: 1-wire, например, неудобен и так и сяк. Чем же ртось может похвастать в работе с ванварью? |
|
|
14.1.2012, 19:51
Сообщение
#79
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Ага, и дровишек подкину: 1-wire, например, неудобен и так и сяк. Чем же ртось может похвастать в работе с ванварью? Вопрос явно не ко мну. А к экспертам по RTOS. А по поводу неудобства 1 Wire у меня есть кое-какие догадки, извлеченные из Вашего nLink-а. И вопросов о временных интервалах у Modbus. Но без Вашего разрешения я их озвучивать не буду. Поскольку могу ошибаться. |
|
|
15.1.2012, 12:50
Сообщение
#80
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
|
|
|
Текстовая версия | Сейчас: 29.3.2024, 4:33 |