Harvester

Если бы только это... Почему-то поведение процессора даже с мануалом не совпадает. :( В доках написано (Table 6-12. EDMA Synchronization Events): Event 2 - McBSP0 Receive, Event 3 - McBSP0 Transmit. Соответственно, 1. Включаю BFIFO; 2. Загружаю PaRAM PaRAM set 2: источник - 0x01F10000 (FIFO RBUF), приемник - буфер в памяти, TCC = 12 PaRAM set 3: источник - буфер в памяти, приемник - 0x01F10000 (FIFO XBUF), TCC = 13 3. Разрешаю прерывания DMA для заданных TCC: IESR = (1 << 12) | (1 << 13) 4. Разрешаю события DMA: EESR = (1 << 2) | (1 << 3) 5. Запускаю McBSP SPCR |= 1 << GRST; SPCR |= (1 << XRST) | (1 << RRST); SPCR |= (1 << FRST); 6. В обработчике прерывания DMA ловлю оба события (по идее они должны наступить практически одновременно и обработаться в одном заходе в обработчик): while ((ipr = HWREG(EDMA3_0CC0_BASE_ADDR + EDMA3CC_IPR)) != 0) { // check flags dmaBusFlags |= ipr; // clear setted IPR bits HWREG(EDMA3_0CC0_BASE_ADDR + EDMA3CC_ICR) |= ipr; } Но на самом деле получается ерунда. Для каждого последующего запуска (пп 1...5) поочередно получаем следующее 1. Ловится прерывание Rx (IPR = 0x1000) 2. Ловится прерывание DMA Error, EMR = 0x04 - пропущено событие 2 либо 1. Ловится прерывание Tx (IPR = 0x2000) 2. Ловится прерывание DMA Error, EMR = 0x08 - пропущено событие 3 Если же я формирую PaRAM наоборот, т.е. [2] - для передачи, а [3] - для приема, то все работает как требуется: сначала ловится Tx (IPR = 0x1000), потом Rx (IPR = 0x2000). Правда, после этого всегда почему-то ловится прерывание DMA Error, EMR = 0x04 - пропущено событие 2 :( Как говорится, кто виноват и что делать? :)

Спасибо, я почему-то не думал в этом направлении. Если что-то не учли, сдвиг действительно может оказаться больше запланированного. Убедиться в этом можно только одним способом - ткнуться анализатором на шину. Пока у меня нет такой возможности, как появится - попробую. А насчет неправильного алгоритма - что есть. Работает не первый год, множество изделий, в обозримом будущем менять никто не будет. Кстати, а какой алгоритм Вы могли бы предложить?

Слейв(ы) - модуль I2S в TMS320С5532. Их может быть несколько В каждом фрейме I2S передается номер (адрес) слейва. Если адрес в фрейме совпадает с адресом слейва, то последний формирует данные (для этого и нужна задержка), через 2 фрейма после получения команды подключается к шине и передает ответ. В исходниках слейва действительно задана задержка в 2 фрейма и по ней вопросов нет. Вопрос в том, что данные приходят с дополнительной задержкой в 3 фрейма, поэтому размер пакета пришлось увеличить на 3. Т.е. должно быть так Tx: XXXXXXXX00 Rx: 00XXXXXXXX а получается так Tx: XXXXXXXX00000 Rx: 00000XXXXXXXX

Ну, насчет "гнать" это не в моей компетенции. Тем более как-то все работает и далеко не первый год. А по существу - можете ли Вы на основании своего опыта предположить причины такой работы периферии? В какую сторону копать?

Добрый день. Что имеется: C6746 (мастер) передает/принимает данные по шине I2S (McBSP) в дуплексном режиме. Для обмена используется DMA (пинг-понг с ручным переключением буферов по событию (Rx Finished & Tx Finished)), данные передаются пакетами по 8 фреймов I2S. Цикл обмена запускается по таймеру. Ведомый отвечает с задержкой в 2 фрейма, поэтому размер пакета для DMA должен быть равен 10. Т.е. теоретически транзакции должны быть такими: Tx: XXXXXXXX00 Rx: 00XXXXXXXX На практике эта система почему-то работает не так: 1. В буфере приёма данные оказываются сдвинуты не на 2 фрейма, а на 5, из-за чего размер пакета увеличен до 13. По словам разработчика эту задержку вносит EDMA или "еще что-нибудь". Раньше я с DMA не работал, но что-то смущает меня такое объяснение. Поэтому хочу спросить у знающих - действительно ли DMA может/должно так криво работать или проблема все же в руках? 2. Имеет место задержка пакетов на 2 цикла обмена, т.е. каждый принятый пакет соответствует пакету, переданному 2 цикла назад. По словам разработчика это задержка в DMA. И опять аналогичный вопрос - действительно ли DMA так работает или проблема все же в некорректной настройке периферии?

Кстати, от техподдержки TI пришел ответ на мой 1-й вопрос. Правильная информация - в datasheet: Event 2 - McBSP0 Receive, Event 3 - McBSP0 Transmit В TRM ошибка.

Спасибо, посмотрю.

Ну, пинг-понг сделан ручной, т.е. в прерывании переключаются буфера и запускается обмен. А что касается мануала, то в нем-то и вопрос. В процессе изучения рабочего исходного кода я вижу, что он не совпадает с мануалом. Поскольку у меня нет опыта работы с такими процессорами, возникает вопрос - правильно ли я понимаю мануал? Тем более что, как я уже сказал, в DS указано: Event 2 - McBSP0 Receive, Event 3 - McBSP0 Transmit. А в TRM написано: "DMA channel 3 services the incoming data stream of the McBSP. <...> DMA channel 2 services the outgoing data stream of the McBSP" (16.3.4.3.1 и 16.3.4.3.2) Т.е. вроде как наоборот. PS На 2-й вопрос я ответ нашел сам - да, так можно: "If in an application, a channel does not make use of the associated synchronization event or does not have an associated synchronization event (unused), that channel can be used for manually-triggered or chained-triggered transfers."

Прошу не пинать за глупые вопросы, в очередной раз разбираюсь с унаследованным кодом. В устройстве производится обмен по шине I2S (McBSP0) с использованием EDMA в режиме пинг-понг. В коде присутствуют следующие определения: // каналы ЕДМА для нужд шины #define EDMA_CH_RX1 3 #define EDMA_CH_RX2 13 #define EDMA_CH_TX1 2 #define EDMA_CH_TX2 12 И уже здесь возникают вопросы: 1. В DS (Table 6-12. EDMA Synchronization Events) указано, что Event 2 - McBSP0 Receive, Event 3 - McBSP0 Transmit, т.е. ровно наоборот. В принципе это не очень важно, поскольку обмен по I2S дуплексный и флаги прерывания по RX и TX устанавливаются и проверяются одновременно. Но хотелось бы понять. 2. В той же таблице указано, что каналы 12 и 13 вообще относятся к UART1. С другой стороны, в документации сказано, что при завершении транзакции DMA будут установлены биты прерывания, соответствующие значению поля TCC регистра OPT PaRAM. Т.е. вроде как никто не запрещает использовать "правильный" для MCBSP канал DMA, но "неправильное" прерывание. Насколько это умозаключение верно? Помогите разобраться.

И где же такие свалки найти? :)

Спасибо большое. Попробую теперь использовать SI не только для разгребания чужих проектов.

Не подскажете, как прикрутить к SI компиляторы? Что-то я такого функционала даже не вижу :(

Не подскажете ссылку на эту библиотеку? А то гугл какого-то неправильного Антона Гусева предлагает :)

Для этого может и найдется. А вот 16-битный TASM, который должен запускаться под DosBox - точно не поддерживается. :) В любом случае cmake, ninja и прочие средства автоматизации/ускорения - это, в лучшем случае, второй этап работы. Вначале следует понять, а нужно ли оно в принципе. Пока я склоняюсь к мысли оставить bat-файлы. На данный момент я понял, что система сборки еще не самый важный вопрос. Сначала нужно понять, как вообще привести проект к виду, удобному для использования и сопровоождения. Но это тема для других обсуждений.

Тоже обратил на него внимание. :) Основной вопрос, который мне не дает покоя - стоит ли овчинка выделки? Была куча bat-файлов, станет куча make-файлов. Есть ли в этом смысл?