Одним и тем же сигналом ФИМ (фазо-импульсной модуляции) управляется и ИК подсветка, и подсветка ЖК экранчика, чтобы и самому понаблюдать, что творится. ИК сколько-нибудь видна, но даже на максимальной яркости для человека очень тускла.
И первое же наблюдение: при 1/256 от максимальной яркости ВООБЩЕ ПОДСВЕТКА НЕ ВИДНА, ни одна!
Ещё и управление с компьютера идёт "рвано", видимо получая в ответ целую мегабайтную картинку, драйвер "виртуального ком-порта" немножечко впадает в ступор, так что надо и программу переиначить, чтобы при подаче этих символов, "+" или "-", он не торопился картинку передавать, потерпим!
С программы и начнём. Так мы раньше ожидали прихода символа по UART:
;далее мы хотим "бесконечный цикл", где мы записываем изображение в статическую память, выдаём самую простенькую информацию, ;и ждём нажатия на кнопку, чтобы передать всё изображение (это дохрена) @@FrameLoop: NOP IN ; ERL 0 ; ERH 0 ; ;давайте для начала почистим память! ; ;если не пожадничать и почистить весь мегабайт, не придётся сбрасывать ERL/ERH :) ; j 29 ; @@OuterCLR: Acc 24575 ;24576 * 30 = 1024 * 720 ; @@InnerCLR: [ER++] 0 ; SUB 1 ; JGE @@InnerCLR ; jLOOP @@OuterCLR ;хотим выждать свои 84 мс. Это свыше 2 кадров. На первый VSync, если повезёт, можем вообще попасть без задержки. ;до второго: 40 мс, до третьего: 80 мс. И давайте не жадничать: четвёртый кадр запишем j 12 @@WaitMenu: ACQ VSync ;дождаться кадрового синхроимпульса jLOOP @@WaitMenu
Дофига закомментированного кода - он использовался для обнуления памяти перед получением изображения, что помогало при отладке, "в какой момент в память попадает мусор"? Но когда мусор закончился, эти строки стали не нужны.
Как видно, у нас здесь в точности "нажмите любую клавишу" - UART используется лишь чтобы "затормозить" программу, пока чего-нибудь не придёт, а собственно пришедшее значение САМИМ ПРОЦЕССОРОМ не используется никак. Оно напрямую, "в обход процессора" управляет экранным меню камеры, а теперь ещё и подсветкой, а процессору вообще на всё пофиг сейчас.
Что ж, символы "+" и "-" имеют коды 0x2B и 0x2D соответственно, они идут перед любыми буквами и цифрами. Будем их "отсекать":
@@FrameLoop: Acc IN SUB 0x2E ;даст отрицательное значение для "+" и "-", положительные для букв JL @@FrameLoop
Дёшево и сердито. Попробуем такую штуковину отсинтезировать. В этот раз включил свой "более совершенный" алгоритм генерации ImmTable (таблицы непосредственных значений) - он очень сильно буксует на крупных программах с большой шириной шин адреса, но куда эффективнее срабатывает на маленьких, к каковым относится и нынешняя ImageTransfer.asm.
Возможно, скоро QuatCoreImmTable (таблица непосредственных значений) ждёт забвение, пришло в голову, что мы могли бы значения 0..127 по SrcAddr воспринимать не как значения -64..+63, как у меня было поначалу, а как обращение к памяти по адресам 0..127, и там "естественным образом" получается таблица непосредственных значений, т.е под неё специальной, отдельной памяти не надо, и есть надежда найти подходящие константы среди read-only строк и констант, определённых в памяти...
А пока "более совершенный" алгоритм свершил небольшое чудо, предельная частота 27,32 МГц, Critical Warning исчез - можно запускать.
Кое-чего начинает получаться, но на малых значениях яркости всё одинаково, хоть 1/256, хоть 1/8:
Начинаем видеть, как "разгораются" отражатели, на 1/4 яркости:
Именно сейчас видна сотовая структура отражателя, хотя по-моему она скорее "декоративная".
Теперь 1/2 яркости:
И полная яркость:
Что-то работает. Сейчас ещё осциллограммы возьму и громко подумаю...
