Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: RTOS: распространенные заблуждения
Шарага > Soft - НЕ железо > Программирование МК
Страницы: 1, 2, 3
Прохожий
Собственно - сабж.
Secter
biggrin.gif ...зашибись тема...апять про домхвоны....))))
Цитата
Оглянитесь вокруг: нас окружают десятки, сотни и тысячи разнообразных устройств. Попробуйте мысленно спроектировать программу для любого устройства дома: будильник, пульт д/у, музыкальный звонок, холодильник и т.д. Выйдите на улицу: светодиодные вывески над магазинчиками, сигнализации почти в каждом автомобиле, домофоны. Зайдите в магазин: кассовые аппараты, система освещения, турникет с магнитной рамкой.
Прохожий
Цитата(Secter @ 5.1.2012, 20:23) *
biggrin.gif ...зашибись тема...апять про домхвоны....))))

Кому что, а голодный про сранье.
Secter
Цитата(Прохожий @ 5.1.2012, 20:37) *
Кому что, а голодный про сранье.

smile.gif...про далесса с максимкой лень влезать...))) ...а тута само то... pardon.gif ...цытатник...)))
Прохожий
Цитата(Secter @ 5.1.2012, 20:40) *
smile.gif...про далесса с максимкой лень влезать...))) ...а тута само то... pardon.gif ...цытатник...)))

Это я к тому, что текст одинаковый, а читаем мы с Вами, что-то разное.
Я бы хотел узнать, в чем по мнению окружающих, с автором статьи можно согласиться, а с чем можно поспорить в области применения RTOS.
Secter
Цитата(Прохожий @ 5.1.2012, 19:48) *
Это я к тому, что текст одинаковый, а читаем мы с Вами, что-то разное.
Я бы хотел узнать....

smile.gif ...енто факт...мы с вами мыслим разными категориями....)))...лично мне более интересна личность Ю.Тёмкина ... pardon.gif http://www.tnkernel.com/about.html
MrYuran
По-моему, в настоящее время очень сузился круг задач и контроллеров, где было бы оправдано НЕприменение оси.
Хотя бы жалкого имитатора типа прототреда.
Ртос - это инструмент. Такой же, как компилятор, как библиотеки итд.
Позволяет программисту не отвлекаться на разную, извиняюсь, хню а делать СВОЮ работу. И не забивать голову лишними сущностями, которые уже давно и, главное, правильно реализованы в сервисах оси.
С прискорбием отмечу, что у нас в конторе оси пока не применяются в боевых девайсах.
Пришедший недавно молодой было поднял фриртос на мсп-шке, но тут срочно дали проект, давай-давай, быстрей-быстрей, никаких осей, делай как обычно, думать некогда...
Ну и в результате занимается самой что ни на есть хней.
"Как бы мне получше реализовать мигание символа при посисвольном вводе и при этом продолжать выполнять всю остальную работу"...
Прохожий
Цитата(GuruKiller @ 5.1.2012, 21:08) *
Для начала, Вы не автор. При этом никак не обозначили своё мнение.

Можно я выступлю чуть позже?
Цитата(GuruKiller @ 5.1.2012, 21:08) *
Но это всё относится к эмбеддерным девайсам. Для девайсов, которые ближе к комповым системам (на АРМовых процах таких много) весы таки перевешивают в сторону РТОСов. И чаще всего наличие эзернета и разных протоколов тоже перевешивают в сторону РТОСов.

Но наличие эзернетов и протоколов - это не RTOS. Это приложение к ней.
Может существовать само по себе...
Даже GUI может существовать немного в стороне от RTOS.

Цитата(MrYuran @ 5.1.2012, 21:40) *
Позволяет программисту не отвлекаться на разную, извиняюсь, хню а делать СВОЮ работу. И не забивать голову лишними сущностями, которые уже давно и, главное, правильно реализованы в сервисах оси.

Вот и давайте поконкретнее о хне и лишних сущностях.
Иными словами, какого уровня абстрагирования от железа и внешнего мира Вам не хватает?
Что для Вас лишняя сущность?
Цитата(MrYuran @ 5.1.2012, 21:40) *
"Как бы мне получше реализовать мигание символа при посисвольном вводе и при этом продолжать выполнять всю остальную работу"...

Это элементарно делается без всякой RTOS.
Harbinger
Попробую по пунктам. Профи в МК-программировании себя не считаю (просто жизнь заставила), поэтому можно и нужно пинать.
1. Смутил последний абзац:
Цитата
Разумеется, приведенные доводы не означают, что RTOS следует применять везде и всюду. Остается класс задач, где она помешает, но это уже за рамками постановки данного вопроса.

А неплохо бы рассмотреть.
2,3. При ограниченных ресурсах абсолютный контроль, увы, необходим. Ситуацию усугубляет момент, когда МК выбирает не сам разработчик, а его начальство, на которое давят сверху, в основном из ценовых соображений. Так тоже бывает! diablo.gif
Там не то что RTOS, даже на С не напишешь. Плавал два раза... в одном случае был ограничен 8 кБ (AT89S8252, довольно навороченная радиостанция), в другом - нечто 2-килобайтное, тоже 51, но шустрее в 6 раз и с очень приличной периферией (которая позволила втиснуть в 2 кБ то, что у других занимало почти всю память Меги8). Авантюра вообще-то, сознаю. Но продаётся. Потом переписал на C, тоже без ОС (флаговый автомат) - заняло, дай бог памяти, 2300 байт где-то, и все оптимизации до лампочки. Не влезло, короче.
Извращение обратного плана - применение МК о 64 кБ флеши, которой было занято аж полтора, при этом никакой оптимизации не делалось. Просто в нём 2 уарта и 2 доллара стоит. Тривиальный перекодировщик протоколов, из китайского в общепонятный. Поднапрягшись, можно было слепить на тини 2313, благо один из уартов работает только на приём, а второй в полудуплексе (485)... или вообще обойтись без этого "костыля", перешив 48-ю мегу в китайском блэкбоксе (дней 10 попыхтеть - на это не пошли).
4. Ерунда. Знаком с "дядями", пишущими ОС, в случае чего не проблема спросить.
5. Проходили. Самодозванивающиеся автоответчики и тому подобное (ну забыли прибить неактуальную задачку). То скорей вопрос дисциплины.
6. Вкратце - улыбнуло. smile.gif
_pasha
Гуй гуём - при чем тута ось?
Стеки протоколов - это единственный способ завлечь колеблющихся.
А штука - в стандартизации. Если таковая не нужна - ось не нать и даром.
Прохожий
Цитата(GuruKiller @ 5.1.2012, 22:04) *
Не согласен. ///большими буквами///

Делал несколько проектов, в которых много независимых алгоритмов (тредов). И делать их жерез опу желанием не горю.

Я не хочу никого ни в чем упрекать.
Каждый поступает так, как считает нужным.
Но существует туева хуча способов организовать псевдопараллельность на последовательной машине.
И для огромного количества процессов в том числе.
РТОС - это всего лишь один из способов.
Кто-то считает его единственно верным, а остальные через (_!_).
Лично я с этим не согласен.
_pasha
Цитата(GuruKiller @ 5.1.2012, 21:04) *
Не согласен. ///большими буквами///
Делал несколько проектов, в которых много независимых алгоритмов (тредов). И делать их жерез опу желанием не горю.

Ну и? Прикинул - у мну всё (99%) вертится над прототредами или над ими же с реалтаймовыми костылями . Необходимости в упорядочении способов передачи событий, мутексов итд не испытываю.
Прохожий
Цитата(GuruKiller @ 5.1.2012, 22:31) *
Ну так давайте расставим все точки над ы. А то каждый останется при мнении "сам дурак" smile.gif
Какие удобные хучи есть, сравнимые с тредопереключалкой (не важно осевой или внеосевой)?

Вы кстати собственноручно писали тредопереключалку?

Я не знаю что это такое.
У меня несколько иное представление об организации псевдопараллельности.
Вкратце поясню.
1. МК со всеми своими потрохами воспринимается как готовая операционная среда.
2. Его система прерываний - это множество возможных событий в системе.
3. Вся совокупность задач - это множество внешних процессов, требующих обслуживания.
4. Множество задач и множество процессов могут не совпадать, потому как задача может требовать нескольких процессов.
5. Множество процессов - это гиперавтомат, состоящий из элементарных автоматов.
6. Каждый процесс в отдельности - элементарный автомат.
7. Смена состояний автоматов производится по событиям (см. п. 2).
Естественно, это упрощенная схема, поскольку сюда накладывается динамическая смена приоритетов прерываний и еще много чего, зависящего от разных нюансов.
Не будем забывать и о основном суперлупе, который тоже участвует в этом деле, если это требуется.
_pasha
Цитата(GuruKiller @ 5.1.2012, 21:50) *
А разница между тем же и Фриртосей, например, какая? Название раздражает? Или спор тупо о наклейке "intel inside"?

