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

[v2]

Вариант добавки:

Подзадача 1: (минимум)
 Необходимый базовый функционал, озвученный в начале темы.

( Представим, что наш маяк имеет канал связи (Uart + простенький протокол))

Подзадача 2: (расширения - коммуникация)
 Сбор и передача телеметрии  (ветер, температура, давление,  влажность,  освещенность, _SOS_ ) ,
  минимум - индикация состояния рабочих входов/выходов и временная метка;

Подзадача 3: (расширения - пользовательский интерфейс)
 Реализовать меню (а-ля ЖК(2х16)+4кнопки через тот же  Uart  ) посредством которого диспетчер будет иметь возможность
 просмотреть/изменить  параметры работы маяка и, при необходимости, просигнализировать (LED) потерпевшим
 о принятии сигнала бедствия.

 =>  Использование одного "долгоиграющего" аппаратного ресурса несколькими подзадачами
 =>  Ожидание и обработка ввода пользователя

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

  ( Если тестировать, то и "эффективность труда" микроконтроллера )
 => Значение инкремента в фоне на единицу времени  даст возможность оценить   варианты   реализации
      по производительности и  расширяемости.

ЗЫ.
Возьмусь вышесказанное  воплотить в код, используя независимые (uOS) потоки (потому как UI на "автоматах" – сложная штука).

[Dale]

Считаю, что для задачи более сложной, чем Hello, word, эта вполне подойдет.

"Эта" - в смысле которая с двумя мигалками и морзянкой, сформулированная в начале темы?

С другой стороны... ммм... дождуссь коментов по поводу статьи.

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

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

Эх, ваши бы слова - да Богу в уши... Зато сколько потенциальных комбинаций! Однобуквенных фраз только 34 (с пробелом), двухбуквенных - 34², ... n-буквенных - 34ⁿ. А если учесть, что n при разбрасывании редко бывает меньше 10.000, прогноз вовсе не радует. Боюсь, во Вселенной столько атомов нет. Пропал калабуховский дом...

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

Вариант добавки:

Подзадача 1: (минимум)
 Необходимый базовый функционал, озвученный в начале темы.

( Представим, что наш маяк имеет канал связи (Uart + простенький протокол))

На моем прототипе есть преобразователь TTL <-> RS232, так что этот вариант легко реализуем без накладных расходов. Можем и обратный канал сделать.

Подзадача 3: (расширения - пользовательский интерфейс)
 Реализовать меню (а-ля ЖК(2х16)+4кнопки через тот же  Uart  )

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

Возьмусь вышесказанное  воплотить в код, используя независимые (uOS) потоки (потому как UI на "автоматах" – сложная штука).

Замечательно. Тогда я начну со standalone версии, а потом как развитие прикрутим к ней ОС.

[RXL]

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

[Dale]

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

Лучше все-таки приурочить к нашим периодическим рассылкам. Если бы лично на меня вывалили разом столько информации, я бы отложил чтение на потом и затем благополучно забыл (так у меня обычно и бывает со слишком частыми и объемными рассылками).

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

[RXL]

Тогда предлагаю слегка форсировать до двух выпусков в неделю. Пятую часть я опубликовал в среду. Рассылка выйдет сегодня.

[Sla]

потому как UI на "автоматах" – сложная штука

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

[Dale]

потому как UI на "автоматах" – сложная штука

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

Сложность - категория весьма относительная и субъективная:

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

(Дейкстра, "Ответы на вопросы студентов отделения программного обеспечения EWD1305"). Впрочем, хватит философствовать, пока не накликали беду.

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

Описать состояния интерфейса, жестко прописать в таблицу.
Переходы на п/п по адресу в таблице.

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

[v2]

(потому как UI на "автоматах" – сложная штука).

Для меня и, скорее, психологически.

[RXL]

Предыдущая статья полностью опубликована.
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
https://club.shelek.ru/viewart.php?id=359
https://club.shelek.ru/viewart.php?id=360

[Dimka]

Ну вот, после отзыва можно вернуться к теме.

Есть следующее предложение по содержанию задачи: световой телеграф.

Это устройство, которое соединено с компьютером по COM или USB, получает от компьютера текстовые сообщения в свой буфер и "намигивает" их лампочкой.

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

Со стороны host-машины для общения с устройством нужно иметь 3 протокола (или 3 направления взаимодействия):
1) Разные настройки - например, скорость вывода.
2) Загрузка текста в буфер устройства.
3) Чтение состояния и управление (остановка, запуск, сброс и т.п.)

