Форум РадиоКот

ПростоНуб писал(а):Но может зависеть от бесконечного количества входных чисел.

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

Demiurg писал(а):Пользуйтесь и радуйтесь красоте кода...

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

1. я описываю структуру, в которой есть строка-идентификатор и функция обработчика
2. я собираю множество таких структур в "массив"
3. когда я принял строку, я перебираю этот массив, сравнивая принятую строку с идентификатором в каждой записи массива, и если нахожу совпадение - вызываю соответствующий обработчик.

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

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

По теме "Вытесняющая многозадачная ОС. Практика AVR."
Тема не раскрыта Знающие, пожалуйста, приведите пример реальной программы на ОС, желательно с дисплеем (хотя бы на символьном или графическом) меню, и каким нибудь датчиком, к примеру ds18b20.
Сам когда то уперся в то, что не понял как создать структуру программы на ос. Как оформить пользовательский интерфейс и т.д. Понять принцип распределения на процессы, и допустим в программе, должно быть много процессов, на каждый выделять процесс ОС нельзя из-за ограничений по ОЗУ, как быть в этом случае? Может есть пример сложной программы на ОС, а не мигания светодиодами и передачей сообщений?

[uquote="DimAlt",url="/forum/viewtopic.php?p=3582771#p3582771"]Тема не раскрыта Знающие, пожалуйста, приведите пример реальной программы на ОС, желательно с дисплеем (хотя бы на символьном или графическом) меню, и каким нибудь датчиком, к примеру ds18b20.[/uquote]
на AVR, ввиду ограниченности ресурсов, лепили собственные реализации, например - тини13:

я использовал несколько новых для себя приемов программирования. В устройстве реализован полнодуплексный программный UART (прием и передача ведутся параллельно, независимо друг от друга) и, как бы это не странно звучало, полнодуплексный IR приемо-передатчик (при передаче IR сигнала передающее устройство принимает свою посылку). Для того чтобы заставить все это дело работать совместно и независимо друг от друга на одном 8-ми битном таймере (и не сломать себе голову при реализации этого) пришлось соорудить нечто наподобие операционной системы реального времени (RTOS).

http://www.getchip.net/posts/079-ir-udl ... -attiny13/
примеров применения "взрослых" RTOS на AVR не встречал. На немножко более продвинутых микроконтроллерах встречается, например и с дисплеем и ds18b20 и пр.:

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

http://cxem.net/mc/mc395.php

oleg110592 писал(а):примеров применения "взрослых" RTOS на AVR не встречал

все-таки как быстро меняется в жизни всё... каких-то 30 лет назад М6000 с ОЗУ 4К и быстродействием порядка 400000 пересылок память-память обеспечивала в реальном времени работу 16 пользовательских терминалов, а вот для AVR c таким же объемом ОЗУ и быстродействием в 20 раз больше RTOS не нашлось...

это так, просто риторическое восклицание в пустоту...

М6000 у нас были завязаны в 5-ти машинный комплекс.))) Некоторые протянули до 2000-х годов! Так что даже не 30, а всего каких то 20!)

М-6000 выпускалась 5 или 6 заводами тысячами штук в год и составляла основу автоматизации технологических процессов от стартовых комплексов до угольных шахт.

Машины уже начиная с самой первой имели до 64 и 256 уровней (векторов) прерывания и время реакции на прерывание 5 мкс, что до сих пор является недостижимым пределом для современных Intel и AMD машин, которые, как ни крути, продожают оставаться калькуляторами, вместе с вистой и прочими так называемыми ОС.

В ОС АСПО был жестко реализованный принцип отделения системных вызовов, команд оператора, управления задачами, распределения ресурсов ЭВМ друг от друга и от прикладных задач, причем все компоненты ОС описывались гарантированными алгоритмами, что позволяло строить "неубиваемые" системы. Некоторые работают до сих пор в режиме 24х7х365, стоя в контуре управления серьезными процессами, и заменить их - нечем.

у AVR нету 64 и 256 уровней (векторов) прерывания

поскольку такого количества прерываний и их уровней и сейчас мало у кого есть, если верить цитате, то не это является ограничением... наверное.

Есть рядовое ядро кортекс м3 для микроконтроллеров. Управление и обработка прерываниями производится контроллером приоритетных векторных прерываний NVIC (Nested Vectored Interrupt Controller).
"The NVIC supports up to 240 dynamically reprioritizable interrupts each with up to 256 levels of priority":
http://infocenter.arm.com/help/index.js ... FCFDB.html
STM32F103 поле приоритета 8-ми разрядное, правда используется только старшие 4 бита. Образуя таким образом 16 уровней приоритетов.

Еще "ОС АСПО был жестко реализованный принцип отделения системных вызовов, команд оператора, управления задачами, распределения ресурсов ЭВМ друг от друга и от прикладных задач"

В ядре кортекс еще всегда есть однообразный системный таймер систик и в системе команд есть команда программного прерывания SVC.
Команда SVC используется для вызова сервисов операционной системы из прикладных программ. Конкретный способ организации связи между программой и ОС определяется разработчиком ОС.
SVC является одной из многих функций, предоставляемых процессором ARM Cortex-M для поддержки RTOS. Аналогично, исключение PendSV - это еще одна функция поддержки ОС.

