 |
Специальные цены | новые товары |  |
 |
 |
Тема раздела Полеты по камере, телеметрия в категории Cамолёты - Общий; Я не делал каких-то специальных телодвижений для этого, просто слежу за своими словами и не лезу на рожон. Может быть, ...
Я не делал каких-то специальных телодвижений для этого, просто слежу за своими словами и не лезу на рожон. Может быть, админы привыкли, я ж здесь с 2007 года железки программирую. А, может быть, реально просто не хотят убивать тему и убирать меня с форума - пользователи останутся без поддержки. В любом случае, админам за это спасибо.
Тихо, тихо. Я по коммерческими образцами имел ввиду законченные работающие изделия. Которые не вдаваясь в подробности алгоритмов и без танцев с бубном можно подключать и летать.
Здесь не о торговле идет речь.
Некоторые проекты тут громко начинались, но со временем их ветки умирали.
Особенно те где много было "Я, у меня, не вижу проблем и т.п"
Ок. Давайте тогда извинимся перед ТС и в качестве пряника и чтоб загладить вину предложим вариант решения проблемы с правильным временем старта ДМА для вывода видеостроки.
То, что ТС предлагает сейчас, выглядит жутковато.
Мне кажется, надо строчные синхроимпульсы завести на ногу, которая умеет работать как ICP и защелкнуть значение таймера в момент восходящего или нисходящего (по желанию) фронта.
Таймер завести на реально высокую частоту, 36 МГц, например.
Дальше, свалившись в прерывание строчного синхроимпульса, надо еще раз напрямую прочитать значение счетчика таймера и получить разницу. Эта разница, очевидно, будет переменной, ибо прерываний много и гарантии свалиться в прерывание ровно за Х клоков нет. Дальше от этой разницы добить пустым циклом ожидания до какой-то заранее заданной константы, физически означающей смещение накладываемых видеоданных по горизонтали, и уже запускать DMA.
Самая огромная засада в том, что в АРМ 3 памяти: флешка, срам и кэш. Если пустой цикл дергается внутри кэша, он крутится быстро. Если инструкции подаются из флешки - медленнее от 2 до 3 раз.Сообщение от smalltim
Оптимальным был бы аппаратный триггер запуска DMA-трансфера сразу по ССИ. Но синхропаузу и вспышку (8 мкс) придется пропускать путем передачи полезной части видеобуфера, забитой нулями.
Чтобы работало по вашей версии, нужно иметь всего одно прерывание в системе - по ССИ, а остальные хандлить программно уже после команды на ДМА-трансфер. Т.е. минимальное время между раздельными событиями будет фиксированно 64 мкс.
А кто-нибудь вообще мерял время входа в прерывание по таймеру на АРМ? Из собственного печального опыта, на TMS320С6728 с его 1.2 GFLOPS вход в таймерное прерывание занимает целых 7 мкс!
===
Появилась другая идея: вход "одноразового таймера" запараллелить с обычным прерыванием по фронту. Процесс: поступает ССИ, генерирует NMI по ноге и одновременно запускает таймер. Через какое-то неопределенное время включается обработчик NMI, в нем читаем таймер, делаем пропорциональную задержку циклом с чтением таймера и заряжаем DMA.
Профит.
И совершенно фиолетово на загруженность системы.
Таймер можно ставить на 8 МГц, квантование будет незаметным.
Последний раз редактировалось Syberian; 14.03.2012 в 22:47.
Как-то у АВР это дело обстоит проще, может автору часть связанную с осд нужно перевести на АВР и не городить аппаратную видеоразвертку, а сделать программную?...
Вы уж извините, но не могу разобрать в таком качестве картинку, где там элементы отвечающие за видеомодулятор, может датите ссылку, не сочтите за труд на лучшую картинку, или саму часть осд системы.
удалось наконец-то скачать схему в лучшем качестве. Я так понимаю, видеомодулятор основан на так называемой "диодной схеме". Вопрос такой, а как дело обстоит с тенями у этого видеомодулятора. Имеется ввиду, что для лучшей читабельности символов, по контуру последних, формируется темные пиксели...?
как и во всех Е-ОСД-подобных штучках. Или символы на затененных знакоместах, или темный квадрат на все графическое поле, больше никак.
Для получения тени нужно или 1) городить grayscale-буфер, чтобы программно дорисовывать черные пиксели до, после, сверху и снизу, или 2) городить схему затенения, как делал MSV.
Олег, я именно так изначально и задумывал. Посмотри на схему. Я завел специально на две ноги. Одна - вход таймера, друга прерывание по фронту. Таймер должен стартовать со своего канала всегда по положительному фронту, а потом спустя неопределенное время мы входим в прерывание. Дальше читаем таймер, который уже стартовал аппаратно и вычисляем паузу. Оно изначально так было задумано, и этот вариант я по прежнему держу в загашнике. Он 100% рабочий. Но я для начала хочу свой вариант на каскадных таймерах опробовать. Я хочу сначала попытаться уйти от софтовых прерываний в процессе развертки видимой части кадра вообще. Вчера я выяснил, что не получится два таймера соединить внутри кристалла штатно, так как получается мне нужно слейв-слейв, а без внешних перемычек получается только мастер-слейв. Пришлось еще один провод тащить внешний. Если бы не это, у меня уже вчера бы все заработало. Сейчас вот каскадная схема на таймерах абсолютно четко генерит окно от начала старта первого таймера с регулируемой задержкой и SPI стартует автоматом в промежутке окна. Я подобрал все тайминги, вывод SPI можно размером окна регулировать с точностью до пиксела, и DMA можно не перезаряжать на каждой строке, достаточно просто первый таймер стартовать и все, больше совсем ничего не надо. Единственный нюанс - последний пиксел в конце каждой строки должен быть обязательно погашен, но это приемлемый побочный эффект, с которым можно спокойно жить, если помнить, что он есть.
Короче, подождите до выходных, я окончательно проверю свой вариант, потом уже выводы будем делать.
Никак, я не собирался в прототипе это городить. В чистовой версии можно завести еще один выход SPI3 до кучи и гнать оттуда тени с задержкой в 1 пиксел. Либо городить схему на дискретных элементах. Сейчас я по простому завел еще диод для уровня серого, чтобы при необходимости как-то воспользоваться.
Я уже писал страницу назад, что такая фича вообще сняла бы все проблемы. Но ее нет. DMA в STM работает слейвом. С таймеров DMA умеет только значения регистров брать. Поэтому управлять надо именно запуском SPI в слэйв режиме.
Смотри мой ответ Олегу, я этот вариант с самого начала в голове держал.
Моя позиция такая - всегда софтово можно извернуться, но это крайний вариант и на него всегда можно перейти. Мне как раз "вставляют" аппаратные решения, разгружающие процессор от ненужной работы.
Я не мерял, но по косвенным признакам вижу, что документации оно не соответствует. Особенно для варианта, когда прерывание из прерывания отрабатывается. Ты вот еще только начал в STM погружаться, а я год назад начал осваивать. И за этот год сделал один неоспоримый вывод. Доку в STM пишут по остаточному принципу, типа и так сойдет, кто надо тот сам разберется. Что ты там про ноющие зубы писал при инициализации таймера? Ну так вот, как только ты например попытаешься ADC запустить с чтением через DMA и запуском от таймера, или например прерывания какие правильно обработать от периферии, у тебя не просто зубы ныть будут, у тебя появится желание взять молоток и треснуть этот STM посильнее и совсем забыть про него. Могу также предсказать какая истерика у тебя случиться, если ты попытаешься посмотреть в исходники STD Perif Lib, которую они предлагают использовать. АВР в этом отношении просто гладкая и пушистая лапочка.
Последний раз редактировалось AlexSneg; 15.03.2012 в 10:46.
АлексСнег, у тебя i2c через DMA работает? Как запускаешь старт и передачу адреса?
Я пробовал через DMA, но в результате остановился на прерываниях. Оно так более контролируемо и предсказуемо. Через ДМА все равно придется работать на прерываниях на фазах старт-адрес-регистр-рестарт. ДМА может работать только в фазах передачи данных или приема. Причем должно быть не менее, чем 2 байта. Короче, овчинка выделки не стоит.
Блин, чуваки, не обижайтесь, но эт чет в радиолюбительский форум переростает.
Где полеты по камере и телеметрия?
Довайте обсуждать этапы создания девайса с каким-либо функционалом.
Или не?
Если в соседних ветках обсуждают инструмент и способ обработки профиля крыла, то это значит столярный форум?
Но с тем что, мой вопрос узко специален согласен, буду писать в личку.
У меня до этого ещё далеко.
Дык вроде как и речь ведём о реализации некоего функционала.
Ну вот будет реализовано осд, можно будет обсудить его функционал. А так уже до старт-рестарт dma дошли.
Именно он.
Довайте результаты уже скорее.
Согласен. Давайте подождем, пока я не покажу как OSD работает, потом обсудим, как и что на экране мне нарисовать. Все желающие спросить по узкоспециализированным моментам могут спросить в личку. Я в течение рабочего дня всегда отвечу.
Туда следует смотреть с целью понять чего вскользь не упомянули в даташите. Хотя перенимать их не стоит- индусам что их писали платили очевидно за каждую строчку кода. инициализация регистров периферии - почти 6 килобайт коданапример чтобы загрузить регистр битрейта usart там строчек 10 написано вместо одной операции деления. А в документации ваще опусы - много воды налито- дробная часть, целя часть- голову сломаешь, вместо того чтобы поделить частоту на битрейт..
холи щет
Цитатка в тему:
http://bash.im/quote/416071
(изменено)
Как я обожаю даташиты для STM!
"Это винтик, это отвертка, винтик можно крутить отверткой. Это всякие железяки, их можно соединять винтиками, закрутив отверткой. Еще бывают гайки и шестеренки.
Задание:
Постройте синхрофазотрон."
Итак отчетец по борьбе за OSD.
Можно сказать, что теория подтвердилась полностью практикой.
Сейчас мне удалось добиться почти полностью аппаратной развертки всего поля. Работает это примерно так:
1. Слушаем все прерывания ССИ до обнаружения начала кадра.
2. Начало кадра обнаружено, пускаем таймер для пропуска 55 строк примерно. прерывания отключаем.
3. приходит прерывание от таймера. Перезаряжаем таймер на 18 мс, чтобы гарантировано вывалится в новое прерывание и не пропустить кадровый импульс следующего кадра, если что-то пойдет не так. Здесь же заряжаем ДМА на начало видео буфера и запускаем: Таймер, который запускается по фронту следующео ССИ, он генерит точно подобранное окно с задержкой примерно 15мкс и скважностью в которую умещается 32 байта - одна строка; это окно разрешает каскадный таймер, который подает синхру на SPI, работающий слэйвом. SPI заряжен и подключен к DMA каналу, который заряжен на начало видеобуфера.
4. Дале все происходит автоматом. Все прерывания от ССИ отключены, таймер автоматом ловит очередной фронт на каждой строке и SPI разворачивает одну строку за другой, так до конца ДМА буфера. При этом вмешательства софтового в этот процесс нет никакого. Оно само все происходит.
5. По окончании ДМА генерит прерывание, в котором отключаем SPI и охранный таймер, заряженный в п.3. Он нам больше не нужен. Его мы перезаряжаем для пропуска примерно 50 строк. Подобрано так, чтобы попасть к началу ожидаемого кадрового импульса
6. Срабатывает прерывание от таймера, разрешаем прерывания от ССИ и идем на пункт 1
Таким образом, практически все само разворачивается. Качество картинки превосходит все ожидания.
Сделал алгоритмы для засветки пиксела, линии, окружности, знакогенератор прикрутил, попробовал. Ну вообще все шоколадно. Просто в любой момент времени рисуем в видео буфере любые рисунки и даже не думаем ни о чем. Ну как в Spectrum'e в свое время практически было. Можно ради прикола пакмэна организовать. Проц практически полностью освобожден от OSD, я даже прерывания ССИ убрал с самого высокого приоритета на 3-е место. На первом оставил I2C шину.
Побочные эффекты:
1. Первый пиксел в первом байте строки должен всегда быть нулевым, иначе в текущей схемотехнике это сорвет синхру.
2. Есть странный сдвиг развертки самой первой линии на 1 знакоместо (8 бит), она получается 31 байт. Не понял почему так. Причем при старте сначала картинка стоит нормально около 3 сек, а затем смещается именно в такое положение и там уже стоит намертво. Пока я не понимаю почему это так. Но все остальные линии разворачиваются четко и без проблем. Фактически достаточно считать, что первая линия не рабочая и начинать рисовать со второй линии, а снизу добавить еще одну. Это совсем не есть проблема, просто первые 31 байт будут балластом. У меня есть подозрение, что первое знакоместо занято нулевыми данными, которые остаются в SPI после окончания предыдущего кадра. Их он как раз и вываливает в новом кадре, а дальше уже идет нормально все. Я еще поковыряюсь с этим делом, засечь причину достаточно сложно даже дебаггером, так как все надо смотреть в риалтайме. Но даже если я не найду почему так, можно с этим спокойно жить. Развертке этот эффект не мешает никак.
На этой неделе буду уже картинку рисовать и сделаю вам видео, на посмотреть как все получилось. Скачал разных видюх с OSD посмотрел в динамике. Пока остановился на на повторении варианта RVOSD. Если есть какие пожелания на тему удобства и недостатков текущих OSD, давайте выкладывайте. Будем думать, как сделать максимально удобно.
Очень понравился стиль отображения горизонта в bvHUD (ODS Олега), было бы здорово исполнить похожую шкалу тангажа, если конечно Олег не будет возражать
Последний раз редактировалось Дми-III-й; 19.03.2012 в 16:21.
Я в этом варианте не очень понимаю где верх, а где низ самолета. Это ведь тестовая видюха. Нет такой-же, но с реального полета?
Верх когда шкала с пямыми делениями, а когда с наклонными это низ. ИМХО очень наглядный вариант отображения горизонта и углов тангажа.
Вот идеал подобного отображения горизонта
Последний раз редактировалось Дми-III-й; 19.03.2012 в 18:17.
Не совсем понятно...
Вот ОСД Икаруса. Может что отсюда возьмете.
может для профессиональных летчиков, это идеал. Но я бы грохнулся с такой шкалой сразу. У вас там СУ-25 еще в видео есть. Вот оно мне очень понравилось. Может как у СУ-25 забацать?
Нет, слишком уж просто выглядит. И переворот на спину не читаем, по крайней мере, на этом видео.
В RVOSD я вот четко вижу короткую и длинную линию. короткая снизу - норма, короткая сверху - кувыркнулись на спину. Линии внизу, значит вверх летим, вверху, значит падаем. Дом в центре, риска по кругу - направление домой.
Все верно, похоже Олег делал отображение горизонта похожим на F-16
Чем именно такой вариант хорош думаю понятно - позволяет оценивать углы крена и тангажа сразу в цифрах, полностью контролировать любое нештатное положение самолета "по приборам" при отсутствии видимости, например в облаках, что немаловажно. Упростить ведь всегда можно и сделать несколько вариантов отображения.
Там как я понял "боевой" режим экрана HUD, поэтому все "лишнее для войны" с экрана спрятано чтобы было видно целеуказатели
Ну вот с этой видюхи, мне более менее все понятно стало. Единственный момент, почему иногда шкала за пределы экрана уезжает. Почему ее просто в центре не фиксируют?
Я думаю там шкала смещается в зависимости от скольжения самолета, видимо пилотам так удобнее... можно и зафиксировать
Ладно поробуем прикунуть этот вариант. Надо подумать как графику, а особенно цифры поворачивать. Боюсь на некоторых углах артефакты некрасивые появятся.
Олег в своей OSD цифры не поворачивает, видимо исходя из таких же соображений
Издеваетесь, что ли
Линии горизонта делал не совсем "копийными", т.к. это получается несколько сегментов с отдельной кучей вычислений.
Ну блин, придет арм4, такой графон забабашу... Если Алекс меня не обскачет
Там как видео заканчивается, сразу "шахматка" с другими видео - своих насчитал 4 штуки.
Зачем? Ты голову крутить собрался?
Потому что пока не знают как надо.
Я выбрал вариант 6x8. Но вращать, наверно, тоже не буду пока, ибо все равно будет отвратно.
А зачем ты на сегменты бьешь? Я думал ты хранишь вершины, их и вертишь. А уже между ними прямые линии проводишь.
Олег, меня радует твой оптимизм. Но тебе предстоит еще много "чудных" открытий истины по ходу изучения STM32. К тому же DISCOVERY4 это не, что тебе нужно. На мой взгляд, это вообще выброшенные на ветер бабки.
Я не ставлю цель с кем-то в перегонки играть.
Пока в планах иметь OSD рабочее к 1 апреля.
Типа бестолковые американские летчики не знают, как им удобно?
По результатам вчерашних ночных посиделок докладываю:
1. Побочный эффект №2 из предыдущего поста побежден. Имеем четкую, гладкую развертку 256X192
2. Остается ограничение на засветку нулевого пиксела в каждой строке. Делать этого просто НЕЛЬЗЯ. Это особенность схемотехники, возможно в чистовой версии, когда буду заказывать заводские печатки это будет устранено.
3. Не рекомендуется зажигать старший пиксел в самом последнем байте развертки. Синхру это не собьет, но вызовет засветку еще 2 пикселов за пределами развертки. Природа этого эффекта на 100% понятна. Побороть чисто программно нельзя. Будет исправлено изменением чистовой схемотехники.
Вот все. Поле развертки готово. Обдумаю детали реализации и приступаю к рисованию графики на этой неделе. Рисовать будем вариант как на F16. Зафиксирую точку поворота шкалы в центре, ибо не понимаю нафига горизонт по всему экрану катать. Цифры на шкале крутить не буду, ибо Дринкер прав, читать их под углом будет неудобно. Шкалу направления домой и компас думаю совмещу, как на СУ-25. Оно мне понравилось больше всех.
А что являецца источником видеосигнала в этих опытах?
Или просто видеогенератор делаеш? Тогда это ни разу не осд.
Если с источником, то что будет когда сигнал пропадёт? Внутри будет синхра генерицца, или все зависнет нафиг?
И как решен вопрос теней? Без них очень трудно на светлом фоне чтото разглядеть.
пал - нтсц распознаёцца?
И где в поделке датчик тока и напряжения?
Пока достаточно
Фотоаппарат Olimpus, генерит широкоформатный PAL.
У меня есть опасения, что разные источники могут не следовать стандартам. На той неделе китайцы прислали NTSC камеру SONY для полетов. Она 12В хочет. Как не лень будет, воткну ее, проверю. Сам я видео сигнал не генерю ни разу.
Реально я пробовал с двух фотиков сигнал щупать. Оба они по разному генерят кадровый импульс. Но не фатально. Разница в алгоритме детектирования не существенна. Есть у меня еще старый видик и видеокамера ручная. Попробую с них попозже взять сигнал.
В любом случае, это не проблема. Техника исследования реального сигнала и всех его перепадов с точностью до 1 мкс у меня отработана. В финальной версии вообще забабахаю автодетект с подбором порога чувствительности компаратора.
Если сигнал пропадет, то пропадет и картинка, но ничего не зависнет. Будет ждать, когда появится. Если появится, то OSD опять включится. Алгоритму по фиг, есть видеосигнал на входе или его нет. А работать генератором синхры я не планировал, хотя можно реализовать аппаратно в чистовом варианте, если есть у летающей аудитории такое желание и реально существует такая необходимость.
Я не показываю видео, как все работает исключительно потому, что надо сначала в динамике горизонт иметь, чтобы интересно смотреть было. Однако если аудитория сильно жаждет, могу вечером снять картинку с экрана телевизора. Но там могу в динамике только порисовать буковки, линии, кружочки поверх видео, которое фотик передает. Горизонта пока нет.
на данный момент никак, я уже обсуждал это. В финальной схемотехнике решим скорее всего аппаратно внутри модулятора. Где-то я уже видел здесь на форуме рабочее решение. Делать тени программно я не буду. Если у тебя есть предложения, я с удовольствием послушаю.
пока ПАЛ. NTSC буду еще обучать.
Ты совсем самое начало темы не читал если такие вопросы задаешь?
Последний раз редактировалось AlexSneg; 20.03.2012 в 11:41.
Видео - в студию!
Автор не обращай внимания, многие из присутствующих тут, строят свое ОСД. И у них "сосет под ложечкой", когда видят, что у кого-то быстрее получается. Может автор - проффесионал.
ИМХО это не то, чтобы жизненная необходимость, но немного повышает надежность системы.
+1
Скорее всего, ибо делает то что умеет.
Вернецца к алгоритмам стабилизации и управления - будет куча вопросов.
Нихренаж себе! Камера запотела, сломалась, шнур отошел - и всё, самик потерян. А с генерацией синхры осд будет продолжать работать и можно попытацца по приборам долететь до зоны визуального контакта.
Не нашол про это.
Если запотела - OSD не пропадет, только картинка.
Андрей, а сколькие из известных Вам OSD умеют работать при отсутсвии видеосигнала? Я только Фишкин AP117 знаю.
PS: И если иречь идет о полноценном АП, то он будет возвращать модель и без OSD.
+100
Я нафига ж, все это затеял? Все в одном флаконе. Нет сигнала, включай возврат, оно прилетит.
Ну я заложу в схемотехнику генератор аппаратный, но реализовывать на первом этапе не буду. Потом, в качестве дополнительных софтовых опций будет.
Сделаю вечером, но особой анимации не ждите. Накидаю разной тестовой графики, так чтобы время на это не тратить. Реально горизонт будет рисоваться на выходных.
Ищи лучше. Мы с baychi обсуждали как пользователи со стандартным PPM смогут к моему проекту подключиться. В этот же модуль будут заводиться все возможные датчики, которые аудитория захочет. Вот чего скажете, то и заведу на входа.
Я работаю четко по намеченному плану. Не надо бежать впереди паровоза. Все будет. Я ж тебе обещал уложиться в сроки до 1 июля? Значит будь терпеливым.
Последний раз редактировалось AlexSneg; 20.03.2012 в 14:09.
Все, которые на maxim
Икарус выводид осд без видеосигнала.
smalltim OSD, как я понимаю, не умеет работать генератором, однако никто из пользователей не считает это большой проблемой. И теней там вроде тоже никаких нет. Городить OSD на maxim это +600руб (а то и +1000руб) к себестоимости и дополнительное место на плате. И, ИМХО, отдача от этого дела не перекроет вложенные средства. Лучше эти 600руб потратить на GPS модуль.
Ваши права
