OSD на ATmega1281
ок, отпишусь что получилось…
Конечно, если получится реально более качественная картинка, можно под все остальные задачи и второй проц подключить
IMHO, чем ставить второй, лучше просто взять более подходящий проц.
IMHO, чем ставить второй, лучше просто взять более подходящий проц.
более подходящий это для авр наверное уже на хмега перейти
а зачем считать? сделать код подготовки загрузки следующего байта 16 тактовым SPI тактированный от половины частоты всякий раз будет опустошаться за 16 тактов, банальный индийский код, без циклов и проверок,
SPI, вот хоть ты тресни, ВСЕГДА оставляет один пустой бит, причем, СВОИХ тактов, а не клока. Проверено нопами.
Есть альтернатива в виде отдельной микрухи-сдвигового регистра на 8 бит, тактировать от прескалера таймера, но это как бы железо дополнительное.
более подходящий это для авр наверное уже на хмега перейти
В мире есть не только меги и авры. Я на 24 пике вообще с видео не парюсь , там 16 битный SPI с восьми уровневым FIFO, раз в пол строки прервался(для 256 точек) чтобы закинуть в буфер 8 слов и дальше пошел, а еще LPC выпустило кучу мелких, недорогих армов , ни как руки не дойдут на них попробовать.
SPI, вот хоть ты тресни, ВСЕГДА оставляет один пустой бит
Вот голова дырявая, ведь знал это… Даже проект какой-то изучал в выводом текста по SPI и там были дырки между знакоместами.
Есть альтернатива в виде отдельной микрухи-сдвигового регистра на 8 бит
Первый вариант в бумаге был именно такой… Потом решил проще сделать на UART в SPI режиме,- не получилось… Ну и успокоился тем, что 4 такта на пиксель мне вполне хватает, получается вполне сбалансированный по времени выполнения код для всех моих хотелок…
кстати в smalltim mini вывод тоже сделан сдвигом вручную (не так как я написал выше)…странно… я думал там сильная проработка вывода сделана…
SPI занят обменом данными с АП.
Увеличение разрешения по горизонтали это конечно хорошо, но писксели станут прямоугольными…
Если уж получится, на отдельном проце увеличить разрешение по горизонтали ,пусть даже и с зазорами между знаками,то удвоить вертикальное это как раз не проблема.
Тока не мелковато ли все получится, или все это затевается ради графики?
тут скорее более явной будет вторая проблема - быстродействие при работе с экраном - увеличение разрешения просто так не проходит 😃
Установил свою LRS на нарождающееся крылышко. Заметил, что элевоны как-то не слишком плавно ходят и задерка ощутима (просто на сервах казалось все отлично…). Стал считать…
- От момента управляющего воздействия до начала передачи пакета PPM в кодере задержка от 0 до 20мс (период PPM).
- Передача PPM - 20ms.
- После окончания PPM пакета от кодера в передатчике, проверки его валидности, передатчик начинает его гнать в ближайшем RF-фрейме через 0…30ms (период передачи пакетов).
- Передача пакета по радио ~26ms.
- После получения пакета в приемнике, он гонит полученные данные по UART в OSD на скорости 19200. Время ~6ms.
- OSD выдает полученные значения PWM-импульсом на серву в ближайшем цикле (синхронизировано с КСИ). Время 0…20ms (период КСИ).
В итоге от начала управляющего воздействия до выдачи импульса серве в сквозном тракте проходит от 52 до 122ms. 😦
Это, конечно, весьма заметно… ( и средняя задержка и ее неравномерность)
Неравномерность можно сгладить фильтром, хотя это приведет к большей средней задержки.
Вот такая забавная арифметика…
зря осд и пилот живут в одном чипе, экономия порядка 300руб - кило колбасы
и код сложнее написать учесть задержки
и случайные баги в осд могут сказаться на действиях автопилота, т.е отражается на надежности
в принципе когда много плат - это тоже не очень удобно, одноплатный - крупноват
а вот модульную конструкцию еслиб сделать как в компе материнка и дочерние в нее в любой слот
Вот такая забавная арифметика…
А из каких соображений такое большое время на изменение номера фрейма?
(период передачи пакетов)? так во всех блютузах и вайфаях по номеру фрейма определяется кто занимает канал а после передача идет до конца пакета.
зря осд и пилот живут в одном чипе
Этот момент комментировал неоднократно… Есть плюсы, есть минусы для каждого подхода, имхо оба имеют право на существование…
А из каких соображений такое большое время на изменение номера фрейма?
(период передачи пакетов)?
Пауза между пакетами 30мс(период)-26мс(время передачи) <4мс. Можно попробовать его уменьшить, но принципиально это ничего не изменит. Проблема в асинхронности получения данных с кодера и момента старта передачи. Если обновленные данные с кодера пришли непосредственно перед стартом передачи, эта задержка близка к 0. Если сразу после старта передачи, (RFM уже передает данные из своего FIFO) будут переданы только в следующем фрейме через время близкое к периоду- 30мс.
В принципе эта проблема думаю присутствует не только в моей системе…😉
Проблема в асинхронности получения данных с кодера и момента старта передачи
Наверно больше в том что время передачи больше либо сравнимо с периодом РРМ, нет готовности к передаче следующего пакета и соответственно прогнозируемой задержки на период РРМ. Если нет возможности увеличить скорость передачи то значит надо искать пути уменьшения количества передаваемых данных.
Не помню сейчас что на схеме передатчика но если там декодирование РРМ то лучше перейти на UART чтобы сократить время между опросом положения стиков и получением данных передатчиком.
На лету полезные данные можно на треть ужать по томуже принципу что и цветоразностные сигналы в телевидении.
Сам издеваюсь на ТR24P столкнулся с тем что у меня пока мозгов не хватает добиться синхронности хода часов при большом количестве прерываний но это пройдет.
Даже если время передачи будет меньше, сделав передачу по готовности данных от кодера, не уверен что получится сделать надежную ППРЧ. Радикальное решение- все сделать с минимальными промежуточными звеньями, те кодер управляет сразу RFM, и АП непосредственно связан с RFM. Но в этом случае усложняется реализация универсальности модулей, получается слишком “вещь в себе”… Ну и начинать мне бы пришлось с “чистого листа” (во всяком случае по железу, софт то просто упростится). Пока надеюсь, что эта проблема для моих задач этих подвигов не стоит, мне же не пилотажкой на соревновании управлять…
Даже если время передачи будет меньше, сделав передачу по готовности данных от кодера, не уверен что получится сделать надежную ППРЧ.
Про надежность ничего немогу сказать, просто думаю будет меньше неопределенности какие длительности будут поступать на серву: предыдущее значение потому что новые значения еще не получены или обновленные.
Радикальное решение- все сделать с минимальными промежуточными звеньями, те кодер управляет сразу RFM, и АП непосредственно связан с RFM.
Думаю здесь будет больше проблем чем выигрыша.
Вот такая забавная арифметика…
Когда с шедевром будет возможность ознакомиться?😃
И сного о разрешении, а что если взять и разогнать проц и производительность повысится и пикселей больше влезет, провел небольшой эксперимент с 48 мегой (думаю это не принципиально, семейство то одно и ядра у них одинаковые ,других мег просто нет в наличии у меня сейчас), она прекрасно гонится внешним генератором до 40 мГц, а возможно и больше, использовал допилиный код смалтима. И вот результат разрешение в 4 раза больше.
Закончил своего вжика, думаю продолжить разбираться со своей LRS.
Вот как выглядит это сейчас:
www.youtube.com/watch?v=97bJY3ZyXoc
Достает не столько средняя задержка, сколько ее неравномерность…
Буду пробовать переделать с синхронизацией времени начала передачи от полученного PPM. При этом есть два варианта:
- Увеличить скорость, что бы успевать передавать за 18мс с периодом 20мс.
- Уменьшить скорость в радиоканале и передавать с интервалом 40мс. В приемнике можно интерполировать до 20мс.
Долго думал какой вариант “правильнее”, решил реализовать оба… 1-й- для низко и близко, 2-й- для высоко и далеко.
Что будет получаться, поделюсь…
и пикселей больше влезет,
Тут главный вопрос:а зачем?
Помимо снижения надежности и увеличения разогрева самого “камня” при его “разгоне”, слишком мелкие буквовки- просто нельзя будет разглядеть к примеру, в видеоочки? Даже если они- очень чётко прописаны?
Ведь смысл ОСД не в достижении предела разрешения, а в удобстве для пользователя (в условиях очень ограниченного времени и распределения внимания) -понять и оценить параметры полёта?
Тут главный вопрос:а зачем?
Думаю для того чтобы на экран влазило больше полезной информации не занимая весь экран, да и линии графики будут менее ломаные, а шрифты можно и больше сделать если плохо читаются, хотя пробовал смотреть в очки ,буквы вполне читабельны правда действительно не оч.четкие (есть небольшие тянучки и ореолы во круг, но я списал все это дело на не качественный монтаж и сборку, так как все сделано на коленке соплями). разогрева камня особого не ощутил возможно он и есть но без приборов не заметен.
Да я собственно не кого и не агитирую повышать разрешение, просто кто то выше интересовался этим вопросом ,мне тоже стало интересно я и попробовал посмотреть что получится, и предложил один из возможных вариантов без серьезных затрат и переделок схемы.