roboforum.ru

У меня на всем порту висит ЦАП, т.к. в режиме 32х32 мне надо отображать много градаций серого (64 в частности сейчас сделано), поэтому SPI мне не очень подходит.

Michael_K писал(а):Далаадна... С вашими-то разрешениями да современными процами
У вас какой процессор и кварц?

у меня АТмега32-16Мгц, гнать бы его не хотелось

Попробую понять ваш код, но с асмом у меня все плохо, стараюсь максимум на Си все писать.

PS: Еще есть мысль подцепить флеш-память на 2 Мб и ее использовать как видеопамять. Нашел упоминание в инете, что так некоторые делали и успешно (даже в цвете), правда на ассемблере, но хочу попробовать, может быть в ЧБ и на Си будет нормально.

Добавлено спустя 13 минут 4 секунды:
С условиями медленнее получается

Код: Выделить всё • Развернуть

;        lineram[0] = 0; if(c&0b10000000)lineram[0] = 255; else { PIXEL_SIZE1bv3 }
   LDI  R30,LOW(0)
   STS  _lineram,R30
   SBRS R16,7
   RJMP _0x87
   LDI  R30,LOW(255)
   STS  _lineram,R30
   RJMP _0x88
_0x87:
   nop
_0x88:

А вы принципиально это хотите на атмеге реализовать?
Есть, например, stm32f103 со встроенным цапом, через который по таймеру можно гнать данные, по цене не сильно дороже выйдет. Либо к тойже меге плиску прицепить, а ей кормить данные по SPI или через двухпортовую память.

атмега это пока единственное семейство МК с которыми я имел дело, их у меня полно, под них я собрал макетные платы с кучей всего. Кроме того они в ДИП-корпусе и их удобно паять.
Поэтому хотелось бы под них именно.
STM32, особенно топовые модели штука вкусная и модная, все на них пересаживаются, я возможно тоже, но сначала хотелось бы освоить то что есть и доделать некоторые устройства на их основе до конца, а уже потом изучать что-то новое, иначе по практического применения не дойдет у меня , постоянно буду только изучать новые платформы.

Еще есть мысль подцепить флеш-память на 2 Мб и ее использовать как видеопамять.

Флеш? Нет, быстродействие не то. SRAM можно.
Причем можно двухпортовую поставить и одно устройство будет в память писать (формировать изображение), а другое - читать (конвертировать в аналог). Это ослабит проблему с быстродействием (нужно будет уложиться только во время обработки полного кадра).

А есть и STM8 32 ноги 10 ШИМ 40 рублей.

Цена не важна, т.к. для себя родимого. Есть вон STM32F103RET6, 72 Мгц, 64к ОЗУ. Там вообще ничего делать не надо, он сам все успеет и памяти полно, что бы видеопамять 256х232х8бит организовать не о чем не думая.
Но как я уже говорил это надо:
- найти и изучить новую среду программирования
- вникнуть в отличия архитектуры ARM от AVR
- Научиться паять LQFP-64, а это возможно повлечет за собой покупку фена, да и на макетке уже не получится, придется травить
- и т.д.

shadowjack писал(а):SRAM можно. Причем можно двухпортовую поставить

Можете посоветовать конкретную сраму? Желательно двухпортовую и попроще в использовании.

Разобрался с at45d161d, не так оно сложно оказалось.
Но скорость ужасная.
За видео-строку у меня успевает считываться из буфера флеша только 16 байт.
Ни о каких 256 или даже 64 речь вообще не идет.
Более того, операция копирования из страницы в буфер (которая должна делаться каждую строку) занимает существенно больше чем 63 мкс (время одной строки)

Короче с первого взгляда - мне не подходит по скорости очень сильно.

2 Michael_K: Я так понимаю вы четные строки брали из одной микросхемы, нечетные из другой? (но даже в этом случае я не знаю, как сделать быстрее) Если не секрет, какую память использовали? Может моя at45d161d это образец тормознутости?

Имхо, если уж наворачивать железо, то нужно поставить цель и ее реализовывать.
А не суетиться "а давайте поставим SRAM", "а давайте поставим флэш".
Сначала нужно ответить на вопрос - А зачем? Чего мы хотим и чего этим достигнем.
В конце концов можно с тем же успехом и аппаратный сдвиговый регистр поставить,
или вообще видеоконтроллер собрать.

Да и в общем, ведь срам - вовсе не замена флэши...

По поводу скорости флэш написали ерунду. Посмотрите с какими скоростями работают всякие USB-флэшки... Да и в любой атмелке флэшка, очевидно, читается со скоростью кварца. Куда там телевизору.

Добавлено спустя 14 минут 37 секунд:
В личку написал.

максимальная цель это ЧБ картинка 256х232х8бит
при этом мне нужно чтобы часть картинок было записано заранее, и так же можно было динамически рисовать/писать все что угодно, т.е. были бы функции setpixel и getpixel
при этом у процессора оставалось время на обмен по I2C (как все мои модули)

