Здравствуйте. Помогите разобраться с проблемой ...
Формирую на ATMega128 видеосигнал при помощи SPI. Устанавливаю режим Master, двойная скорость. Одна точка изображения занимает два такта. Необходимо выводить байт за байтом непрерывно. Всего 48 байт.
Инициализация:
LDI BUF,(1<<SPE)|(1<<MSTR)|(1<<CPHA); 4
OUT SPCR,BUF ; SPI
LDI BUF,1<<SPI2X ; CONFIGURATION
OUT SPSR,BUF ;
(BUF - временный регистр)
SS устанавливаю на вывод единицы. MOSI устанавливаю на выход.

Начинаю вывод строки:
VSTRLOOP: OUT SPDR,VDATA24 ; 1 - начинаю вывод данных
OUT ATTRPORT,ATTR ; 2 - это вывод аттрибутов цвета изображения
LD VDATA24,X+ ; 4 - читвю из ОЗУ очередной байт данных
LD ATTR,Y+ ; 6 - и очередной аттрибут цвета
NOP ; 7 - выравниваю время нопами
NOP ; 8
NOP ; 9
NOP ; 10
NOP ; 11
NOP ; 12
NOP ; 13
CPI XL,0X40 ; 14 - в конце проверяю на предмет передачи последнего байта
BRNE VSTRLOOP ; 15 /> 16 - цикл
NOP ; 16

Такты подсчитываю в комментариях.

В результате: первый байт передаётся правильно. Второй - не передаётся, вместо него на экране вижу последний переданный бит - белую черту в случае если последним битом была единица и тёмную - если был ноль. Третий байт опять корректный, четвёртый - как второй и так далее до конца строки.
В общем пока не понял что это такое и как добиться задуманного.

я бы проверил осциллографом что там физически выходит по SPI может там все так как и задумалось а проблема в другом месте

Проблема точно не в другом. Видеосигнал я принимаю USB TV тюнером Beholder по нч видеовходу. Есть другая программа, где я вывод делаю вручную, и и она работает отлично, но там получается три такта на пиксел, а мне недо 2.

А вот если в конце передачи байта выключть SPI и тут же включить, то всё становится на свои места. Но только на место этого включения/выключения смотреть неприятно. Пиксел затянут.
Схемка во вложении)

ИМХО, это принципиально невозможно. Новые данные в SPDR можно загрузить только после передачи предыдущего байта (т.е. на семнадцатом такте).


Эти симптомы подтверждают сказанное мной выше.

Чтобы убедится в этом окончательно - добавьте один NOP к группе пустых операторов в "выравнивании времени". Думаю, что тут же появятся и четные байты, а вот последние пикселы каждого байта будут в полтора раза "длиннее" остальных...

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

Нет, шестнадцатым - считать нужно с команды, следующей за OUT SPDR,VDATA24. Вставьте, в конце концов, ещё один NOP и убедитесь, что отображение четных байт появиться...

Я их там три штуки пробовал ставить. Ничего. Строчная синхронизация уже слетать начинает. Да и делу это не поможет - мне нужно непрерывное изображение, без затягиваний ...

В том, что Вы пытаетесь записать данные раньше положенного времени, можно убедиться, посмотрев на флаг WCOL

Не раньше. Проблема совсем не в этом. SPI по скорости настроен как надо: 2 такта процессора не точку, и на экране я вижу то же самое ...Передаю 0B10101010 и вижу 4 точки и 4 пробела. Из 48 байт вижу ровно 24 корректных и 24 некоректных.

= 64 или первые 16 чем-то ещё заняты?

И схему выложите в pdf