[zubr]

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

[Dale]

Ну, граждане алкоголики, хулиганы, тунеядцы – кто хочет поработать?

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

Итак, вкратце.

Основная задача: повысить качество разработки встроенных систем с микропроцессорами с одновременным уменьшением временных затрат за счет более тщательного тестирования как отдельных блоков, так и системы в целом. Акцент делается не на soft и не на hard (в обеих областях есть инструменты для этого), а именно на firmware.

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

Идеология: попытаться экстраполировать "гибкие" методики проектирования ПО (TDD, BDD) на процесс проектирования программно-аппаратного комплекса в целом.

Предполагаемый инструментарий для решения: C (для стенда), Ruby + Cucumber (для хоста, управляющего тестированием), Gherkin (как язык описания функциональных требований к системе).

Есть реально заинтересованные в результате (или хотя бы в процессе его получения)?

P.S. Не могу сказать, что идея нова: несколько лет назад команда из Atomic Object публиковала статьи и доклады о чем-то наподобие. Однако в качестве стенда использовалось оборудование с довольно ограниченными возможностями, без перспектив расширения. Софт так и не был доведен до состояния "бери и пользуйся", требовал плясок с бубном и не обновлялся уже несколько лет.

[RXL]

Я пасс. Времени мало.

[LemmonRus]

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

[Dale]

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

[Ochkarik]

кстати... недавно один человек тут на форуме искал команду единомышленников, для построения ЧПУ станка. от проектирования плат-плис-контроллеров до драйверов. как раз в учебно-практическом смысле... правда я ему ответил, что сомнительно, что кто то присоединится, в виду отсутствия времени и интереса по данной тематике у основной части участников. но если кому то идея интересна - могу ему отписать?

[Dale]

Конечно, почему бы нет. Правда, тема самодельных ЧПУ давно избита и заезжена, поэтому имеет смысл браться только при наличии свежих идей. Ибо на конструкции, которые массово тиражируют, без слез не взглянуть. Спроектировано по принципу "зато работает".

[Aether]

Можно тоже подкинуть тему, чтобы было и полезно и занимательно.

Много народа использует МК для устройств различной сложности, и значительное место занимает вопрос вывода информации, в том числе и во время тестирования, когда имеется необходимость выводить не только нужные параметры, но и служебные. Обычно, по мере роста сложности, для простых устройств используются сегментные индикаторы, шкалы, далее идут готовые малоформатные текстовые и графические модули. Но, что делать, когда нужно следить за кучей параметров, использовать, некоторую графику? Самое распространённое решение - сделать интерфейс с компьютером и выводить информацию через него на монитор, но можно ли поступить иначе - формировать изображение на мониторе, минуя стадию обработки на ПК?
Надо сказать, что даже информации по электрике VGA в сети не так уж и много, но на сегоднешний день этот стандарт уже устарел, да и разрешения, вроде, 640х480 на современных мониторах выглядят некачественно.
Задача: сделать модуль для организации вывода текстовой или графической информации на экран обычного монитора (например, через DVI). Речь, естественно, не идёт об интерактивном выводе видео - просто терминал. Мне это видится, как два буфера - один заполняем, другой рисуется, по заполнению нужными данными производим переключение. Управление модулем и передача данных должны происходить простейшим способом: SPI, I2C, RS-232... Время заполнения пассивного буфера не критично, так как до переключения будет повторно рисоваться активный буфер во избежания мерцания или появления каких-либо дефектов изображения.

Возможно, существуют готовые решения? Но, в любом варианте сама тема актуальна и интересна.

[Ochkarik]

http://rspmarket.com/shop/

[Aether]

Одноплатные компьютеры - это, конечно, хорошо, но:

как раз в учебно-практическом смысле...

Задача даст возможности оценить и ПЛИС и МК, работу с разными типами памяти... хотя, конечно, объёмно и не так просто, но не писать же статью на тривиальную тематику? Как идея для статьи, достойной профессионала, думаю, неплохо.

[Dale]

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

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

Во-вторых, рассмотрим его как устройство для вывода. Дисплею нужен буфер для хранения битовой карты экрана. Разместить его во встроенной оперативной памяти контроллера нереально - даже для VGA 640х480 требуется треть миллиона пикселов. Если выделить всего по байту на пиксел, получается запредельный для типичного микроконтроллера объем. Если вынести битовую карту в отдельную память и заполнять ее по серийному интерфейсу - грубо оценим необходимое для формирования кадра время. SPI с натугой пропустит несколько мегабит в секунду (вопрос, сколько времени уйдет на генерацию этих данных на большинстве микроконтроллеров, пока отложим). I2C с порогом  400 кбит/с и RS232 с еще более скромными показателями годятся еще меньше.

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

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

