Необходимо сделать устройство на МК 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 символов ?

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