Необходимо сделать устройство на МК tiny2313, которое будет накладывать данные (цифры и простую графику), получаемые из другого более мощного МК, на композитный видео-сигнал.
Начало реализации я себе представляю - LM1881 ловит строчные и кадровые импульсы, а attiny в нужный момент выдает логическую единичку в видео-линию. Связать tiny с другим МК с целью приема данных по USART тоже не проблема.
А вот как реализовать программную часть на Си так, чтобы все было быстро и компактно - не представляю, туго у меня пока с программированием

Если сначала описать все возможные символы двухмерными битовыми массивами, а потом в нужные моменты выбирать нужный слой нужного символа (так я делал в другом проекте на atmega16) - выбор из массива занимает много процессорного времени, да и такой массив (даже на 20 символов) на attiny не влезает

Может быть можно как-то принимать от другого МК уже готовые битовые "маски" символов, но тогда как их хранить до момента вывода, ведь памяти на attiny для этого тоже не хватит.
Передавать по USART прямо к моменту вывода на экран невозможно - скорости не те.

Подскажите решение для моего случая, пожалуйста. Если это вообще возможно на tiny2313...

P.S. Нужно накладывать на изображение символы размером 6х8 пикселов в количестве около 20 штук и простую графику размером 30х30 пикселов

Вообще то любой проект должен начинаться с оценки необходимых ресурсов МК и выбора МК с запасом.

Вопрос именно в возможности реализации на этом МК, т.к. нужное количество уже есть в наличии.
Если никакой возможности реализовать проект на этом МК нет - то конечно буду закупать другие.

Если убрать графику, то вывод символов можно реализовать "аппаратно", через SPI?

1) Прежде всего надо прикинуть, какая нужна скорость выдачи пикселей. Прямой ход строки порядка 64 мкс, пусть на строку укладывается 640 пикселей, значит, на один пиксель приходится 0.1 мкс или 2 машцикла.

2) Теперь надо решить вопрос о программной или аппаратной реализации. Программно можно выдать один пиксель за два такта (с разрывом в один такт между символами текста), графику без разрыва - сомнительно.

3) Остаётся делать аппаратно, используя USI с максимальной скоростью Fck/2, что как раз соответствует вашей скорости 10Мпиксель/с. Написать программу на си, даже для аппаратного интерфейса, будет проблематично.

4) Для хранения пикселей одной тв-строки вам надо 20 байт. Для 8 тв-строк вам понадобится 160 байт, в тайни их всего 128. Для решения проблемы можно использовать 120 байт озу для 6 тв-строк, остальные 40 байт подкачивать из главного МК по мере освобождения озу.

5) Никаких двумерных массивов, всё должно быть строго линейно.

Подобные проекты уже обсуждались воспользуйтесь поиском, но там делалось на AtMega

Спасибо =GM=
Прикинул, что действительно для полноценной реализации устройства понадобится более сильный МК. Буду закупать мегу164.

Все уже придумано до нас

Уже изучал эти balloon overlay, avr-vga и подобные тысячу раз. Немного не по теме

А можно узнать - ЧТО именно не по теме? У меня две аналогичные разработки (одна - с LM1881, другая без) отлично работают в десятках изделий по всему миру - так ЧТО не так-то?

Ну, дам вам ещё один совет, подумайте. Можно поставить две тайни, которые работают параллельно-последовательно на один провод. Сначала одна тайни выдает пиксель, потом вторая. Памяти обоих хватит за глаза. Немного непривычно писать параллельную задачу, но проблем никаких не вижу, поскольку задача достаточно простая. Ну или так, одна тайни выдаёт 4 тв-строки и засыпает, потом вторая выдаёт 4 тв-строки и засыпает. Преимущество тут - программа практически будет одна и та же для обоих тайни.

Вообще-то, можно было бы и на одной тайни написать, но надо сильно извиваться. Этим стоит заниматься, если только хочется ощутить свои собственные возможности в программировании, ну или если идёт большая серия, тогда может и стоит.

Помните о чересстрочной развертке в телевидении. Ваш шрифт с размерами 6х8 пикселей (а это очень мало) будет сильно "бить" по глазам за счет 25-герцового мерцания тонких горизонтальных линий. Все это будет усугубляться тем, что "врезаться" вы будете в композитный сигнал (PAL или SECAM - не важно) - получите возможные проблемы по цвету - в виде "тянучек" и "факелов". Для лучшей читаемости текста необходимо применять антиальясинг, хотя бы дублируйте изображение в обоих полях тв-развертки, чтобы получить горизонтальные линии толщиной в 2 строки. И, по-возможности, избегайте насыщенных цветов - композитные сигналы этого не прощают.

Подумал немного, на тайни можно и графику 30х30 выдавать программно без разрывов.

Наверное можно,
Господа разработчики, а не порешать ли нам эту задачку совместно ?
Сразу скажу что у меня такая задачка не стоит и мой интерес чисто абстрактный...
Предлагаю открыть такой проект по выводу(подмешиванию) картинки на телик.
Только он должен быть полностью открытым....
Те высказывания в стиле "а я могу круче..." без демонстрации кода просто удаляются.
Готов в этом поучаствовать насколька хватит знаниев

Фрагмент выдачи 20 символов в тв-строку через пин pd0. Как я и говорил, будет зазор в один такт между символами

