[kostya-m 0]

Для обслуживания McASP через dMAX в фирменном документе SPRU795D есть пункт 3.6.1 (страница 132)

При ее изучении, возникли вопросы:

 

1. Они почему-то используют абстрактный Event#18, хотя на странице 49 есть таблица событий и есть событие 5 - MCASP0RX - как раз предназначенное для обслуживания приема по нулевому каналу, который в примере. Собственно даже непонятно как это 18-е событие вдруг сгенерится.

 

2. Почему в качестве адреса источника используется базовый адрес McASP0 0x54000000, а не адрес приемного буфера McASP0.RBUF[0] 0x54000280, с которого реально придут первые данные

 

3. Предположим, что ответ на пункт 2 в том, что dMAX сам разберется из какого буфера читать, но зачем тогда введены инкременты для адреса источника SINDX0,1,2. После чего в на картинке примера вообще чтение из McASP идет по адресам 0х540000000, 0х54000004 и 0х54000008

spru795d_TMS320C672x_DSP_Dual_Data_Movement_dMAX.pdf

[kostya-m 0]

На вопросs 2 и 3 ответ в документации на McASP "3.3.2 Transfers through the dMAX Port"

А вот на вопрос 1 пока ответа не вижу. Похоже у них очепятка

[andrewn 0]

А вот на вопрос 1 пока ответа не вижу. Похоже у них очепятка

Не знаю, зачем в примере ипользуется 18 ивент, но он програмно генерится установкой (или сбросом) бита 18 в регистре DETR.

[kostya-m 0]

Не знаю, зачем в примере ипользуется 18 ивент, но он програмно генерится установкой (или сбросом) бита 18 в регистре DETR.

Вот и я не могу этого понять в примере по McASP, поскольку последний не должен трогать этот бит

[andrewn 0]

Вот и я не могу этого понять в примере по McASP, поскольку последний не должен трогать этот бит

В качестве гипотезы можно предположить, что McASP прерывает ЦПУ, а DMAX запускается программно, 18 ивентом из ISR.

 

"Нормальные герои всегда идут в обход"...

[kostya-m 0]

В том то и проблема, что McASP в С672х не умеет делать прерывания, только умеет создавать эвенты для dMAX.

[andrewn 0]

В том то и проблема, что McASP в С672х не умеет делать прерывания, только умеет создавать эвенты для dMAX

Непосредственно да, действительно нет прерывания. Есть способ "в обход" (надо же, я не знал, только сейчас прочитал в data manuale, но как в воду глядел!) насетапить ивент энтри в dMAXе, чтобы генерилось прерывание от McASP (см. INT9-INT13 и INT15). Но это только если очень надо.

 

Если задача просто запустить пример dMAX передачи, то и нужно использовать соответствующий ивент (EVT 5,7,9), а прерывание dMAX пусть устанавливает по завершению передачи.

 

[kostya-m 0]

Непосредственно да, действительно нет прерывания. Есть способ "в обход" (надо же, я не знал, только сейчас прочитал в data manuale, но как в воду глядел!) насетапить ивент энтри в dMAXе, чтобы генерилось прерывание от McASP (см. INT9-INT13 и INT15). Но это только если очень надо.

 

Если задача просто запустить пример dMAX передачи, то и нужно использовать соответствующий ивент (EVT 5,7,9), а прерывание dMAX пусть устанавливает по завершению передачи.

 

Спасибо. В общем то, я запустил и прием и передачу. Правда, пока с глюками и без обработки ошибок. И по общему описанию, а не по примеру. Ох тяжело разбирать. Странно, на другие семейства у ТИ гораздо лучше документация, а на 672х просто мрак. На 28х вообще никого не пришлось спрашивать, а тут на форуме ТИ пришлось кучу вопросов позадавать. Да и пока не удается получить прерывание 8-е по завершению. Но тут писали, что может надо патч применить к dMAXу

Изменено 7 января, 2014 пользователем Мусатов Константин

[andrewn 0]

Спасибо. В общем то, я запустил и прием и передачу. Правда, пока с глюками и без обработки ошибок. И по общему описанию, а не по примеру. Ох тяжело разбирать. Странно, на другие семейства у ТИ гораздо лучше документация, а на 672х просто мрак. На 28х вообще никого не пришлось спрашивать, а тут на форуме ТИ пришлось кучу вопросов позадавать. Да и пока не удается получить прерывание 8-е по завершению. Но тут писали, что может надо патч применить к dMAXу

INT8? А оно разрешено во всех K регистрах разрешения? Начиная с битов в Event Entry TCC, ATCINT, TCINT и т.д...

 

Поздравляю. Это хорошая тренировка, и без пользы она не пропадёт, если будете дальше работать с другими С64+/С674х/С66х. А 28х - это просто счёты по сравнению с С6000.

 

