С настольного компьютера или ноутбука мы прошиваем микроконтроллеры обычно через USB, да часто и с каким-нибудь программатором. А что если мы хотим прошить или сконфигурировать поделку с телефона? Некоторые телефоны имеют USB-OTG. Некоторые контроллеры умеют BlueTooth. Существуют системы поддерживающие WiFi. К сожалению всё это не носит массового характера - нужен подходящий телефон, подходящий контроллер и т.п.
Стало интересно - можно ли "пропищать" данные через динамик телефона - и уловить их микрофоном присоединённым к микроконтроллеру? В этой статье я кратенько расскажу о своих жалких попытках в этом направлении. Пока "с полпути" - потому что, предположительно, демонстрация самого принципа для Ардуино может оказаться полезнее для большинства коллег, чем конечный, узконаправленный результат - загрузчик для конкретного проца.
Был "предшествующий этап" - передача через аудиоразъём телефона, по проводу - об этом тоже вкратце расскажу и покажу (можете попробовать).
Предупреждение!!!
Не нажимайте кнопки на прилагаемых веб-страничках не сняв наушники!
Идея не нова
Кто помнит ZX-Spectrum и некоторые другие компьютеры той эпохи - они загружались с помощью магнитофона, правда через линейный выход (а у себя на входе использовали фильтр и компаратор).
Телефоны с тональным набором - на них можно было набирать номер "пропищав" его в трубку - например часами с памятью на сколько-то номеров.
А ещё раньше была оперативная память для ранних ЭВМ, которая гоняла звуковую волну (обычно в плотной среде, не в воздухе) с одного конца на другой а потом обратной связью подавала её вновь на начало. Динамическая, получается, память. На звуке :)
Предыдущая попытка
Я пока пропущу предысторию, зачем всё это было нужно - если кратко, для использования в образовательном процессе. Но поскольку идеального решения пока не получилось - использование пока тоже больше в тестовом режиме на добровольцах, которые не имели возможности отвертеться. Хо-хо-хо.
Прежняя версия позволяет программировать AVR чипы на ассемблере (мы использовали AtMega8) примерно следующим образом:
в контроллер прошивается кастомный загрузчик (вот код и прошивка)
кроме чипа нужен только разъём (на ADC3 и GND) и светодиод для наблюдения результата (а ещё кнопка для входа в режим программирования при старте)
подключаем аудиокабель с 3.5 джеком между контроллером и телефоном, нажатием кнопки при старте переводим контроллер в загрузочный режим
открываем веб-страничку с формой для ввода программы (вот она)
пишем код (по умолчанию там есть некий stub из пары команд)
жмём Compile и Burn (компилятор ассемблера там встроен в JS)
Если захотите попытаться прошить этот загрузчик - по-моему нужно фьюзами выставить частоту 1МГц внутреннего осциллятора. И запуск собственно загрузчика (в 1кб памяти вроде). Он ограничен возможностью записать то ли 1 то ли 4 страницы.
В общем это работало более-менее - но обнаружилась пара проблем, даже три:
придуманный протокол обмена был недостаточно надёжен - программа больше 50 команд уже через раз заливалась с ошибкой
и он был довольно медленным
а главное - аудиоразъём в наше время уже не на каждом телефоне присутствует!
Итак - над первыми двумя пунктами можно было голову поломать - но по третьему пришло понимание что нужно делать следующий шаг - передавать звук прямо через динамик и ловить микрофоном.
На словах звучит понятно и даже банально. На деле всё немного сложнее оказывается.
Схема подключения
Изначально я хотел чтобы электронная часть была максимально простой - подключить микрофон прямо к АЦП и всё. Та старая версия так и работает (видно по коду) - к сожалению при передаче "через воздух" а не по проводу сигнал получается очень слабый. Кроме того нелинейности такой передачи добавляют проблем - приходится пробовать цифровую фильтрацию, сглаживание и т.п. Старая версия использовала небольшие "пучки" - что-то около 10 периодов довольно пронзительной частоты - и расстояния между ними кодировали нули и единицы. Скорость передачи получалась просто божественная (вы сами можете проверить на указанной выше странице - добавьте десяток-другой NOP-ов в программу. Что-то порядка 10 команд в секунду.
Я решил сдаться и незначительно усложнить хардварную часть ради более надёжной и быстрой передачи.
Подключение микрофона стандартное - через небольшой резистор к плюсу (не перепутаем полярность микрофона!) - а с середины этой "стойки" через конденсатор колебания уходят на базу транзистора. Транзистор без подтяжки поэтому он обычно закрыт и напряжение на коллекторе близко к VCC - когда на микрофон приходит какой-то "клик" - импульс проходит через конденсатор и ненадолго его приоткрывает - на выходе PIN появляется коротенький по длительности "ноль". Этот выход мы и подключаем к выбранной ноге микроконтроллера.
В данном виде схема достаточно чувствительна к номиналам компонент (конденсатора и резистора в коллекторной цепи в первую очередь) - которые в свой черед зависят от коэффициента передачи транзистора. Предстоит немного поэкспериментировать насколько её можно "загрубить" с учетом что, например, многократные срабатывания можно отсеивать в коде (уже).
Программная часть
На текущий момент то что есть - это "демонстрашка" - веб-страничка на которой можно вбить какой-то текст в поле ввода и нажать "Beep". С помощью незамысловатого кода на JS всё это преобразуется в последовательность данных для вывода в звук.
Вот эта страничка https://rodiongork.github.io/avr-mic-loader/extra/sound2.html
Принцип кодирования пока такой (сильно в подробности не погружаюсь т.к. может ещё немного изменится):
в цепочке данных 0-0-0-0-...-0-0 местами появляются 1 - будем называть их "пиками", это значения для вывода в звук, а не логические значения, но не столь важно
бит 0 кодируется промежутком между двумя пиками в 13 нулей, а бит 1 более коротким, в 7 нулей
звук воспроизводится с дискретизацией 16кГц
байты кодируются по аналогии с UART - пока данных нет передаются единицы, а первый же "провал" в 0 является "стартовым битом" за которым следуют восемь бит данных
Что касается прошивки - это код для Arduino, так что вы несложно можете попробовать запустить такую установку сами (ну несколько упомянутых выше компонент понадобятся).
Код незамысловатый - он в цикле проверяет сигнал на входном пине, и когда обнаруживает провал в LOW (то есть "пик" в аудио-канале) - засекает время до следующих пиков. После каждого следующего пика мы определяем пришёл ли таким образом бит 0 или 1 - и если обнаруживаем 0, то начинаем отсчет нового байта. Когда байт готов - просто печатаем его.
Вот эта прошивка https://github.com/RodionGork/avr-mic-loader/blob/master/idea-proof/receiver-air/receiver-air/receiver-air.ino (что-то тут лишний уровень вложенности, ну да ладно)
Текст введённый на веб-страничке "пропискивается" через динамик, улавливается микрофоном и выводится в последовательный порт микроконтроллером, то есть его можно видеть в Serial Monitor:
К коду не стоит присматриваться внимательно или относиться слишком серьёзно - это сугубо черновик чтобы протестировать идею, оценить задержки и примериться как сделать загрузчик. Всё же в него включен макрос DEBUG - если его активировать, то вместо символов отрисовываются биты (как показано в середине картинки - из долларов и дефисов).
Оценка результата
В этом варианте передача проходит успешно при расстоянии между микрофоном и динамиком телефона около сантиметра. Хотя наверняка зависит от качества того и другого. Предстоит ещё поэкспериментировать с разными девайсами. Кроме того примитивная электронная усилительная схема, возможно, может быть немного улучшена - ещё потестирую.
Скорость передачи гораздо выше - нетрудно прикинуть что в среднем 1 бит занимает около 10 "точек" звуковой волны, а 11-битный байт, значит, 110 точек. При частоте 16кГц это больше 140 байт в секунду (то есть 70 AVR-ных команд).
Код "приёмника" стал гораздо проще т.к. не нужно обрабатывать "корявые" данные с АЦП. Это немаловажно для создания бутлоадера - чем меньше ассемблера, тем проще жить! Кроме того он подходит теперь и для чипов без АЦП вообще.
К ошибкам (на первый взгляд) система стала устойчивее. В принципе возникновение ошибок сейчас просто зависит от расстояния между микрофоном и динамиком.
Понятно что для передачи больших объёмов данных этот способ не очень-то подходит (хотя мы и проверим насколько его можно ускорить). Для прошивок в несколько килобайт сойдёт. Или для загрузки конфигурации.
Из достоинств - его можно использовать с любым в общем-то контроллером, лишь бы он умел записывать свою флэш-память (младшие AVR и некоторые другие чипы не умеют).
Но про контроллеры говорить пока рано - немножко поковыряюсь с тем чтобы сделать протокол надёжнее и тогда уже сотворю новую версию загрузчика.
Если кому-то будет не лень потестировать и возникнут идеи по улучшению или какие-то важные наблюдения - пожалуйста, делитесь! Если захотите как-то переиспользовать в своих поделках - милости прошу - на вопросы постараюсь ответить!
До скорого :)
Комментарии (47)
YMA
05.11.2024 05:43Еще немного, и будет изобретен акустический модем (V.21 300 bod FSK) ;)
И пойдет развитие технологии - v34 (скорость), v42bis (сжатие передаваемых данных). С v90 не выйдет, к сожалению, там нужно прямое подключение.
Интересно, какой скорости можно достичь на звуке, не ограничиваясь телефонными частотами и с современными вычислительными мощностями?
RodionGork Автор
05.11.2024 05:43да-да, всё по кругу :) ну и не зря - решая новые инженерные задачи порой стоит оглянуться назад
Интересно, какой скорости можно достичь на звуке, не ограничиваясь телефонными частотами
Если речь о том чтобы не использовать собственный динамик телефона и обычный аудиоканал - а какой-то специальный УЗ-излучатель, то можно прикинуть - поделить скорость звука на характерный размер излучателя и микрофона, т.к. они должны быть сопоставимы с длиной волны. Я что-то думаю там несколько сот килогерц достижимо, но с уменьшением размеров девайсов будет уменьшаться громкость.
randomsimplenumber
05.11.2024 05:43Пора пробудить древнее зло ;) Входная цепь АОН или Спектрума - 1 компаратор. Скорость получается пристойная, никак не байты в секунду.
А в чем проблема подключить к телефону через OTG что угодно, USB - uart например?
RodionGork Автор
05.11.2024 05:43ходная цепь АОН или Спектрума - 1 компаратор. Скорость получается пристойная, никак не байты в секунду.
с той только разницей что всё же проводной канал а не микрофон :) но думаю что сравнимых скоростей "по воздуху" достигнем - в основном за счет того что возможности воспроизведения звука у нынешних телефонов довольно мощные (в смысле времени нарастания сигнала и т.п.)
А в чем проблема подключить к телефону через OTG что угодно
только в том что OTG не на всех телефонах
ну и скорее всего приложуху придётся писать, хотя какое-то веб-апи для работы с USB есть в браузерах. а приложухи писать - это доп.геморрой на Android/iPhone разделяться...
randomsimplenumber
05.11.2024 05:43ну и скорее всего приложуху придётся писать
Их >1 ;) нужно подобрать ту что умеет передавать файлы.
RodionGork Автор
05.11.2024 05:43ну да, а файл откуда возьмётся :) его надо скомпилировать
можно это делать в общей веб-страничке, как здесь, но тогда юзабилити получается на уровне "в страничке компилируем, потом копипастом сохраняем файл, потом программулиной его пытаемся прошивать" - вроде все ничего, но в сумме получается уныло.
и при том что это решение пригодится только для тех у кого OTG в телефоне таки найдётся. для одного себя это можно решить - а если класс на 20 человек, то хочется большей универсальности :)
randomsimplenumber
05.11.2024 05:43Использовать телефон для набирания и компилирования кода конечно же можно. Но зачем это превозмогание? Неудобно же. А если у кого-то телефон кнопочный?
имхо если у вас там какая то общая одинаковая программа для всех - то и материалы должны быть одинаковые. Если ориентироваться на то, что ни у кого ничего нет - можно переходить сразу к картонной клавиатуре и программированию на листочке бумаги. Программу можно писать на ассемблере, переводить вручную в машинные коды, и заливать в микроконтроллер самодельным программатором на переключателях.
RodionGork Автор
05.11.2024 05:43Использовать телефон для набирания и компилирования кода конечно же можно.
да, не супер удобно, но...
у нас несколько уроков в годовом курсе по электронике посвящены контроллерам и микропроцессорным основам. затащить откуда-то 20 компов на 20 человек и на все их установить нужный софт... тоже муторно выходит
randomsimplenumber
05.11.2024 05:43Учимся плавать, а если мы будем хорошо себя вести, нам воды нальют (ц)
Как то странно учиться плавать, если бассейна нет, и воду нужно свою приносить.
RodionGork Автор
05.11.2024 05:43неясно что вы предлагаете - закрывать лавочку и ничего не делать?
устраивайте свои кружки или курсы - обменяемся опытом :) а так в комментах рассуждать как в идеале хорошо было бы жить в идеальном мире - это трата времени
randomsimplenumber
05.11.2024 05:43устраивайте свои кружки или курсы
Сперва добейся (ц) ? ;)
неясно что вы предлагаете - закрывать лавочку и ничего не делать?
Чтобы учиться плавать - нужен бассейн. Хотя можно и на стадионе.
Чтобы учиться кататься на лыжах - нужен снег. Хотя можно и на асфальте.
sapiens sat.
RodionGork Автор
05.11.2024 05:43у меня есть бассейн, и плавать в нём можно, и желающие плавать есть
а у вас всё развлечение - по комментам на хабре бурчать
ну, каждому своё :)
RodionGork Автор
05.11.2024 05:43не серчайте, речь не про "сперва добейся" - тут добиваться особо нечего, тут дело делать надо. я говорю лишь о том что вы не в теме проблемы, даже особо не слушаете, но считаете своим долгом указать что всё-то ты делаешь не так, всё надо по-другому. это не очень конструктивно.
hw_store
05.11.2024 05:43Вторая жизнь биперов.... между прочим, при советской власти даже специальные чипы для биперов были.
jbourne
05.11.2024 05:43Вот даже продается штука, сделанная на подобных идеях (и там есть сравнение с аналогами):
RodionGork Автор
05.11.2024 05:43забавная штука, но тут речь не идёт о решении "для любых контроллеров" а подробностей вроде они не приводят :)
sim2q
05.11.2024 05:43На схеме с базы нужен резистор (10...100к) на GND или диод (катодом вверх).
RodionGork Автор
05.11.2024 05:43да, после написания статьи уже добавил диод, но пожалуй заменю на резистор по Вашей подсказке. каким образом работает без них я не оч понимаю - м.б. саморазряд конденсатора достаточный
kuzzdra
05.11.2024 05:43Обратите внимание на кодирование, которое в Спектруме
https://habr.com/ru/articles/510386/
Или в Радио-86РК - там манчестерское кодирование.
Ваш способ с широтно-импульсным кодированием для звука не очень.
И входной каскад противоречит законам природы - выходное сопротивление электретного микрофона большое, входное у транзистора маленькое.. Без смещения..RodionGork Автор
05.11.2024 05:43Про формат в спектруме я знаю, но, напомню, он работает при передаче по кабелю с линейного входа. При передаче через связку динамик-воздух-микрофон сигнал претерпевает изменения... иными словами переиспользовать вариант со спектрума "с полпинка" не получится, можете поэкспериментировать для любопытства (а может придумаете сразу как его улучшить) - но в эту сторону ещё подумаем
насчет законов природы думаю в данном случае какая-то нестыковка вкралась - выходное сопротивление стойки из резистора и микрофона - пара килоом. входное сопротивление ОЭ каскада - вещь деликатная когда нет резистора в эмиттерной цепи - оно определяется напряжением БЭ и током в базе - если ток мал, то сопротивление велико. можно считать что оно равно коэффициенту усиления умноженному на резистор в коллекторе. по-моему так.
но в целом я не ратую за данную схему и буду ещё модификации пробовать, может компаратор или ОУ затащить практичнее будет.
kuzzdra
05.11.2024 05:43сигнал претерпевает изменения
Начните с конденсатора. Сравните, как через него пройдет ваш сигнал и как спектрумовский.
TovarischSuhov
05.11.2024 05:43Вроде что-то подобное реализованно в умных колонках: Марусю точно можно таким образом настраивать. Хотя понятное дело сравнение не очень корректное: там и железо сильно помощнее, да и реализуется это в рамках полноценной системы, а не загрузчика.
RodionGork Автор
05.11.2024 05:43любопытно! а как эта фича называется чтобы загуглить, вдруг что про интерфейс пишут. не могу так сразу найти...
TovarischSuhov
05.11.2024 05:43Нашел только такое упоминание в документации: "подключение колонки по звуку.". В официальной докумнетации можно найти только упоминание, что такой функционал есть. Вся инструкция по настройкев ней сводится к краткому "Следуйте дальнейшим указаниям на экране". Самого приложения под рукой нет, чтобы посмотреть, как оно называется. Да и сходу по такому упоминанию особо ничего не нашлось(
RodionGork Автор
05.11.2024 05:43в любом случае спасибо - это ж круто, иметь возможность сказать что и у Маруси так сделано :)
Dr_Faksov
05.11.2024 05:43Не только в умных колонках. Практически все современные и не очень китайские камеры наблюдения имеют возможность настройки через звуковой канал (помимо оптического QR). Точно, что ещё попадались устройства с подобным видом коммуникации, но не могу вспомнить, что именно.
ciuafm
05.11.2024 05:43Напомню. В прошлом веке 8бит/8кГц канала хватало для передачи 56 кбод. Идея с бутлоадером изначально нежизнеспособна. Все равно нужно питание, микрофон, усилитель, етс.
Советую сделать программатор на ESP32, который будет работать с микрофоном, BT и WiFi по выбору. Внутри поместится как минимум v34, верю что АЦП 12 бит 2 МГц сможет оцифровать больше чем 3 кГц полосу. Но желателен обратный канал в каком-либо виде, хотя бы через светодиод и камеру мобилки, иначе будет тяжело с контролем ошибок.
kuzzdra
05.11.2024 05:43программатор на ESP32
Следующий шаг - программатор на raspberry, к которому можно подключить клавиатуру, мышку, дисплей, и прямо на нем писать код.
RodionGork Автор
05.11.2024 05:43а терминал с клавиатурой и дисплеем для AVR-контроллера гоняющего бейсик у меня где-то был уже сделан. естественно это не так легко масштабируется, поэтому дальше пушать эту идею я не стал
RodionGork Автор
05.11.2024 05:43Не очень понятно почему вы считаете что необходимость питания (батарейка + регулятор) и микрофона делают систему "нежизнеспособной". ESP32 это не микроконтроллер а целая система SoC. Насчет 12 бит при 2 МГц вроде бы Вы ошибаетесь. АЦП там такого же класса что и в AVR-ках - и там и здесь его можно на 1 или 2 МГц запустить но с потерей точности.
Напомню. В прошлом веке 8бит/8кГц канала хватало для передачи 56 кбод.
опять же напомню, это всё касалось проводной линии.
randomsimplenumber
05.11.2024 05:43это всё касалось проводной линии.
Никакой существенной разницы. У вас расстояние между источником и приемником звука значительно меньше длины волны. Многократных отражений быть не должно. Скопируйте входную цепь Спектрума и будет вам счастье.
Vladionair
05.11.2024 05:43Битпотоковое программирование не оно?! По идее та же самая работа с амплитудой сигнала.
checkpoint
05.11.2024 05:43Двухчастотный (FSK) демодулятор мог бы радикально решить Вашу проблему.
Вот простейшая реализация FSK на Verilog-е, можете его затолкать в Tang-Nano-1K и получить "over-the-air ISP". Замодулировать сигнал cо стороны мобилки проблем для Вас, как я понимаю, не составит.
Еще есть микросхема FSK демодулятора XR2211, но ей требуется +12V. Возможно есть что-то поновее.
Еще решение - однокристальный ИК приемник. Передавать можно модулированием "фонаря".
RodionGork Автор
05.11.2024 05:43Да, с мобильной стороны проблем не составит, с мощью джаваскрипта нафантазировать можно что угодно :) просто хотелось со стороны контроллера минимальной "обвязкой" обойтись, почему сперва и пробовал вообще голый микрофон к АЦП привязать. А так получается в общем-то вынести загрузчик в отдельную плату :) можно но удорожает решение, особенно в случае программирования чипов вроде AVR или STM32 которые сами по себе значительно дешевле чем Tang-Nano-1K если я правильно понимаю :)
FSK же вообще я пробовал (ради "гладкости" волны) но скорость показалась не фонтан (на каждый бит несколько периодов частоты тратилось). Если с текущей реализацией в какие-то проблемы воткнусь, м.б. ещё поразмышляю над FSK, спасибо.
randomsimplenumber
05.11.2024 05:43В esp8266 можно заливать код через wifi. Это 0 дополнительных денег, не благодарите;)
RodionGork Автор
05.11.2024 05:43благодарить не буду :) вы упорно не хотите понять о чем вообще речь, но почему-то вам очень понравилось комментировать все подряд замечания в этой статье :)
мы же говорим о прошивке потенциально любого контроллера. ESP8266 это не любой контроллер.
randomsimplenumber
05.11.2024 05:43мы же говорим о прошивке потенциально любого контроллера.
Не мы а вы ;) (ц)
кэп подсказывает, что микроконтроллеров очень много. абсолютно универсального программатора не существует, да и не нужен он никому. так что вы все равно под любым вы понимаете какое то их подмножество. esp 8266 - тоже подмножество.
Конфуций учит нас подбирать инструмент под задачу, а не наоборот. Ну, если задача - организовать прошивку без проводов - то она решается очень просто, если взять подходящий инструмент. Затея с микрофоном же - это визуализация анекдота про медведя и охотника, который в лес не на охоту ходит, евпочя ;)
вы упорно не хотите понять о чем вообще речь
Понимаю, у самурая нет цели, есть только путь ;) . Ок ;)
но почему-то вам очень понравилось комментировать все подряд замечания в этой статье :)
Ну, все мы немного самураи ;)
Klochko
05.11.2024 05:43А зачем Doom люди всюду запускать пытаются или San Andreas? А процессоры разгоняют так, что жидким азотом охлаждать приходится и целые лаборатории под это строить. Но а толку с этого?
Я тоже обратил внимание, что вы смотрите на задачи которые решает автор с какой-то практической точки зрения или коммерческого продукта. Хотя, судя по всему, не ту не другую цель автор не преследует.
Человек чего-то себе придумал и с этим теперь развлекается. Решил показать другим, поделится наработками. Он же не позиционирует себя как автора единого истинно правильного способа программировать МК. Просто нашел для себя интересную тему, добился определенных результатов и показал это публике. Ничего не предлагая и не навязывая .
Да есть OTG, есть разноплановые загрузчики по воздуху. Ну так и что :) Почему наличие этих средств должно остановить ТС в его исследованиях интересной ему темы?
randomsimplenumber
05.11.2024 05:43Я тоже обратил внимание, что вы смотрите на задачи которые решает автор с какой-то практической точки зрения или коммерческого продукта.
Ну, мне показалось, что это для радио кружка решение. Там, по легенде, компьютеров не выдают, и для программирования микроконтроллеров есть только телефон. Возможно я перепутал с другим автором, почему нет ;)
Почему наличие этих средств должно остановить ТС в его исследованиях интересной ему темы?
Почему мои комментарии должны кого то останавливать? ;) Я достаточно политкорректно обращаю внимание на места, которые можно улучшить.
Klochko
05.11.2024 05:43Кстати по поводу звука, может не совсем в тему, но может и в тему.
В 2013 году вышел фильм «Android» и бонусом к этому фильму шло приложение на OS Android. Тогда зрителям предлагали установить это приложение перед началом просмотра фильма.
По ходу действий в фильме приложение на смартфоне синхронизируется с приложением персонажей фильма. Допустим вечеринка, людям в фильме приходит сообщение и это же сообщение приходит к вам на телефон.
Я тогда быстро понял, что приложуха синхронизируется с аудио дорожкой фильма.
После этого сам загорелся сделать нечто подобное, но для МК. Но моих познаний математики не хватило и энтузиазм со временем угас. Но фильм запомнился))
Jury_78
Не проще ли перейти в оптический диапазон? У телефона есть экран, нужен фотоприемник. Остаётся вопрос в скорости передачи... :)
RodionGork Автор
конечно, прикидывали этот вариант - скорость никакая :) частота обновления экрана 60-100 Гц - по сравнению с десятками килогерц дискретизации звука - это несерьезно. 1-2 байта в секунду передавать можно. не помню уже в этой репе или где-то по соседству был тест этого варианта, но наверное и так всё понятно :)
Jury_78
Можно от последовательной передачи перейти к параллельной. Например 8 фотоприемников. Сложней конечно...
RodionGork Автор
да, для каких-то узких кейсов можно на это заморочиться (я уверен что в Юном Технике видел когда-то статью с идеей управления светомузыкой подобным образом через монитор БК) - но возрастающая сложность решения делает вариант со звуком более приемлемым :)
tormozedison
Не светомузыкой, а проектором слайдов.
gsaw
У меня был лет пятнадцать назад генератор ключей к онлайн банкингу. Его надо было для синхронизации прикладывать к экрану монитора, запускать программу. На экране быстро рисовались белые и черные полосы в окошке. Через несколько секунд было готово. Но там да, там наверное несколько байт передавались, для синхронизации, может подпись какая то еще. Нынешние микроконтроллеры c четвертью мегабайта памяти придется долго таким способом программировать. :)
RodionGork Автор
любопытная история :) касательно полос - я прикидывал и такую возможность как изображать программу штрих-кодом (видимо в несколько полос) и считывать её несколькими фотодатчиками... в идеале её тогда и на бумажке можно записывать - но в реализации и использовании выглядит жутко :)