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

[Dale]

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

Нашей мигалкой заинтересовались производители маячков для небольших тихоокеанских атоллов. Просят доработать конструкцию. Их требования:

• прожектор, направленный на север, дает красные вспышки (0.5с длительность, 1.5с пауза;
• прожектор, направленный на юг, дает зеленые вспышки (0.8с длительность, 1.3с пауза);
• маячок включается с наступлением сумерек датчиком освещенности; включение в светлое время не допускается для экономии аккумуляторных батарей, заряжаемых днем солнечными панелями;
• имеется аварийная кнопка для потерпевших крушение; по ее нажатию включается белый ненаправленный плафон, выдающий сигнал бедствия SOS азбукой Морзе (длительность точки 0.15с); повторное нажатие выключает сигнал бедствия.

Контроллер имеет один программируемый таймер, выдающий прерывания с заданным периодом (пока считаем, что с любым), и порт, 3 бита которых на вывод управляют соответствующими ключами подачи света, а 1 бит работает на ввод (кнопка с дребезгом на замыкание на землю, подтянутая на плюс питания резистором; аппаратное подавление дребезга отсутствует).

Требуется описание процедуры работы в любом виде (словесное, псевдокод, блок-схема...).

[RXL]

Тайминги на Морзе:

International Morse code is composed of five elements:

   1. short mark, dot or 'dit' (·) — 'dot duration' is one unit long
   2. longer mark, dash or 'dah' (–) — three units long
   3. inter-element gap between the dots and dashes within a character — one dot duration or one unit long
   4. short gap (between letters) — three units long
   5. medium gap (between words) — seven units long

1. 0.15
2. 0.45
3. 0.15
4. 0.45
5. 1.05

Для простоты я бы выбрал жесткий интервал 50 мс.

Не задана периодичность посылки SOS. Непрерывная посылка?

Имеет ли смысл посылка SOS в светлое время суток?

[Dale]

Не задана периодичность посылки SOS. Непрерывная посылка?

Возьмем серию из 3 посылок подряд с периодом повторения серии минута. Такое усложнение заставит научиться комбинировать короткие и длинные интервалы.

Имеет ли смысл посылка SOS в светлое время суток?

Однозначно нет. Выдача всех световых сигналов блокируется датчиком освещенности.

[RXL]

Следовательно, нажав кнопку днем пользователь не знает, включил он или выключил SOS.

[Dale]

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

[RXL]

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

Предположим, механический индикатор. Тогда днем видна маркировка кнопки, а ночью будет видно по световому сигналу. Но в этом случае кнопка должна быть с механической фиксацией.

[Dale]

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

[Sla]

По частям.

Прерывание таймера нужно только для ведения счета (пока для этого).
Количество счетчиков определяется количеством временных отрезков.

Возможны два варианта или комбинация, в зависимости от приоритетов
1. Обработка значений счетчиков в п/п прерывания
2. Обработка значений счетчиков в основном цикле
3. Комбинация.

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

Это все что касалось  мигалок и посылок.


Добавлено через 1 минуту и 25 секунд:
не понятно как в систему заведен индикатор сумерек

[Dale]

По частям.

Прерывание таймера нужно только для ведения счета (пока для этого).

Считаем, что:

Контроллер имеет один программируемый таймер, выдающий прерывания с заданным периодом (пока считаем, что с любым)

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

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

не понятно как в систему заведен индикатор сумерек

Будем считать, что двоичный пороговый сигнал "темно-светло" заведен на бит m порта n. Сейчас не занимаемся философскими вопросами типа "сумерки - это темно или светло?" или "сколько конкретно люкс нужно для включения и сколько для выключения?". Основной акцент на то, как делать множество дел на одном ядре без ОС.

[Sla]

Будем считать, что двоичный пороговый сигнал "темно-светло" заведен на бит m порта n. Сейчас не занимаемся философскими вопросами типа "сумерки - это темно или светло?" или "сколько конкретно люкс нужно для включения и сколько для выключения?". Основной акцент на то, как делать множество дел на одном ядре без ОС.

Имеем 5 бит in/out (2 in, 3 out)

Добавлено через 17 минут и 43 секунды:
Теперь Сразу и почтит все учитывая вышесказанной

Основной цикл
   Обслуживание Север
   Обслуживание Юг
   Опрос и обслуживание SOS
Конец основного цикла

Таймер работает в непрерывном режиме - его задача инкремент счетчиков. Инкремент по прерыванию. Интервал - наименьшее кратное для всех временных параметров (0.5с)

Обнуление счетчиков происходит в  функциях обслуживания


Почему выбрана именно такая система обслуживания и работы контроллера.
Задача не привязывается к жесткой привязке реалтайма. +- 0.01с  в задержке посылки не повлияют на функциональность системы.


Пока за бортом дребезг кнопки SOS  (я пока не определился с режимом опроса и приоритета кнопки.)


Кроме того... про маячки.. можно усложнить
в дневное время - работают радиомаяки с указанием  координат сам только шо придумал )

