OSD на ATmega1281
А то мои монологи уже всем надоели…
Отнюдь, все по делу, ждемс не дождемся исходников.
Даже если Сергей их выложит, там, подозреваю, черт ногу сломит. Сплошной асм. Имею в виду ОСД. Другими средствами такую красивую картинку не получить, да еще и навигация…
если Сергей их выложит, там, подозреваю, черт ногу сломит.
Ну дык уже влез, железо на мази, приходится на кого то полaгаться. Тут по ходу присматриваюсь к OpenPilot GCS.
была картинка с алгоритмом автопилота…
Сейчас она малость устарела… Будет время, пройдусь по коду, обновлю… Кстати тогда был разочарован, что не было никаких вопросов, замечаний, предложений…
Кстати, Сергей, а генерацию видео при помощи SPI делаете или вручную сдвиг делаете ?
К сожалению передающий регистр SPI в атмегах не буферирован и выводить им графику не получится. Приходится программно двигать. Ближе к началу темы есть исходный код вывода строки.
простите за дилетантский вопросик, а в атмегах нельзя делать непосредственный сдвиг в выходном порту
типа portb<<1 ?
чтоб сдвиг за один такт, конечнож потеряются остальные выводы порта для использования с другим функционалом, но у атмеги их полно
Такой команды в атмегах нет. Собственно за один такт все равно не получится, надо подгружать данные в порт, проверять условия… Но здесь уважаемый abalex предложил гениальный код вывода строки всего по 3 такта на пиксель.
К сожалению передающий регистр SPI в атмегах не буферирован и выводить им графику не получится. Приходится программно двигать. Ближе к началу темы есть исходный код вывода строки.
что значит не буферизирован ?
я тут считал как то…
настраиваем частоту spi например на 1/2 такта (при тактировании в 16 мгц это будет 8 мгц - это 8 точек на 1мкс!!)
и далее:
-подготовили байт для выдачи
loop:
-ожидаем освобождения регистра данных spi
-отправляем байт для вывода в SPI SPDR (после этого spi сам будет сдвигать байт выдавая его на MOSI, и после передачи последнего бита выдаст флаг освобождения - по нему можно либо прерывание либо просто ожидание делать в цикле вывода)
-проверим все ли байты строки передали, если да то выходим
-пока передается байт по spi готовим следующий байт, у нас на это около 10 тактов (уже 2 потратили на проверку всю ли строку передали, еще 2 нужно будет на переход, и еще 2 на проверку освобождения SPI)
-переход на loop
таким образом технически разрешение по горизонтали которое можно достичь достигает около 52 мкс*8=416 точек, ИМХО, это очень даже неплохо для телевизора, пусть по 50 точек слева и справа оставим на бордер, останется 300 точек по горизонтали, столько же по вертикали - ИМХО хорошее поле для вывода!
в данном алгоритме мы на вывод пискела тратим 2 такта 16 мгц… + самое главное пока пикселы байта выводятся - мы не теряем время, и готовим следующий байт для вывода ! то есть накладных расходов между байтами вообще небудет !! ИМХО это важно поскольку позволит при достаточно серьездном разрешении получить отсутствие эффекта увеличения интервала каждые 8 точек… я не помню можно ли тактировать SPI от тактовой частоты… тогда вывод будет еще более мелкий… причем мы все равно будем успевать !
я планировал использовать внешнюю память, тем более что мне тут дали наводку на atmega162 - если к ней подключить внешнюю RAM то на все поле телевизора можно хоть картинку выводить ! (иначе не хватает внутренней памяти меги для хранения)
p.s. кстати в smalltim mini вывод тоже сделан сдвигом вручную (не так как я написал выше)…странно… я думал там сильная проработка вывода сделана…
p.p.s. посмотрел стр163 даташита на мегу162 - делитель spi не менее 2… так что разрешение что я описал максимально
я планировал использовать внешнюю память, тем более что мне тут дали наводку на atmega162 - если к ней подключить внешнюю RAM то на все поле телевизора можно хоть картинку выводить ! (иначе не хватает внутренней памяти меги для хранения)
если текст или векторная графика зачем ей забивать память? на обратном ходе строчного импульса налету считать строку и помещать ее в массив в рам, а на обратном ходе кадрового импульса считать векторы и подготавливать текст по позициям
с spi может быть засада что если ждать освобождения то это значит когда 8 бит выведены будет задержка на 1 такт минимум и это отразится на картинке
если текст или векторная графика зачем ей забивать память? на обратном ходе строчного импульса налету считать строку и помещать ее в массив в рам, а на обратном ходе кадрового импульса считать векторы и подготавливать текст по позициям
ну если кроме как считать графику больше делать нечего то согласен, а иначе не будет других задач…
тем более что строчный импульс это всего 8 мкс на все, включая прерывания… это в лучшем случае 64 команды - особо не рассчитаешь ничего
кадровый тоже не настолько велик чтобы успеть чтото расчитать из графики…
а у нас тут еще кучу периферии нужно обслужить…
так что никакой графики на лету не получиться 😦 это я уже считал…
с spi может быть засада что если ждать освобождения то это значит когда 8 бит выведены будет задержка на 1 такт минимум и это отразится на картинке
к сожалению моя макетка другим занята, поэтому я не занимался реализацией и оптимизацией алгоритма, но уверен что можно сделать “гладкий вывод” без какой либо задержки (посчитать такты команд наконец!)…
еще раз повторюсь получив очень большое разрешение, можно добиться того чтобы картинка была очень гладкой… времени на это предостаточно! получили ведь 16 тактов запаса при отправке байта ! вопрос только как их использовать… быстродействие в 2 такта на бит - тоже очень не кислый результат…
в текущей реализации 3 такта на один бит изображения и никаких запасов или возможностей к улучшению… 😦
Эх… если бы на SPI был аппаратный буфер хоть 1 регистр… жизнь была бы проста и неинтересна…
А тут… если такты считать и синхронно после передачи последнего бита (такт в такт!) записывать в сдвиговый регистр SPI след. байт… Может и есть шанс… Но ни о каком опросе флагов и тем более прерывании речи быть не может…
Эх… если бы на SPI был аппаратный буфер хоть 1 регистр… жизнь была бы проста и неинтересна…
А тут… если такты считать и синхронно после передачи последнего бита (такт в такт!) записывать в сдвиговый регистр SPI след. байт… Может и есть шанс… Но ни о каком опросе флагов и тем более прерывании речи быть не может…
а зачем считать? сделать код подготовки загрузки следующего байта 16 тактовым SPI тактированный от половины частоты всякий раз будет опустошаться за 16 тактов, банальный индийский код, без циклов и проверок,
все остальные ништяки с вычисленями пока нет отрисовки экрана (из 320 линий видимыми вроде считаются 288 + ССИОХ + КСИОХ столь недооцениваемые **Витго** во время которых можно даже разрешать прерывания ) правда в этом случае тени придется отрисовывать аппаратно по нарастанию и спаду единицы в ноль
а зачем считать?
Имел в виду считать программеру при написании кода… 😃
Увеличение разрешения по горизонтали это конечно хорошо, но писксели станут прямоугольными…
Ну и отрисовка в видео буфер для качественной графики тоже дело “времяемкое”. А еще там (в межкадровый промежуток) мне приходится читать/парсить GPS, разбирать PPM, обсчитывать всю логику АП… Конечно, если получится реально более качественная картинка, можно под все остальные задачи и второй проц подключить… Пока бум ждать практический результат Виталия…
ок, отпишусь что получилось…
Конечно, если получится реально более качественная картинка, можно под все остальные задачи и второй проц подключить
IMHO, чем ставить второй, лучше просто взять более подходящий проц.
IMHO, чем ставить второй, лучше просто взять более подходящий проц.
более подходящий это для авр наверное уже на хмега перейти
а зачем считать? сделать код подготовки загрузки следующего байта 16 тактовым SPI тактированный от половины частоты всякий раз будет опустошаться за 16 тактов, банальный индийский код, без циклов и проверок,
SPI, вот хоть ты тресни, ВСЕГДА оставляет один пустой бит, причем, СВОИХ тактов, а не клока. Проверено нопами.
Есть альтернатива в виде отдельной микрухи-сдвигового регистра на 8 бит, тактировать от прескалера таймера, но это как бы железо дополнительное.
более подходящий это для авр наверное уже на хмега перейти
В мире есть не только меги и авры. Я на 24 пике вообще с видео не парюсь , там 16 битный SPI с восьми уровневым FIFO, раз в пол строки прервался(для 256 точек) чтобы закинуть в буфер 8 слов и дальше пошел, а еще LPC выпустило кучу мелких, недорогих армов , ни как руки не дойдут на них попробовать.
SPI, вот хоть ты тресни, ВСЕГДА оставляет один пустой бит
Вот голова дырявая, ведь знал это… Даже проект какой-то изучал в выводом текста по SPI и там были дырки между знакоместами.
Есть альтернатива в виде отдельной микрухи-сдвигового регистра на 8 бит
Первый вариант в бумаге был именно такой… Потом решил проще сделать на UART в SPI режиме,- не получилось… Ну и успокоился тем, что 4 такта на пиксель мне вполне хватает, получается вполне сбалансированный по времени выполнения код для всех моих хотелок…
кстати в smalltim mini вывод тоже сделан сдвигом вручную (не так как я написал выше)…странно… я думал там сильная проработка вывода сделана…
SPI занят обменом данными с АП.