Дык я уже сказал: стандартизация. Например, стек тцп/ип, который настолько муторно перекраивать, он же еще и подминает под себя необходимость не возвращаться более к вопросам устроительства обмена сообщениями соотв. уровня сложности. Или, например, - нарастает что-то типа гуя и не факт, что я единолично буду этим заниматься. А в остальном мне оно не надо. Разве что удобства организации мониторинга ресурсов, но это для случая, когда управлять потреблением наряду с чем-либо серьёзным. Все. pardon.gif
ЗЫ вот в металлодетектор, например, я бы ось впендюрил не задумываясь.
Harbinger
Цитата(_pasha @ 5.1.2012, 22:56) *
ЗЫ вот в металлодетектор, например, я бы ось впендюрил не задумываясь.

В рыбоэхолоте тоже не помешает. smile.gif
_pasha
Цитата(Harbinger @ 5.1.2012, 23:43) *
В рыбоэхолоте тоже не помешает. smile.gif

А в такие вещи, как ПЛК - ось нужна, начиная с того момента, как идет работа с CAN и ETHERNET. Вывод - чтоы объять большую линейку изделий, лучше пересаживаться на плюсы и оборачивать в классы возможную ось.
dxp
Согласен со всеми пунктами полностью. Есть несколько случаев, когда, например, вытесняющая ось не катит. Это, очевидно, когда проц откровенно не тянет - есть определённый порог, ниже которого такую систему не поставить - просто элементарно не хватит памяти на контексты. Т.е. МК со 128 байтами ОЗУ под вытесняющую ОС никак не подойдёт. Правда, нынче в ценовой нише таких МК завелись камешки, в которых ось встаёт со свистом - 8К ОЗУ, 32К флеши, куча периферии и всё это удовольствие за цену порядка доллара! Трудно поверить, но это так.

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

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

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

Например - не выдуманный пример, из моей практики: у меня уже лет 8 назад был проект, где надо было раз в 100 мс производить интенсивные вычисления с плавающей точкой (численное нахождение значения по измеренной величине от датчика угла), при этом ещё надо было обслуживать командный канал по UART'у и производить обновление динамическому индикатору - разряды переключать. Проц был MSP430F149, работал на 5 МГц, вычисления занимали порядка 20 мс. Т.е. процесс вычислений занимает процессор на весьма длительное время.

Выбор был - либо распихать всё остальное, что требует более быстрой реакции (UART на 9600 - это порядка 1 мс период передачи символов, обновление индикатора - 250 Гц = 4 мс) в обработчики прерываний, либо использовать вытесняющую ось с приоритетным планированием процессов. С прерываниями решение простое, но не очень хорошее и красивое.

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

Зато с вытесняющей осью целевая задача решается вообще без напрягов. Интенсивные вычисления помещаются низкоприоритетный процесс, остальные задачи распределяются по своим процессам. Код пишется независимо, и результирующее решение получается тривиальным, легко расширяемым и прозрачным. Без такой оси пришлось бы процесс вычислений разбивать на куски, обеспечивать их время выполнения не более определённого и т.д. - куча ручной работы, где всегда есть возможность что-то неверно рассчитать и нарушить целостность работы программы. Да, и код получается тут совсем не такой простой и прозрачный. Время на передачу управления в тех условиях (MSP430F149 @5MHz) составляло порядка 50 мкс (т.е., скажем, при возникновения события - байт прилетел в последовательный порт, поток управления окажется в коде, который должен обработать событие, через промежуток времени порядка 50 мкс, это гарантировано) .

Подобная вытесняющая RTOS во многом аналогична аппаратному приоритетному контроллеру прерываний, но реализованная программно, поэтому имеет недостаток в виде накладных расходов и достоинство в виде большей гибкости.

MrYuran
Цитата(Прохожий @ 5.1.2012, 23:53) *
Вкратце поясню.
1. МК со всеми своими потрохами воспринимается как готовая операционная среда.
2. Его система прерываний - это множество возможных событий в системе.
3. Вся совокупность задач - это множество внешних процессов, требующих обслуживания.

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

Ось позволяет абстрагироваться от такого ненужного програмисту понятия, как поток инструкций и состедоточиться на алгоритме непосредственной задачи.
То есть, в случае с тем же меню, видеть задачу глазами пользователя.
Вывели картинку - ждем нажатия кнопки.
Например, WaitForEvent() или что-то в этом роде.
И мигание осуществлять тупым Sleep(500)
Прохожий
Цитата(MrYuran @ 6.1.2012, 13:17) *
Не всегда система прерываний конкретного контроллера отвечает требованиям задачи.
Тем более, что сегодня железо одно, завтра другое, а бывает, что и одновременно разное.

Ну, в этом плане я сам себе хозяин.
А у Microchip-а всегда можно найти все, что нужно.
Цитата(MrYuran @ 6.1.2012, 13:17) *
Ось позволяет абстрагироваться от такого ненужного програмисту понятия, как поток инструкций и состедоточиться на алгоритме непосредственной задачи.
То есть, в случае с тем же меню, видеть задачу глазами пользователя.
Вывели картинку - ждем нажатия кнопки.
Например, WaitForEvent() или что-то в этом роде.
И мигание осуществлять тупым Sleep(500)

Вот про это я и говорю и то же самое говорил автору статьи.
Если Вам для сосредоточения на задаче нужна ОС, то мне это не требуется.
Если Вам для осуществления замысла необходимо привести как задачу, так и архитектуру под какие-то удобные Вам, как программисту условия, то мне этого не нужно.
Я умею приспосабливаться к любому сочетанию архитектура/набор задач без промежуточных прокладок в виде ОС.
ОС - это сам МК.
А отговорки в виде неподходящего под задачу МК попахивают дилетантизмом.
Или еще хуже - нежеланием разбираться с его "железом".
Простите, если кого обидел.
Теперь про WaitForEvent() и Sleep(500).
Я Вас удивлю. Но я так и делаю.
Я довожу уровень абстракции от железа именно до этого состояния.
Но несколько иным способом.
Для этого существуют специальные глобальные битовые переменные.
Blink500ms и RxEvent (сказывается тяжелое наследие PLC)
Хотя, для меня не составит труда сделать и по-Вашему.
И вообще - HAL существует и при моем подходе (куда же без него), но без ОС.
И я не месил бы в кучу абстрагирование от железа и ОС.


Цитата(dxp @ 6.1.2012, 11:47) *
Зато с вытесняющей осью целевая задача решается вообще без напрягов.

Приведенная Вами задача решена мною без всяких ОС на PIC18F при разработке терморегулятора с двухстрочным индикатором, кнопками и Modbus/RTU на RS485. Там как раз и было все, что Вами упомянуто. Плавающая запятая при расчете температуры по термо ЭДС, то же самое для ПИД, плюс к этому, линеаризация для фазового управления. Туда же была встроена проверка на коротыш и обрыв при включении тиристора. Ну и само фазовое управление для трехфазной сети без рабочего нуля. С учетом фильтрации моментов перехода через ноль каждой из фаз. Задача чудным образом решается исключительно с помощью автоматов и прерываний на МК всего лишь с двумя уровнями приоритетов. Контроллер приоритетов эмулируется непосредственно при программном поллинге флагов. Поверьте, это совсем незначительное количество команд на ASM-е.
Цитата(dxp @ 6.1.2012, 11:47) *
Подобная вытесняющая RTOS во многом аналогична аппаратному приоритетному контроллеру прерываний, но реализованная программно, поэтому имеет недостаток в виде накладных расходов и достоинство в виде большей гибкости.

Ну и какой же тогда смысл в ОС, если у большинства современных МК это добро есть в аппаратном виде?
А если, вдруг, нет, то это опять же Ваша недоработка.
_pasha
Цитата(dxp @ 6.1.2012, 9:47) *

Да, плавучие калькуляторы ложатся исключительно на вытесняющую ось. В общем-то все задачи, где муторно прерывать поток всякими йелдами и релаксами.
dxp
Цитата(Прохожий @ 7.1.2012, 15:42) *
А отговорки в виде неподходящего под задачу МК попахивают дилетантизмом.
Или еще хуже - нежеланием разбираться с его "железом".
Простите, если кого обидел.

Простите, но настаивание на отказе от использования RTOS в принципе с отнесением их к классу прокладок характеризует сложность задач.

Цитата(Прохожий @ 7.1.2012, 15:42) *
Теперь про 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);
    ...
}


Цитата(Прохожий @ 7.1.2012, 15:42) *
Хотя, для меня не составит труда сделать и по-Вашему.
И вообще - HAL существует и при моем подходе (куда же без него), но без ОС.
И я не месил бы в кучу абстрагирование от железа и ОС.

А HAL-то тут причём?