[Dale]

Уточняем по итогам обсуждения.

Входы:
- датчик освещенности;
- тумблер сигнала бедствия.

Выходы:
- красный прожектор;
- зеленый прожектор;
- белый аварийный сигнал.

Все входные-выходные сигналы однобитные.

Внутренние ресурсы:
- программируемый таймер с дискретностью 1 мкс неограниченной разрядности;
- память программ и данных неограниченного объема.

Выполняемые операции:
- в светлое время суток все световые сигналы выключены;
- в темное время подаются сигналы:
  - прожектор, направленный на север, дает красные вспышки (0.5с длительность, 1.5с пауза;
  - прожектор, направленный на юг, дает зеленые вспышки (0.8с длительность, 1.3с пауза);
  - если включен тумблер бедствия, включается белый ненаправленный плафон, выдающий сигнал бедствия SOS азбукой Морзе (длительность точки 0.15с).

P.S. С точки зрения функциональности, конечно, тумблер лучше (нагляднее); но для усложнения задачи лучше все-таки кнопка без фиксации, она заставит отмерять малые интервалы времени (подавление дребезга) на фоне больших (управление лампами).

[DneprSMV]

Dale, - по формированию Морзе.
Можно сделать достаточно небольшими усилиями универсальный формирователь Морзе.
Таблица char [n][2] - по количеству знаков, которые требуется формировать

Код:

[0][0] - "сигнатура" знака морзе, например А = ( .- )  0x80
[0][1] - длина сигнатуры (для А = 2) 
SOS = (...) (- - -) ( ... )  { {0xE0,0x03}, {0x00, 0x03}, {0xE0,0x03}  }

далее - двигаем в нужном направлении.
кажется так  
-----
когда планируется выезд на атоллы для отладки  ?

[Sla]

DneprSMV, м...
здесь не рассматриваются решения
Здесь предлагаются решения


Т.е.

Требуется описание процедуры работы в любом виде (словесное, псевдокод, блок-схема...).

Это не помощь, это просто попытка увидеть видение разработчиков.

[Dale]

Dale, - по формированию Морзе.
Можно сделать достаточно небольшими усилиями универсальный формирователь Морзе.

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

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

когда планируется выезд на атоллы для отладки  ?

На атоллах лучше загорать, а отлаживаться нужно заранее здесь:

https://club.shelek.ru/viewart.php?id=348
https://club.shelek.ru/viewart.php?id=349
https://club.shelek.ru/viewart.php?id=350
https://club.shelek.ru/viewart.php?id=351
https://club.shelek.ru/viewart.php?id=354
https://club.shelek.ru/viewart.php?id=355
https://club.shelek.ru/viewart.php?id=356
https://club.shelek.ru/viewart.php?id=357
https://club.shelek.ru/viewart.php?id=358

Ну и так далее. Если сделать все по уму, при монтаже на атоллах будем отдыхать.

[DneprSMV]

Dale,  "общая архитектура приложения"
Вариант с "главным циклом - 1"
Максимальная длит. гл. цикла - 1 мс
----- Обработчик прерывания ----
Апп. прерываение таймера - 1 мс
Софт-таймер 100 мс  (все временнЫе процессы имеют дискретность не менее 0.1 с)
----- Гл.цикл ----
Реализации N таймеров на базе софт-таймера (по постановке задачи - память - произвольное кол-во)
Опрос вх.сигналов
Обрабока вх. сигналов - дребезг, задержки включения итд
Логика вх.сигналов - формирование флагов состояния
Отработка N-задач по флагам состояния (псевдопараллельное выполнение)
Формирование выходных сигналов на базе фл. состояния
------ / главный цикл ----
Это типовая структура.
Время реакции зависит от длины гл. цикла и может быть от десятков мкс.

[Sla]

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

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

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

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

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

А оно (предложение) вот отсюда

Там должна получиться очередь к таймеру от разных устройств (две мигалки, кнопка с программным подавлением дребезга, генератор кода Морзе)... Эту очередь нужно будет сортировать, синхронизировать задачи... Сначала покажу, какой запутанный, некрасивый и трудно масштабируемый код получается, а потом перейдем к протопотокам.

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

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

Добавлено через 1 час, 37 минут и 11 секунд:
С кнопкой SOS прикольно получается, на такой абстрактной модели контроллера.

Offtopic:

На хрена  кнопка SOS, если днем фонари не горят

Поставлю в угол.

В ТЗ не указана возможность работы по прерыванию, от IN pin
На этапе проектирования неизвестно время выполнения п/п управления мигалкой, и, соответственно, основного цикла.

Ограничение на одно прерывание таймера заставляет разбивать логику от управления.
Логика = анализ готовности к выполнению функции (или потухнуть или погаснуть)
Управление = выдача сигнала на pinOut

Вся логика управления сводится к возведению флагов (или изменению состояния автомата управления внешним устройством)

выдача сигналов (управление) - в п/п прерывания от таймера.
Соответственно  и опрос Кнопки SOS производить  в прерывании.
Таймер должен быть настроен на приемлемую для всех случаев частоту срабатывания.

[RXL]

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

Глобальные имена:

Код:

// источники внешнего сигнала
var состояние_кнопки_sos
var состояние_датчика_освещенности

// глобальные переменные
var сигнал_sos = false
var световая_посылка_sos = false
var сирена = false

// программные счетчики времени
// время в мс
var счетчик_времени_опроса_кнопки_sos
var счетчик_времени_южного_огня
var счетчик_времени_северного_огня
var счетчик_времени_световой_посылки_sos
var счетчик_времени_посылки_морзе

Процедуры-нити:

Код:

procedure обслуживание_кнопки_sos
  var предыдущее_состояние_кнопки
begin
  предыдущее_состояние_кнопки = 0
  while состояние_кнопки_sos = предыдущее_состояние_кнопки do
    спим()
  end while

  сброс_счетчика_времени(счетчик_времени_опроса_кнопки_sos)

  while счетчик_времени_опроса_кнопки_sos < 100
    спим()
  end while

  if состояние_кнопки_sos = предыдущее_состояние_кнопки then
    return
  end if

  if предыдущее_состояние_кнопки = 1 then
    предыдущее_состояние_кнопки = 0
    сигнал_sos = true
  else
    предыдущее_состояние_кнопки = 1
    сигнал_sos = false
  end if
end

procedure обслуживание_сигнала_sos
  var передача_сигнала
begin
  if состояние_датчика_освещенности = 1 then
    передача_сигнала = сигнал_sos
  else
    передача_сигнала = false
  end if

  световая_посылка_sos = передача_сигнала
  сирена = передача_сигнала
end

procedure обслуживание_световой_посылки_sos
  var счетчик_посылок
begin
  if световая_посылка_sos = false then
    return
  end if

  сброс_счетчика_времени(счетчик_времени_световой_посылки_sos)

  for счетчик_посылок = 1 to 3
    послать_морзе_букву("S")
    послать_морзе_букву("O")
    послать_морзе_букву("S")

    if счетчик_посылок <> 3 then
      послать_морзе_пауза(между_словами)
    end if
  next

  while счетчик_времени_световой_посылки_sos < 60000 do
    спим()
  end while
end

procedure обслуживание_сирены
begin
  // драйвер сирены требует проработки
end

procedure мигание_южным_огнем
begin
  сброс_счетчика_времени(счетчик_времени_южного_огня)
  включить_огонь(зеленый)

  while счетчик_времени_южного_огня < 500 do
    спим()
  end while

  выключить_огонь(зеленый)

  while счетчик_времени_южного_огня < 500 + 1500 do
    спим()
  end while
end

procedure мигание_северным_огнем
begin
  сброс_счетчика_времени(счетчик_времени_северного_огня)
  включить_огонь(красный)

  while счетчик_времени_южного_огня < 800 do
    спим()
  end while

  выключить_огонь(красный)

  while счетчик_времени_южного_огня < 800 + 1300 do
    спим()
  end while
end

procedure обслуживание_морзе
begin
  // позжее
end

Обычные процедуры:

Код:

procedure послать_морзе_букву(буква)
begin
  // позжее
end

procedure послать_морзе_пауза(размер_паузы)
begin
  // позжее
end

Забыл про датчик света...

[Dale]

Dale,  "общая архитектура приложения"
...
Это типовая структура.

Архитектуру пока здесь не смог увидеть.

Сейчас, собственно, два основных вопроса:
1) Как устроен планировщик?
2) Как устроена задача?

