[501-й 0]

и что-то не припомню наличие аппаратных циклов у xmegи, то есть вот этот макрос .rep он не бесплатный, а всё равно развернётся в dec и brne, так что тактов на нормальный цикл там в любом случае не хватит.

а вот ценой нескольких кб флэша цикл можно действительно полностью развернуть, и передать всё за пару тактов на байт или за ~100мкс.

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

 

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

 

Илья

[_pv 52]

Ну на деле есть 6400 тактов.

Конечно, компилятор развезет это на много операций. Я описал примерно алгоритм работы.

То есть вы собрались выйти из передачи только по таймеру заранее зная сколько прйдет тактов на операции?

А как будет приемник принимать данные за 3 такта? 3 такта это 93нс. Только если их соединить чуть ли не вплотную, ибо 10+МГц будет и принимать без синхронизации. Непонятно

6400 тактов есть для передачи 1536 байт, то есть по 4 такта на байт.

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

LD .. 1 такт

OUT .. 1 такт

RJMP -2 2 такта

и предварительно завести таймер на N*4 вперёд то он сработает когда надо.

 

а в приёмнике

IN .. 1 такт

ST .. 1 такт

RJMP -2 2 такта

 

то передатчик будет выдавать данные каждые 4ре такта, а приёмник забирать.

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

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

 

[RadiatoR 2]

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

[_pv 52]

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

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

 

[RadiatoR 2]

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

[501-й 0]

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

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

 

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

 

Илья

 

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

 

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

 

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

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

 

Илья

[ILYAUL 0]

Но если памяти хватает, то можно тупо повторить 1536 раз фрагмент:

in reg, PORT_PIN

st Y+, reg

И без всяких jmp-ов и циклов

+

NOP - n раз для синхронизации , где n = 1,2,3.....

[pyroman 2]

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

[RadiatoR 2]

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

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

[BALDA 0]

Для приема:

Триггер ДМА завести по прерыванию внешнего входа

источник будет порт приема

назначение будет буфер озу с инкрементом

по истечению нужного колва байт в транзакции ДМА вывести запрос на прерывание у дма

вот и всего делоф.

 

Для передачи:

добавляем эвент контроллер дергания ноги строба.

загрузка проца минимальна.

 

 

 

 

[zombi 0]

Триггер ДМА завести...

Предлагаете и в приёмнике и в передатчике использовать DMA?

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

И как оба процесса синхронизировать?

[501-й 0]

Предлагаете и в приёмнике и в передатчике использовать DMA?

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

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

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

 

Илья

[Склихасовский 0]

у меня был подобный опыт

реализация LVDS на хмега

только там 3 порта вывода пришлось реализовывать и внешнюю срам ставить.

примерно 15 гц рефреша получилось

--

ваше беспокойство по поводу сколько тактов нужно чтобы данные успели отобразиться в порту

хотя это как правило 1,5 такта

решается банально таймером с PWM и двумя системами сравнения

этот же таймер будет вам генерировать стробы.

а ширину периода крутите как вам угодно.

 

 

 

 

 

 

 

[BALDA 0]

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

если это для людей сложность..

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

----------------------

[RadiatoR 2]

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