Кстати! Возможно, их там и нужно вставить три штуки! Согласно с комментарием к команде данные выбираются не из памяти программ (как я это отчего-то подумал), а из ОЗУ. В этом случае команда LD Rd,X+ выполняется за один такт, а таких команд у Вас в программе две.
Но! И в этом случае может быть неудача! Обратите внимание на рисунок "SPI Block Diagram", приведенный в DS. Тактирование SPI осуществляется от делителя сигнала XTAL. C этим сигналом тактирования SPI выполнение Вашей программы нигде не синхронизируется. Т.е. работа SPI при выводе первого байта может начаться не в следующий такт за командой загрузки данных в регистр SPDR, а при поступлении от делителя тактового импульса (поскольку у Вас деление на 2, то больше чем на такт он задержаться не может).
Таким образом, следует добавить в "выравнивание времени" три пустых оператора, и если не изменилась картина на выводе, то перед циклом вывода добавить ещё один пустой оператор для синхронизации с импульсами тактирования SPI.

P.S. Извеняюсь - недодумал... Если вставить в "выравнивание времени" три пустых оператора, то выполнение цикла будет производиться за нечетное число тактов XTAL и произайдёт рассинхронизация с тактовыми импульсами SPI (т.е. цикл должен всегда выполняться за четное число тактов). Следовательно в цикл следует добавить четыре пустых оператора (ну, или, возможно, и два, в чём я лично сомневаюсь).

P.P.S. Я, конечно, понимаю, что Вам не хочется вставлять такое число пустых операторов - последний пиксел, соответствующий последниму биту в байте будет в два раза "длиннее" остальных... Я в своем первом сообщении в этой теме и предупреждал о вероятной невозможности обеспечения непрерывной передачи по SPI. Если Вы намеревались выводить графическую информацию, то, конечно, при таком выводе она будет неприятно искажена. А для вывода символной информации - такой эффект может оказаться маленьким плюсом, если у Вас символы будут иметь ширину 7 пикселов: удвоенный восьмой бит можно использовать как промежуток между символами...

Может я кончно чего и не знаю, но согласно DS на мегу128 все LD Rd,X... выполняются минимум за ДВА такта.

Непрерывную строку пикселов выводить не получается. Между двумя байтами минимальный зазор 1,5 такта spi, на загрузку нового значения. Долго возился в своё время с мегой16 - не получилось. И в даташите в общем так и нарисовано. Разве что переделали SPI в 128-й меге, но вряд ли.

Спасибо.
Да, действительно. Сегодня плотно повозился с этим делом. Наилучший эффект получается только с двумя дополнительными нопами плюс к 16 тактам. Последний бит неизбежно затягивается.
Я разозлился и сделал следующее: начинаю делать вывод данных через SPI. Пока они выводятся вывожу в порт B: MOSI последний - нулевой бит данных. Когда доходит дело до вывода этого самого бита через SPI жестоко выключаю SPI по питанию. В этот момент конфигурация порта В:MOSI изменяется и на линии оказывается записанное прежде в порт В последнего бита. Тут же включаю SPI. В результате портятся пол точки на экране. Затем повторяю весь цикл.
Но и тут возникает загвоздка. Всё равно корректность работы SPI зависит от ДАННЫХ, которые я передаю. И при определённых данных опять чётные передачки ломаются.
Короче после этого я окончательно разозлился на SPI и стал выводить данные вручную по 3 такта на точку. Как раз 48 байт умещаются в строке, но на экране я вижу только 43, а 5 по-моему оказываются в зоне сигналов гашения TV тюнера. Вот такая вот история.А код такой:
.MACRO VIDEOSTRING_

OUT PORTB,VDATA1 ; 7
OUT ATTRPORT,ATTR ; 7
LSL VDATA1 ; 7

OUT PORTB,VDATA1 ; 6
BST VDATA1,1 ; 6 SAVE BIT 0
LSL VDATA1 ; 6

OUT PORTB,VDATA1 ; 5
BLD VDATA10,PIXEL ; 5 TO VDATA10:PIXEL
LSL VDATA1 ; 5

OUT PORTB,VDATA1 ; 4
BST VDATA1,4 ; 4 SAVE BIT 1
LSL VDATA1 ; 4

OUT PORTB,VDATA1 ; 3
BLD VDATA11,PIXEL ; 3 TO VDATA11:PIXEL
LSL VDATA1 ; 3

OUT PORTB,VDATA1 ; 2
LD VDATA1,X+ ; 2

OUT PORTB,VDATA11 ; 1
;LD ATTR,Y+ ; 1
LDI BUF,0B01000111
MOV ATTR,BUF

