flybrain. передатчик + приемник + автопилот. powered by stm32
Хочу намекнуть, что есть фатальная засада
На данный момент засаду я вижу только одну.
Если работать с прерываниями в лоб, то частота 15,5кГц это перебор. Паразитных работ со стеком слишком много. Проц занимается только входом и выходом из процедуры. И даже если он там находится не много, все равно паразитная составляющая получается слишком дорогой. Но с другой стороны по факту сейчас я имею постоянных 8 источников прерываний:
- сигнал готовности данных с гиры - 400Гц
- Готовность акселя - 50 Гц
- готовность компаса - 30 Гц
- Опрос статуса и данных с барометра - около 25 Гц
- цикл опроса и сбора данных с датчиков - 1КГц
- Видео ССИ - 15,5кГц
- USB запросы - тут по разному
- I2C шина
И тем не менее, все работает в принципе. И отрабатывает нормально горизонт с EKF на частоте 400Гц и не пропускает циклы.
На горизонте еще маячит отрисовка OSD , опрос и парсинг GPS и сам алгоритм принятия решения о стабилизации. Но ни одна из этих задач не критична к фазовым сдвигам начала и окончания ее расчета. Все эти задачи могу отрабатывать по остаточному принципу, пока проц вне прерываний.
Ну будем дальше двигаться, чего сейчас гадать, может ты и прав, а может нет. Увидим уже скоро.
критична к фазовым сдвигам начала и окончания ее расчета
Не вдаваясь в подробности STM архитектуры ( с коей незнаком), могу предложить такое тупое решение:
- Зная приблизительно момент наступления очередного критического прерывания, запустить таймер на время заведомо меньшее времени наступления критического события.
- При обработке прерывания от таймера запретить все остальные прерывания, кроме критического. Или еще тупее - программно опрашивая флажок прерывания, ждать критического события - что точнее?
Понятно что будем терять ресурсы на дельте времени от вспомогательного прерывания до критического, но ИМХО это не должно быть большой потерей.
могу предложить такое тупое решение:
Решение нормальное, если доработать его, и по сработке таймера отмерять окно для ССИ, тем же таймером, по окончании окна восстановить разрешения. Иначе по неприходу ССИ из-за сбоя видео и тп, система встанет.
Иначе по неприходу ССИ из-за сбоя видео и тп, система встанет.
Само собой дополнительный контроль нужен. Не допускать потенциально бесконечных циклов - это азы программирования. 😃
Вопросы к Дринкеру:
- У тебя есть отладочная плата на СТМ, чем её программируете и шьете?
- Вроде как твой алгоритм построен на кватернионах? Подскажи, если не тайна, как вектора компаса и акселя приводишь к кватерниону? Код не нужно, лучше на словах.
На данный момент засаду я вижу только одну.
Если работать с прерываниями в лоб, то частота 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 мкс!
Как-то у АВР это дело обстоит проще, может автору часть связанную с осд нужно перевести на АВР и не городить аппаратную видеоразвертку, а сделать программную?..
Нет, не секрет. Все электрические схемы текущего рабочего прототипа опубликованы на первых двух страницах темы. Изменений практически никаких внесено не было. Как изначально было задумано в теории, так все на практике и заработало.
Вы уж извините, но не могу разобрать в таком качестве картинку, где там элементы отвечающие за видеомодулятор, может датите ссылку, не сочтите за труд на лучшую картинку, или саму часть осд системы.