Цитата(Прохожий @ 7.1.2012, 15:42) *
Приведенная Вами задача решена мною без всяких ОС на PIC18F при разработке терморегулятора с двухстрочным индикатором, кнопками и Modbus/RTU на RS485. Там как раз и было все, что Вами упомянуто. Плавающая запятая при расчете температуры по термо ЭДС, то же самое для ПИД, плюс к этому, линеаризация для фазового управления. Туда же была встроена проверка на коротыш и обрыв при включении тиристора. Ну и само фазовое управление для трехфазной сети без рабочего нуля. С учетом фильтрации моментов перехода через ноль каждой из фаз. Задача чудным образом решается исключительно с помощью автоматов и прерываний на МК всего лишь с двумя уровнями приоритетов. Контроллер приоритетов эмулируется непосредственно при программном поллинге флагов. Поверьте, это совсем незначительное количество команд на ASM-е.

Круто. Только я не понял, как вы решили проблему с длительными вычислениями, которые нужно выполнять на фоне резких металовок по запросам от аппаратуры, которая не будет ждать. Вот есть вычисления на десятки мс, я просто пишу их как они есть, совершенно не заморачиваясь, что там в системе ещё происходит - процесс вычислений будет прерван, запросы обслужены, и вычисления продолжатся как ни в чём не бывало. Как вы поступаете в этом случае?

Цитата(Прохожий @ 7.1.2012, 15:42) *
Ну и какой же тогда смысл в ОС, если у большинства современных МК это добро есть в аппаратном виде?

У какого это большинства? У AVR? Нету. У MSP430? Нету. У PIC16/18? Нету. Есть у кортексов, но это уже дюже новая вещь. К тому же, аппаратный контроллер прерываний - штука специфичная и предъявляющая ряд ограничений (например, количество уровней, коих бывает у иных совсем немного - 2, 4, 8, у совсем толстых МК до 16) . И с переносимостью тут полный аут.

Цитата(Прохожий @ 7.1.2012, 15:42) *
А если, вдруг, нет, то это опять же Ваша недоработка.

В чём недоработка? В том, что использовал отличный МК MSP430?

У меня к вам вопрос: какие RTOS и сколько раз и в каких проектах вы использовали? Хочу понять, на чём основано ваше неприятие. Или не пробовали, но твёрдое мнение имеете?
MrYuran
Цитата(dxp @ 7.1.2012, 19:44) *
Круто. Только я не понял, как вы решили проблему с длительными вычислениями, которые нужно выполнять на фоне резких металовок по запросам от аппаратуры, которая не будет ждать.?

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

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

В общем, спор опять какой-то беспредметный. Есть искусство программирования , а есть рутина ремесленничества. Тайм-ту-маркет и сопровождение в быстро меняющихся условиях и возможно при текучке кадров (в больших конторах). Там вообще все на конвейер поставлено., свободу выбора имеет только руководитель проекта или системный архитектор. И это вполне обосновано.
Прохожий
Цитата(dxp @ 7.1.2012, 18:44) *
Простите, но настаивание на отказе от использования RTOS в принципе с отнесением их к классу прокладок характеризует сложность задач.

Опять же - это только для Вас. С Вашим складом характера и состояния ума.
Цитата(dxp @ 7.1.2012, 18:44) *
Это как это? Покажите аналог кода (включаем внешнее устройство (реле, например) и мигаем два раза индикатором с периодом 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;    
    }

Цитата(dxp @ 7.1.2012, 18:44) *
А HAL-то тут причём?

Просто мне показалось, что Hardware Abstraction Layer как-то должен быть увязан на RTOS. Или нет?
Цитата(dxp @ 7.1.2012, 18:44) *
Круто. Только я не понял, как вы решили проблему с длительными вычислениями, которые нужно выполнять на фоне резких металовок по запросам от аппаратуры, которая не будет ждать. Вот есть вычисления на десятки мс, я просто пишу их как они есть, совершенно не заморачиваясь, что там в системе ещё происходит - процесс вычислений будет прерван, запросы обслужены, и вычисления продолжатся как ни в чём не бывало. Как вы поступаете в этом случае?

Абсолютно аналогично. А что мне должно помешать так поступать?
Цитата(dxp @ 7.1.2012, 18:44) *
У какого это большинства? У AVR? Нету. У MSP430? Нету. У PIC16/18? Нету. Есть у кортексов, но это уже дюже новая вещь. К тому же, аппаратный контроллер прерываний - штука специфичная и предъявляющая ряд ограничений (например, количество уровней, коих бывает у иных совсем немного - 2, 4, 8, у совсем толстых МК до 16) . И с переносимостью тут полный аут.

Переносимость низкого уровня - миф. В контроллере прерываний PIC24, dsPIC и PIC32 - это все имеется. 8 уровней приоритетов для преиферийных прерываний и столько же для всяких системных неудач. Я же и говорю, что надо пользовать Microchip, вместо всякой ерунды, пусть и хорошей.
Цитата(dxp @ 7.1.2012, 18:44) *
В чём недоработка? В том, что использовал отличный МК MSP430?

Ну раз у него нет развитой системы прерываний, то он явно уже не отличный.
Цитата(dxp @ 7.1.2012, 18:44) *
У меня к вам вопрос: какие RTOS и сколько раз и в каких проектах вы использовали? Хочу понять, на чём основано ваше неприятие. Или не пробовали, но твёрдое мнение имеете?

CoDeSyS и TwinCat поверх Windows и Linux, косвенно - встроенные проприетарные RTOS от SIEMENS, OMRON.
В разных проектах, в основном по долгу службы.
Самолепные никогда.
В них очень долго разбираться, большая вероятность ошибок, и чуждая мне идеология.
Idle
Цитата(dxp @ 6.1.2012, 11:47) *
жёстком реальном времени программно

вот кстати, а занимается ли кто-нибудь вещами типа Rate Monotonic Analisys, или такие задачи надуманны и очень редко встречаются?
Прохожий
Цитата(MrYuran @ 7.1.2012, 21:17) *
Я думаю, все сводится к выбору расово верного пика smile.gif
Кстати, на днях глянул stm8 - тоже забавная вещица, особенно в части прерываний и переключения контекста.
Но кортекс конечно это вообще нечто.

Кортекс - это вытягивание бабла из нищих разработчиков. До нормальных прерываний они добрались только на М4.
У нормальных МК - это все уже давно на борту. Не менее 5-ти лет тому.
Stm8 - выстрел в никуда.
Цитата(MrYuran @ 7.1.2012, 21:17) *
Да, возможно, это можно назвать дилетантизмом, ленью изучать архитектуру (новую каждый год-два), но это реалии. Немногие программеры вообще хотят возиться с каким-то низкоуровневым программированием, а от руководителя разработки требуется сделать конфетку приемлемого уровня за Н дней и М человекодней, и это в условиях, когда ТЗ может изменяться по три раза на дню, а экранные менюшки правятся вообще прямо по живому в реальном времени. Тут такая вермишель начинается...

Многие западные конторы в связи с этим уже давно отказались от использования МК в чистом виде. И перешли на ПЛК.
И получили одни плюсы. Скорость создания продукта выше в разы. Сопровождаемость высокая, причем местными специалистами, а не своими конторскими. Пайщики не нужны. Производсство удешевляется значительно.
Я думаю, это время и у Вас не за горами. Просто Ваше руководство еще не в курсе...
Может помочь ему?
Цитата(MrYuran @ 7.1.2012, 21:17) *
В общем, спор опять какой-то беспредметный. Есть искусство программирования , а есть рутина ремесленничества. Тайм-ту-маркет и сопровождение в быстро меняющихся условиях и возможно при текучке кадров (в больших конторах). Там вообще все на конвейер поставлено., свободу выбора имеет только руководитель проекта или системный архитектор. И это вполне обосновано.

Во-во. И я к тому-же. Это как раз и объясняет все, что Вы перечислили. Хорошо, что я сам себе и системный архитектор и программист. Даже при острых разногласиях между ними , всегда будет по-моему.
А так, Вы правы. Спор бесполезный. Каждый останется "при своих".
Цитата(Idle @ 7.1.2012, 21:54) *
вот кстати, а занимается ли кто-нибудь вещами типа Rate Monotonic Analisys, или такие задачи надуманны и очень редко встречаются?

Обычно сия проблема решается элементарно.
Если чего-то не срослось по времени, то на этапе проектирования выбирается более шустрый МК.
Кроме этого, все это дело можно симулировать с подсчетом времени вплоть до такта.
Проверяются высоко приоритетные блокирующие куски. И если они занимают более, чем 25% системного времени, то выбирается МК с аппаратным решением этих проблем, или аппаратная нашлепка к нему.
К примеру. Чтобы избежать затрат на TCP/IP стек, можно поставить специальную микросхему.
Тоже самое и с USB.
Idle
Цитата(Прохожий @ 7.1.2012, 23:25) *
Если чего-то не срослось по времени, то на этапе проектирования выбирается более шустрый МК.

