RTOS: распространенные заблуждения, Обсудим? |
Здравствуйте, гость ( Вход | Регистрация )
RTOS: распространенные заблуждения, Обсудим? |
7.1.2012, 17:44
Сообщение
#21
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
А отговорки в виде неподходящего под задачу МК попахивают дилетантизмом. Или еще хуже - нежеланием разбираться с его "железом". Простите, если кого обидел. Простите, но настаивание на отказе от использования RTOS в принципе с отнесением их к классу прокладок характеризует сложность задач. Теперь про WaitForEvent() и Sleep(500). Я Вас удивлю. Но я так и делаю. Я довожу уровень абстракции от железа именно до этого состояния. Но несколько иным способом. Для этого существуют специальные глобальные битовые переменные. Blink500ms и RxEvent (сказывается тяжелое наследие PLC) Это как это? Покажите аналог кода (включаем внешнее устройство (реле, например) и мигаем два раза индикатором с периодом 1 с) : Код for(;;) { ... relay_on (true); led_on(true); sleep(500); // 500 ms led_on(false); sleep(500); // 500 ms led_on(true); sleep(500); // 500 ms led_on(false); ... } Хотя, для меня не составит труда сделать и по-Вашему. И вообще - HAL существует и при моем подходе (куда же без него), но без ОС. И я не месил бы в кучу абстрагирование от железа и ОС. А HAL-то тут причём? Приведенная Вами задача решена мною без всяких ОС на PIC18F при разработке терморегулятора с двухстрочным индикатором, кнопками и Modbus/RTU на RS485. Там как раз и было все, что Вами упомянуто. Плавающая запятая при расчете температуры по термо ЭДС, то же самое для ПИД, плюс к этому, линеаризация для фазового управления. Туда же была встроена проверка на коротыш и обрыв при включении тиристора. Ну и само фазовое управление для трехфазной сети без рабочего нуля. С учетом фильтрации моментов перехода через ноль каждой из фаз. Задача чудным образом решается исключительно с помощью автоматов и прерываний на МК всего лишь с двумя уровнями приоритетов. Контроллер приоритетов эмулируется непосредственно при программном поллинге флагов. Поверьте, это совсем незначительное количество команд на ASM-е. Круто. Только я не понял, как вы решили проблему с длительными вычислениями, которые нужно выполнять на фоне резких металовок по запросам от аппаратуры, которая не будет ждать. Вот есть вычисления на десятки мс, я просто пишу их как они есть, совершенно не заморачиваясь, что там в системе ещё происходит - процесс вычислений будет прерван, запросы обслужены, и вычисления продолжатся как ни в чём не бывало. Как вы поступаете в этом случае? Ну и какой же тогда смысл в ОС, если у большинства современных МК это добро есть в аппаратном виде? У какого это большинства? У AVR? Нету. У MSP430? Нету. У PIC16/18? Нету. Есть у кортексов, но это уже дюже новая вещь. К тому же, аппаратный контроллер прерываний - штука специфичная и предъявляющая ряд ограничений (например, количество уровней, коих бывает у иных совсем немного - 2, 4, 8, у совсем толстых МК до 16) . И с переносимостью тут полный аут. А если, вдруг, нет, то это опять же Ваша недоработка. В чём недоработка? В том, что использовал отличный МК MSP430? У меня к вам вопрос: какие RTOS и сколько раз и в каких проектах вы использовали? Хочу понять, на чём основано ваше неприятие. Или не пробовали, но твёрдое мнение имеете? |
|
|
Гость_MrYuran_* |
7.1.2012, 20:17
Сообщение
#22
|
Гости |
Круто. Только я не понял, как вы решили проблему с длительными вычислениями, которые нужно выполнять на фоне резких металовок по запросам от аппаратуры, которая не будет ждать.? Я думаю, все сводится к выбору расово верного пика Кстати, на днях глянул stm8 - тоже забавная вещица, особенно в части прерываний и переключения контекста. Но кортекс конечно это вообще нечто. Да, возможно, это можно назвать дилетантизмом, ленью изучать архитектуру (новую каждый год-два), но это реалии. Немногие программеры вообще хотят возиться с каким-то низкоуровневым программированием, а от руководителя разработки требуется сделать конфетку приемлемого уровня за Н дней и М человекодней, и это в условиях, когда ТЗ может изменяться по три раза на дню, а экранные менюшки правятся вообще прямо по живому в реальном времени. Тут такая вермишель начинается... И на качестве разработки это сказывается совершенно отрицательно, какими бы благими намерениями ни руководствовались. Конечные автоматы это конечно интересно, сам так делаю. Но это значит, что в каждом углу программы приходится лепить кучу самодельных велосипедиков, вместо того чтобы применить стандартный, отлаженный сервис и избежать кучи граблей. В общем, спор опять какой-то беспредметный. Есть искусство программирования , а есть рутина ремесленничества. Тайм-ту-маркет и сопровождение в быстро меняющихся условиях и возможно при текучке кадров (в больших конторах). Там вообще все на конвейер поставлено., свободу выбора имеет только руководитель проекта или системный архитектор. И это вполне обосновано. |
|
|
7.1.2012, 20:30
Сообщение
#23
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Простите, но настаивание на отказе от использования RTOS в принципе с отнесением их к классу прокладок характеризует сложность задач. Опять же - это только для Вас. С Вашим складом характера и состояния ума. Это как это? Покажите аналог кода (включаем внешнее устройство (реле, например) и мигаем два раза индикатором с периодом 1 с) : Без проблем: Код for(;;) { ... if (RelayState==RELAY_START) { relay_on (true); Repeat=4; RelayState==RELAY_ON; } ... if (Blink1S && Repeat) led_on(true); else led_on(false); ... } В прерывании от таймера: Код if(Cnt500ms++ >= __500ms) { if(Blink1S)Blink1S=false; else Blink1S=true; if(Repeat>0) Repeat--; ...... Cnt500ms=0x00u; } А HAL-то тут причём? Просто мне показалось, что Hardware Abstraction Layer как-то должен быть увязан на RTOS. Или нет? Круто. Только я не понял, как вы решили проблему с длительными вычислениями, которые нужно выполнять на фоне резких металовок по запросам от аппаратуры, которая не будет ждать. Вот есть вычисления на десятки мс, я просто пишу их как они есть, совершенно не заморачиваясь, что там в системе ещё происходит - процесс вычислений будет прерван, запросы обслужены, и вычисления продолжатся как ни в чём не бывало. Как вы поступаете в этом случае? Абсолютно аналогично. А что мне должно помешать так поступать? У какого это большинства? У AVR? Нету. У MSP430? Нету. У PIC16/18? Нету. Есть у кортексов, но это уже дюже новая вещь. К тому же, аппаратный контроллер прерываний - штука специфичная и предъявляющая ряд ограничений (например, количество уровней, коих бывает у иных совсем немного - 2, 4, 8, у совсем толстых МК до 16) . И с переносимостью тут полный аут. Переносимость низкого уровня - миф. В контроллере прерываний PIC24, dsPIC и PIC32 - это все имеется. 8 уровней приоритетов для преиферийных прерываний и столько же для всяких системных неудач. Я же и говорю, что надо пользовать Microchip, вместо всякой ерунды, пусть и хорошей. В чём недоработка? В том, что использовал отличный МК MSP430? Ну раз у него нет развитой системы прерываний, то он явно уже не отличный. У меня к вам вопрос: какие RTOS и сколько раз и в каких проектах вы использовали? Хочу понять, на чём основано ваше неприятие. Или не пробовали, но твёрдое мнение имеете? CoDeSyS и TwinCat поверх Windows и Linux, косвенно - встроенные проприетарные RTOS от SIEMENS, OMRON. В разных проектах, в основном по долгу службы. Самолепные никогда. В них очень долго разбираться, большая вероятность ошибок, и чуждая мне идеология. |
|
|
7.1.2012, 20:54
Сообщение
#24
|
|
Активный участник Группа: Пользователи Сообщений: 1075 Регистрация: 22.11.2009 Пользователь №: 20 |
|
|
|
7.1.2012, 21:25
Сообщение
#25
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Я думаю, все сводится к выбору расово верного пика Кстати, на днях глянул stm8 - тоже забавная вещица, особенно в части прерываний и переключения контекста. Но кортекс конечно это вообще нечто. Кортекс - это вытягивание бабла из нищих разработчиков. До нормальных прерываний они добрались только на М4. У нормальных МК - это все уже давно на борту. Не менее 5-ти лет тому. Stm8 - выстрел в никуда. Да, возможно, это можно назвать дилетантизмом, ленью изучать архитектуру (новую каждый год-два), но это реалии. Немногие программеры вообще хотят возиться с каким-то низкоуровневым программированием, а от руководителя разработки требуется сделать конфетку приемлемого уровня за Н дней и М человекодней, и это в условиях, когда ТЗ может изменяться по три раза на дню, а экранные менюшки правятся вообще прямо по живому в реальном времени. Тут такая вермишель начинается... Многие западные конторы в связи с этим уже давно отказались от использования МК в чистом виде. И перешли на ПЛК. И получили одни плюсы. Скорость создания продукта выше в разы. Сопровождаемость высокая, причем местными специалистами, а не своими конторскими. Пайщики не нужны. Производсство удешевляется значительно. Я думаю, это время и у Вас не за горами. Просто Ваше руководство еще не в курсе... Может помочь ему? В общем, спор опять какой-то беспредметный. Есть искусство программирования , а есть рутина ремесленничества. Тайм-ту-маркет и сопровождение в быстро меняющихся условиях и возможно при текучке кадров (в больших конторах). Там вообще все на конвейер поставлено., свободу выбора имеет только руководитель проекта или системный архитектор. И это вполне обосновано. Во-во. И я к тому-же. Это как раз и объясняет все, что Вы перечислили. Хорошо, что я сам себе и системный архитектор и программист. Даже при острых разногласиях между ними , всегда будет по-моему. А так, Вы правы. Спор бесполезный. Каждый останется "при своих". вот кстати, а занимается ли кто-нибудь вещами типа Rate Monotonic Analisys, или такие задачи надуманны и очень редко встречаются? Обычно сия проблема решается элементарно. Если чего-то не срослось по времени, то на этапе проектирования выбирается более шустрый МК. Кроме этого, все это дело можно симулировать с подсчетом времени вплоть до такта. Проверяются высоко приоритетные блокирующие куски. И если они занимают более, чем 25% системного времени, то выбирается МК с аппаратным решением этих проблем, или аппаратная нашлепка к нему. К примеру. Чтобы избежать затрат на TCP/IP стек, можно поставить специальную микросхему. Тоже самое и с USB. |
|
|
7.1.2012, 22:01
Сообщение
#26
|
|
Активный участник Группа: Пользователи Сообщений: 1075 Регистрация: 22.11.2009 Пользователь №: 20 |
Если чего-то не срослось по времени, то на этапе проектирования выбирается более шустрый МК. а вот если одному моему знакомому и железку начальство определяет, и ОС, и железо делается одновременно с разработкой софта, а ему надо только закодить большую софтину `чтоб работало`? |
|
|
7.1.2012, 22:08
Сообщение
#27
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
|
|
|
7.1.2012, 22:30
Сообщение
#28
|
|
Активный участник Группа: Пользователи Сообщений: 1075 Регистрация: 22.11.2009 Пользователь №: 20 |
нет, больше не могу; спасибо за ответ
меня, собственно, интересовало, занимается ли кто-то верификацией на этот самый RT в смысле подсчёта worst-case для сложных алгоритмов, всяческих latency и как это вообще всё делается; понятно что функциональный тест для проверки что 'всё работает' + выбор более мощного процессора если нет - решит проблему; а если, например, вопрос стоит так, что ты или делаешь или доказываешь, что так оно работать не будет? |
|
|
7.1.2012, 22:37
Сообщение
#29
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
а если, например, вопрос стоит так, что ты или делаешь или доказываешь, что так оно работать не будет? В принципе, можно попробовать оценить это дело вручную. По известным аналогам. Лучше, конечно, иметь симулятор со счетчиком тактов. Тогда ставишь точки останова на начале участка и его конце. И смотришь - чего вышло. |
|
|
7.1.2012, 23:26
Сообщение
#30
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
нет, больше не могу; спасибо за ответ меня, собственно, интересовало, занимается ли кто-то верификацией на этот самый RT в смысле подсчёта worst-case для сложных алгоритмов, всяческих latency и как это вообще всё делается; понятно что функциональный тест для проверки что 'всё работает' + выбор более мощного процессора если нет - решит проблему; а если, например, вопрос стоит так, что ты или делаешь или доказываешь, что так оно работать не будет? В половине случаев должна спасать "живая" прекалибровка задержек, ибо, если точность не устраивает, железяка выбрана мимо кассы. Можно ведь встроить режимы стресс-тестов? |
|
|
8.1.2012, 0:16
Сообщение
#31
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
В половине случаев должна спасать "живая" прекалибровка задержек, ибо, если точность не устраивает, железяка выбрана мимо кассы. Можно ведь встроить режимы стресс-тестов? С "живой" прекалибровкой не выйдет. По условиям задачи надо произвести оценку до выбора "железа". Или того хуже - свергнуть навязанное. Без натурного моделирования. Т. е. основная задача - не допустить появления того, куда эти стресс-тесты можно было бы встроить. Или я не так понял? |
|
|
8.1.2012, 8:26
Сообщение
#32
|
|
Активный участник Группа: Пользователи Сообщений: 18789 Регистрация: 13.1.2011 Пользователь №: 332 |
Я думаю, все сводится к выбору расово верного пика ... постновогоднее-легкое дежавю...))) http://spnx.ru/blog/?p=30 ...апять же любимец публики топор : http://www.video-c.net/UserFiles/Pictures/1_902.jpg |
|
|
Гость_MrYuran_* |
8.1.2012, 10:09
Сообщение
#33
|
Гости |
Stm8 - выстрел в никуда. А мне понравилось. Если параметры энергосбережения у 8L соответствуют заявленным, вполне может претендовать на "убийцу МСПшек". Вот только компилятора нормального (GCC) под него пока нет. Цитата Хорошо, что я сам себе и системный архитектор и программист. Даже при острых разногласиях между ними , всегда будет по-моему. Дык, и у нас то же самое, с небольшими ограничениями на выбор элементной базы (по возможности максимальная унификация номенклатуры). Но когда уже четверо "самих себе", и у каждого велосипед собственной конструкции, поневоле начинаешь задумываться... |
|
|
8.1.2012, 10:52
Сообщение
#34
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
Вот только компилятора нормального (GCC) под него пока нет. Меня RCSTM8 пугает своей фаст-плавучкой Цитата – IEEE rounding is NOT the same as the 8087 FPU, but is a truncate instead. This means that the transcendental operations +, -, * and / may report a result which is slightly different than the standard float library. Ну и, традиционно, куча новых зарезервированных слов вместо атрибутов и прагм. Блин, что же столько дебилов на свете расплодилось? |
|
|
8.1.2012, 11:23
Сообщение
#35
|
|
Активный участник Группа: Пользователи Сообщений: 1075 Регистрация: 22.11.2009 Пользователь №: 20 |
С "живой" прекалибровкой не выйдет. По условиям задачи надо произвести оценку до выбора "железа". Или того хуже - свергнуть навязанное. Без натурного моделирования. Т. е. основная задача - не допустить появления того, куда эти стресс-тесты можно было бы встроить. Или я не так понял? всё верно. я понимаю, что то, о чём я пишу - это задача проектирования, моделирования, предварительных оценок с ответственностью того, кто собственно проектирует и оценивает _но_, допустим, мой знакомый пишет довольно "толстый" софт, у который в итоге должны работать в RT; а параллельно написанию, другие люди разрабатывают аппаратуру с вложениями в виде семизначных сумм; и вот моему знакомому было бы неплохо владеть неэмпирическими методами (пусть даже в конкретном случае всё 'срастётся' и будет ок) |
|
|
8.1.2012, 13:28
Сообщение
#36
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
всё верно. я понимаю, что то, о чём я пишу - это задача проектирования, моделирования, предварительных оценок с ответственностью того, кто собственно проектирует и оценивает Насчет правильного уяснения задачи - это все относилось исключительно ко мне лично. С возрастом, знаете ли, соображается все туже и туже... _но_, допустим, мой знакомый пишет довольно "толстый" софт, у который в итоге должны работать в RT; а параллельно написанию, другие люди разрабатывают аппаратуру с вложениями в виде семизначных сумм; и вот моему знакомому было бы неплохо владеть неэмпирическими методами (пусть даже в конкретном случае всё 'срастётся' и будет ок) Раньше для всего этого дела использовалось имитационное моделирование на языке JPSS. Мои соратники по учебе с прикладной математики и АСУ изучали это дело в обязательном порядке. Я учился на другой специальности и в нашу программу изучение этого пакета не входило. Но, судя по всему, Вашему товарищу это средство должно помочь - задачи, описываемые Вами, на первый взгляд совпадают с теми, которые позволяет решить этот пакет. |
|
|
8.1.2012, 14:45
Сообщение
#37
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
Без проблем: Код for(;;) { ... if (RelayState==RELAY_START) { relay_on (true); Repeat=4; RelayState==RELAY_ON; } ... if (Blink1S && Repeat) led_on(true); else led_on(false); ... } В прерывании от таймера: Код if(Cnt500ms++ >= __500ms) { if(Blink1S)Blink1S=false; else Blink1S=true; if(Repeat>0) Repeat--; ...... Cnt500ms=0x00u; } И что? Это аналог того кода? Совершенно несравнимо - там тривиальный линейный код в три строчки, а тут куча условий, каких-то внутренних переменных, логика их взаимодействия, в которую надо врубаться. И это на таком простейшем примере. А в реальности код процессов и сам по себе бывает достаточно непрост, с такой реализацией в сколько-нибудь серьёзном проекте 80% усилий будут уходить на code maintainance. Кроме того, я не понял, как тут осуществляется передача управления. В случае RTOS это делает ядро, переключая контексты. А тут как? Поллингом, что-ли? Просто мне показалось, что Hardware Abstraction Layer как-то должен быть увязан на RTOS. Или нет? Отчасти. HAL - это задача, которая ложится на драйвера по большей части. А главное назначение RTOS - обеспечить квазипараллельное выполнение независимых асинхронных потоков выполнения. Абсолютно аналогично. А что мне должно помешать так поступать? Именно то же самое: отсутствие механизмов, дающих возможность писать код, сосредотачиваясь на нём. Если я запускаю вычисления полинома 3-го порядка от двух переменных (там с десяток-полтора членов), который выполняется два десятка миллисекунд, и мне при этом не надо думать о том, что этот код может помешать реалтаймовой работе остальной программы, то это очень зримое преимущество. Вам же придётся разбивать вычисления полинома на куски, оценивать время выполнения каждого куска - чтобы оно не превышало определённого значения, организовывать автомат состояний и.д. Гора ручной работы и совершенно нечитабельный код. А сделать-то можно, да, с этим никто не спорит. Это и на асме можно написать. Если кто преподчитает асм - вэлком, никому не препятствуем. Переносимость низкого уровня - миф. Ну, кому миф, а для кого и реальность. В контроллере прерываний PIC24, dsPIC и PIC32 - это все имеется. 8 уровней приоритетов для преиферийных прерываний и столько же для всяких системных неудач. Всего 8? А что так мало. У меня вот щас в текущем проекте 11 процессов вращается. Как же быть? Я же и говорю, что надо пользовать Microchip, вместо всякой ерунды, пусть и хорошей. Микрочип по ряду параметров до всякой ерунды не дорос. Ну раз у него нет развитой системы прерываний, то он явно уже не отличный. Конечно, отличный. 16 разрядов, а потребляем меньше 8-битников, прекрасно продуманная периферия и управление ею. На сегодня он уже устарел, нынче ему хорошая альтернатива имеется. Но это не умаляет его достоинств. И одноуровневый контроллер прерываний не мешает эффективно решать задачи. CoDeSyS и TwinCat поверх Windows и Linux, косвенно - встроенные проприетарные RTOS от SIEMENS, OMRON. В разных проектах, в основном по долгу службы. Ну, где есть Window/Linux - это уже не RTOS, как бы его не называли. Самолепные никогда. В них очень долго разбираться, большая вероятность ошибок, и чуждая мне идеология. В венде, надо полагать, разобраться можно очень быстро, бо очень простая ось. И идеология её, надо полагать, близка. Ну, т.е. с именно RTOS'ами дела не имели. Вот тут и кроется у нас взаимонепонимание. Кортекс - это вытягивание бабла из нищих разработчиков. Любопытная мысль. Поясните, пожалуйста, почему МК с 4к ОЗУ, 32к флеши и кучей стандартной периферии, стоящий в розницу 1 бакс, - это вытягивание бабла из нищих разработчиков? До нормальных прерываний они добрались только на М4. Ой! У всех CortexM имеется NVIC. Вы бы уж хоть с матчастью ругаемых МК познакомились бы поближе. |
|
|
Гость_MrYuran_* |
8.1.2012, 15:23
Сообщение
#38
|
Гости |
Конечно, отличный. 16 разрядов, а потребляем меньше 8-битников, прекрасно продуманная периферия и управление ею. На сегодня он уже устарел, нынче ему хорошая альтернатива имеется. Но это не умаляет его достоинств. И одноуровневый контроллер прерываний не мешает эффективно решать задачи. У техасцев новая фича завелась - FRAM based MSP Все то же, только вместо флеши - ФРАМ. По баксу за штуку, если килограммами брать. |
|
|
8.1.2012, 16:45
Сообщение
#39
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
У техасцев новая фича завелась - FRAM based MSP Все то же, только вместо флеши - ФРАМ. По баксу за штуку, если килограммами брать. MSP430 хорош, пока вписывается в 16-разрядную модель адресного пространства. Попытка расширить его в виде ядра 430Х выглядит довольно уродливо, имхо. И на фоне EFM32 MSP430 уже смотрится бледновато. |
|
|
8.1.2012, 17:30
Сообщение
#40
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
И что? Это аналог того кода? Совершенно несравнимо - там тривиальный линейный код в три строчки, а тут куча условий, каких-то внутренних переменных, логика их взаимодействия, в которую надо врубаться. И это на таком простейшем примере. А в реальности код процессов и сам по себе бывает достаточно непрост, с такой реализацией в сколько-нибудь серьёзном проекте 80% усилий будут уходить на code maintainance. У меня есть уважительная причина. Даже несколько. 1. Логика проста и тривиальна. 2. Метод универсален. Попробуйте в своей методике моргнуть светодиодом раз, эдак, 200 после включения реле. 3. Скорость работы выше, чем у Вас. 4. Код короче, чем в Вашем случае поскольку я Вам предъявил заодно и реализацию, чего в Вашем случае не было. Кроме того, я не понял, как тут осуществляется передача управления. В случае RTOS это делает ядро, переключая контексты. А тут как? Поллингом, что-ли? Я думал, что у меня все очевидно. Прерывания от таймера наступают в строго отведенные отметки времени. Поэтому счетчик Cnt500ms увеличивается на 1 только через промежутки времени между прерываниями от таймера. В момент, когда счетчик Cnt500ms достигнет числа __500ms, которое соответствует 500 мсек произойдет следующее: 1. Сигнал Blink1S изменит состояние на противоположное. 2. Счетчик повторений Repeat уменьшится на 1 в том случае, если он больше нуля, иначе он останется нулем. В основном суперлупе. В автомате, управляющем релями, на переходе из состояния RELAY_START в состояние RELAY_ON счетчику повторений Repeat присваивается число подмигиваний, умноженное на два. Далее вообще все просто. Светодиод загорается, если сигнал Blink1S единица и счетчик повторений Repeat не ноль, в противном случае гаснет. Естественно, все переменные - глобальные. Теперь о коде процессов. Поверьте - он ничуть не сложнее для каждого из состояний автомата-процесса, чем приведенный мною, какой бы технической сложности не был сам процесс. И про поддержку. С ней все в полном порядке, ничуть не хуже, чем у Вас, только все там несколько иначе. Это все уже давно опробовано в программировании PLC. Я не придумал ничего нового. Отчасти. HAL - это задача, которая ложится на драйвера по большей части. А главное назначение RTOS - обеспечить квазипараллельное выполнение независимых асинхронных потоков выполнения. Для начала выскажу простой тезис. RTOS для Вас - это тоже некий уровень абстракции, обеспечивающий квазипараллельность. Поскольку мне эта абстракция не нужна, а драйвера - это тоже совокупность процессов, то моя основная забота - это HAL. Именно то же самое: отсутствие механизмов, дающих возможность писать код, сосредотачиваясь на нём. Если я запускаю вычисления полинома 3-го порядка от двух переменных (там с десяток-полтора членов), который выполняется два десятка миллисекунд, и мне при этом не надо думать о том, что этот код может помешать реалтаймовой работе остальной программы, то это очень зримое преимущество. Вам же придётся разбивать вычисления полинома на куски, оценивать время выполнения каждого куска - чтобы оно не превышало определённого значения, организовывать автомат состояний и.д. Гора ручной работы и совершенно нечитабельный код. А сделать-то можно, да, с этим никто не спорит. Это и на асме можно написать. Если кто преподчитает асм - вэлком, никому не препятствуем. С чего бы это? Расчет полиномов - это сплошная программа, оформленная в виде функции для повторного использования. Ее можно использовать и из автомата процесса. Мне, честно говоря, не понятно - откуда у Вас такое заблуждение, про которое Вы говорите в цитируемом выше тексте? С какой это радости мне нужно терпеть все мучения, описанные Вами? Уверяю Вас. В реальности все гораздо проще. Всего 8? А что так мало. У меня вот щас в текущем проекте 11 процессов вращается. Как же быть? А Вы уверены, что им всем нужны разные приоритеты? И еще. Открою маленький секрет. Число возможных состояний приоритета процесса для меня не суть. Запрос на необработанное прерывание никуда не исчезает. А в большинстве случаев задержка его обработки значения не имеет. Микрочип по ряду параметров до всякой ерунды не дорос. Микрочип на сегодняшний день - самая лояльная к потребителю контора с достаточно неплохой поддержкой. Конечно, отличный. 16 разрядов, а потребляем меньше 8-битников, прекрасно продуманная периферия и управление ею. На сегодня он уже устарел, нынче ему хорошая альтернатива имеется. Но это не умаляет его достоинств. И одноуровневый контроллер прерываний не мешает эффективно решать задачи. Согласен со всеми тезисами. Добавлю еще, что у него очень приятная система команд, очень похожая на PDP11, но отсутствие бесплатной полновесной среды разработки перечеркивает для меня всю его привлекательность. Равно как и его улучшенному варианту. Ну, где есть Window/Linux - это уже не RTOS, как бы его не называли. А если переписать Кернел? В венде, надо полагать, разобраться можно очень быстро, бо очень простая ось. И идеология её, надо полагать, близка. Гы, винда - это первая ОС, где было введено понятие события. И осуществлено переползание с обыкновенного программирования к событийному. А так, там все то же самое, что и в Ваших любимых RTOS. Обыкновенная вытесняющая ОС, с присущими ей достоинствами и недостатками. Ну, т.е. с именно RTOS'ами дела не имели. Вот тут и кроется у нас взаимонепонимание. Я достаточно хорошо ознакомился с идеологией RTOS и понял, что мне на текущем этапе это не нужно. Еще раз повторю. Любой современный МК - сам себе RTOS. Любопытная мысль. Поясните, пожалуйста, почему МК с 4к ОЗУ, 32к флеши и кучей стандартной периферии, стоящий в розницу 1 бакс, - это вытягивание бабла из нищих разработчиков? А сколько стоит нормальный софт разработчика с симулятором и приличной IDE? GNU не предлагать. Ой! У всех CortexM имеется NVIC. Вы бы уж хоть с матчастью ругаемых МК познакомились бы поближе. Да, действительно есть. Но с NVIC от ARM я знаком давно. Просто не ассоциировал его и CORTEX-ы. Но это бред, а не контроллер прерываний. Это источник неисчислимых багов и загадок для программиста. Как, впрочем, и весь ARM. Как был студенческой поделкой, так ею и остается по сей день. Кстати, у NVIC тоже всего 8 уровней приоритетов. Вот беда... |
|
|
Текстовая версия | Сейчас: 29.3.2024, 13:31 |