Жаль, что dMAX это один немногих контроллеров, который в серию не пошёл, кроме С672х нигде больше не применяется. Но он похож на EDMA/EMDA2/EDMA3, так что и этот опыт в плюс а не в минус.

 

А вот контроллер прерываний изменился существенно. Внутри ЦПУ всё осталось прежним, 14 прерываний, IFR/IER/ISR/ICR, а снаружи - мультиплексор на 128 входных сигналов (INTC) плюс на этот мультиплексор подвешиваются дополнительные мультиплексоры (Chip Interrupt Controller CIC). Немного сложнее.

 

Удачи.

[kostya-m 0]

INT8? А оно разрешено во всех K регистрах разрешения? Начиная с битов в Event Entry TCC, ATCINT, TCINT и т.д...

Вроде да. Даже иcискусственно его инициировал - стоит бит в IFR, но прерывание не вызывается

Но наверно что-то еще упустил.

[Alex11 5]

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

[andrewn 0]

стоит бит в IFR, но прерывание не вызывается

Понятно... Тогда попробуем посмотреть с другой стороны цепочки:

Бит 0 в CSR, GIE = 1

Бит 1 в IER, NMIE = 1

Бит 8 в IER, IE8 = 1

ISTP инициализирован правильным адресом таблицы прерываний

По адресу ISTP + 8 * 8 * 4 записан правильный ISFP для INT8 с переходом в ISR

И сама ISR записана по адресу из ISFP.

??

 

[kostya-m 0]

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

Спасибо, я его заранее скачал, но не применял, что бы понять его надобность. Значит нужен.

Бит 0 в CSR, GIE = 1

Бит 1 в IER, NMIE = 1

Бит 8 в IER, IE8 = 1

ISTP инициализирован правильным адресом таблицы прерываний

По адресу ISTP + 8 * 8 * 4 записан правильный ISFP для INT8 с переходом в ISR

И сама ISR записана по адресу из ISFP.

Спасибо! GIE не стоял. Теперь принудительно заработало прерывание. Возьмусь за настройку его из dMAX

 

После постановки патча dMAX перестал давать что до этого жило. Наверно жило не по-првилам.

Заметил, что когда разрешаю эвенты в DEER, то эти же биты поднимаются в DEDR (запрет на эвенты) . Вроде по описанию они сбрасываются записью в DEER, но этого не происходит. Или это не важно?

Еще вопрос по DEPR - полярность эвентов. В McASP бит XDATA и RDATA положительные, потому ставлю в DEPR единички - т.е. по поднятию (но и нолики не помогают)

После инициализации dMAX внутри инициализации McASP0 идет проверка, что заработал dMAX тем, что дожидаюсь, что сбрасывается XDATA

while( MCASP0->XSTAT.XDATA )
        asm( "    nop 4" ); // Если XDATA сбросился, значит DMA начал работать

Теперь на этом зависаю. Хотя в DEFR стоит бит 4, который вроде как раз и отвечает за MCASP0TX. Но еще стоит бит 26 "AMUTEIN0 or McASP0 TX INT or McASP0 RX INT (error

on MCASP0)". Но я обработчик этого дела еще не писал.

 

 

Запретил прерывания у McASP - снялся бит 26, а 4-й остался, но обслуживания события не происходит. Все не дает мне покоя самовыставляемый бит в DEDR.

 

Применил фирменный патч - все заработало, и dMAX и прерывания.

Может я самодельный патч неправильно ставил? Я в начале main после инициализации таблицы прерываний вызывал

dMaxPatch();

и программу в буфер пока не засовывал.

[andrewn 0]

Применил фирменный патч - все заработало, и dMAX и прерывания.

А этот патч на что похож? Из CSL?

 

Заметил, что когда разрешаю эвенты в DEER, то эти же биты поднимаются в DEDR (запрет на эвенты) . Вроде по описанию они сбрасываются записью в DEER, но этого не происходит. Или это не важно?

Да, это несколько "странные" регистры. По идее, должно бы одного хватить - 0 = событие запрещено, 1 = разрешено, но сделали два и они не связаны логически между собой (грубо говоря, внутри контроллера замыкают-размыкают 32 контактика). Т.е. из DEER = DEDR = 0x00000001 непонятно разрешено или запрещено событие 0. Это зависит от последовательности записи 1 в DEER, DEDR. Например, после ресета оба эти регистра = 0. Т.е. их читать вообще смысла нет, а если нужно отслеживать разрешённые события, то для этого надо выделить специальную переменную и обновлять её в соответствии с записями в DEER, DEDR.

Изменено 8 января, 2014 пользователем AndrewN

[kostya-m 0]

А этот патч на что похож? Из CSL?

Не, он отдельно взят из SPRC203. Версия патча в нем 2.00