а вот если одному моему знакомому и железку начальство определяет, и ОС, и железо делается одновременно с разработкой софта, а ему надо только закодить большую софтину `чтоб работало`?
Прохожий
Цитата(Idle @ 7.1.2012, 23:01) *
а вот если одному моему знакомому и железку начальство определяет, и ОС, и железо делается одновременно с разработкой софта, а ему надо только закодить большую софтину `чтоб работало`?

А более конкретно можете?
Idle
нет, больше не могу; спасибо за ответ

меня, собственно, интересовало, занимается ли кто-то верификацией на этот самый RT в смысле подсчёта worst-case для сложных алгоритмов, всяческих latency и как это вообще всё делается; понятно что функциональный тест для проверки что 'всё работает' + выбор более мощного процессора если нет - решит проблему; а если, например, вопрос стоит так, что ты или делаешь или доказываешь, что так оно работать не будет?
Прохожий
Цитата(Idle @ 7.1.2012, 23:30) *
а если, например, вопрос стоит так, что ты или делаешь или доказываешь, что так оно работать не будет?

В принципе, можно попробовать оценить это дело вручную. По известным аналогам.
Лучше, конечно, иметь симулятор со счетчиком тактов.
Тогда ставишь точки останова на начале участка и его конце.
И смотришь - чего вышло.
_pasha
Цитата(Idle @ 7.1.2012, 22:30) *
нет, больше не могу; спасибо за ответ

меня, собственно, интересовало, занимается ли кто-то верификацией на этот самый RT в смысле подсчёта worst-case для сложных алгоритмов, всяческих latency и как это вообще всё делается; понятно что функциональный тест для проверки что 'всё работает' + выбор более мощного процессора если нет - решит проблему; а если, например, вопрос стоит так, что ты или делаешь или доказываешь, что так оно работать не будет?

В половине случаев должна спасать "живая" прекалибровка задержек, ибо, если точность не устраивает, железяка выбрана мимо кассы. Можно ведь встроить режимы стресс-тестов? smile.gif
Прохожий
Цитата(_pasha @ 8.1.2012, 1:26) *
В половине случаев должна спасать "живая" прекалибровка задержек, ибо, если точность не устраивает, железяка выбрана мимо кассы. Можно ведь встроить режимы стресс-тестов? smile.gif

С "живой" прекалибровкой не выйдет. По условиям задачи надо произвести оценку до выбора "железа".
Или того хуже - свергнуть навязанное. Без натурного моделирования.
Т. е. основная задача - не допустить появления того, куда эти стресс-тесты можно было бы встроить.
Или я не так понял?
Secter
Цитата(MrYuran @ 7.1.2012, 21:17) *
Я думаю, все сводится к выбору расово верного пика smile.gif

smile.gif ... постновогоднее-легкое дежавю...))) http://spnx.ru/blog/?p=30 ...апять же любимец публики топор : http://www.video-c.net/UserFiles/Pictures/1_902.jpg
MrYuran
Цитата(Прохожий @ 7.1.2012, 23:25) *
Stm8 - выстрел в никуда.

А мне понравилось.
Если параметры энергосбережения у 8L соответствуют заявленным, вполне может претендовать на "убийцу МСПшек".
Вот только компилятора нормального (GCC) под него пока нет.
Цитата
Хорошо, что я сам себе и системный архитектор и программист. Даже при острых разногласиях между ними , всегда будет по-моему.

