Задача: проблесковый маячок с сигналом SOS.

[Dale]

В телекоммуникациях еще SDL любят использовать. Особенно всякие Голдштейны. Перекрывает "деятельность" в UML.

Так ведь у SDL и UML общий создатель - Айвар Джейкобсон:

В сущности, этот подход использовал то, что мы называем сегодня разработкой, основанной на компонентах. Создателем этого метода был Ивар Джекобсон (Ivar Jacobson). Он руководил этим развитием процесса разработки программного обеспечения в течение многих лет - до периода Objectory.

Язык спецификации и описания

В тот период важнейшим делом стало издание в 1976 году CCITT, международным органом по стандартизации в области телекоммуникаций, Языка спецификации и описания (SDL) функционального поведения телекоммуникационных систем. Этот стандарт, оказавший важное влияние на подход фирмы Эрикссон, определяет систему в виде набора связанных блоков, которые общаются друг с другом исключительно путем обмена сообщениями (названных в стандарте "сигналами"). Каждый блок владеет набором "процессов" (это термин SDL для активных классов). Процесс имеет множество экземпляров, подобно классу в терминологии объектно-ориентированного подхода. Экземпляры процесса обмениваются сообщениями. Рекомендованы диаграммы, специализации которых в UML называются диаграммами классов, диаграммами деятельности, диаграммами кооперации и диаграммами последовательностей.

Итак, SDL был специализированным стандартом объектного моделирования. Периодически обновляемый, он использовался более чем 10 000 разработчиками и поддерживался некоторыми поставщиками утилит. Изначально разработанный более 20 лет назад, он далеко опередил свое время. Однако он был разработан в те времена, когда объектное моделирование было еще не развито. SDL был вытеснен Унифицированным языком моделирования, Unified Modeling Language, который прошел стандартизацию в ноябре 1997 года.

(выделение мое).

http://citforum.ru/book/unifpo/unifpo_pr.shtml

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

[RXL]

Дим, потребление AVR в активном режиме сравнимо с потреблением одного светодиода. Тут же явно одним светодиодом не обойдется.

[Dale]

болтун (ковыряюсь в носу и достаю пачечку попкорна )

Эти сухопутные крысы, эти пресноводные моллюски пытались протолкнуть фуфло вместо маяка, фор-бом-брамсель им в глотку! Не на того напали.

"Мне не нравится этот маяк, сэр".

[RXL]

Если я правильно понимаю, основной задачей у нас стоит создание "дубового" устройства?

[Dale]

Если я правильно понимаю, основной задачей у нас стоит создание "дубового" устройства?

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

[Dimka]

Дим, потребление AVR в активном режиме сравнимо с потреблением одного светодиода.

Ну ладно.


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

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

[Dale]

В целом, с использованием protothreads (как плоская запись конечного автомата) задача получается несложная.

Автомат классический.
...
А многопоточность тут к этой задаче за уши притянута.

Итак, в чистом итоге имеем:

• автомат, поэтому потоки нужны;
• автомат, поэтому потоки не нужны.

Интересно, третье мнение будет (типа воздержался)?

– Да не согласен я.
– С кем? С Энгельсом или с Каутским?
– С обоими.

[RXL]

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

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

[Dale]

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

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

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

[RXL]

Предлагаю экономию отложить до следующего раза.

[Dale]

Предлагаю экономию отложить до следующего раза.

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

[Sla]

Возни много, результат неощутим.

Ощутим...
Срок службы девайса от автономного питания - 1год.
Девайс сейчас считает расход воды и отправляет данные по GPRS.
Если бы не спал - месяц.

[RXL]

Слав, по условию у нас солнечная батарея есть. В случае особо пасмурной погоды панель даст 10-20 Вт/м^2 в течении 8-10 часов. При ясной погоде батарея выдаст в 10 раз больше! Т.е. для роскошества в виде 10 мА при 5 В нам нужна панелька (24/8) * (5 * 0.01)/10 = 0.015 м^2 = 1.5 дм^2.

[Dale]

Даже древняя Mega16 без современных наворотов потребляет 12 мА в активном режиме. Это ток двух не слишком ярких светодиодов. Он попросту потеряется на фоне потребления наших индикаторов. Более современные микросхемы еще экономнее.

P.S. Впрочем, при желании добавить режим экономии вполне можно позже. Гораздо проще правильно работающее устройство сделать экономным, чем экономное заставить работать правильно. Исходя из этого и определяем приоритеты.

[Dimka]

Итак, в чистом итоге имеем:
автомат, поэтому потоки нужны;
автомат, поэтому потоки не нужны.

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