Мне абсолютно не нужно чтобы информация сохранялась при отключении питания. У меня есть SD карта на 2Гб, я все что угодно оттуда могу загрузить после включения уже, поэтому мне и SRAM подойдет

Пока камень преткновения это именно скорость (напомню, я пишу на чистом Си без асма)
В частности вывод пиксела из датафлеша у меня идет следующим образом:
SPDR = 0xFF; // Загружаем стартовое значение в сдвиговый регистр
while (!(SPSR & 0x80)); // Ждем завершения процесса
PORTC = SPDR; // записываем байт принятый по SPI на экран (на PORTC стоит ЦАП)

Включил сейчас double clock на SPI, получилось 24 пиксела на строку.
Возможно while отжирает много. Думаю вместо него попробовать просто задержку в несколько тактов поставить, которую экспериментально подобрать.

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

Очевидно, для этой задачи вам понадобится 64кбайта памяти. Так же очевидно, что у меги32 внутри столько нету.
Можно поставить SRAM, но она сразу отъест у проца 27 ног.
Кроме того, при кварце 16 МГц вам нужно выводить новый бит каждые три такта.
Проще всего поставить ЦАП прямо на шину данных памяти, и как-то отключать его на время формирования бланков и синхр
(это еще две-три ноги). Тогда, чтобы вывести новый пиксель, вам нужно будет всего лишь инкрементировать значение одного восьмибитного порта (это в принципе можно сделать за три такта, но на си вы это не сможете контролировать).

В целом, я бы сказал, что реализация задумки плохо "спроектирована", то есть для таких параметров
выбраны не очень подходящие компоненты, поэтому получаются лишние навороты.

Michael_K писал(а):Затея довольно странная.

Чего только не придумает мой больной могз, что бы себя занять

Michael_K писал(а):Если придираться, то 256 градаций серого - это очень много.
На практике вы не различите и тридцати двух... Ну да бог с ними.

Я различаю 64. 1 байт просто для скорости и удобства работы.
Текущая реализация чисто на AVR 32х29х8бит. На порту стоит 6-ти битный ЦАП, обеспечивающий 64 уровня серого, соотв младшие 2 бита не используются.

Michael_K писал(а):В целом, я бы сказал, что реализация задумки плохо "спроектирована", то есть для таких параметров выбраны не очень подходящие компоненты, поэтому получаются лишние навороты.

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

Я бы попробовал сделать что-то вроде 72x54x4 только на меге. На ассемблере это делается довольно легко.
На Си - угадать невозможно.
Если хочется большего, то простой способ - это применение знакогенератора и псевдографики. Тоже только на меге.
Но при этом вы не сможете нарисовать все что угодно (только собирать картинку из заранее заготовленных кусочков)
и насчет Си я очень сильно сомневаюсь.

Ну а дальше - это уже аппаратные навороты. И тут уже можно выбирать компоненты под задачу.
Можно тупо взять проц с видеоконтроллером - и не мучаться. (хотя это неинтересно, согласен )

От безысходности пробую вариант по SPI
Через него можно сделать горизонтальное разрешение хоть 320 точек, но есть проблема:
Каждый 8й пиксель больше остальных в 4 раза!
От этого можно как-то избавиться? С SPI я только вчера начал разбираться.
SPI Mode 3, Master, частота например 2Мгц (при этом 88 точек в строке)
Пиксели вывожу вот так:

Код: Выделить всё • Развернуть

    SPDR = lvideo[0];           // 8 пикселей
    while (!(SPSR & 0x80));     // Ожидание конца передачи
    SPDR = lvideo[1];           // 8 пикселей
    while (!(SPSR & 0x80));     // Ожидание конца передачи
    ...
    SPDR = lvideo[9];           // 8 пикселей
    while (!(SPSR & 0x80));     // Ожидание конца передачи

Добавлено спустя 50 минут:
И еще при включении SPI командой SPCR = 0x5D; на MOSI появляется 1, которая сбрасывается только выводом байта
Поэтому не получается включать-выключать SPI каждый байт, а делать это 1 раз в строке во время обратного хода луча. Если бы не это, можно было бы сделать хотя бы темные промежутки каждые 8 пикселей.

HarryStar писал(а):Каждый 8й пиксель больше остальных в 4 раза!

Это скорее всего из-за проверки конца передачи в цикле. Реально там всего один или два такта добавляется (не помню точно).
Полностью выровнять все-равно не удастся, даже если по тактам все посчитать и нопами выравнивать, вообще ничего не проверяя.
И, да, SPI оставляет выход в последнем состоянии. Так что черные промежутки придется делать битом данных. То есть например семь пикселей видимых, а последний - ноль, чтобы промежуток не светился.

Можно попробовать реализовать 6 бит на пиксель по другому.
4 бит на пиксель в ЦАП.
и 2 бит за счет снижения частоты картинки, своеобразный ШИМ. Вывод 1 кадра из памяти за 4 видео кадра.