Дык, и у нас то же самое, с небольшими ограничениями на выбор элементной базы (по возможности максимальная унификация номенклатуры).
Но когда уже четверо "самих себе", и у каждого велосипед собственной конструкции, поневоле начинаешь задумываться...
_pasha
Цитата(MrYuran @ 8.1.2012, 10:09) *
Вот только компилятора нормального (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.

Ну и, традиционно, куча новых зарезервированных слов вместо атрибутов и прагм. Блин, что же столько дебилов на свете расплодилось?
Idle
Цитата(Прохожий @ 8.1.2012, 2:16) *
С "живой" прекалибровкой не выйдет. По условиям задачи надо произвести оценку до выбора "железа".
Или того хуже - свергнуть навязанное. Без натурного моделирования.
Т. е. основная задача - не допустить появления того, куда эти стресс-тесты можно было бы встроить.
Или я не так понял?

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

_но_, допустим, мой знакомый пишет довольно "толстый" софт, у который в итоге должны работать в RT; а параллельно написанию, другие люди разрабатывают аппаратуру с вложениями в виде семизначных сумм; и вот моему знакомому было бы неплохо smile.gif владеть неэмпирическими методами (пусть даже в конкретном случае всё 'срастётся' и будет ок)
Прохожий
Цитата(Idle @ 8.1.2012, 13:23) *
всё верно. я понимаю, что то, о чём я пишу - это задача проектирования, моделирования, предварительных оценок с ответственностью того, кто собственно проектирует и оценивает

Насчет правильного уяснения задачи - это все относилось исключительно ко мне лично. С возрастом, знаете ли, соображается все туже и туже...
Цитата(Idle @ 8.1.2012, 13:23) *
_но_, допустим, мой знакомый пишет довольно "толстый" софт, у который в итоге должны работать в RT; а параллельно написанию, другие люди разрабатывают аппаратуру с вложениями в виде семизначных сумм; и вот моему знакомому было бы неплохо smile.gif владеть неэмпирическими методами (пусть даже в конкретном случае всё 'срастётся' и будет ок)

Раньше для всего этого дела использовалось имитационное моделирование на языке JPSS.
Мои соратники по учебе с прикладной математики и АСУ изучали это дело в обязательном порядке.
Я учился на другой специальности и в нашу программу изучение этого пакета не входило.
Но, судя по всему, Вашему товарищу это средство должно помочь - задачи, описываемые Вами, на первый взгляд совпадают с теми, которые позволяет решить этот пакет.
dxp
Цитата(Прохожий @ 8.1.2012, 0:30) *
Без проблем:
Код
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 это делает ядро, переключая контексты. А тут как? Поллингом, что-ли?

Цитата(Прохожий @ 8.1.2012, 0:30) *
Просто мне показалось, что Hardware Abstraction Layer как-то должен быть увязан на RTOS. Или нет?

Отчасти. HAL - это задача, которая ложится на драйвера по большей части. А главное назначение RTOS - обеспечить квазипараллельное выполнение независимых асинхронных потоков выполнения.

Цитата(Прохожий @ 8.1.2012, 0:30) *
Абсолютно аналогично. А что мне должно помешать так поступать?

Именно то же самое: отсутствие механизмов, дающих возможность писать код, сосредотачиваясь на нём. Если я запускаю вычисления полинома 3-го порядка от двух переменных (там с десяток-полтора членов), который выполняется два десятка миллисекунд, и мне при этом не надо думать о том, что этот код может помешать реалтаймовой работе остальной программы, то это очень зримое преимущество. Вам же придётся разбивать вычисления полинома на куски, оценивать время выполнения каждого куска - чтобы оно не превышало определённого значения, организовывать автомат состояний и.д. Гора ручной работы и совершенно нечитабельный код. А сделать-то можно, да, с этим никто не спорит. Это и на асме можно написать. Если кто преподчитает асм - вэлком, никому не препятствуем. smile.gif

Цитата(Прохожий @ 8.1.2012, 0:30) *
Переносимость низкого уровня - миф.

Ну, кому миф, а для кого и реальность.

Цитата(Прохожий @ 8.1.2012, 0:30) *
В контроллере прерываний PIC24, dsPIC и PIC32 - это все имеется. 8 уровней приоритетов для преиферийных прерываний и столько же для всяких системных неудач.

Всего 8? А что так мало. У меня вот щас в текущем проекте 11 процессов вращается. Как же быть?

Цитата(Прохожий @ 8.1.2012, 0:30) *
Я же и говорю, что надо пользовать Microchip, вместо всякой ерунды, пусть и хорошей.

biggrin.gif Микрочип по ряду параметров до всякой ерунды не дорос.

Цитата(Прохожий @ 8.1.2012, 0:30) *
Ну раз у него нет развитой системы прерываний, то он явно уже не отличный.

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

Цитата(Прохожий @ 8.1.2012, 0:30) *
CoDeSyS и TwinCat поверх Windows и Linux, косвенно - встроенные проприетарные RTOS от SIEMENS, OMRON.
В разных проектах, в основном по долгу службы.

Ну, где есть Window/Linux - это уже не RTOS, как бы его не называли.

Цитата(Прохожий @ 8.1.2012, 0:30) *
Самолепные никогда.
В них очень долго разбираться, большая вероятность ошибок, и чуждая мне идеология.

В венде, надо полагать, разобраться можно очень быстро, бо очень простая ось.smile.gif И идеология её, надо полагать, близка.

Ну, т.е. с именно RTOS'ами дела не имели. Вот тут и кроется у нас взаимонепонимание.

Цитата(Прохожий @ 8.1.2012, 1:25) *
Кортекс - это вытягивание бабла из нищих разработчиков.

Любопытная мысль. Поясните, пожалуйста, почему МК с 4к ОЗУ, 32к флеши и кучей стандартной периферии, стоящий в розницу 1 бакс, - это вытягивание бабла из нищих разработчиков?

Цитата(Прохожий @ 8.1.2012, 1:25) *
До нормальных прерываний они добрались только на М4.

Ой! У всех CortexM имеется NVIC. Вы бы уж хоть с матчастью ругаемых МК познакомились бы поближе.smile.gif
MrYuran
Цитата(dxp @ 8.1.2012, 16:45) *
Конечно, отличный. 16 разрядов, а потребляем меньше 8-битников, прекрасно продуманная периферия и управление ею. На сегодня он уже устарел, нынче ему хорошая альтернатива имеется. Но это не умаляет его достоинств. И одноуровневый контроллер прерываний не мешает эффективно решать задачи.

У техасцев новая фича завелась - FRAM based MSP
Все то же, только вместо флеши - ФРАМ.
По баксу за штуку, если килограммами брать.
dxp
Цитата(MrYuran @ 8.1.2012, 19:23) *
У техасцев новая фича завелась - FRAM based MSP
Все то же, только вместо флеши - ФРАМ.
По баксу за штуку, если килограммами брать.

MSP430 хорош, пока вписывается в 16-разрядную модель адресного пространства. Попытка расширить его в виде ядра 430Х выглядит довольно уродливо, имхо. И на фоне EFM32 MSP430 уже смотрится бледновато.
Прохожий
Цитата(dxp @ 8.1.2012, 15:45) *
И что? Это аналог того кода? Совершенно несравнимо - там тривиальный линейный код в три строчки, а тут куча условий, каких-то внутренних переменных, логика их взаимодействия, в которую надо врубаться. И это на таком простейшем примере. А в реальности код процессов и сам по себе бывает достаточно непрост, с такой реализацией в сколько-нибудь серьёзном проекте 80% усилий будут уходить на code maintainance.

У меня есть уважительная причина. Даже несколько.
1. Логика проста и тривиальна.
2. Метод универсален. Попробуйте в своей методике моргнуть светодиодом раз, эдак, 200 после включения реле.
3. Скорость работы выше, чем у Вас.
4. Код короче, чем в Вашем случае поскольку я Вам предъявил заодно и реализацию, чего в Вашем случае не было.
Цитата(dxp @ 8.1.2012, 15:45) *
Кроме того, я не понял, как тут осуществляется передача управления. В случае RTOS это делает ядро, переключая контексты. А тут как? Поллингом, что-ли?

Я думал, что у меня все очевидно.
Прерывания от таймера наступают в строго отведенные отметки времени.
Поэтому счетчик Cnt500ms увеличивается на 1 только через промежутки времени между прерываниями от таймера.
В момент, когда счетчик Cnt500ms достигнет числа __500ms, которое соответствует 500 мсек произойдет следующее:
1. Сигнал Blink1S изменит состояние на противоположное.
2. Счетчик повторений Repeat уменьшится на 1 в том случае, если он больше нуля, иначе он останется нулем.
В основном суперлупе.
В автомате, управляющем релями, на переходе из состояния RELAY_START в состояние RELAY_ON счетчику повторений Repeat присваивается число подмигиваний, умноженное на два.
Далее вообще все просто. Светодиод загорается, если сигнал Blink1S единица и счетчик повторений Repeat не ноль, в противном случае гаснет.
Естественно, все переменные - глобальные.
Теперь о коде процессов. Поверьте - он ничуть не сложнее для каждого из состояний автомата-процесса, чем приведенный мною, какой бы технической сложности не был сам процесс.
И про поддержку. С ней все в полном порядке, ничуть не хуже, чем у Вас, только все там несколько иначе.
Это все уже давно опробовано в программировании PLC. Я не придумал ничего нового.
Цитата(dxp @ 8.1.2012, 15:45) *
Отчасти. HAL - это задача, которая ложится на драйвера по большей части. А главное назначение RTOS - обеспечить квазипараллельное выполнение независимых асинхронных потоков выполнения.

Для начала выскажу простой тезис. RTOS для Вас - это тоже некий уровень абстракции, обеспечивающий квазипараллельность. Поскольку мне эта абстракция не нужна, а драйвера - это тоже совокупность процессов, то моя основная забота - это HAL.
Цитата(dxp @ 8.1.2012, 15:45) *
Именно то же самое: отсутствие механизмов, дающих возможность писать код, сосредотачиваясь на нём. Если я запускаю вычисления полинома 3-го порядка от двух переменных (там с десяток-полтора членов), который выполняется два десятка миллисекунд, и мне при этом не надо думать о том, что этот код может помешать реалтаймовой работе остальной программы, то это очень зримое преимущество. Вам же придётся разбивать вычисления полинома на куски, оценивать время выполнения каждого куска - чтобы оно не превышало определённого значения, организовывать автомат состояний и.д. Гора ручной работы и совершенно нечитабельный код. А сделать-то можно, да, с этим никто не спорит. Это и на асме можно написать. Если кто преподчитает асм - вэлком, никому не препятствуем. smile.gif

С чего бы это? Расчет полиномов - это сплошная программа, оформленная в виде функции для повторного использования. Ее можно использовать и из автомата процесса.
Мне, честно говоря, не понятно - откуда у Вас такое заблуждение, про которое Вы говорите в цитируемом выше тексте?
С какой это радости мне нужно терпеть все мучения, описанные Вами?
Уверяю Вас. В реальности все гораздо проще.
Цитата(dxp @ 8.1.2012, 15:45) *
Всего 8? А что так мало. У меня вот щас в текущем проекте 11 процессов вращается. Как же быть?

А Вы уверены, что им всем нужны разные приоритеты?
И еще. Открою маленький секрет. Число возможных состояний приоритета процесса для меня не суть.
Запрос на необработанное прерывание никуда не исчезает. А в большинстве случаев задержка его обработки значения не имеет.
Цитата(dxp @ 8.1.2012, 15:45) *
biggrin.gif Микрочип по ряду параметров до всякой ерунды не дорос.

Микрочип на сегодняшний день - самая лояльная к потребителю контора с достаточно неплохой поддержкой.
Цитата(dxp @ 8.1.2012, 15:45) *
Конечно, отличный. 16 разрядов, а потребляем меньше 8-битников, прекрасно продуманная периферия и управление ею. На сегодня он уже устарел, нынче ему хорошая альтернатива имеется. Но это не умаляет его достоинств. И одноуровневый контроллер прерываний не мешает эффективно решать задачи.

Согласен со всеми тезисами. Добавлю еще, что у него очень приятная система команд, очень похожая на PDP11, но отсутствие бесплатной полновесной среды разработки перечеркивает для меня всю его привлекательность. Равно как и его улучшенному варианту.
Цитата(dxp @ 8.1.2012, 15:45) *
Ну, где есть Window/Linux - это уже не RTOS, как бы его не называли.

А если переписать Кернел?
Цитата(dxp @ 8.1.2012, 15:45) *
В венде, надо полагать, разобраться можно очень быстро, бо очень простая ось.smile.gif И идеология её, надо полагать, близка.

Гы, винда - это первая ОС, где было введено понятие события. И осуществлено переползание с обыкновенного программирования к событийному.
А так, там все то же самое, что и в Ваших любимых RTOS. Обыкновенная вытесняющая ОС, с присущими ей достоинствами и недостатками.
Цитата(dxp @ 8.1.2012, 15:45) *
Ну, т.е. с именно RTOS'ами дела не имели. Вот тут и кроется у нас взаимонепонимание.

Я достаточно хорошо ознакомился с идеологией RTOS и понял, что мне на текущем этапе это не нужно.
Еще раз повторю. Любой современный МК - сам себе RTOS.
Цитата(dxp @ 8.1.2012, 15:45) *
Любопытная мысль. Поясните, пожалуйста, почему МК с 4к ОЗУ, 32к флеши и кучей стандартной периферии, стоящий в розницу 1 бакс, - это вытягивание бабла из нищих разработчиков?

А сколько стоит нормальный софт разработчика с симулятором и приличной IDE? GNU не предлагать.
Цитата(dxp @ 8.1.2012, 15:45) *
Ой! У всех CortexM имеется NVIC. Вы бы уж хоть с матчастью ругаемых МК познакомились бы поближе.smile.gif

Да, действительно есть. Но с NVIC от ARM я знаком давно. Просто не ассоциировал его и CORTEX-ы.
Но это бред, а не контроллер прерываний.
Это источник неисчислимых багов и загадок для программиста.
Как, впрочем, и весь ARM.
Как был студенческой поделкой, так ею и остается по сей день.
Кстати, у NVIC тоже всего 8 уровней приоритетов.
Вот беда...
_pasha
Тут интересно со РТОС ведь другие проблемы возникают - реентерабельность сторонних подпрограмм, TLS и размеры стека задачи.
Прохожий
Цитата(GuruKiller @ 9.1.2012, 3:27) *
Так нельзя. Иначе тема "ымбеддер и AVR" будет закрыта smile.gif
Как собственно ещё дозревающая тема "ымбеддер и ОСь".
Поражаюсь способности Прохожего ругать то, в чём не разбираешься (или с чем не работал) smile.gif

Ладно, насчет NVIC я слегка погорячился.
Контроллер, как контроллер, только очень много лишнего, впрочем, как и в самой архитектуре ARM.
При ознакомлении с этими потрохами возникает масса вопросов о назначении тех или иных технических изысков.
Основная претензия к ARM - отсутствие бесплатных полноценных средств разработки.
Что же касается темы "Ымбедер и AVR", то было бы неплохо услышать претензии по-существу.
Кто и когда там был незаслуженно упомянут.
А то, что Ымбедеры постсоветского пространства почему-то предпочитают именно AVR - действительно загадка.
Цитата(GuruKiller @ 9.1.2012, 3:27) *
Очень любопытно. Получается реальная РТОСь, написанная для этого МК - это ОСь в квадрате smile.gif

Ну да, вот им она и стучит...
_pasha
Цитата(Прохожий @ 9.1.2012, 10:18) *
А то, что Ымбедеры постсоветского пространства почему-то предпочитают именно AVR - действительно загадка.

А что там загадочного? После пиков появились АВР с (о чудо!) гораздо более прямой архитектурой, народ ломанулся. Это подстегнуло к развитию средств разработки и отладки. Теперь достаточно иметь бесплатный ГЦЦ и пижженый протеус, чтобы, не отрывая жжж от стула, чувствовать себя гением. По себе знаю.
Прохожий
Цитата(_pasha @ 9.1.2012, 12:55) *
А что там загадочного? После пиков появились АВР с (о чудо!) гораздо более прямой архитектурой, народ ломанулся. Это подстегнуло к развитию средств разработки и отладки. Теперь достаточно иметь бесплатный ГЦЦ и пижженый протеус, чтобы, не отрывая жжж от стула, чувствовать себя гением. По себе знаю.

Но все-равно, не до конца понятно.
"Протез" поддерживает не только AVR.
Можно чувствовать себя гением и с ARM от различных контор и с тем же PIC24/dsPIC.
Но почему-то именно AVR здесь в лидерах.
Хотя архитектура у ARM еще более кошерная (не гарвардская) и возраст у него приблизительно совпадает с AVR.
MrYuran
Цитата(Прохожий @ 9.1.2012, 12:18) *
Основная претензия к ARM - отсутствие бесплатных полноценных средств разработки..

О5 25 smile.gif
между прочим, ARM в GCC отродясь поддерживается.
А ECLIPSE - вполне полноценная среда, не хуже мелкосиудии и уж точно не хуже бледно-серых IDE от IAR или кейла.
Отладка работает замечательно, я на STM32 гонял.
Симулятор- для симулянтов smile.gif
Честно говоря, я и отладку-то не люблю, привык как-то через терминал контрольные точки выводить.
dxp
Цитата(Прохожий @ 8.1.2012, 21:30) *
У меня есть уважительная причина. Даже несколько.
1. Логика проста и тривиальна.

Отнюдь не так проста как кажется - особенно по сравнению с альтернативным вариантом, где три строчки линейного кода и больше ничго - ни таймеров, ни счётчиков, ни автоматов (во, сколько лишних сущностей на пустом месте). И это в таком простейшем примере.

Цитата(Прохожий @ 8.1.2012, 21:30) *
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, извините. Т.е. код, который более-менее понятен автору (в течение пары месяцев с момента написания). smile.gif

Цитата(Прохожий @ 8.1.2012, 21:30) *
3. Скорость работы выше, чем у Вас.

Что вы понимаете под скоростью? Поясните?. Скорость реакции на событие - например, timer expiration, в моём варианте будет лучше - процесс сразу получит управление по выходу из таймерного прерывания, это время предсказуемое. А как у вас это осуществляется, я так и не понял, извините. Накладные расходы в случае вытесняющей RTOS будут больше, главным образом по расходу ОЗУ на стеки процессов. Но и только. На современных копеечных МК это вообще не проблема.

Цитата(Прохожий @ 8.1.2012, 21:30) *
4. Код короче, чем в Вашем случае поскольку я Вам предъявил заодно и реализацию, чего в Вашем случае не было.

Ваш код выглядит длиннее. И в целом будет длиннее, если в программе будет не один такой фрагмент. У меня же используются общие для всех частей программы механизмы RTOS. Футпринт RTOS, которую я использую составляет для MSP430 1.2K (из примера с тремя пользовательскими процессами) при 60К доступной флеши. При этом имеет полноценное приоритетное вытеснение и все плюшки в виде межпроцессного взаимодействия.

Цитата(Прохожий @ 8.1.2012, 21:30) *
Я думал, что у меня все очевидно.

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

Цитата(Прохожий @ 8.1.2012, 21:30) *
Естественно, все переменные - глобальные.

Ещё один недостаток - замусоривание глобального пространства имён. Такой простой код уже добавляет прилично мусора, что же там будет твориться в действительно большой программе?

Цитата(Прохожий @ 8.1.2012, 21:30) *
а драйвера - это тоже совокупность процессов, то моя основная забота - это HAL.

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

Цитата(Прохожий @ 8.1.2012, 21:30) *
С чего бы это? Расчет полиномов - это сплошная программа, оформленная в виде функции для повторного использования. Ее можно использовать и из автомата процесса.
Мне, честно говоря, не понятно - откуда у Вас такое заблуждение, про которое Вы говорите в цитируемом выше тексте?
С какой это радости мне нужно терпеть все мучения, описанные Вами?
Уверяю Вас. В реальности все гораздо проще.

Гуд. Изобразите ваш вариант насчёт этого полинома:
Код
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 мс пыхтел. smile.gif Но для программы это всё без прозрачно - пишешь код свободно, как хочешь, совершенно не напрягаясь насчёт времянок - главное, чтобы вычисления были завершены до определённого момента.

Цитата(Прохожий @ 8.1.2012, 21:30) *
А Вы уверены, что им всем нужны разные приоритеты?

Абсолютно. Это относительно большая программа, которая выполняет кучу задач от обслуживания обмена по сериальным протоколам, взаимодействие с ПЛИС, корректировка параметров видеотракта, управление исполнительными устройствами, сбор и обработка данных от датчиков (температура приёмника, углы наклона, клавиатура), GUI и ещё много всяких более мелких задач. Не вижу причин ограничивать себя в удобстве проектирования и создании читабельного и сопровождаемого кода.

Цитата(Прохожий @ 8.1.2012, 21:30) *
Микрочип на сегодняшний день - самая лояльная к потребителю контора с достаточно неплохой поддержкой.

Только это не характеризует уровень его достижений в МКстроении. Не вижу причин отдавать ему предпочтение на фоне TI, ADI и других фирм.

Цитата(Прохожий @ 8.1.2012, 21:30) *
Согласен со всеми тезисами. Добавлю еще, что у него очень приятная система команд, очень похожая на PDP11, но отсутствие бесплатной полновесной среды разработки перечеркивает для меня всю его привлекательность. Равно как и его улучшенному варианту.

А что вы понимаете под "полновесной" средой разработки?

Цитата(Прохожий @ 8.1.2012, 21:30) *
А если переписать Кернел?

Ну, это-то дело плёвое, не то, что осовить RTOS, общий объём сорцов которой составляет меньше сотни килобайт.

Цитата(Прохожий @ 8.1.2012, 21:30) *
Гы, винда - это первая ОС, где было введено понятие события. И осуществлено переползание с обыкновенного программирования к событийному.
А так, там все то же самое, что и в Ваших любимых RTOS. Обыкновенная вытесняющая ОС, с присущими ей достоинствами и недостатками.

Пардон. Вот у меня в текущем проекте время передачи управления (т.е. при возникновении события, через сколько времени ожидающий этого события код получит управление) составляет 1.5 мкс. Это на Blackfin @200MHz. И это время детерминировано. Детерминированность именно обеспечивается используемыми простыми механизмами. Какие времена даёт венда? Как они детерминированы? Да никак. Именно этим RTOS и отличается от просто OS.

Цитата(Прохожий @ 8.1.2012, 21:30) *
Я достаточно хорошо ознакомился с идеологией RTOS и понял, что мне на текущем этапе это не нужно.

Мои поздравления. smile.gif

Цитата(Прохожий @ 8.1.2012, 21:30) *
Еще раз повторю. Любой современный МК - сам себе RTOS.

Очень сильное заявление. smile.gif Наверное, чтобы разобраться в этом вопросе, нужно дать определение терминам - что такое "МК" и что такое "ОС". Тогда сразу станет ясно, на самом ли деле MK == OS.

Цитата(Прохожий @ 8.1.2012, 21:30) *
А сколько стоит нормальный софт разработчика с симулятором и приличной IDE? GNU не предлагать.

Это почему это? ГНУтые компиляторы очень приличны и по кодогенерации, и по поддерживаемым фичам языка. Отладчики тоже есть. Даже среда есть могучая - эклипс, которую не брезгуют брать за основу ведущие производители софта - IAR, Altera, Xilinx, NXP и многие другие. Уж не убожище ли MPLab вы хотите противопоставить? smile.gif

Цитата(Прохожий @ 8.1.2012, 21:30) *
Да, действительно есть. Но с NVIC от ARM я знаком давно. Просто не ассоциировал его и CORTEX-ы.
Но это бред, а не контроллер прерываний.
Это источник неисчислимых багов и загадок для программиста.
Как, впрочем, и весь ARM.
Как был студенческой поделкой, так ею и остается по сей день.
Кстати, у NVIC тоже всего 8 уровней приоритетов.
Вот беда...

Cortex-M - очень продуманная серия процессоров. При изучении документации постоянно ловлю себя на мысли, что люди, которые его спроектировали, прошли определённый путь, тут чувствуется школа. Вы как-то погорячились насчёт него, не разобрались. К сведению, сам по себе NVIC поддерживает до 250 уровней прерываний. Просто не во всех МК это количество реализовано, т.к. там просто не надо.
Прохожий
Во-первых, приношу свои извинения за те места, где был излишне эмоционален.
Перечитал нашу переписку и понял, что выгляжу не очень хорошо.
Еще раз извините...
Цитата(dxp @ 9.1.2012, 12:59) *
Отнюдь не так проста как кажется - особенно по сравнению с альтернативным вариантом, где три строчки линейного кода и больше ничео - ни таймеров, ни счётчиков, ни автоматов (во, сколько лишних сущностей на пустом месте). И это в таком простейшем примере.

Это базовые сущности. Они будут всегда.
Вне зависимости от примера.
Причем, с увеличением технической сложности примера, структура и сущности остаются.
Цитата(dxp @ 9.1.2012, 12:59) *
Что вы понимаете под скоростью? Поясните?. Скорость реакции на событие - например, timer expiration, в моём варианте будет лучше - процесс сразу получит управление по выходу из таймерного прерывания, это время предсказуемое. А как у вас это осуществляется, я так и не понял, извините. Накладные расходы в случае вытесняющей RTOS будут больше, главным образом по расходу ОЗУ на стеки процессов. Но и только. На современных копеечных МК это вообще не проблема.

В моем случае время реакции на простое событие - конец отсчета таймера - это время, необходимое МК для входа в обработчик прерывания (прерывание пипелайна и аппаратное сохранение контекста). В случае сложного события - когда этот таймер увязан еще на что-то - к этому времени добавляются простые логические операции. Все считается с точностью до такта.
Цитата(dxp @ 9.1.2012, 12:59) *
Ваш код выглядит длиннее. И в целом будет длиннее, если в программе будет не один такой фрагмент. У меня же используются общие для всех частей программы механизмы RTOS. Футпринт RTOS, которую я использую составляет для MSP430 1.2K (из примера с тремя пользовательскими процессами) при 60К доступной флеши. При этом имеет полноценное приоритетное вытеснение и все плюшки в виде межпроцессного взаимодействия.

Еще раз извините, но Вы пока еще не поняли сути подхода, о котором я рассказываю. Попытаюсь объяснить.
Заодно, отвечу и на эти вопросы:
Цитата(dxp @ 9.1.2012, 12:59) *
Вы описали логику работы, а я спрашивал не про это, а про то, как осуществляется передача управления. Т.е. когда таймер досчитал до нужного значения - тут нужно немедленно передать управление в основную программу - именно в тот автомат, который ждёт события. Как это осуществляется у вас? Поллингом? Или карусель в суперлупе?

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

Но на самом деле все очень просто. Если отойти в сторону от парадигмы непременной линейности кода, за которую Вы ратуете.
Каждый процесс представляется в виде автомата, иногда вырожденного, как в моем примере. И переход этого автомата из состояния в состояние осуществляется в прерываниях с действиями на переходах. Программа в этом случае может вообще не иметь суперлупа, а МК может переходить в спячку до следующего события.
Т. е. каждое событие, приписанное к данному процессу, вызывает условно мгновенную реакцию (за вычетом аппаратных издержек самого МК) этого процесса на это событие.
Вы можете законно возразить - действия на переходах могут быть очень долгими и обслуживание прерывания может затянуться.
В этом случае действие на переходе осуществляется в суперлупе. Т. е. в самом низкоприоритетном месте программы.
Которое всегда может быть прервано другими процессами, чьи события наступили в текущий момент времени.
Таким образом, процесс сам меняет приоритеты в зависимости от того, в каком состоянии он находится.
Вот более сложный пример, чтобы было понятно, о чем идет речь.
Нажмите для просмотра прикрепленного файла
Если пользоваться всеми возможностями современных контроллеров прерываний, то можно изменять приоритеты динамически.
Но лично я этого пока не делал. Но непременно буду - есть для чего.
При таком подходе скорость обслуживания событий максимальная и определяется в случае совпадения событий с прерыванием только аппаратными издержками МК.
Нет необходимости изучать дополнительную документацию по RTOS.
Документирование ведется на этапе проектирования.
А сами недостатки имеются и это:
Цитата(dxp @ 9.1.2012, 12:59) *
Ещё один недостаток - замусоривание глобального пространства имён. Такой простой код уже добавляет прилично мусора, что же там будет твориться в действительно большой программе?

не самый главный.
Я вообще не заморачиваюсь насчет глобальных переменных.
Памяти в современных МК более, чем достаточно.
И документирование при таком подходе - вещь отработанная.
Цитата(dxp @ 9.1.2012, 12:59) *
Извините, вот это (выделенное) я никак принять не могу. Драйвер - это программный код, предназначенный для абстрагирования управления аппаратурой от конкретного устройства аппаратуры. К процессам, потокам выполнения программы это не имеет ни малейшего отношения. Драйвера прекрасно живут в окружении, где может быть вообще только один поток выполнения.

Правильно. Но при работе даже одного потока пользователя, драйвера обязаны работать во всей свое совокупности. Т. е. реально имеем выполнение нескольких задач одновременно. Просто драйвера лежат ниже уровня HAL и Вы эти задачи не видите.
А когда между человеком и железом МК никого нет, то достигать нужного уровня приходится самостоятельно.
Поверьте, мне тоже неудобно смешивать низ и верх. Поэтому я и стремлюсь к их разделению.
Цитата(dxp @ 9.1.2012, 12:59) *
Гуд. Изобразите ваш вариант насчёт этого полинома:
Код
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.
Цитата(dxp @ 9.1.2012, 12:59) *
У меня в программе он именно так и реализован, я голову не грею себе...

Дык, и я тоже.
Цитата(dxp @ 9.1.2012, 12:59) *
Абсолютно. Это относительно большая программа, которая выполняет кучу задач от обслуживания обмена по сериальным протоколам, взаимодействие с ПЛИС, корректировка параметров видеотракта, управление исполнительными устройствами, сбор и обработка данных от датчиков (температура приёмника, углы наклона, клавиатура), GUI и ещё много всяких более мелких задач. Не вижу причин ограничивать себя в удобстве проектирования и создании читабельного и сопровождаемого кода.

Без всяких шуток. А Вы на людях эксперименты проводили? Давали посмотреть свой код кому-нибудь еще?
Ведь читаемость и сопровождаемость - понятия относительные и очень субъективные.
Поверьте человеку, который вынужден сопровождать кучу разных девайсов, в том числе и программных.
Разница есть и существенная.
Цитата(dxp @ 9.1.2012, 12:59) *
Только это не характеризует уровень его достижений в МКстроении. Не вижу причин отдавать ему предпочтение на фоне TI, ADI и других фирм.

ADI - это кто? Гугель на вскидку дает это.
Я с Вами соглашусь, когда среды разработки будут бесплатными.
Цитата(dxp @ 9.1.2012, 12:59) *
А что вы понимаете под "полновесной" средой разработки?

1. Наличие адекватного симулятора.
2. Наличие удобной IDE. Никаких make файлов (только по запросу, если сильно кому надо).
3. Наличие удобных дебуггеров.
Цитата(dxp @ 9.1.2012, 12:59) *
Ну, это-то дело плёвое, не то, что осовить RTOS, общий объём сорцов которой составляет меньше сотни килобайт.

Вы меня не поняли. Среда CoDeSys в варианте TwinCat, с которой я имею дело, как простой юзер, перегружает Кернел, как в Винде, так и в Линуксе.
При этом софт-PLC на основе любого либо x-86, либо ARM работает в реал тайме.
Его жесткость можете оценить самостоятельно, если хотите - дам ссылку на первоисточник.
В моем варианте это PC от Beckhoff и их же удаленка на ProfiBus-е.
Для линии, упаковывающей по 300 пачек сигарет в минуту вполне хватает.
Цитата(dxp @ 9.1.2012, 12:59) *
Пардон. Вот у меня в текущем проекте время передачи управления (т.е. при возникновении события, через сколько времени ожидающий этого события код получит управление) составляет 1.5 мкс. Это на Blackfin @200MHz. И это время детерминировано. Детерминированность именно обеспечивается используемыми простыми механизмами. Какие времена даёт венда? Как они детерминированы? Да никак. Именно этим RTOS и отличается от просто OS.

Ого! Целых 300 команд. Расточительно, однако.
Цитата(dxp @ 9.1.2012, 12:59) *
Очень сильное заявление. smile.gif Наверное, чтобы разобраться в этом вопросе, нужно дать определение терминам - что такое "МК" и что такое "ОС". Тогда сразу станет ясно, на самом ли деле MK == OS.

Скажу как художник художнику. Я так вижу! biggrin.gif
Цитата(dxp @ 9.1.2012, 12:59) *
Уж не убожище ли MPLab вы хотите противопоставить? smile.gif

Не такое оно и убожище. Всегда можно сделать лучше - это понятно.
С Эклипсом дело имел очень мало в варианте от ARM-KEIL.
Честно скажу, не увидел в нем ничего особо выдающегося.
Может быть я его готовить не умею?
Цитата(dxp @ 9.1.2012, 12:59) *
Cortex-M - очень продуманная серия процессоров. При изучении документации постоянно ловлю себя на мысли, что люди, которые его спроектировали, прошли определённый путь, тут чувствуется школа. Вы как-то погорячились насчёт него, не разобрались. К сведению, сам по себе NVIC поддерживает до 250 уровней прерываний. Просто не во всех МК это количество реализовано, т.к. там просто не надо.

Я очень давно приглядываюсь к ARM. Может быть там все так и есть, как Вы говорите. Но у меня есть рад вопросов к архитектуре ядра и к NVIC, на которые вразумительных ответов в документации я не нашел. Качество самой документации от ARM - очень низкое. По крайней мере на Thumb2.
В отличие от...
Но это выходит за рамки применения RTOS. Если хотите, можно сделать отдельную тему - "Изучаем/Применяем ARM Cortex М".
Idle
Цитата(Прохожий @ 9.1.2012, 18:34) *
ADI - это кто?

скорее всего Analog Devices, Inc. (NYSE: ADI)

dxp
Цитата(Прохожий @ 9.1.2012, 20:34) *
В моем случае время реакции на простое событие - конец отсчета таймера - это время, необходимое МК для входа в обработчик прерывания (прерывание пипелайна и аппаратное сохранение контекста). В случае сложного события - когда этот таймер увязан еще на что-то - к этому времени добавляются простые логические операции. Все считается с точностью до такта.

Так при выходе из прерывания таймера, когда счётчик досчитал до нужного значения и состояние автомата обновилось, поток выполнения куда попадает?

Цитата(Прохожий @ 9.1.2012, 20:34) *
Еще раз извините, но Вы пока еще не поняли сути подхода, о котором я рассказываю. Попытаюсь объяснить.
Заодно, отвечу и на эти вопросы:

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

Спасибо за экскурс, с удовольствием бы послушал лет 15 назад, а сегодня уже не актуально. Хочется на конкретные вопросы получить конкретные ответы, а не пространные рассуждения, уж простите.

Цитата(Прохожий @ 9.1.2012, 20:34) *
Но на самом деле все очень просто. Если отойти в сторону от парадигмы непременной линейности кода, за которую Вы ратуете.

А зачем от неё отходить? Это и была цель - сделать написание кода простым и прозрачным, без видимых ветвлений и явных "завязок" на конкретные прерывания.

Цитата(Прохожий @ 9.1.2012, 20:34) *
Каждый процесс представляется в виде автомата, иногда вырожденного, как в моем примере. И переход этого автомата из состояния в состояние осуществляется в прерываниях с действиями на переходах. Программа в этом случае может вообще не иметь суперлупа, а МК может переходить в спячку до следующего события.

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

Цитата(Прохожий @ 9.1.2012, 20:34) *
Да нет проблем.
Кусок из пресловутого терморегулятора:
Код
float t;
char i;
...
switch (ThermoType)
{
<...>    }
    break;
............
Ну и так далее для остальных типов термопар.

Здесь е - нормализованное значение термо ЭДС, ThermoType - номер типа термопары.
t - температура.
R0, R1, R2, R3 - массивы коэффициентов полиномов для каждого из диапазонов термо ЭДС для термопары типа R.

Что-то у нас с вами как-то не ладится взаимопонимание. Я вам про Фому, вы мне про Ерёму. Я вас просил показать реализацию вычисления полинома - так, чтобы оно не мешало работе с периферией, которая не будет ждать. Вы мне какой-то левый код обработки термодачтиков. Покажите реализацию предъявленного полинома, чтобы его вычисление не мешало приёму и отправке пакетов байтов через UART на скорости 9600 бод.

Цитата(Прохожий @ 9.1.2012, 20:34) *
Без всяких шуток. А Вы на людях эксперименты проводили? Давали посмотреть свой код кому-нибудь еще?
Ведь читаемость и сопровождаемость - понятия относительные и очень субъективные.

Конечно. У нас целое семейство проектов, где большая часть кода просто заимствована. Работают разные люди. Нареканий нет. То, что RTOS позволяет формализовать подход в организации потока выполнения программы, оказывается очень кстати при работе в команде.

Цитата(Прохожий @ 9.1.2012, 20:34) *
ADI - это кто? Гугель на вскидку дает это.

Нет, это Analog Devices Inc.

Цитата(Прохожий @ 9.1.2012, 20:34) *
Я с Вами соглашусь, когда среды разработки будут бесплатными.

Их есть.

Цитата(Прохожий @ 9.1.2012, 20:34) *
1. Наличие адекватного симулятора.

А это-то зачем, когда щас в любом проце эмулятор имеется?

Цитата(Прохожий @ 9.1.2012, 20:34) *
2. Наличие удобной IDE. Никаких make файлов (только по запросу, если сильно кому надо).

Как всё запущено. smile.gif Я так скажу - такие IDE фтопку! Кроме шуток. Они хороши для тотальных бегиннеров или только для того, чтобы быстро попробовать. Для серьёзной работы рулит хороший программерский редактор + система сборки (make или что-то иное (у меня SCons)).

Цитата(Прохожий @ 9.1.2012, 20:34) *
Ого! Целых 300 команд. Расточительно, однако.

Не команд, а тактов. У этого процессора контекст большой - 180 байт. Но полторы микросекунды не напрягают совершенно. Проц, кстати, без проблем может работать на 500 МГц, просто мне это не надо, электроэнергию экономлю, а успевает он со свистом и на 200 МГц.

Цитата(Прохожий @ 9.1.2012, 20:34) *
Честно скажу, не увидел в нем ничего особо выдающегося.
Может быть я его готовить не умею?

Очень гибкая среда, всё позволяет настроить. Правда, надо с системами сборки дружить, хотя бы на уровне базовых принципов. Минус для меня был - тормознутая она весьма, во всяком случае была года полтора назад, когда я её щупал. Поэтому до сих пор сижу на слике.
MrYuran
Цитата(dxp @ 10.1.2012, 10:18) *
Покажите реализацию предъявленного полинома, чтобы его вычисление не мешало приёму и отправке пакетов байтов через UART на скорости 9600 бод.

Попробую угадать: автомат, расположенный в прерывании UARTа.
Я с этого начинал 6 лет назад, и постепенно отказался в пользу карусельного поллинга в суперлупе.
При всех сопутствующих издержках, получается структурнее, более предсказуемо и переносимо (даже из проекта в проект).
Ну и естественно, (RT)OS - следующий логический шаг на пути к всеобщей гармонии и стандартизации.
Это правильно подмечено, что общая платформа в виде RTOS дисциплинирует и приводит к общему знаменателю разношерстный мелкопрограммерский коллектив.
Кстати, тоже сейчас на МСП сидим, но уже в глубоких раздумьях по поводу STM32.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2020 IPS, Inc.