Все остальное гораздо менее значимо и может уточняться позже.

Время реакции зависит от длины гл. цикла и может быть от десятков мкс.

На время пока не заморачиваемся. Например, Atmega на частоте 16 МГц дает 16 миллионов инструкций в секунду. У нас процессы измеряются десятыми долями секунды, то есть на одно событие приходится миллион инструкций. Процедуры примитивны, поэтому скорость вычисления можем смело считать бесконечной без потери общности.

Добавлено через 39 минут:

С кнопкой SOS прикольно получается, на такой абстрактной модели контроллера.

Offtopic:

На хрена  кнопка SOS, если днем фонари не горят

Поставлю в угол.

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

В ТЗ не указана возможность работы по прерыванию, от IN pin

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

На этапе проектирования неизвестно время выполнения п/п управления мигалкой, и, соответственно, основного цикла.

Без большого ущерба пока можем считать загрузку процессора пренебрежимо малой.

Вся логика управления сводится к возведению флагов (или изменению состояния автомата управления внешним устройством)

Автоматная модель - вполне достойная тема для рассмотрения в статье. Один из способов реализовать действительно устойчиво работающую систему.

выдача сигналов (управление) - в п/п прерывания от таймера.
Соответственно  и опрос Кнопки SOS производить  в прерывании.

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

