.rep -- это директива ассемблера (в частности, gas), повторяет фрагмент до .endr указанное число раз.

И за пару тактов не получится. Передатчик не может тратить меньше трёх тактов на передачу байта. Вот если передатчик ПЛМ'ка какая... то тут возникает вопрос со стабильностью приёма, т.к. входной тракт вывода порта микроконтроллера требует стабильного состояния сигнала в течении двух тактов минимум.

Илья

6400 тактов есть для передачи 1536 байт, то есть по 4 такта на байт.
такты на операции у авров вполне себе предсказуемо считаются, и контроллеры работают от одного тактового сигнала, поэтому если в передачике сделать
LD .. 1 такт
OUT .. 1 такт
RJMP -2 2 такта
и предварительно завести таймер на N*4 вперёд то он сработает когда надо.

а в приёмнике
IN .. 1 такт
ST .. 1 такт
RJMP -2 2 такта

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

rjmp это хорошо, а кто инкремент будет делать? Или он оффсетом будет идти?

ST Y+, reg у хмеги всё равно за 1 такт вроде, не?

сначала написал - потом подумал, жалко удалить коммент нету кнопки

Да. 'LD reg, Z+' 2 такта. Так что три такта -- минимум.

Синхронизацию можно глянуть на avrfreaks.net. Там есть проект вывода видеосигнала из икс-меги, и в нем есть синхронизация сигналов до такта. И я там же код для синхронизации приводил.

Илья



Не-не-не. Так нельзя. Можно нарваться на чтение порта в нестабильном состоянии. Передатчик и приёмник должны быть синхронизированы с точностью до такта. Чтение первого байта любого пакета всегда должно отставать на некоторое (фиксированное!) число тактов от записи этого байта (и у нас должна быть возможность выбрать величину отставания). Если момент чтения сдвигается относительно момента записи (от пакета к пакету; в пределах пакета он точно двигаться не будет), то я бы не стал гарантировать работоспособность.


Ага, Ты тоже это понимаешь. Но если мы можем синхронизироваться в пределах передачи байта (т.е. в пределах 3-х тактов), то это значит, что мы можем синхронизироваться и в пределах пакета.

Илья

И без всяких jmp-ов и циклов
+
NOP - n раз для синхронизации , где n = 1,2,3.....

SPI + DMA и нет проблем.

А ничего, тчо тактовая 32Мгц и передавать придется со скоростью 61,5Mbps?

Для приема:
Триггер ДМА завести по прерыванию внешнего входа
источник будет порт приема
назначение будет буфер озу с инкрементом
по истечению нужного колва байт в транзакции ДМА вывести запрос на прерывание у дма
вот и всего делоф.

Для передачи:
добавляем эвент контроллер дергания ноги строба.
загрузка проца минимальна.

Предлагаете и в приёмнике и в передатчике использовать DMA?
А сколько тактов необходимо для передачи одного байта из увв во внутр. память и наоборот?
И как оба процесса синхронизировать?

Человек не осознал сложность, поторопился. Этот вариант уже отвергли.

Не менее 5 тактов (я бы рассчитывал на значение более 7, но если нужно точно, то это можно проверить). Плюс задержки из-за конфликтов во время доступа ядра и DMA к шине данных (в SPI, USART и т.п. эти задержки сглаживаются наличием промежуточного буфера).

Илья

у меня был подобный опыт
реализация LVDS на хмега
только там 3 порта вывода пришлось реализовывать и внешнюю срам ставить.
примерно 15 гц рефреша получилось
--
ваше беспокойство по поводу сколько тактов нужно чтобы данные успели отобразиться в порту
хотя это как правило 1,5 такта
решается банально таймером с PWM и двумя системами сравнения
этот же таймер будет вам генерировать стробы.
а ширину периода крутите как вам угодно.

если это для людей сложность..
нада зарплату пойти больше просить. :-)
----------------------

Может тут имелась ввиду не сама сложность, а то, что не подходит по временным характеристикам?