Второй вариант тоже не блещет оригинальностью: используем популярное в "большом" программировании отделение данных от представления (MVC/MVP и иже с ними). Оснащаем контроллер сетевым интерфейсом (с проводами либо без, не суть важно) и встроенным web-сервером (благо этого добра в Сети навалом в готовом виде). Любой желающий отобразить эти данные подключается как браузер, причем годится что угодно вплоть до смартфона.

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

[Aether]

Основная цель, естественно, образовательная, как говорите - поднатореть, думаю, многие, начиная от радиолюбителей и заканчивая "домашними" ЧПУ-строителями, заинтересуются данным устройством или, по крайней мере, получат серьёзный стимул к развитию в области практической электроники. С коммерческой стороны - да, одноплатные компьютеры - решение эффективное, масштабируемое...

С точки зрения реализации, не нужно умножать цель, например, сетевой интерфейс - сам по себе не так прост, и является темой для отдельной статьи. Главное просто и доступно. Не зря изначально я сказал, что о воспроизведении видео не может быть и речи, естественно, ни у одного МК не хватит собственной памяти, а у средних, например, PIC - скорости. Стало быть, передача, исключительно, массива точек из устройства пользователя (на базе МК, МП - да чего угодно) в девайс лишена смысла. Мне видится интерфейс методом последовательной передачи команд (пакетов, содержащих команды, данные, код контроля целостности), то есть модуль должен поддерживать команды:
а) собственной инициализации (вкл/выкл, установка разрешения монитора...),
б) закрашивания пассивного буфера в заданный цвет (или прямоугольной области),
в) установки пикселя в пассивном буфере по координатам и цвету,
г) записи таблицы растрового шрифта в ПЗУ,
д) установки буквы по координате, цвету и адресу в ПЗУ...
...
е) обмена активного и пассивного буферов местами.
Активный буфер - тот, который выводится на экран, пассивный - тот, в котором мы рисуем, подготавливая изображение.

[Dale]

С коммерческой стороны - да, одноплатные компьютеры - решение эффективное, масштабируемое...

Сегодня это вполне реально не только для коммерческого применения. Возьмите, к примеру, Raspberry Pi. За несчастных 36$ вместе с доставкой получаете готовый компьютер размером с кредитку под Linux'ом с частотой 700 Мгц, ОЗУ в полгигабайта, сетевой интерфейс 10/100 Mбит/c, 4 порта USB, довольно приличный для таких размера и цены видеоакселератор, звук средней паршивости и интерфейс расширения, к которому можно нацеплять чего угодно. По сегодняшнему курсу это немного меньше 2.000 руб, не жалко пожертвовать в качестве контроллера для нетривиальной задачи. Сумеете уложить свой мегадевайс вместе с разработкой железа/софта и изготовлением в эту сумму?

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

IMHO преувеличение, и сильное. Модуль на 28J60 стоит меньше трех баксов с доставкой и устроен проще пареной репы, если захочется развести на плате собственный вариант, а не лепить покупной. От софта к нему буквально ломится интернет, начиная со стека сетевых протоколов и до готового встроенного web-сервера. Писать о нем статью - пустая трата времени, такую статью только ленивый до сих пор не написал: http://yandex.ru/yandsearch?text=28j60%20%D0%BF%D0%BE%D0%B4%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5&lr=39

Разумеется, это при условии, что не польстились на Raspberry.

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

Ну вот я, к примеру, тот самый многий радиолюбитель и домашний строитель ЧПУ. Устройством не заинтересовался по описанным выше причинам (соотношение затраченных на девайс усилий и полученной от него радости складывается не в его пользу). Стимул к развитию тоже вряд ли получу. Остается исключительно образовательный аспект - сделать, похвалить себя за усидчивость и сложить на полку.

Я бы поискал более достойную задачу для освоения современных ПЛИС. Хотя мне самому такая задача навскидку не приходит в голову.

[Aether]

За несчастных 36$ вместе с доставкой... По сегодняшнему курсу это немного меньше 2.000 руб, не жалко пожертвовать в качестве контроллера для нетривиальной задачи. Сумеете уложить свой мегадевайс вместе с разработкой железа/софта и изготовлением в эту сумму?

Хорошо, убедили.