Таймер должен быть настроен на приемлемую для всех случаев частоту срабатывания.

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

[Sla]

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

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

[Dale]

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

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

Глобальные имена

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

Забыл про датчик света...

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

Добавлено через 17 минут и 17 секунд:

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

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

Можно затянуть "фронты" Импульсов мигания на сотые доли секунды

Затянуть или задержать? Задержать - запросто, никто не заметит. Затянуть - силовые ключи могут не простить...

[Sla]

Конечно задержать.

Аварийная кнопка - необходимость расставить приоритеты в обслуживании устройств (пусть и к ней не реалтайм чувствительность).

[RXL]

Забыл про датчик света...

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

Добавил (и в пост № 18 тоже).

Код:

procedure обслуживание_сигнала_sos
  var передача_сигнала
begin
  if состояние_датчика_освещенности = 1 then
    передача_сигнала = сигнал_sos
  else
    передача_сигнала = false
  end if

  световая_посылка_sos = передача_сигнала
  сирена = передача_сигнала
end

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

Глобальные объекты - это условность. Просто на Паскале-подобном псевдоязыке удобнее описать задачу, чем на Си. Проще абстрагироваться от подробностей типа структур и указателей.

Кстати, подача сигнала SOS в нашем случае тоже не требует риалтайма. Куда торопиться то? Уж несколько мс можно и подождать.

[Dale]

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

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

Глобальные объекты - это условность. Просто на Паскале-подобном псевдоязыке удобнее описать задачу, чем на Си. Проще абстрагироваться от подробностей типа структур и указателей.

Оба (Паскаль и С) - процедурные языки, поэтому хорошо подходят для описания последовательности действий, но не годятся для описания интерфейсов, а нам для архитектуры именно интерфейсы сейчас важнее всего. Тут бы лучше подошло что-нибудь объектно-ориентированное (типа псевдокода на Java), или же диаграммы UML. Опять же, видимость и доступность объектов лучше видно будет.

[v2]

Код: (C++)

//------Hdr.m-------
#define PIN_SOS 0x80
#define PIN_LGH 0x10
#define PIO_SOS 0x08
#define PIO_GRN 0x04
#define PIO_RED 0x02

const char stepT = 1; //~10ms

struct TContext
{
  char Tick, State;  //...  
};

void Live    ();
void Init    (char &Timer);
char GetPin  ();
void SetPio  (char Pio, bool On);

__monitor bool TestEv(char &Ev);

char TickPin (TContext &Inf, char Pin);
bool TickRed (TContext &Inf, char Key);
bool TickGrn (TContext &Inf, char Key);
bool TickSos (TContext &Inf, char Key);