Код

      ld     r16,z+
      out    portd,r16
      ror    r16
      out    portd,r16
      ror    r16
      out    portd,r16
      ror    r16
      out    portd,r16
      ror    r16
      out    portd,r16
      ror    r16
      out    portd,r16
Повторить фрагмент ещё 19 раз

Скорость выдачи 10Мбит/с

Все конечно хорошо, но в общем очевидно...
Зачем выводить со скорость 10мбит/сек если нужно раз в пять медленнее на 20 символов ?

Вопрос в том как грамотно организовать получение/вывод данных для того что бы и
картинка была красивой и данные можно было обновлять быстро.

Что-то я не совсем пойму, какая проблема. Берем ATMega48 (для начала), используем для вывода USART, переключенный в режим SPI. При этом дырок между символами не будет. Выводить необходимо по UDRE прерыванию/флагу. Если по прерываниям, то навскидку, еще и время останется между выводами. Или надо прямо код готовый написать?

Автор - новичок, мы - помогаем ему освоиться в этом поле. А проблем никаких нет. Лично я могу ПРОГРАММНО довести вывод до 20 Мбит/с (без разрывов, и графику, и текст, в рамках поставленной задачи). А вы можете аппаратно выдать на скорости 20 Мбит/с?

через CPLD.

Не спортивно . Если бы там, ну скажем, один логический элемент снаружи, тогда еще ничего.

Програмно и я могу. Там говорилось про 30*30 графику? Так что без проблем положил 30 регистров и 30 раз out сделал - получил 20МБит.

Аппаратно могу предложить так - берем через SPI выводим все четные биты, другим способом - все нечетные. Снаружи - делаем xor между ними (хотите - одним логическим элементом, хотите - на двух транзисторах, хотите коммутатор ставьте, на входА подаем обе битовые последовательности, на управление - CLK от SPI). Конечно, данные надо подготовить заранее, и хитро.



Зря Вы, кстати, проигнорировали мое предложение

Или Вас что-то пугает в такой реализации?

Наш человек, не то что некоторые тиоретеги, не побоюсь этого слова, которым всё очевидно(:-). Теперь сделайте текст без разрывов на 10 Мбит/с.

Не получится, по-моему. Первый байт через SPI вы выведете, затем надо перегружать регистр, а времени на перегрузку - нет.

Ну смотрите, если брать Mega48/88/168, то у нас есть USART, который мы переключаем в режим SPI и обычный SPI, у которого правда есть вопрос в пропуске одного такта. Давайте посмотрим, есть ли способ быстро шевельнуть лапкой MOSI обычного SPI, в паузе между передачами байт. Если есть - то все пучком. Правда, это получится один поток по 8 бит, другой по 9, ну если уж совсем прижмет, то так можно извращаться

В Tiny2313 видимо вывод таким способом никак не получится, нет подходящей периферии. Правда, есть еще таймеры, которые могут шевельнуть ножкой в нужный момент. Так что если будем продолжать писькомеряться, то можно и продолжить исследования.

Но я предлагаю померяться в другом. Не в выводе, а в самом быстродействующем вводе последовательных данных, эту тему еще не копали

Ну тему вроде замутили для тайни...А так можно взять атмеловский МК с тактовой 48 МГц и с криком ура...назад(:-)

SPI-слейв работает на максимум Fclk/4=5МГц, т.е. четыре МЦ на бит, или 32 МЦ на байт, вполне можно принять и разместить, скажем, в кольцевом буфере.

Следующая скорость - Fclk/2=10МГц, два МЦ на бит. Если оба МК работают от одного и того же тактового генератора, то думаю, принять можно, хотя сам не пробовал. Если они работают от разных генераторов/кварцев, то имею тень сомнения. Вся проблема состоит в пресловутых пин-синхронизаторах.

Последняя скорость - Fclk=20МГц, один МЦ на бит. Можно принять два байта, да и то надо сильно думать, как засинхронизировать начало передачи.

Можно принять 4 байта на 40 МГц, но это extraordinary.

Для затравки предлагаю принять пакет с эзернета 10Мбит. Правда совсем без аппартаной части не получится, но так, чтобы в $1.2 вложиться - легко.

Какой длины пакет, какая структура, сколько данных? Там манчестер вроде рулит? Я тут пока ни уха, ни рыла(:-).

Что я обдумываю неспешно - приём с юэсби на 12 МГц, всё вроде ничего, но всю голову сломал, как засинхронизироваться с началом пакета.

Ну давайте ограничимся длинной 256 байт, структура - стандартная, классический эзернет, преамбула, старт, сами данные, crc.

Просто 2 буфера по 256 байт - уже половина озу меги88/168, а надо еще и TCP/IP стек там держать...

И это, если будем меряться, давайте тему организуем отдельную, пока нас за злостный оффтопик не постреляли модераторы

Действительно, не стоит испытывать их терпение. Давайте пока в личку.

Согласен. Я в этом разделе уже три темы про это открывал и то все до конца не понял



Я с удовольствием бы реализовал обработку данных уже на земле (тем более что с помехами на борт. аппаратуру так и не разобрался), но не представляю как это сделать программно (на Си)
У меня еще свободный аудио-канал есть в AV-передатчике, но с реализацией передачи по нему тоже пока туго