FreeRTOS, популярная RTOS во эмбед мире, использует SVC для запуска первой задачи. При запуске первой задачи ядро ​​во FreeRTOS выполняет инструкцию SVC с параметром ноль - svc 0 . На самом деле этот параметр больше не используется, поскольку FreeRTOS не использует SVC для каких-либо других целей. Однако при использовании SVC обязательно передавать значение параметра. Затем код обработчика SVC загружает данные стека первых задач из памяти в область стека. Он также изменяет возвращаемое значение исключения так, что при выходе из обработчика SVC первая задача затем начинает выполняться. Последующее переключение задач выполняется другим исключением PendSV.
RTX - встроенная ОС от ARM / Keil использует SVC с разными параметрами для выполнения разных задач. Он использует SVC для инициализации ядра, приостановки или возобновления работы ядра или получения состояния ядра и т. д.

Уровни выполнения привилегированного и непривилегированного программного обеспечения - важная особенность ARM Cortex-M. Разделение уровней доступа вместе с механизмом SVC делает ARM Cortex-M мощным кандидатом для ОСРВ и других сложных систем.

преимущества, предлагаемые SVC

1)Этот механизм делает встроенную систему более надежной и безопасной. Приложение не может получить несанкционированный доступ к критически важным аппаратным ресурсам.
2)Это помогает разработчику сосредоточиться на коде приложения, не беспокоясь о точном адресе функций службы ОС. Нужно только знать номер требуемого сервиса и любые дополнительные параметры, передаваемые обработчику SVC.
3)Это помогает разрабатывать задачи приложения независимо от операционной системы. Прикладные задачи не должны знать механизм и детали программирования базового оборудования.

Команду SVC можно использовать без ОС, пример тут:
https://www.youtube.com/watch?v=J2ke8DDibfA
В сочетании с систиком можно сделать простейшую ОС.
Еще недавнее с сахары:

Забавный факт о кортексах. Блок NVIC умеет вызывать прерывание программно, что позволяет делать всякое. Например в таблице прерываний есть секции, помеченные как unused - эти векторы можно использовать в качестве пользовательских прерываний!
Ничего не мешает вам использовать векторы, занятые неиспользуемой периферией для себя))
Привет аппаратный механизм сигналов и слотов!
Примечание: за физические пределы таблицы прерываний выходить не получится, отрезаны ещё на этапе сборки ядра.

oleg110592 - перечитайте заголовок темы, чтобы не скатиться на сами знаете что...

а что не так? M6000 обсуждаем - не я первый начал. Обсуждаем "Вытесняющая многозадачная ОС". "Практика AVR" вроде пока не задалась.

как бы вы посоветовали разделить относительно долгий процесс работы с множеством датчиков типа DS18x20 на "кооперативно-многозадачный" алгоритм?

то есть ситуация такая: есть 8 датчиков, и опрос их всех занимает порядка 100 мс (округляю). хочется, чтобы 1 раз в секунду происходил их опрос и делалась какая-то обработка результата, по итогам которой включались или выключались соответствующие 8 реле. хотелось бы, чтобы все реле включались-отключались одновременно, одной командой вывода в порт. не знаю, зачем... наверное, чтобы можно было гарантировать, что "измерение температуры и принятие решения о включении реле происходит с заданной пользователем периодичностью". типа, между отдельными каналами нет "джиттера"

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

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

наконец, можно каждую секунду измерять и изменять состояние только одного канала... тогда прощай "четкая периодичность"...

вероятно, есть и иные варианты?

что бы вы мне посоветовали?

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

В первую очередь это зависит от того, какие ещё функции выполняет микроконтроллер помимо опроса датчиков. Сколько времени занимает опрос одного датчика. Как выводится информация: на дисплей, какого типа дисплей. ЖКИ, семисегментные индикаторы; либо по интерфейсу. Если есть критические по времени операции, тогда опрос датчиков лучше сделать на отдельном микроконтроллере.

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

Опрос 8 датчиков занимает порядка 100 мс, т.е. один датчик, грубо говоря, 12,5 мс опрашивается. Информация не выводится постоянно (только по запросу в виде текстовой строки), постоянно происходит анализ температур и управление релюшками.

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

И с минусами давайте поаккуратнее. Как дети, мля... Пожмите друг-другу руки, уберите всё за собой и улыбнитесь.
"Ребята, давайте жить дружно !" (с) Кот Леопольд.

[uquote="ARV",url="/forum/viewtopic.php?p=3584504#p3584504"]Отдельный микроконтроллер - это не наш метод [/uquote]