OUT PORTB,VDATA10 ; 0
NOP ; 0
NOP ; 0



OUT PORTB,VDATA1 ; 7
OUT ATTRPORT,ATTR ; 7
LSL VDATA1 ; 7

OUT PORTB,VDATA1 ; 6
BST VDATA1,1 ; 6 SAVE BIT 0
LSL VDATA1 ; 6

OUT PORTB,VDATA1 ; 5
BLD VDATA10,PIXEL ; 5 TO VDATA10:PIXEL
LSL VDATA1 ; 5

OUT PORTB,VDATA1 ; 4
BST VDATA1,4 ; 4 SAVE BIT 1
LSL VDATA1 ; 4

OUT PORTB,VDATA1 ; 3
BLD VDATA11,PIXEL ; 3 TO VDATA11:PIXEL
LSL VDATA1 ; 3

OUT PORTB,VDATA1 ; 2
LD VDATA1,X+ ; 2

OUT PORTB,VDATA11 ; 1
;LD ATTR,Y+ ; 1
LDI BUF,0B01000111
MOV ATTR,BUF

OUT PORTB,VDATA10 ; 0
NOP ; 0
CLR BUF ; 0




.ENDMACRO
А схема есть в ворде (вложение).

А какая частота строчной развёртки?

В новых мегах можно настроить USART как SPI Master, причем с буферизацией, и такой проблемы быть не должно. Когда-то я воевал с SPI, что-то отложилось про 18 тактов на все. Подробностей не помню, правда...

Стандартная. 15.625 КГц.


Новые меги ... Имеется ввиду ATMega128A- ... ?

Нет, имеется в виду ATmega164/324/644/1284

Да, и в младших (48/88/168). Если нужно что-то многоногое типа M128 - надо смотреть, я с такими дела не имел...

Ну, вот полмысли Вам уже высказали- UART - и это не только двойная буферизация , но и работа в сихронном режиме с помощью внешнего сигнала XCK.
Например с 15.625 КГц*8. Что во много меньше чем необходимо по DS = 5Мгц

P/S Кстати , ради чистой проверки идеи , когда-то делал на нем генератор меандра, замечательно получается и с изменением частот меандра , правда чисто в асинхроном режиме. Это к тому, что "разрывов" в форме меанра нет

Не, USART не пойдёт. Там старт и стоп биты. Ещё хужее будет ... А другой пин-несовместимый процессор ставить - эт значит весь проект перелопатить, а он у меня уже в завершённой стадии. Простро я пытаюсь на этой же платформе сделать эмуляцию уже другой машины ...

ИМХО - странная и бесполезная идея... Я, конечно, понимаю - бывают случаи, когда некоторых ресурсов (например, таймера) не хватает, но при этом есть неиспользованные ресурсы (например, USART) и логично их использовать так сказать - "нетрадиционно"... Но, в Вашем случае - использовать TxD для генерации меандра... Это, уж извините, - извращение и мазохизм. Ведь "рядом" есть вывод XCK от того же USART, на котором меандр и выводится (абсолютно без "разрывов" ), стоит только настроить USART в Master Synchronous Mode - и всё !

Какие в синхронном режиме старт и стоп биты? Читаем хотя бы тут или напрягаем Гошу 2.1.3. Взаимодействие устройств в синхронном режиме


Целиком согласен . И никогда такое использовать не буду. Был чистый эксперимент

Не знаком с Гошей, и поэтому не знаю: где у него про это почитать...
В синхронном и асинхронном режимах USART Frame Format ничем не отличаются. Т.е. в обоих режимах будут присутствовать старт и стоп импульсы. В AVR эти режимы отличаются исключительно тем, что в синхронном режиме тактовую частоту USART у Master с Baund Rate Generatоr можно вывести "наружу" на ногу XCK, а у Slave этот сигнал можно использовать вместо сигнала от Baund Rate Generatоr. Полезность использования синхронного режима я вижу только в том, что при нестабильной тактовой частоте МК (например, при тактировании от RC-генератора) не будет проблем в обмене по последовательному интерфейсу из-за "неточностей" скоростей USART разных МК.

