flybrain. передатчик + приемник + автопилот. powered by stm32
Ты в меня не веришь просто.
Верю. Но я реалист. И это всё уже проходил. И по времени примерно ориентируюсь.
для изучения принципов решения аналогичных задач
Это и есть сп@#$ть.
А вот если что-то будет оригинальное - то это, да.
сп@#$ть
Ну вот… пошли вольности толкования 😃
Оно, это самое, это когда без спроса, а когда исходники и формулы открыты это называется простым русским словом подсмотреть
Иначе, если по честному, все должны были бы отчислять дивиденды потомкам великих умов прошлых столетий за их выдающиеся… и неоценимый… 😉
Это и есть сп@#$ть
С таким подходом, можно обобщить, что за последние 5-10 лет в мире программирования ничего нового не происходит, а все тупо друг у друга пи…ят.
оригинальное
Согласись, тут тоже должна быть определенная мера разумного.
Но я реалист
Постараюсь не оправдать твои надежды 😃
а когда исходники и формулы открыты
Я бы еще добавил: “…когда прямым текстом разрешают и предлагают пользоваться кодом и модифицировать его как угодно в своих собственных благих целях, и при этом не просят за это ничего кроме СПАСИБО…”
Я за тобой слежу
А весь форум за вами обоими… 😎 😃
С надеждой и пожеланием успеха… кхм… вот за всех-то наверно поторопился сказать?
[quote=PAF;3214087]А весь форум за вам[/quoteДа
Да нормально всё. А вот чё там в роскосмасе. Я вот глонас прикручиваю. А тут на тебе - глава в больнице, у зама литсо разбито, а прессекретарь… Опасносте?
Берем TIM8, оно у меня на схеме уже имеет вход, на который video sync уже заведен. Настраиваем его в мастер режим one-pulse mode. Далее берем TIM2. У него есть 4-й канал (pin30), замыкаем его с SPI2_SCK (pin 29). Они рядом, это просто перемычку на плате посадить.
Удачно получилось, но надеюсь в чистовой версии будет использоваться только один таймер.
А в теории, если с точностью до бита подобрать окно для TIM2 можно даже DMA не перезаряжать на каждой строке, а тупо ждать процесса до конца полукадра. Оно само будет на следующем кадре продолжать автоматом буфер дальше выводить. И только вконце всего полукадра, опять включать прерывания от синхры и ловить начало кадра, чтобы DMA и таймеры перезарядить.
Могут быть грабли ввиде параллелограмма на экране, нужна будет динамическая подстройка под ССИ. Думается, это не будет оправданно в части производительности, ведь зарядка ПДП это всего лишь загрузка 3х регистров.
Блин, у меня у же свербит, до дома не дотерплю, хочу уже попробовать
Каков результат?
насчет сп@#$ть , например, я перед собой не ставлю задачи написать оригинальный код, задача в другом написать “правильный” код, без костылей и понятный мне самому. Если лучше того что есть я написать не смогу, то возьму его с чисто эстетическими доработками.
насчет АВР/АРМ: есть смысл уйти от приближенных вычислений тригонометрии и перейти на плавучку, т.е. получить точность, плавность, адекватность, плюс оставить пространство, над кодом навигатора и стабилизатора, для какой либо логической надстройки (облет припятствий, алгоритмы миссий и т.п.).
есть смысл уйти от приближенных вычислений тригонометрии
Где приближенная?
насчет АВР/АРМ: есть смысл уйти от приближенных вычислений тригонометрии и перейти на плавучку, т.е. получить точность, плавность, адекватность,
предлагается double (64 бита? ) сразу быстродействие падает на порядок примерно по сравнению с целочисленными вычислениями. ( на M3)
а повышенной точности в шумах не видно… 😃
но надеюсь в чистовой версии будет использоваться только один таймер.
Ну нет, зачем. В любом случае два надо. Одним таймером окно с отступом генерим для второго (нам же нужно отступить от левой границы экрана). А второй в этом окне тактирует SPI.
Могут быть грабли ввиде параллелограмма на экране, нужна будет динамическая подстройка под ССИ.
Не, ты не до конца прочувствовал. Там же как получается. Первый таймер запускается от восходящего фронта строчного импульса аппаратно. Затем он генерит окно с отступом. Весь период работы примерно 54 мкс. Дальше он останавливается, он в режиме одиночного импульса. Далее он автоматом ждет следующего фронта от следующего строчного импульса и так далее до конца экрана. То есть “окна” автоматом укладываюся в центр ССИ автоматически. А DMA оно зависит от SPI слэйвом. оно отдаст байт и ждет, пока SPI не скомандует следующий. Соответственно SPI будет само приостанавливаться до следующего окна от первого таймера (тактирование же будет пропадать автоматом вне окна), а DMA просто ждет готовности SPI. Ну вот как-то так до конца экрана. То есть, каждая строка в любом случае синхронизится от начала CCИ.
Более того, в продолжение этой темы. Поскольку удачно совпало, что каналы у TIM8 и TIM3 сидят на одном пине видео синхры, то вот я сейчас вижу, что можно организовать не просто ПОЧТИ аппаратно все, а реально 100% аппаратно, если еще +2 таймера задействовать. Один чтобы аппаратно отсчитывать время прихода кадрового импульса и автоматом его детектить через период задержки сэмплирования, а еще таймер, чтобы отступить сверху экрана. То есть будет постоянно всего 4 таймера + 1 прерывание раз в 20 мс это дело обслуживать полностью аппаратно без участи кода. Но здесь есть опасность кривизны и неустойчивости самого видео сигнала от камеры. Короче, уже будем такими оптимизациями заниматься сильно потом.
Каков результат?
Соединил два таймера вместе программно, потестил в дебаггере, вроде все как надо работает в связке. Хотел уже перемычки паять, но жена спутала все карты: заставила английским с ребенком идти заниматься. Сегодня вечером продолжу.
есть смысл уйти от приближенных вычислений тригонометрии и перейти на плавучку
У меня в коде все во float, мне нет никакого смысла, костыли из int’ов городить. У меня вычисления в int’ах работают с той же скоростью, что во float. Так что все и так уже плавно и адекватно 😃 Код сейчас занимает компиленый около 48Кб, а сделано уже не мало: основной скелет проекта по классам, классы общения с датчиками (гира, аксель, компас, баро) на аппаратном уровне, классы постоянного опроса датчиков, Классы под таймеры для реал-тайм временных меток и отсечек, опроса датчиков, USB device драйвер (уже полностью функционален), консоль командная, алгоритм 3D горизонта и положения в пространстве на кватернионах + EKF, сейчас OSD на подходе. Флешка у меня 1Мб, так что пространства под любые дальнейшие апгрейды и извращения просто до фига. При этом я по загрузке даже близко к 50 % не подобрался.
предлагается double (64 бита? )
Зачем, достаточно плавучки обычной точности.
Не, ты не до конца прочувствовал.
Дествительно не допонял! Да, красиво получается, одно прирывание по концу кадра на преключение на начало видеобуфера. Ещё один момент не понял, как кадровый таймер АППАРАТНО разрешит работу строчного?
а сделано уже не мало:
молодца! за полтора месяца , быстрый ты однако. Я с ноября 11го только гироскопы сделал на макете, еще не решен вопрос с коррекцией по акселю и компасу.
как кадровый таймер АППАРАТНО разрешит работу строчного?
Надо подумать, вероятно таки оставить еще одно прерывание по окончанию паузы после начала кадра и в нем разрешить tim8 слушать синхру
Ну будет 2 прерывания в течение 20мс.
Ну вот, вас уже двое единомышленников.
Хочу намекнуть, что есть фатальная засада при совмещении осд и всего остального в одном камне.
есть фатальная засада при совмещении осд и всего остального в одном камне
ARM должен спарвиться, походу… А вот из авр-ок, надо бы было делать мультипроцессор.
ARM должен спарвиться, походу…
Дело не в производительности.
Хочу намекнуть, что есть фатальная засада
На данный момент засаду я вижу только одну.
Если работать с прерываниями в лоб, то частота 15,5кГц это перебор. Паразитных работ со стеком слишком много. Проц занимается только входом и выходом из процедуры. И даже если он там находится не много, все равно паразитная составляющая получается слишком дорогой. Но с другой стороны по факту сейчас я имею постоянных 8 источников прерываний:
- сигнал готовности данных с гиры - 400Гц
- Готовность акселя - 50 Гц
- готовность компаса - 30 Гц
- Опрос статуса и данных с барометра - около 25 Гц
- цикл опроса и сбора данных с датчиков - 1КГц
- Видео ССИ - 15,5кГц
- USB запросы - тут по разному
- I2C шина
И тем не менее, все работает в принципе. И отрабатывает нормально горизонт с EKF на частоте 400Гц и не пропускает циклы.
На горизонте еще маячит отрисовка OSD , опрос и парсинг GPS и сам алгоритм принятия решения о стабилизации. Но ни одна из этих задач не критична к фазовым сдвигам начала и окончания ее расчета. Все эти задачи могу отрабатывать по остаточному принципу, пока проц вне прерываний.
Ну будем дальше двигаться, чего сейчас гадать, может ты и прав, а может нет. Увидим уже скоро.
критична к фазовым сдвигам начала и окончания ее расчета
Не вдаваясь в подробности STM архитектуры ( с коей незнаком), могу предложить такое тупое решение:
- Зная приблизительно момент наступления очередного критического прерывания, запустить таймер на время заведомо меньшее времени наступления критического события.
- При обработке прерывания от таймера запретить все остальные прерывания, кроме критического. Или еще тупее - программно опрашивая флажок прерывания, ждать критического события - что точнее?
Понятно что будем терять ресурсы на дельте времени от вспомогательного прерывания до критического, но ИМХО это не должно быть большой потерей.
могу предложить такое тупое решение:
Решение нормальное, если доработать его, и по сработке таймера отмерять окно для ССИ, тем же таймером, по окончании окна восстановить разрешения. Иначе по неприходу ССИ из-за сбоя видео и тп, система встанет.
Иначе по неприходу ССИ из-за сбоя видео и тп, система встанет.
Само собой дополнительный контроль нужен. Не допускать потенциально бесконечных циклов - это азы программирования. 😃
Вопросы к Дринкеру:
- У тебя есть отладочная плата на СТМ, чем её программируете и шьете?
- Вроде как твой алгоритм построен на кватернионах? Подскажи, если не тайна, как вектора компаса и акселя приводишь к кватерниону? Код не нужно, лучше на словах.