Много лет назад один человек мне сказал, что радиоэлектроника это ремесло. Тогда я с ним не согласился. А не так давно я согласился с его высказыванием, и понял, что он этим хотел сказать. Прежде всего я хотел бы указать на то, что вы сами себя ограничиваете.
1 - Красивость кода. Вы уперлись в красивость кода. В ущерб целесообразности. Потеряли на этом кучу времени. Автоматы, не автоматы не суть. Да, вы вроде решили проблему. Написали программу. Будущие проекты покажут ваш подход. Годен, не годен. Почему я настаивал на КА, потому что этот подход применим во всех моих проектах. Как я уже говорил, спор насчет КА закончен. У меня своя область, у вас своя, возможно вам действительно нужен другой подход.
2 - "Не наш метод". Уже много лет используют такой подход. Отдельный модуль термодатчиков со своим МК. Сразу пример, пусть у вас семисегментные индикаторы. Это динамическая индикация. И вы не сможете реализовать одновременно динамическую индикацию и зацикливание программы на время большее, чем переключение сегментов-общих анодов, катодов. Лично я смог реализовать динамическую индикацию в ОСНОВНОМ ЦИКЛЕ. Не на прерываниях. Итерация основного цикла у меня выполняется с запасом за 1 мс. Дробление процессов.

P.S. Опрос датчиков можно реализовать так: пусть время опроса одного датчика 12,5 мс. Ставим программный таймер, скажем на 15 мс. И в каждой итерации по очереди делать опрос. Полный цикл займет 15 * 8 = 120 мс

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

у меня вопрос концептуальный, с реализацией выбранной концепции я разберусь сам.

я вижу несколько вариантов концептуальной реализации работы с датчиками:
1. опрос датчиков в фоне с периодом, который определяется их параметрами, и накопление результатов в промежуточном массиве. а обработку делать уже с другим периодом (заданным пользователем) по значениям из массива.
2. опрос всех датчиков делать с периодом, заданным пользователем, и сразу делать обработку.
3. опрос и обработку вести по одному датчику.

достоинства подходов:
1. независимость обработки от поступления интформации с датчиков, т.е. можно соблюсти идеально периодичность обработки, как захотел пользователь.
2. четкая взаимосвязь моментов принятия решения (обработки) с моментом поступления информации с датчиков.
3. минимальная загрузка "ядра" программы, т.к. опрос одного датчика занимает минимум времени.

недостатки подходов:
1. разрыв между моментом измерения и моментом принятия решения.
2. относительно долгий процесс обработки всех 8-и датчиков (100 мс)
3. невозможность обеспечить заданный пользователем интервал опроса датчиков с высокой точностью.

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

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

Добавлено after 2 minutes 1 second:

Аlex писал(а):их можно вообще повесить на отдельные пины целого порта и опрашивать одновременно. Вот вам и быстродействие и одновременность.

я и так их повесил на пины одного порта... только вот с одновременностью не очень: если работать ПАРАЛЛЕЛЬНО со всем сразу, обработка получается слишком сложной, хотя... в этом направлении, вероятно, стоит подумать подольше

Добавлено after 38 minutes 7 seconds:
пока вопрос про датчики в стадии обдумывания, поделюсь немного своими достижениями в плане RTOS, а точнее, в получающейся у меня кооперативной ОС.

концептуально у меня получается event-driven система, т.е. диспетчер "процессов" у меня работает путем разбора очереди поступающих событий.
событие может генерироваться прерыванием или другим процессом.
процесс, само собой, это просто функция без больших циклов, уж точно без бесконечных циклов.
дополнительно к прерываниям есть и ранее описанная система таймеров, которая тоже может генерировать сообщения.
если в очереди в текущий момент нет сообщений (в RTOS такое называется состоянием Idle), у меня работает система "отложенных действий" - это мое очередное "изобретение"
в чем его смысл? допустим, возникла необходимость отправить СМС, а по каким-то причинам GSM-сеть отвалилась. ну, представим себе на минуту, что это так, хотя для стационарного устройства это достаточно редкое явление. что делать в этом случае? event-driven система, теоретически, обнаружив ситуацию, когда обработать событие невозможно, может посылать его сама себе снова и снова, в надежде, что когда-нибудь... ну вы поняли. но в этом случае очередь сообщений будет засрана бесполезными сообщениями, что блкирует работу полезных. можно, конечно, ставить какие-то флаги, а потом по таймеру эти флаги отслеживать... ну и т.д.
я же решил все это упростить. у меня есть "очередь" отложенных действий, т.е. массив структур, где хранятся функции, которые надо вызывать, если больше делать нечего (Idle). функция может вернуть true - и это будет означать, что она свое дело сделала, и больше вызывать её не надо (в этом случае она удаляется из списка). если же она вернула false - она остается в списке и вызывается снова и снова.
так вот, в ранее описанном случае отправки СМС я помещаю в список отложенных функцию, которая тупо пытается отправить СМС и возвращает результат этой отправки (на самом деле я делаю чуть иначе, но для простоты описания пусть будет так). и это означает, что если в очереди сообщений нет других сообщений, моя программа пытается отправить СМС, пока, наконец, не сумеет это сделать (т.е. как только сеть восстановится - так сразу и оправит). но если в очереди есть сообщение - оно приоритетно обработается.

поскольку в моей системе много устройств, которые могут либо быть готовыми, либо быть неготовыми, и заранее невозможно предсказать, когда готовность/неготовность появится, система "отложенных" действий помогает разрулить это вполне красиво, как мне кажется...