#define INF_Z  {0,0}
#define INF_SET(A,B,C,D) TContext A=INF_Z, B=INF_Z, C=INF_Z, D=INF_Z

//------Main.m-------
void main()
{
  char  Key, EvT = stepT;

  INF_SET(Pin, Red, Grn, Sos);
 
  Init(EvT);
 
  while (1) {
   while ( TestEv(EvT) )
   {
     Key = TickPin(Pin, GetPin() );
   
     SetPio( PIO_RED, TickRed(Red, Key) );
     SetPio( PIO_GRN, TickGrn(Grn, Key) );    
     SetPio( PIO_SOS, TickSos(Sos, Key) );
   }
   Live();
  }
}

//-------Hala.m---------
char *TimerEv;
void Init(char &Timer)
{
  TimerEv = &Timer;
  //...
};
__interrupt void TimerUp()
{
  *TimerEv = 1;
}

void Sleep   ()                  { /*.*/ };
char GetPin  ()                  { /*.*/ };
void SetPio  (char Pio, bool On) { /*.*/ };

//------Core.m-------
__monitor bool TestEv(char &Ev)
{
  if (Ev) { Ev = 0;
    return true;
  } return false;
}
void Live()
{
  Sleep();   // ;)
};        

//------- Task.m---------                              
char TickPin (TContext &Inf, char Pin) { /*.*/ };
bool TickRed (TContext &Inf, char Key) { /*.*/ };  
bool TickGrn (TContext &Inf, char Key) { /*.*/ };
bool TickSos (TContext &Inf, char Key) { /*.*/ };

[RXL]

Вот этого я и опасался - типы, ссылки/указатели, тонкости синтаксиса, рябь в глазах... И никакой самодокументируемости - остается только догадываться, о чем идет речь в данной конкретной строке. C/C++ - это все таки привычно и от того хочется автоматом упрощать.
Паскалеподобный язык (или Algol-подобный) использовался в документации Intel для описания логики работы команд x86. Там я его оценил и с тех пор применяю. Конечно, если есть более выразительный способ - было бы хорошо увидеть сравнительный пример.

[Dale]

Паскалеподобный язык (или Algol-подобный) использовался в документации Intel для описания логики работы команд x86. Там я его оценил и с тех пор применяю.

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

Конечно, если есть более выразительный способ - было бы хорошо увидеть сравнительный пример.

Очень хорош UML. Вот примеры из недавней статьи:

(статика, архитектура)

(динамика, деятельность)

Добавлено через 4 минуты и 1 секунду:

Код: (C++)

...

Я пока не вникал даже, как это работает. Главный вопрос: как это тестировать?

[Sla]

v2,
Мне проще в морду дать, чем объяснить за что  -  так выглядит твое предложение/код

[RXL]

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

[Dimka]

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

Непонятны заморочки с кнопкой SOS. Если SOS - это световые импульсы, выдаваемые белой лампой, то кому и зачем нужен какой-то дополнительный индикатор? Неужели не видно, мигает белая лампа или нет.


Теперь о главном. А то я вижу, что народ тут от навигационного дела далёкий - замечания от штурмана

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

У буксира к кормовому белому огню добавляется ещё один жёлтый огонь.

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

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

Береговой маяк также имеет световой треугольник из белого, зелёного и красного огней, при помощи которого задаётся сектор безопасного выхода на маяк (и входа в порт или гавань, если надо).

Сигналы маяков модулированы, и если маяки находятся в общей зоне видимости, каждый маяк обладает собственным законом модуляции светового сигнала (отражённом в картах и справочниках).

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


Далее. Насчёт 50 мс для морзянки, передаваемой световым телеграфом, мне кажется, вы сильно погорячились. А в условиях плохой погоды и болтанки, когда внимание оператора на спасательном корабле или вертолёте рассредоточено (это не радист в своей рубке в тишине, это человек на палубе, на ветру, на волнах) уверенное воспрятие возможно только на сравнительно низких частотах. Поэтому точка Морзе должна иметь световую длительность около 0,3 секунды, т.е. быть в 6 раз длиннее. (Аналогично относительно импульсов маяка - порядка секунд, а то и десятков секунд, но не десятых долей секунды. А вот радиосигналы вполне могут быть длительностью порядка десятых секунды.)

[Sla]

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