RTOS: распространенные заблуждения, Обсудим? |
Здравствуйте, гость ( Вход | Регистрация )
RTOS: распространенные заблуждения, Обсудим? |
9.1.2012, 4:41
Сообщение
#41
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
Тут интересно со РТОС ведь другие проблемы возникают - реентерабельность сторонних подпрограмм, TLS и размеры стека задачи.
|
|
|
9.1.2012, 10:18
Сообщение
#42
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Так нельзя. Иначе тема "ымбеддер и AVR" будет закрыта Как собственно ещё дозревающая тема "ымбеддер и ОСь". Поражаюсь способности Прохожего ругать то, в чём не разбираешься (или с чем не работал) Ладно, насчет NVIC я слегка погорячился. Контроллер, как контроллер, только очень много лишнего, впрочем, как и в самой архитектуре ARM. При ознакомлении с этими потрохами возникает масса вопросов о назначении тех или иных технических изысков. Основная претензия к ARM - отсутствие бесплатных полноценных средств разработки. Что же касается темы "Ымбедер и AVR", то было бы неплохо услышать претензии по-существу. Кто и когда там был незаслуженно упомянут. А то, что Ымбедеры постсоветского пространства почему-то предпочитают именно AVR - действительно загадка. Очень любопытно. Получается реальная РТОСь, написанная для этого МК - это ОСь в квадрате Ну да, вот им она и стучит... |
|
|
9.1.2012, 10:55
Сообщение
#43
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
А то, что Ымбедеры постсоветского пространства почему-то предпочитают именно AVR - действительно загадка. А что там загадочного? После пиков появились АВР с (о чудо!) гораздо более прямой архитектурой, народ ломанулся. Это подстегнуло к развитию средств разработки и отладки. Теперь достаточно иметь бесплатный ГЦЦ и пижженый протеус, чтобы, не отрывая жжж от стула, чувствовать себя гением. По себе знаю. |
|
|
9.1.2012, 11:07
Сообщение
#44
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
А что там загадочного? После пиков появились АВР с (о чудо!) гораздо более прямой архитектурой, народ ломанулся. Это подстегнуло к развитию средств разработки и отладки. Теперь достаточно иметь бесплатный ГЦЦ и пижженый протеус, чтобы, не отрывая жжж от стула, чувствовать себя гением. По себе знаю. Но все-равно, не до конца понятно. "Протез" поддерживает не только AVR. Можно чувствовать себя гением и с ARM от различных контор и с тем же PIC24/dsPIC. Но почему-то именно AVR здесь в лидерах. Хотя архитектура у ARM еще более кошерная (не гарвардская) и возраст у него приблизительно совпадает с AVR. |
|
|
Гость_MrYuran_* |
9.1.2012, 11:52
Сообщение
#45
|
Гости |
Основная претензия к ARM - отсутствие бесплатных полноценных средств разработки.. О5 25 между прочим, ARM в GCC отродясь поддерживается. А ECLIPSE - вполне полноценная среда, не хуже мелкосиудии и уж точно не хуже бледно-серых IDE от IAR или кейла. Отладка работает замечательно, я на STM32 гонял. Симулятор- для симулянтов Честно говоря, я и отладку-то не люблю, привык как-то через терминал контрольные точки выводить. |
|
|
9.1.2012, 11:59
Сообщение
#46
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
У меня есть уважительная причина. Даже несколько. 1. Логика проста и тривиальна. Отнюдь не так проста как кажется - особенно по сравнению с альтернативным вариантом, где три строчки линейного кода и больше ничго - ни таймеров, ни счётчиков, ни автоматов (во, сколько лишних сущностей на пустом месте). И это в таком простейшем примере. 2. Метод универсален. Попробуйте в своей методике моргнуть светодиодом раз, эдак, 200 после включения реле. Любой метод может быть универсальным, а вот код непереносим, т.к. завязан на прерывания. А вот в моём примере код полностью переносим. Мигнуть раз 200? Вы шутите? Извольте: Код ... relay_on(true); for(int i = 0; i < 200; ++i) { led_on(true); sleep(500); led_on(false); sleep(500); } Код абсолютно прозрачен и тривиален. А ваш пример - это write-only code, извините. Т.е. код, который более-менее понятен автору (в течение пары месяцев с момента написания). 3. Скорость работы выше, чем у Вас. Что вы понимаете под скоростью? Поясните?. Скорость реакции на событие - например, timer expiration, в моём варианте будет лучше - процесс сразу получит управление по выходу из таймерного прерывания, это время предсказуемое. А как у вас это осуществляется, я так и не понял, извините. Накладные расходы в случае вытесняющей RTOS будут больше, главным образом по расходу ОЗУ на стеки процессов. Но и только. На современных копеечных МК это вообще не проблема. 4. Код короче, чем в Вашем случае поскольку я Вам предъявил заодно и реализацию, чего в Вашем случае не было. Ваш код выглядит длиннее. И в целом будет длиннее, если в программе будет не один такой фрагмент. У меня же используются общие для всех частей программы механизмы RTOS. Футпринт RTOS, которую я использую составляет для MSP430 1.2K (из примера с тремя пользовательскими процессами) при 60К доступной флеши. При этом имеет полноценное приоритетное вытеснение и все плюшки в виде межпроцессного взаимодействия. Я думал, что у меня все очевидно. Вы описали логику работы, а я спрашивал не про это, а про то, как осуществляется передача управления. Т.е. когда таймер досчитал до нужного значения - тут нужно немедленно передать управление в основную программу - именно в тот автомат, который ждёт события. Как это осуществляется у вас? Поллингом? Или карусель в суперлупе? Естественно, все переменные - глобальные. Ещё один недостаток - замусоривание глобального пространства имён. Такой простой код уже добавляет прилично мусора, что же там будет твориться в действительно большой программе? а драйвера - это тоже совокупность процессов, то моя основная забота - это HAL. Извините, вот это (выделенное) я никак принять не могу. Драйвер - это программный код, предназначенный для абстрагирования управления аппаратурой от конкретного устройства аппаратуры. К процессам, потокам выполнения программы это не имеет ни малейшего отношения. Драйвера прекрасно живут в окружении, где может быть вообще только один поток выполнения. С чего бы это? Расчет полиномов - это сплошная программа, оформленная в виде функции для повторного использования. Ее можно использовать и из автомата процесса. Мне, честно говоря, не понятно - откуда у Вас такое заблуждение, про которое Вы говорите в цитируемом выше тексте? С какой это радости мне нужно терпеть все мучения, описанные Вами? Уверяю Вас. В реальности все гораздо проще. Гуд. Изобразите ваш вариант насчёт этого полинома: Код float P3x(const float Coeffs[3], const float x) { float x2 = x*x; return Coeffs[0]*x2*x + Coeffs[1]*x2 + Coeffs[2]*x + Coeffs[3]; } Условия: в программе происходит обмен через UART на скорости 9600 бод (примерно 1 мс на символ), данный полином вычисляется за время порядка 5 мс (MSP430 @5MHz). У меня в программе он именно так и реализован, я голову не грею себе, как его декомпозировать на части, чтобы удовлетворить времянки (в том числе и при переносе на другой МК - в частности на AVR это тоже успешно работает в том же виде, хотя там время выполнения побольше - что-то около 8 мс). На самом деле код процесса состоит не только из этого полинома, там их пачка вычисляется - численное нахождение значения итеративным путём. Полиномы тоже разные. Был даже вариант с нахождением значения через полином двух переменных - там МК 22 мс пыхтел. Но для программы это всё без прозрачно - пишешь код свободно, как хочешь, совершенно не напрягаясь насчёт времянок - главное, чтобы вычисления были завершены до определённого момента. А Вы уверены, что им всем нужны разные приоритеты? Абсолютно. Это относительно большая программа, которая выполняет кучу задач от обслуживания обмена по сериальным протоколам, взаимодействие с ПЛИС, корректировка параметров видеотракта, управление исполнительными устройствами, сбор и обработка данных от датчиков (температура приёмника, углы наклона, клавиатура), GUI и ещё много всяких более мелких задач. Не вижу причин ограничивать себя в удобстве проектирования и создании читабельного и сопровождаемого кода. Микрочип на сегодняшний день - самая лояльная к потребителю контора с достаточно неплохой поддержкой. Только это не характеризует уровень его достижений в МКстроении. Не вижу причин отдавать ему предпочтение на фоне TI, ADI и других фирм. Согласен со всеми тезисами. Добавлю еще, что у него очень приятная система команд, очень похожая на PDP11, но отсутствие бесплатной полновесной среды разработки перечеркивает для меня всю его привлекательность. Равно как и его улучшенному варианту. А что вы понимаете под "полновесной" средой разработки? А если переписать Кернел? Ну, это-то дело плёвое, не то, что осовить RTOS, общий объём сорцов которой составляет меньше сотни килобайт. Гы, винда - это первая ОС, где было введено понятие события. И осуществлено переползание с обыкновенного программирования к событийному. А так, там все то же самое, что и в Ваших любимых RTOS. Обыкновенная вытесняющая ОС, с присущими ей достоинствами и недостатками. Пардон. Вот у меня в текущем проекте время передачи управления (т.е. при возникновении события, через сколько времени ожидающий этого события код получит управление) составляет 1.5 мкс. Это на Blackfin @200MHz. И это время детерминировано. Детерминированность именно обеспечивается используемыми простыми механизмами. Какие времена даёт венда? Как они детерминированы? Да никак. Именно этим RTOS и отличается от просто OS. Я достаточно хорошо ознакомился с идеологией RTOS и понял, что мне на текущем этапе это не нужно. Мои поздравления. Еще раз повторю. Любой современный МК - сам себе RTOS. Очень сильное заявление. Наверное, чтобы разобраться в этом вопросе, нужно дать определение терминам - что такое "МК" и что такое "ОС". Тогда сразу станет ясно, на самом ли деле MK == OS. А сколько стоит нормальный софт разработчика с симулятором и приличной IDE? GNU не предлагать. Это почему это? ГНУтые компиляторы очень приличны и по кодогенерации, и по поддерживаемым фичам языка. Отладчики тоже есть. Даже среда есть могучая - эклипс, которую не брезгуют брать за основу ведущие производители софта - IAR, Altera, Xilinx, NXP и многие другие. Уж не убожище ли MPLab вы хотите противопоставить? Да, действительно есть. Но с NVIC от ARM я знаком давно. Просто не ассоциировал его и CORTEX-ы. Но это бред, а не контроллер прерываний. Это источник неисчислимых багов и загадок для программиста. Как, впрочем, и весь ARM. Как был студенческой поделкой, так ею и остается по сей день. Кстати, у NVIC тоже всего 8 уровней приоритетов. Вот беда... Cortex-M - очень продуманная серия процессоров. При изучении документации постоянно ловлю себя на мысли, что люди, которые его спроектировали, прошли определённый путь, тут чувствуется школа. Вы как-то погорячились насчёт него, не разобрались. К сведению, сам по себе NVIC поддерживает до 250 уровней прерываний. Просто не во всех МК это количество реализовано, т.к. там просто не надо. |
|
|
9.1.2012, 16:34
Сообщение
#47
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Во-первых, приношу свои извинения за те места, где был излишне эмоционален.
Перечитал нашу переписку и понял, что выгляжу не очень хорошо. Еще раз извините... Отнюдь не так проста как кажется - особенно по сравнению с альтернативным вариантом, где три строчки линейного кода и больше ничео - ни таймеров, ни счётчиков, ни автоматов (во, сколько лишних сущностей на пустом месте). И это в таком простейшем примере. Это базовые сущности. Они будут всегда. Вне зависимости от примера. Причем, с увеличением технической сложности примера, структура и сущности остаются. Что вы понимаете под скоростью? Поясните?. Скорость реакции на событие - например, timer expiration, в моём варианте будет лучше - процесс сразу получит управление по выходу из таймерного прерывания, это время предсказуемое. А как у вас это осуществляется, я так и не понял, извините. Накладные расходы в случае вытесняющей RTOS будут больше, главным образом по расходу ОЗУ на стеки процессов. Но и только. На современных копеечных МК это вообще не проблема. В моем случае время реакции на простое событие - конец отсчета таймера - это время, необходимое МК для входа в обработчик прерывания (прерывание пипелайна и аппаратное сохранение контекста). В случае сложного события - когда этот таймер увязан еще на что-то - к этому времени добавляются простые логические операции. Все считается с точностью до такта. Ваш код выглядит длиннее. И в целом будет длиннее, если в программе будет не один такой фрагмент. У меня же используются общие для всех частей программы механизмы RTOS. Футпринт RTOS, которую я использую составляет для MSP430 1.2K (из примера с тремя пользовательскими процессами) при 60К доступной флеши. При этом имеет полноценное приоритетное вытеснение и все плюшки в виде межпроцессного взаимодействия. Еще раз извините, но Вы пока еще не поняли сути подхода, о котором я рассказываю. Попытаюсь объяснить. Заодно, отвечу и на эти вопросы: Вы описали логику работы, а я спрашивал не про это, а про то, как осуществляется передача управления. Т.е. когда таймер досчитал до нужного значения - тут нужно немедленно передать управление в основную программу - именно в тот автомат, который ждёт события. Как это осуществляется у вас? Поллингом? Или карусель в суперлупе? Извините, если буду банален и будет много букофф. Любую программу, выполняемую на МК, в простейшем виде можно представить как последовательность неких операторов. В примитивной модели - это суперлуп, когда анализируя входные переменные мы выполняем или пропускаем те или иные последовательности этих самых операторов. Попутно застревая в продолжительных участках долгоиграющего кода, в тот момент, когда надо бы выполнить что-то более существенное и важное. Желая разорвать этот порочный круг мы можем сделать вставки в долгоиграющий код с проверками, типа, а не пришло ли время проверить такие-то и такие-то условия? И тут возникает вопрос - как это сделать, тем более асинхронно? И желательно быстро, чтобы реакция на события была как можно более короткой. Все решения, которые приходят в голову, кроме RTOS, которая инкапсулирует так или иначе это безобразие, выглядят кургузо и коряво. Но на самом деле все очень просто. Если отойти в сторону от парадигмы непременной линейности кода, за которую Вы ратуете. Каждый процесс представляется в виде автомата, иногда вырожденного, как в моем примере. И переход этого автомата из состояния в состояние осуществляется в прерываниях с действиями на переходах. Программа в этом случае может вообще не иметь суперлупа, а МК может переходить в спячку до следующего события. Т. е. каждое событие, приписанное к данному процессу, вызывает условно мгновенную реакцию (за вычетом аппаратных издержек самого МК) этого процесса на это событие. Вы можете законно возразить - действия на переходах могут быть очень долгими и обслуживание прерывания может затянуться. В этом случае действие на переходе осуществляется в суперлупе. Т. е. в самом низкоприоритетном месте программы. Которое всегда может быть прервано другими процессами, чьи события наступили в текущий момент времени. Таким образом, процесс сам меняет приоритеты в зависимости от того, в каком состоянии он находится. Вот более сложный пример, чтобы было понятно, о чем идет речь. Процесс_обслуживания_USART.pdf ( 150,44 килобайт ) Кол-во скачиваний: 39 Если пользоваться всеми возможностями современных контроллеров прерываний, то можно изменять приоритеты динамически. Но лично я этого пока не делал. Но непременно буду - есть для чего. При таком подходе скорость обслуживания событий максимальная и определяется в случае совпадения событий с прерыванием только аппаратными издержками МК. Нет необходимости изучать дополнительную документацию по RTOS. Документирование ведется на этапе проектирования. А сами недостатки имеются и это: Ещё один недостаток - замусоривание глобального пространства имён. Такой простой код уже добавляет прилично мусора, что же там будет твориться в действительно большой программе? не самый главный. Я вообще не заморачиваюсь насчет глобальных переменных. Памяти в современных МК более, чем достаточно. И документирование при таком подходе - вещь отработанная. Извините, вот это (выделенное) я никак принять не могу. Драйвер - это программный код, предназначенный для абстрагирования управления аппаратурой от конкретного устройства аппаратуры. К процессам, потокам выполнения программы это не имеет ни малейшего отношения. Драйвера прекрасно живут в окружении, где может быть вообще только один поток выполнения. Правильно. Но при работе даже одного потока пользователя, драйвера обязаны работать во всей свое совокупности. Т. е. реально имеем выполнение нескольких задач одновременно. Просто драйвера лежат ниже уровня HAL и Вы эти задачи не видите. А когда между человеком и железом МК никого нет, то достигать нужного уровня приходится самостоятельно. Поверьте, мне тоже неудобно смешивать низ и верх. Поэтому я и стремлюсь к их разделению. Гуд. Изобразите ваш вариант насчёт этого полинома: Код float P3x(const float Coeffs[3], const float x) { float x2 = x*x; return Coeffs[0]*x2*x + Coeffs[1]*x2 + Coeffs[2]*x + Coeffs[3]; } Условия: в программе происходит обмен через UART на скорости 9600 бод (примерно 1 мс на символ), данный полином вычисляется за время порядка 5 мс (MSP430 @5MHz). Да нет проблем. Кусок из пресловутого терморегулятора: Код float t; char i; ... switch (ThermoType) { case 'R': if(e>=-0.226&&e<1.923) { t=R0[10]*e; for(i=9;i>0;i--) t=(t+R0[i])*e; t=t+R0[0]; } else if(e>=1.923&&e<11.361) { t=R1[9]*e; for(i=8;i>0;i--) t=(t+R1[i])*e; t=t+R1[0]; } else if(e>=11.361&&e<19.739) { t=R2[5]*e; for(i=4;i>0;i--) t=(t+R2[i])*e; t=t+R2[0]; } else if(e>=19.739&&e<=21.103) { t=R3[4]*e; for(i=3;i>0;i--) t=(t+R3[i])*e; t=t+R3[0]; } break; ............ Ну и так далее для остальных типов термопар. Здесь е - нормализованное значение термо ЭДС, ThermoType - номер типа термопары. t - температура. R0, R1, R2, R3 - массивы коэффициентов полиномов для каждого из диапазонов термо ЭДС для термопары типа R. У меня в программе он именно так и реализован, я голову не грею себе... Дык, и я тоже. Абсолютно. Это относительно большая программа, которая выполняет кучу задач от обслуживания обмена по сериальным протоколам, взаимодействие с ПЛИС, корректировка параметров видеотракта, управление исполнительными устройствами, сбор и обработка данных от датчиков (температура приёмника, углы наклона, клавиатура), GUI и ещё много всяких более мелких задач. Не вижу причин ограничивать себя в удобстве проектирования и создании читабельного и сопровождаемого кода. Без всяких шуток. А Вы на людях эксперименты проводили? Давали посмотреть свой код кому-нибудь еще? Ведь читаемость и сопровождаемость - понятия относительные и очень субъективные. Поверьте человеку, который вынужден сопровождать кучу разных девайсов, в том числе и программных. Разница есть и существенная. Только это не характеризует уровень его достижений в МКстроении. Не вижу причин отдавать ему предпочтение на фоне TI, ADI и других фирм. ADI - это кто? Гугель на вскидку дает это. Я с Вами соглашусь, когда среды разработки будут бесплатными. А что вы понимаете под "полновесной" средой разработки? 1. Наличие адекватного симулятора. 2. Наличие удобной IDE. Никаких make файлов (только по запросу, если сильно кому надо). 3. Наличие удобных дебуггеров. Ну, это-то дело плёвое, не то, что осовить RTOS, общий объём сорцов которой составляет меньше сотни килобайт. Вы меня не поняли. Среда CoDeSys в варианте TwinCat, с которой я имею дело, как простой юзер, перегружает Кернел, как в Винде, так и в Линуксе. При этом софт-PLC на основе любого либо x-86, либо ARM работает в реал тайме. Его жесткость можете оценить самостоятельно, если хотите - дам ссылку на первоисточник. В моем варианте это PC от Beckhoff и их же удаленка на ProfiBus-е. Для линии, упаковывающей по 300 пачек сигарет в минуту вполне хватает. Пардон. Вот у меня в текущем проекте время передачи управления (т.е. при возникновении события, через сколько времени ожидающий этого события код получит управление) составляет 1.5 мкс. Это на Blackfin @200MHz. И это время детерминировано. Детерминированность именно обеспечивается используемыми простыми механизмами. Какие времена даёт венда? Как они детерминированы? Да никак. Именно этим RTOS и отличается от просто OS. Ого! Целых 300 команд. Расточительно, однако. Очень сильное заявление. Наверное, чтобы разобраться в этом вопросе, нужно дать определение терминам - что такое "МК" и что такое "ОС". Тогда сразу станет ясно, на самом ли деле MK == OS. Скажу как художник художнику. Я так вижу! Уж не убожище ли MPLab вы хотите противопоставить? Не такое оно и убожище. Всегда можно сделать лучше - это понятно. С Эклипсом дело имел очень мало в варианте от ARM-KEIL. Честно скажу, не увидел в нем ничего особо выдающегося. Может быть я его готовить не умею? Cortex-M - очень продуманная серия процессоров. При изучении документации постоянно ловлю себя на мысли, что люди, которые его спроектировали, прошли определённый путь, тут чувствуется школа. Вы как-то погорячились насчёт него, не разобрались. К сведению, сам по себе NVIC поддерживает до 250 уровней прерываний. Просто не во всех МК это количество реализовано, т.к. там просто не надо. Я очень давно приглядываюсь к ARM. Может быть там все так и есть, как Вы говорите. Но у меня есть рад вопросов к архитектуре ядра и к NVIC, на которые вразумительных ответов в документации я не нашел. Качество самой документации от ARM - очень низкое. По крайней мере на Thumb2. В отличие от... Но это выходит за рамки применения RTOS. Если хотите, можно сделать отдельную тему - "Изучаем/Применяем ARM Cortex М". |
|
|
9.1.2012, 17:21
Сообщение
#48
|
|
Активный участник Группа: Пользователи Сообщений: 1075 Регистрация: 22.11.2009 Пользователь №: 20 |
|
|
|
10.1.2012, 8:18
Сообщение
#49
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
В моем случае время реакции на простое событие - конец отсчета таймера - это время, необходимое МК для входа в обработчик прерывания (прерывание пипелайна и аппаратное сохранение контекста). В случае сложного события - когда этот таймер увязан еще на что-то - к этому времени добавляются простые логические операции. Все считается с точностью до такта. Так при выходе из прерывания таймера, когда счётчик досчитал до нужного значения и состояние автомата обновилось, поток выполнения куда попадает? Еще раз извините, но Вы пока еще не поняли сути подхода, о котором я рассказываю. Попытаюсь объяснить. Заодно, отвечу и на эти вопросы: Извините, если буду банален и будет много букофф. Любую программу, выполняемую на МК, в простейшем виде можно представить как последовательность неких операторов. Спасибо за экскурс, с удовольствием бы послушал лет 15 назад, а сегодня уже не актуально. Хочется на конкретные вопросы получить конкретные ответы, а не пространные рассуждения, уж простите. Но на самом деле все очень просто. Если отойти в сторону от парадигмы непременной линейности кода, за которую Вы ратуете. А зачем от неё отходить? Это и была цель - сделать написание кода простым и прозрачным, без видимых ветвлений и явных "завязок" на конкретные прерывания. Каждый процесс представляется в виде автомата, иногда вырожденного, как в моем примере. И переход этого автомата из состояния в состояние осуществляется в прерываниях с действиями на переходах. Программа в этом случае может вообще не иметь суперлупа, а МК может переходить в спячку до следующего события. Я всё-таки не вижу ответа на свой простой вопрос: как осуществляется передача управления при возникновении события. Т.е. вот работает какой-то код - например, длительные вычисления в низком приоритете, а ваш автомат ждёт события от таймера. Происходит прерывание, в котором состояние автомата обновляется - теперь нужно передать управление этому автомату, чтобы он отработал новое состояние, но при выходе из прерывания поток выполнения попадёт в прерванный код (так устроена аппаратура процессора), а не в автомат. Так вот, вопрос в том, как при возникновении события передать управление сразу автомату? В RTOS'ах это реализуется путём специальных механизмов, которые переключают контексты процессов, и из прерывания поток выполнения сразу попадает в нужное место, а не в прерванный код. Вот и интересно, как вы добиваетесь такого же поведения (по вашим словам) без RTOS'овых механизмов. Да нет проблем. Кусок из пресловутого терморегулятора: Код float t; char i; ... switch (ThermoType) { <...> } break; ............ Ну и так далее для остальных типов термопар. Здесь е - нормализованное значение термо ЭДС, ThermoType - номер типа термопары. t - температура. R0, R1, R2, R3 - массивы коэффициентов полиномов для каждого из диапазонов термо ЭДС для термопары типа R. Что-то у нас с вами как-то не ладится взаимопонимание. Я вам про Фому, вы мне про Ерёму. Я вас просил показать реализацию вычисления полинома - так, чтобы оно не мешало работе с периферией, которая не будет ждать. Вы мне какой-то левый код обработки термодачтиков. Покажите реализацию предъявленного полинома, чтобы его вычисление не мешало приёму и отправке пакетов байтов через UART на скорости 9600 бод. Без всяких шуток. А Вы на людях эксперименты проводили? Давали посмотреть свой код кому-нибудь еще? Ведь читаемость и сопровождаемость - понятия относительные и очень субъективные. Конечно. У нас целое семейство проектов, где большая часть кода просто заимствована. Работают разные люди. Нареканий нет. То, что RTOS позволяет формализовать подход в организации потока выполнения программы, оказывается очень кстати при работе в команде. ADI - это кто? Гугель на вскидку дает это. Нет, это Analog Devices Inc. Я с Вами соглашусь, когда среды разработки будут бесплатными. Их есть. 1. Наличие адекватного симулятора. А это-то зачем, когда щас в любом проце эмулятор имеется? 2. Наличие удобной IDE. Никаких make файлов (только по запросу, если сильно кому надо). Как всё запущено. Я так скажу - такие IDE фтопку! Кроме шуток. Они хороши для тотальных бегиннеров или только для того, чтобы быстро попробовать. Для серьёзной работы рулит хороший программерский редактор + система сборки (make или что-то иное (у меня SCons)). Ого! Целых 300 команд. Расточительно, однако. Не команд, а тактов. У этого процессора контекст большой - 180 байт. Но полторы микросекунды не напрягают совершенно. Проц, кстати, без проблем может работать на 500 МГц, просто мне это не надо, электроэнергию экономлю, а успевает он со свистом и на 200 МГц. Честно скажу, не увидел в нем ничего особо выдающегося. Может быть я его готовить не умею? Очень гибкая среда, всё позволяет настроить. Правда, надо с системами сборки дружить, хотя бы на уровне базовых принципов. Минус для меня был - тормознутая она весьма, во всяком случае была года полтора назад, когда я её щупал. Поэтому до сих пор сижу на слике. |
|
|
Гость_MrYuran_* |
10.1.2012, 8:36
Сообщение
#50
|
Гости |
Покажите реализацию предъявленного полинома, чтобы его вычисление не мешало приёму и отправке пакетов байтов через UART на скорости 9600 бод. Попробую угадать: автомат, расположенный в прерывании UARTа. Я с этого начинал 6 лет назад, и постепенно отказался в пользу карусельного поллинга в суперлупе. При всех сопутствующих издержках, получается структурнее, более предсказуемо и переносимо (даже из проекта в проект). Ну и естественно, (RT)OS - следующий логический шаг на пути к всеобщей гармонии и стандартизации. Это правильно подмечено, что общая платформа в виде RTOS дисциплинирует и приводит к общему знаменателю разношерстный мелкопрограммерский коллектив. Кстати, тоже сейчас на МСП сидим, но уже в глубоких раздумьях по поводу STM32. |
|
|
10.1.2012, 10:01
Сообщение
#51
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
Очень гибкая среда, всё позволяет настроить. Правда, надо с системами сборки дружить, хотя бы на уровне базовых принципов. Минус для меня был - тормознутая она весьма, во всяком случае была года полтора назад, когда я её щупал. Поэтому до сих пор сижу на слике. Да, если бы там таггер был не на жабе... Не будет клипса шустрой никогда. |
|
|
Гость_MrYuran_* |
10.1.2012, 10:33
Сообщение
#52
|
Гости |
Да, если бы там таггер был не на жабе... Не будет клипса шустрой никогда. Излишества типа парсинга на лету можно и отключить, если уж прижмет. А поскольку сейчас даже самые дешёвые нетбуки на 2-ядерных процессорах делают, то вообще проблем никаких. Зато никаких вопросов типа "как запустить под линуксом". А для меня лично главное преимущество всех свободных систем - возможность работать с любой флешки, не заморачиваясь с установкой и уж тем более (боже упаси) с кряками/патчами етц. Если ранняя клипса требовала какой-то минимальной установки, то нынешняя вообще идет в виде рабочей копии. |
|
|
10.1.2012, 10:54
Сообщение
#53
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
Парсинг на лету - это как воздух. Особенно там, где чувствительность к регистру.
Когда постоянно сидел в паскале, ассемблере - потребности никакой в этом не ощущал. |
|
|
10.1.2012, 14:16
Сообщение
#54
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
Попробую угадать: автомат, расположенный в прерывании UARTа. Ну, это не спортивно. На прерываниях, конечно, можно приоритетный код выполнять, только это не очень способствует реализации более-менее больших кусков кода, а иначе тормоза остальной программы. Да, если бы там таггер был не на жабе... Не будет клипса шустрой никогда. Да, именно оно и тормозило больше всего. Поэтому и остался на слике - этот шустрый и умеет всё это с незапамятных времён. Излишества типа парсинга на лету можно и отключить, если уж прижмет. Ну уж нет. Эта штука оченно полезная и сильно экономит силы и нервы, особенно когда проект немалый - быстренько сходили, посмотрели, что за объект такой, вернулись и "продолжаем разговор" - на всю операцию пара-тройка секунд. Ну, и автодополнение и контроль области видимости тоже в тему - пресекает ошибки кодирования непосредственно на этапе кодирования. |
|
|
10.1.2012, 18:26
Сообщение
#55
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Так при выходе из прерывания таймера, когда счётчик досчитал до нужного значения и состояние автомата обновилось, поток выполнения куда попадает? Какой такой поток выполнения? Вы можете хоть на шаг отойти в сторону от своей парадигмы? У меня этого понятия нет. Спасибо за экскурс, с удовольствием бы послушал лет 15 назад, а сегодня уже не актуально. Хочется на конкретные вопросы получить конкретные ответы, а не пространные рассуждения, уж простите. Извините, но при отсутствии желания разобраться, Вы ничего не поймете. А зачем от неё отходить? Это и была цель - сделать написание кода простым и прозрачным, без видимых ветвлений и явных "завязок" на конкретные прерывания. Хотя бы затем, чтобы осознать, что в природе существуют и другие подходы, отличные от линейного кодинга. Простой и прозрачный код опять же только в Вашем понимании. Еще раз повторю, что в этом мире существуют и иные системы программирования. Что касается "конкретных" прерываний. Они у большинства МК практически одинаковы в логическом аспекте. Я всё-таки не вижу ответа на свой простой вопрос: ... Уверяю Вас, я практически Вам уже все рассказал. Не скрыл практически ничего. Что-то у нас с вами как-то не ладится взаимопонимание. Я вам про Фому, вы мне про Ерёму. Я вас просил показать реализацию вычисления полинома - так, чтобы оно не мешало работе с периферией, которая не будет ждать. Вы мне какой-то левый код обработки термодачтиков. Покажите реализацию предъявленного полинома, чтобы его вычисление не мешало приёму и отправке пакетов байтов через UART на скорости 9600 бод. Я Вам показал. Все именно так и выглядит. Я Вам практически все рассказал для того, чтобы можно было понять, каким образом это все проистекает. Но попробую еще раз. Предположим, расчет находится в суперлупе и выполняется. В этот момент очередной байт был отправлен по USART и наступает прерывание от этого периферийного устройства. В обработчике прерывания мы загружаем в регистр передатчика USART очередной байт и возвращаемся к расчетам, если в системе ничего не произошло. Пусть, параллельно с окончанием выдачи байта, приходит передний фронт синхронизации с сетью для фазы А, заведенный на одно из внешних прерываний. Тогда мы не вернемся к расчетам, а выполним следующие действия: 1. Изменим состояние автомата управления симистором фазы А со СТОП на ОТСЧЕТ_УГЛА; 2. Загрузим таймер, отвечающий за фазу А неким наперед рассчитанным значением. 3. Запустим этот таймер. После этого, таки, вернемся к расчетам. Конечно. У нас целое семейство проектов, где большая часть кода просто заимствована. Работают разные люди. Нареканий нет. То, что RTOS позволяет формализовать подход в организации потока выполнения программы, оказывается очень кстати при работе в команде. Ненавижу этот термин - "работать в команде". Тем не менее, в той же Италии существуют достаточно большие коллективы, которые сопровождают огромные проекты для PLC. Они - эти PLC работают исключительно на прерываниях, где нет потока выполнения в Вашем понимании. Ну и RTOS соответственно. Ну, это не спортивно. На прерываниях, конечно, можно приоритетный код выполнять, только это не очень способствует реализации более-менее больших кусков кода, а иначе тормоза остальной программы. Если Вы не умеете этого делать, то это не означает того, что этого не умеют делать остальные... Симуляторы как раз и предназначены для того, чтобы обеспечить именно это. Попробую угадать: автомат, расположенный в прерывании UARTа. Не угадали. Фикус в том, что автомат распределен по прерываниям. Что гораздо более естественно: ... карусельного поллинга в суперлупе. ...хотя и это используется тоже. И не только... Ну и естественно, (RT)OS - следующий логический шаг на пути к всеобщей гармонии и стандартизации. Это правильно подмечено, что общая платформа в виде RTOS дисциплинирует и приводит к общему знаменателю разношерстный мелкопрограммерский коллектив. Опять же. Это только для Вас. Нельзя отображать свои комплексы на остальных. Если Вы не в состоянии структурировать алгоритм, кроме как линейным кодом, то это Ваша проблема, а не достоинство. Простите за резкость. Огромное количество специалистов не нуждаются в линейном коде. И нет ничего удивительного в том, что не все Ваши коллеги воспринимают Ваши подходы. Может быть они наделены тем, чего нет у Вас? |
|
|
10.1.2012, 20:45
Сообщение
#56
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
Какой такой поток выполнения? Вы можете хоть на шаг отойти в сторону от своей парадигмы? У меня этого понятия нет. Поток выполнения программы - устоявшийся термин (program control flow). Если вступаете в такие дискуссии, то азы бы надо знать. * * * При всём уважении, замечу, что вы переходите рамки, переходите на личности, не замечая собственных недостатков (коих в избытке) в знаниях. ... Извините, но при отсутствии желания разобраться, Вы ничего не поймете. ... Простой и прозрачный код опять же только в Вашем понимании. Еще раз повторю, что в этом мире существуют и иные системы программирования. ... Если Вы не умеете этого делать, то это не означает того, что этого не умеют делать остальные... Опять же. Это только для Вас. Нельзя отображать свои комплексы на остальных. Если Вы не в состоянии структурировать алгоритм, кроме как линейным кодом, то это Ваша проблема, а не достоинство. ... И нет ничего удивительного в том, что не все Ваши коллеги воспринимают Ваши подходы. Может быть они наделены тем, чего нет у Вас? Я был предельно корректен и вежлив и достаточно терпел необоснованные заявления по поводу подходов в разработке софта, инструментария и процессоров. Но толку нет, дошло до того, что посыпались обвинения в невежестве, неумении и прочем. Отвечу теперь без обиняков, не обессудьте. Вы демонстрируете удивительную зашоренность в знаниях по очень широкому спектру вопросов embedded программирования. Вы понятия не имеете, как устроена и функционирует приоритетная вытесняющая RTOS, предлагая в качестве альтернативы примитивный подход, когда код, рассован по прерываниям - такие программы я успешно писал 10 лет назад, пока не вышел на новый уровень понимания в организации потоков управления (да, да, именно потоков управления - есть такое технический термин). Уровень вашего кода на два порядка ниже по сложности уровня кода любой простейшей RTOS. И вы при этом не стесняетесь обвинять в невежестве тех, кто разобрался досконально в этом и успешно применяет, зряче и эффективно. Вы понятия не имеете о том, как организуется эффективная среда разработки, основанная на редакторах с поддержкой context tagging, обработкой вывода с анализом на основе регулярных выражений, мощными средствами навигации по проекту, системах сборки проектов, основанных на скриптах, позволяющих делать что угодно, а не только то, что предоставляет IDE в виде чекбоксов. Но это не мешает вам критиковать этот подход. Про С++ говорить не буду, тут мы его не обсуждали, зато обсуждали на элхе. Симптомы ровно те же. На этом я, пожалуй, с вами дискуссию на эту тему закончу. Прошу просить, если был излишне резок. Всего доброго. |
|
|
10.1.2012, 21:02
Сообщение
#57
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
На этом я, пожалуй, с вами дискуссию на эту тему закончу. Прошу просить, если был излишне резок. Всего доброго. Я тоже несколько устал от разговора в позиции младшего брата. Опять же, приношу извинения, если чем-то Вас обидел. Обвинений Вас в невежестве не было. Было предположение, что некоторые вещи Вам даются тяжело, и Вы нашли иные пути для решения этих проблем. Которые недоступны мне в силу моих собственных невежестве и лени. И, если можно, хотелось бы глянуть Ваш код 10-летнй давности. P. S. Я сожалею, что так вышло... |
|
|
11.1.2012, 2:42
Сообщение
#58
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
Мне вот другой вопрос интересен.
Где конечный автомат может выиграть, если ресурсы не напрягают применять ось? Если не вспоминать про размеры контекста итд итп и не затрагивать GUI, там везде мрачные автоматы, чёрт голову сломит |
|
|
11.1.2012, 5:58
Сообщение
#59
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
Я еще когда на асме для авров сидел, это начиная года с 1999 по 2007, когда Winavr соответствующий стал устраивать, созрел к середине этого периода до самописных реалтаймовых приемов, благодаря ассемблеру меня не смущал размер контекста, ибо ручками его ограничивал до нужного набора регистров, обычно это были X,Y,Z и пара для знакового умножения, остальные служили для прерываний, системных вызовов, упрощали синхронизацию итд итп
С бесповоротным переходом на Си стала рулить кооперативка на прото..не буду больше всуе Ессно, раз и навсегда распрощавшись с грязной любовью к авркам, никаких сомнений не будет по поводу перехода на ось, извиняюсь за лесть в сторону dxp, мне scmRTOS как-то больше приглянулась, или на крайняк по-Клёновски фриртос оберну в классы. Но это должен Везувий проснуться, чтоб я куда-то спрыгнул. Кстати, были у меня проёбы на sam7s***, по-старинке ось по-боку, натрахался наверняка больше, чем мог бы с фриртосом. Но тогда zltigo чуть ли не каждый день обновления отписывал, испугало. Ну, PICи двигательные, - тут я тоже консерватор, хоть и ресурсов на dsPIC - выше крыши будет. И все еще 18F2431 ставлю - скоро выжму из них 100% возможностей, с очередными совершенствованиями, но блин, они дубовые, значит - крепкие |
|
|
11.1.2012, 19:00
Сообщение
#60
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
К сожалению, уважаемый Прохожий не может сравнить варианты объективно. Безусловно. Хотя бы потому, что с ОС дела не имел в практическом смысле. Но просматривал несколько. ПМСМ, беда такого раздела человеческой деятельности, как программирование, в том, что нормального результата можно достичь разными способами. В отличие от силовой электроники, скажем. Поскольку там все просто - некорректные действия караются немедленно. Отсюда - разница во взглядах на это дело. Уважаемый dxp, безусловно, имеет в нем больший опыт, нежели я. Точно так же, как и MrYuran, хотя бы потому что это их основной способ существования. Но и мои проекты проверены временем и жесткими условиями эксплуатации. Один из проектов, правда, не очень большой, сопровождается уже порядка 7 лет и совсем без меня. Ряд проектов средней сложности работают от года до 4-х лет без выключения оборудования. Опять же сопровождаются с моим достаточно редким участием. Следовательно, подходы, мною озвученные, имеют право на жизнь. С другой стороны, RTOS и ООП на сегодня - это, де факто, мэйнстрим. Этим по долгу службы занимается достаточно большое количество народу. А поскольку я свободный художник, то могу себе позволить несколько выпасть из "потока управления". И исследовать альтернативные подходы. Их суть я и пытался изложить... Вышло не очень. В чем признаю только свою вину. |
|
|
Текстовая версия | Сейчас: 28.3.2024, 23:49 |