Вот вот, а то я уже тоже испугаться уже хотел ...

А вот Вы меня по настоящему пугаете. Я уж воспользовался DS микрочип, у них как-то лучшее показаны диаграммы , но если шо, попрошу AVR прислать что нить поподробнее , чем в их даташит.
Ну и ответьте сами себе , на ..на в синхронном режиме , ещё и старт стор биты- чего ещё там нужно подсихронизировать?


P/S Гоша = Google

Ну, стоповый импульс в синхронном режиме - излишен, а, вот, стартовый - для того же, что и в асинхронном - начало передачи информации.

P.S. C ненужностью стопового - погорячился... Для синхронизации тактовых импульсов МК и USART.

Да нет там ни старта ни стопа. Ну посмотрите внимательно диаграммы. Всё определяется фронтами и спадами импульсов сихро XCK и схемой сихронизации MC этих импульсов с внутренним передатчиком или приёмником USART. По фронту импульса мастер может принимать или прередавать данные , соответсвенно по спаду того же импульса передать или принять данные. Или наоборот. Зависит от установок.
Вы можете в этом режиме предать сколь угодно байтов без остановочно и без стартов и так же принять. Вся сихронизация определяется именно XCK

Народ, я уже готов поверить в отсутствие старт/стоп бит в синхронном режиме, но проштудировав datasheet на ATMega128 ничего подобного не нашёл ... Ну будьте любезны, ткните меня носом ... Если это так, я просто возрадуюсь !!!
ЗЫ - а диаграммы эти вообще не оттуда )))

Импульсы XCK следуют без "перерывов" (иначе Slave не сможет передавать информацию Master'у). Стартовый импульс нужен как сигнал "Далее идут данные"

Увы! Разачарую Вас... Я это исследовал в своё время: стартовый и стоповый импульсяы - присутствуют в любом режиме (иначе оно и работать не должно !). Если хотите реализовать формирование сигнала именно на последовательном устройстве AVR, то, имхо, единственный выход USART в режиме SPI.

Вот первая из приведённых мной диаграмм - пересылаются 2 байта , где окончание (stop) одного и start другого?


PIC16F87/88

Этот подраздел форума называется "AVR", а тема про USART ATmega128. USART AVR не обязан быть идентичен устройству с последовательным обменoм в PIC.

P.S. Поправочка: тема начиналась про SPI AVR, но "скатилась" в USART.

Ну не надо. Не красиво. Я уже попросил в ATMEL такие же диаграмы , а заодно уж и про Stop-start биты спросил.
Да разбирались с SPI - поняли , что не прокатывает. Ищем другой путь. Ну уж , если у PIC и AVR асинхронные режимы как братья близнецы , то почему вдруг синхронные должны различаться. Кстати я пояснял почему взял те диаграммы
С уважением
Илья

Примите за данность - синхронный режим в AVR не такой, как в PIC. Он вообще совершенно идиотский. И да, гонит и старт, и стоп, и отключить это нельзя. Проверяется, кстати, элементарно, даже скоп не нужен - стрелочным вольтметром.


В PIC-то работает. Байтовую синхронизацию - да, надо бы какую-то приделать. Но хоть как-то похоже было бы на "нормальный" синхронный режим. А так - совершенно бесполезная вещь, IMHO.

Пипец , какой-то. Тогда это чёрти что и на... он нужен. Палыч, примите мои искриние извинения.

Как это не смешно но у support нет диаграм работы (расширенные) в синхронном режиме. Правда пояснили почему у них есть стартовые импульсы, в синхронном режиме частота ХСК - генерится постоянно , поэтому и нужны старты. Предложили использовать USART в SPI режиме - там нет стартов и стопов. Но 128 такое не поддерживает.

Замените ATmega128 на ATmega1281 - они по пинам один-в-один. ATmega1281 имеет "на борту" USART, который может работать в режиме SPI. Ваша проблема будет решена. Про переход с m128 на m1281 можно прочитать в AppNote AVR098 .

Спасибо огромное !!!
По-моему, это решение проблемы )))