flybrain. передатчик + приемник + автопилот. powered by stm32
На данный момент засаду я вижу только одну.
Если работать с прерываниями в лоб, то частота 15,5кГц это перебор. Паразитных работ со стеком слишком много. Проц занимается только входом и выходом из процедуры. И даже если он там находится не много, все равно паразитная составляющая получается слишком дорогой. Но с другой стороны по факту сейчас я имею постоянных 8 источников прерываний:
- сигнал готовности данных с гиры - 400Гц
- Готовность акселя - 50 Гц
- готовность компаса - 30 Гц
- Опрос статуса и данных с барометра - около 25 Гц
- цикл опроса и сбора данных с датчиков - 1КГц
- Видео ССИ - 15,5кГц
- USB запросы - тут по разному
- I2C шина
И тем не менее, все работает в принципе. И отрабатывает нормально горизонт с EKF на частоте 400Гц и не пропускает циклы.
На горизонте еще маячит отрисовка OSD , опрос и парсинг GPS и сам алгоритм принятия решения о стабилизации. Но ни одна из этих задач не критична к фазовым сдвигам начала и окончания ее расчета. Все эти задачи могу отрабатывать по остаточному принципу, пока проц вне прерываний.Ну будем дальше двигаться, чего сейчас гадать, может ты и прав, а может нет. Увидим уже скоро.
Самая жара наступит, когда надо будет циферки и буковки формировать для осд, а также шкалы…
- У тебя есть отладочная плата на СТМ, чем её программируете и шьете?
leaf maple mini у неё ардуино ide и даже с натяжкой совместимость по коду. Так что очень удобно.
Единственная проблема - долго стартует. Пришлось долго извращаться для квадрика - не успевал пвм сигнал на регули поступать после подачи питания.
- Вроде как твой алгоритм построен на кватернионах? Подскажи, если не тайна, как вектора компаса и акселя приводишь к кватерниону? Код не нужно, лучше на словах.
У меня т.н. расширенный калман (екф), положение описывается в виде кватерниона. предиктор использует гиры, компас и аксель используются на шаге коррекции.
аксель:
ДЛЯ КАЖДОЙ ОСИ ПО-ОЧЕРЕДИ
вычисляем ожидаемые показания акселя из текущего кватерниона (который построен на шаге предикции на основе интегрирования гир) с учетом референсного вектора (X=0 y=0 z=1) далее коррекция, словами долго описывать ибо матричные операции.
магнитометр аналогично.
если есть желание - можно пообщаться в личке
Самая жара наступит, когда надо будет циферки и буковки формировать для осд, а также шкалы
Не думаю. У меня преимущество в том, что оперативки валом. Я могу один буфер 10кб выделить под экран + еще такой-же под shadow буфер. В shadow неспешно рисуем, а потом через DMA скидываем картинку в основной буфер. Еще есть вариант отрисовывать куски спрайтов в памяти CСM. У нее преимущество, она работает на частоте ядра и не требует циклов ожидания, но зато она с DMA не работает. Вообщем, я не вижу никаких реальных проблем.
Не думаю. У меня преимущество в том, что оперативки валом. Я могу один буфер 10кб выделить под экран + еще такой-же под shadow буфер. В shadow неспешно рисуем, а потом через DMA скидываем картинку в основной буфер. Еще есть вариант отрисовывать куски спрайтов в памяти CСM. У нее преимущество, она работает на частоте ядра и не требует циклов ожидания, но зато она с DMA не работает. Вообщем, я не вижу никаких реальных проблем.
А как решен вопрос видеомодулятора (схемы, которая вносит изменения уровня яркости в видеосигнал для графики), если не секрет?
А как решен вопрос видеомодулятора
Нет, не секрет. Все электрические схемы текущего рабочего прототипа опубликованы на первых двух страницах темы. Изменений практически никаких внесено не было. Как изначально было задумано в теории, так все на практике и заработало.
миром правит Тимофей
Делают-то оно конечно делают.
Но до коммерческих образцов чета не доходят.
На этом форуме заикнись про коммерцию - сразу банят. А Тимофей процветает почему-то.
На этом форуме заикнись про коммерцию - сразу банят. А Тимофей процветает почему-то.
Платите за рекламу - и никто никого не забанят. Я так понимаю.
логично, вопрос снят.
На этом форуме заикнись про коммерцию - сразу банят. А Тимофей процветает почему-то.
Извините меня, пожалуйста, если это так мозолит вам глаза и не дает жить спокойно. К сожалению, не могу ответить вам взаимностью - не считаю корректным высказывать свое мнение о чужой работе, если только не хочу чем-то помочь.
В своей теме на форуме я стараюсь говорить только о технических деталях, без рекламы и ссылок и прочего, и никуда в соседние ветки не лезу. Получается этакий вариант техподдержки. Только поэтому, думаю, меня еще терпят.
Олег, тебе ж никто не запрещает продавать свои изделия на стороне, а обсуждать подробности алгоритмов- здесь. Как и мне тоже, впрочем 😃
[deleted]
Cообщения с №275 и далее надо стереть как офтоп.
Прошу прощения у топик-стартера за разведение свинарника в чужой теме 😁
Я не делал каких-то специальных телодвижений для этого, просто слежу за своими словами и не лезу на рожон. Может быть, админы привыкли, я ж здесь с 2007 года железки программирую. А, может быть, реально просто не хотят убивать тему и убирать меня с форума - пользователи останутся без поддержки. В любом случае, админам за это спасибо.
Тихо, тихо. Я по коммерческими образцами имел ввиду законченные работающие изделия. Которые не вдаваясь в подробности алгоритмов и без танцев с бубном можно подключать и летать.
Здесь не о торговле идет речь.
Некоторые проекты тут громко начинались, но со временем их ветки умирали.
Особенно те где много было “Я, у меня, не вижу проблем и т.п”
Ок. Давайте тогда извинимся перед ТС и в качестве пряника и чтоб загладить вину предложим вариант решения проблемы с правильным временем старта ДМА для вывода видеостроки.
То, что ТС предлагает сейчас, выглядит жутковато.
Мне кажется, надо строчные синхроимпульсы завести на ногу, которая умеет работать как ICP и защелкнуть значение таймера в момент восходящего или нисходящего (по желанию) фронта.
Таймер завести на реально высокую частоту, 36 МГц, например.
Дальше, свалившись в прерывание строчного синхроимпульса, надо еще раз напрямую прочитать значение счетчика таймера и получить разницу. Эта разница, очевидно, будет переменной, ибо прерываний много и гарантии свалиться в прерывание ровно за Х клоков нет. Дальше от этой разницы добить пустым циклом ожидания до какой-то заранее заданной константы, физически означающей смещение накладываемых видеоданных по горизонтали, и уже запускать DMA.
Дальше от этой разницы добить пустым циклом ожидания
Самая огромная засада в том, что в АРМ 3 памяти: флешка, срам и кэш. Если пустой цикл дергается внутри кэша, он крутится быстро. Если инструкции подаются из флешки - медленнее от 2 до 3 раз.
Оптимальным был бы аппаратный триггер запуска DMA-трансфера сразу по ССИ. Но синхропаузу и вспышку (8 мкс) придется пропускать путем передачи полезной части видеобуфера, забитой нулями.
Чтобы работало по вашей версии, нужно иметь всего одно прерывание в системе - по ССИ, а остальные хандлить программно уже после команды на ДМА-трансфер. Т.е. минимальное время между раздельными событиями будет фиксированно 64 мкс.
А кто-нибудь вообще мерял время входа в прерывание по таймеру на АРМ? Из собственного печального опыта, на TMS320С6728 с его 1.2 GFLOPS вход в таймерное прерывание занимает целых 7 мкс!
===
Появилась другая идея: вход “одноразового таймера” запараллелить с обычным прерыванием по фронту. Процесс: поступает ССИ, генерирует NMI по ноге и одновременно запускает таймер. Через какое-то неопределенное время включается обработчик NMI, в нем читаем таймер, делаем пропорциональную задержку циклом с чтением таймера и заряжаем DMA.
Профит.
И совершенно фиолетово на загруженность системы.
Таймер можно ставить на 8 МГц, квантование будет незаметным.
Самая огромная засада в том, что в АРМ 3 памяти: флешка, срам и кэш. Если пустой цикл дергается внутри кэша, он крутится быстро. Если инструкции подаются из флешки - медленнее от 2 до 3 раз.
Оптимальным был бы аппаратный триггер запуска DMA-трансфера сразу по ССИ. Но синхропаузу и вспышку (8 мкс) придется пропускать путем передачи полезной части видеобуфера, забитой нулями.Чтобы работало по вашей версии, нужно иметь всего одно прерывание в системе - по ССИ, а остальные хандлить программно уже после команды на ДМА-трансфер. Т.е. минимальное время между раздельными событиями будет фиксированно 64 мкс.
А кто-нибудь вообще мерял время входа в прерывание по таймеру на АРМ? Из собственного печального опыта, на TMS320С6728 с его 1.2 GFLOPS вход в таймерное прерывание занимает целых 7 мкс!
Как-то у АВР это дело обстоит проще, может автору часть связанную с осд нужно перевести на АВР и не городить аппаратную видеоразвертку, а сделать программную?..
Нет, не секрет. Все электрические схемы текущего рабочего прототипа опубликованы на первых двух страницах темы. Изменений практически никаких внесено не было. Как изначально было задумано в теории, так все на практике и заработало.
Вы уж извините, но не могу разобрать в таком качестве картинку, где там элементы отвечающие за видеомодулятор, может датите ссылку, не сочтите за труд на лучшую картинку, или саму часть осд системы.
Вы уж извините, но не могу разобрать в таком качестве картинку, где там элементы отвечающие за видеомодулятор, может датите ссылку, не сочтите за труд на лучшую картинку, или саму часть осд системы.
удалось наконец-то скачать схему в лучшем качестве. Я так понимаю, видеомодулятор основан на так называемой “диодной схеме”. Вопрос такой, а как дело обстоит с тенями у этого видеомодулятора. Имеется ввиду, что для лучшей читабельности символов, по контуру последних, формируется темные пиксели…?
видеомодулятор основан на так называемой “диодной схеме”.
как и во всех Е-ОСД-подобных штучках. Или символы на затененных знакоместах, или темный квадрат на все графическое поле, больше никак.
Для получения тени нужно или 1) городить grayscale-буфер, чтобы программно дорисовывать черные пиксели до, после, сверху и снизу, или 2) городить схему затенения, как делал MSV.
Появилась другая идея: вход “одноразового таймера” запараллелить с обычным прерыванием по фронту.
Олег, я именно так изначально и задумывал. Посмотри на схему. Я завел специально на две ноги. Одна - вход таймера, друга прерывание по фронту. Таймер должен стартовать со своего канала всегда по положительному фронту, а потом спустя неопределенное время мы входим в прерывание. Дальше читаем таймер, который уже стартовал аппаратно и вычисляем паузу. Оно изначально так было задумано, и этот вариант я по прежнему держу в загашнике. Он 100% рабочий. Но я для начала хочу свой вариант на каскадных таймерах опробовать. Я хочу сначала попытаться уйти от софтовых прерываний в процессе развертки видимой части кадра вообще. Вчера я выяснил, что не получится два таймера соединить внутри кристалла штатно, так как получается мне нужно слейв-слейв, а без внешних перемычек получается только мастер-слейв. Пришлось еще один провод тащить внешний. Если бы не это, у меня уже вчера бы все заработало. Сейчас вот каскадная схема на таймерах абсолютно четко генерит окно от начала старта первого таймера с регулируемой задержкой и SPI стартует автоматом в промежутке окна. Я подобрал все тайминги, вывод SPI можно размером окна регулировать с точностью до пиксела, и DMA можно не перезаряжать на каждой строке, достаточно просто первый таймер стартовать и все, больше совсем ничего не надо. Единственный нюанс - последний пиксел в конце каждой строки должен быть обязательно погашен, но это приемлемый побочный эффект, с которым можно спокойно жить, если помнить, что он есть.
Короче, подождите до выходных, я окончательно проверю свой вариант, потом уже выводы будем делать.
Вопрос такой, а как дело обстоит с тенями у этого видеомодулятора.
Никак, я не собирался в прототипе это городить. В чистовой версии можно завести еще один выход SPI3 до кучи и гнать оттуда тени с задержкой в 1 пиксел. Либо городить схему на дискретных элементах. Сейчас я по простому завел еще диод для уровня серого, чтобы при необходимости как-то воспользоваться.
Оптимальным был бы аппаратный триггер запуска DMA-трансфера сразу по ССИ.
Я уже писал страницу назад, что такая фича вообще сняла бы все проблемы. Но ее нет. DMA в STM работает слейвом. С таймеров DMA умеет только значения регистров брать. Поэтому управлять надо именно запуском SPI в слэйв режиме.
Ок. Давайте тогда извинимся перед ТС и в качестве пряника и чтоб загладить вину предложим вариант решения проблемы с правильным временем старта ДМА для вывода видеостроки. То, что ТС предлагает сейчас, выглядит жутковато.
Смотри мой ответ Олегу, я этот вариант с самого начала в голове держал.
Моя позиция такая - всегда софтово можно извернуться, но это крайний вариант и на него всегда можно перейти. Мне как раз “вставляют” аппаратные решения, разгружающие процессор от ненужной работы.
А кто-нибудь вообще мерял время входа в прерывание по таймеру на АРМ?
Я не мерял, но по косвенным признакам вижу, что документации оно не соответствует. Особенно для варианта, когда прерывание из прерывания отрабатывается. Ты вот еще только начал в STM погружаться, а я год назад начал осваивать. И за этот год сделал один неоспоримый вывод. Доку в STM пишут по остаточному принципу, типа и так сойдет, кто надо тот сам разберется. Что ты там про ноющие зубы писал при инициализации таймера? Ну так вот, как только ты например попытаешься ADC запустить с чтением через DMA и запуском от таймера, или например прерывания какие правильно обработать от периферии, у тебя не просто зубы ныть будут, у тебя появится желание взять молоток и треснуть этот STM посильнее и совсем забыть про него. Могу также предсказать какая истерика у тебя случиться, если ты попытаешься посмотреть в исходники STD Perif Lib, которую они предлагают использовать. АВР в этом отношении просто гладкая и пушистая лапочка.
АлексСнег, у тебя i2c через DMA работает? Как запускаешь старт и передачу адреса?
у тебя i2c через DMA работает
Я пробовал через DMA, но в результате остановился на прерываниях. Оно так более контролируемо и предсказуемо. Через ДМА все равно придется работать на прерываниях на фазах старт-адрес-регистр-рестарт. ДМА может работать только в фазах передачи данных или приема. Причем должно быть не менее, чем 2 байта. Короче, овчинка выделки не стоит.