Задачу можно решить, спроектировав автомат без потоков, но нельзя решить, спроектировав независимые потоки без синхронизации (т.е. общего, объемлющего их алгоритма или автомата). При использовании потоков в данном решении неизбежно возникают точки прерывания потоков, потому что есть зависимости от внешних сигналов. Но прерывания потоков на синхронизацию, вообще говоря, нивелируют саму идею параллелизма. Единственное, что в таких условиях даёт поток - возможность написания в рамках одной функции сценария прохождения состояний автомата с локальными переменными потока в качестве хранилища состояния автомата. Т.е. синтаксический сахар, слабо отличающийся от реализации простого автомата в одной функции с большим switch внутри. Это хорошо ровно до тех пор, пока сценарий тривиален (как в данном случае). Как только сценарий усложняется, или возникают различные сценарии, стартующие и завершающиеся в разных точках графа состояний, такая монолитная функция "алгоритма работы" превращается в трудно сопровождаемый ад, возникают потребности в декомпозиции. Прекрасно, когда такая декомпозиция возможна на "подавтоматы" - тогда тривиально выделить "подпотоки", но усложняется диспетчер потоков, поскольку жизненный цикл дочерних потоков ограничен тем или иным состоянием родительского, т.е. это не простая схема с фиксированным количеством "вечных" потоков. А если независимые "подавтоматы" не выделяются, то большой нечитабельный "спагетти" из многочисленных условий и циклов с copy-paste в разных местах одинаковых условных выражений, гарантирован.

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

[RXL]

Dimka, точнее так: protothreads позволяет:
1. Реализовать на Си линейную запись кода, который после препроцессора превращается в код автомата.
2. Благодаря п.1 прозрачно реализуется кооперативная многозадачность.

http://www.sics.se/~adam/dunkels05using.pdf
http://www.sics.se/~adam/dunkels06protothreads.pdf
Дим, ты изучал данный вопрос (protothreads)?

[Dimka]

RXL, я против этого ничего не имею. Но, во-первых, считаю это второстепенным вопросом. Во-вторых, у этого подхода есть ограничения по сложности в части кооперативного взаимодействия. Поскольку в этой мигалке сложностей достаточного уровня нет, то "во-вторых" можно не учитывать.

На уровне "принципиальных схем" (хоть на том же UML) это будет выглядеть классическим автоматом - состояния и переходы (может диаграммы деятельности, правда, тут сложных алгоритмов нету). Остальное - особенности записи в той или иной среде разработки.

[RXL]

Взаимодействие потоков распространяется итеративно. Разве в реальной многозадачности это не так?

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

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

[Sla]

Предлагаю дискуссию прекратить.

Напоминаю!
Решения предлагаются без обсуждений.
Я думаю, что топик может быть активным еще до понедельника.
В понедельник его закрыть.

За неделю обработать (выделить) предложения, а уж потом ...

[Dale]

Предлагаю дискуссию прекратить.

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

Напоминаю!
Решения предлагаются без обсуждений.

Я бы поставил вопрос шире.

Во-первых, напоминаю, что центральная тема по-прежнему остается той, что задал Sla:

Прошу прощения, для тех кто не понял для чего это.

Эта задача выросла из моего предложения

Предлагаю сделать топик, где
Будет поставлена задача

Мигание светодиода, нажатие кнопок и прочее
Определены условия  - возможности железяки

Заслушать мнения и решения без обсуждений.

...
Это нужно для будущей статьи в продолжение Hello Word на микроконтроллерах
чтобы показать как писать софт, как писать тесты, как проводить отладку и прочее.

Поэтому в первую очередь приветствуются интересные задачи, которые могли бы стать темой для продолжения цикла. Я привел лишь один пример, первый попавшийся. Основные требования к задаче:

• Устройство должно иметь хорошо различимые аудиовизуальные эффекты (световые индикаторы, зуммеры-пищалки и пр.), позволяющие легко убедиться в действительной параллельности нескольких задач бес специального оборудования (JTAG-отладчиков, осциллографов, логических анализаторов и т.д.). Короче говоря, чтобы по итогам можно было снять небольшой видеоролик, на котором видно, что девайс работает.
• Аппаратура должна иметь разумную сложность. Сейчас у меня на плате прототипа установлен контроллер с 16К флеш-памяти программ, 1К ОЗУ и 512 байтами энергонезависимой памяти. Без проблем могу прицепить к нему несколько светодиодов разного цвета, кнопок, пьезопищалку. В принципе могу еще добавить текстовый ЖК дисплей (2 строки по 16 литер) и клавиатурную матрицу вроде телефонной (0-9, *, #). Переход на более мощный контроллер нежелателен, но в принципе возможен, если задача будет того стоить.
• Программная реализация функций устройства также должна быть по возможности несложной. Основной фокус будущей статьи направлен не на реализацию сложных функций, а на организацию вычислительного процесса.

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

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

Требования к соавторам: умение и, главное, желание конструктивно поработать. Писатели клуджей не приветствуются, флудогенераторы категорически не приветствуются. Остальные - добро пожаловать.

[Dimka]

Взаимодействие потоков распространяется итеративно. Разве в реальной многозадачности это не так?

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

В реальной многозадачности так. Но чем "толще" логика синхронизации, тем слабее реальность многозадачности.

Предлагаю дискуссию прекратить.

То у нас с Ромой не дискуссия, то "прояснение моментов". Рома хочет protothread для мигалок - без вопросов. Я лишь отмечаю граничные условия, если вместо мигалок представить что-то более сложное.

Это нужно для будущей статьи в продолжение Hello Word на микроконтроллерах
чтобы показать как писать софт, как писать тесты, как проводить отладку и прочее.

Дело, конечно, благое, но, вообще говоря, ещё не было обсуждения Hello World в 7-и томах. Я пока ожидаю окончания публикации - неправильно обсуждать содержательную часть в закрытом для посетителей разделе. А так, вообще говоря, готовится отзыв в духе В.Г.Белинского "Взгляд на русскую литературу"

[Dale]

Я пока ожидаю окончания публикации - неправильно обсуждать содержательную часть в закрытом для посетителей разделе. А так, вообще говоря, готовится отзыв в духе В.Г.Белинского "Взгляд на русскую литературу"

Да уж, блестящая перспектива... Можно, пока не поздно, попросить взамен что-нибудь в духе Дейкстры или Кнута? Честное слово, я не заслужил столь изощренной пытки Белинским. Пусть уж он лучше порезвится в другой теме, благо места хватает.

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

[Sla]

на вскидку

программный ШИМ
i2c
rs232/485
динамическая индикация
Цап/АЦП
Сухой контакт

[Dale]

на вскидку

программный ШИМ

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

i2c

Нет под рукой подходящего железа, с которым общаться по I2C. Скорее можно что-нибудь с SPI замутить. Даже есть наметки, что именно, но не сразу.

rs232/485
Цап/АЦП

Этот вариант уже зарезервировал на будущее как пример синхронизированной задачи "производитель-потребитель": вольтметр делает замеры и отправляет на COM-порт PC, на котором терминальная программа отображает данные.

динамическая индикация

В принципе можно, но реальная ценность невелика при нынешней доступности ЖК дисплеев. Хорошо бы, чтобы проект имел потом логическое продолжение.

Сухой контакт

Не смог придумать никакой эффектный трюк с его использованием.

[Dimka]

Да уж, блестящая перспектива... Можно, пока не поздно, попросить взамен что-нибудь в духе Дейкстры или Кнута? Честное слово, я не заслужил столь изощренной пытки Белинским. Пусть уж он лучше порезвится в другой теме, благо места хватает.

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

Это звучит как призыв мне покинуть сию песочницу. В части этой темы - охотно. А в части отзывов на цикл статей - нет.

[Dale]

Это звучит как призыв мне покинуть сию песочницу. В части этой темы - охотно. А в части отзывов на цикл статей - нет.

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

[DneprSMV]

Dale, "Второй заход ковбоя в салун в незнакомом городе" 
Как варианты "подгрузки" процессора предлагается:
- Подзадача1: выдавать кроме SOS координаты точки, + значения температуры - ветра итд
- Подзадача2: Кроме передачи SOS морзянкой передавть следом пакет FSK модуляции для автомат. приема (догружать протоколом, дополнительным кодированием, проверкой связи итд).
Квитирование получения аварийного сигнала.
В лабораторном варианте сделать возможность визуализации по послед. порту.

[Dale]

- Подзадача1: выдавать кроме SOS координаты точки, + значения температуры - ветра итд

Суть темы в том, что стенд можно было реально собрать дома из подручных средств. Если кнопки со светодиодами подключить реально, то приобретать приемник GPS/GLONASS, анемометр и прочую экзотику ради статьи точно не буду.

- Подзадача2: Кроме передачи SOS морзянкой передавть следом пакет FSK модуляции для автомат. приема (догружать протоколом, дополнительным кодированием, проверкой связи итд).

В смысле тоже оптическим способом, тем же светодиодом?

[DneprSMV]

Dale,
(1) GPS не нужен, ведь координаты вроде константа. Задача их передать. По крайней мере на N-ой версии разработки может пригодиться. Отметка времени с таймера контроллера (например время сработки кнопки + текущее время).
(2) вполне тоже могобыть. Только вид модуляции другой. И приемник в случае чего несложный.
(использование одного ресурса-выхода двумя задачами)

[Sla]

Вся ситуЁвина в том, что, к сожалению, пока не нашлось подходящего примера, вот и притянуто кое-что за уши.
Как говорил один из экс президентов - маємо, те що маємо.

Вот пытаюсь, вспомнить свои  наработки.... Вся сложность сводилась только к программному автомату - правильно описать состояния и переходы.
Какая-либо мат обработка сигналов? - опять же,  можно рассмотреть отложенное состояние.
Считаю, что для задачи более сложной, чем Hello, word, эта вполне подойдет.

С другой стороны... ммм... дождуссь коментов по поводу статьи. Ибо нефик тут словами разбрасываться. Итак всего букв 33.