AndruLud

Все выглядит достаточно логично, однако представляется маловероятным, что передача память-память запускается только вручную. Да и проведенные сегодня эксперименты показали, что память-память и память-переферия запускаются от таймера и работают совершенно идентично. Никаких манипуляций с DMACSoftBReq/DMACSoftSReq не проводил, менял TransferType. Если сконфигурировать переферия-память, не работает выдача в FIFO UART, в GPIO выдает нормально. На днях реализую предложенный Вами алгоритм, идея которого весьма хороша, благодарю.

Согласен с Вами, что запросы DMA и пересылки - разные вещи, но их несвязанность на логическом уровне для меня не очевидна. Смущает следующая фраза из мануала (с.605), описывающая назначение бита, определяющего вроде как переферийный источник запроса: "Source peripheral. This value selects the DMA source request peripheral. This field is ignored if the source of the transfer is from memory...." Если бы не последнее предложение, то все прозрачно. Почему, согласно последнему предложению, контроллеру DMA становится все равно, откуда приходит запрос, если передача по DMA будет вестись из памяти?

Я так понял, что "переферия"для DMA - это все, что может гененрировать запросы, остальное - "память", поправьте, если не так. Таким образом, когда я выставляю GPIO пакетом DMA - значит, пишу в память, когда отправляю данные в UART - пишу в переферию. Когда правлю управляющие регистры таймера - в память.

Спасибо за ответ! У меня таймер генерит запрос к дма, который вываливает данные из RAM в UART FIFO, из FIFO они уже передаются UARTом своим чередом. Описанную Вами идею я в свое время пробовал реализовать в несколько упрощенном варианте (событие MR0 запускает пакет дма, переписывающий в GPIO единицу 100 раз (процесс занимает ~1мкс) далее запускается пакет, преписывающий данные в UART; по событию MR1 (конец пакета) запускается другой dma, сбрасывающий GPIO ), но не удачно. Либо молчит UART, либо не выставляется GPIO. Склонен полагать, проблема в том, что в LLI нельзя видоизменить конфигурационный регистр (DMAnConfig), в котором задается направление передачи. А мне надо сначала выдавать "память-память", потом "память-переферия".

Может, у кого есть идеи как сгенерировать сигнал на ноге , устанавливающийся в 1 за 1мкс до начала передачи по UART и в 0 при ее окончании? Длина пакета, скорость передачи известны, передача инициируется таймером, генерирующим dma-запрос. Прерывания и дополнительные таймеры не хотелось бы использовать, UART интерфейс rs-485 не поддерживает.

Привет всем! Ситуация следующая: 2 канала DMA lpc1768 сконфигурированы для предачи данных "память-память" и "память-перефирия" соответственно. Запрос на передачу генерит один и тот же таймер. Какой из каналов DMA начнет передачу первым? В мануале описана лишь ситуация, когда по одному каналу передача уже идет, а запрос поступает к другому каналу. Там же есть рекомендации использовать для передачи "память-память" каналы с более низким приоритетом, иначе другие каналы не запустятся. С уважением.

Не-а. Здесь все параллельно и перпендикулярно, без подтанцовок с бубном.

Всем доброго здоровья! Есть контроллер LPC1768, использую его модуль PWM. Проблема в том, что PWM может быть источником нескольких прерываний одновременно, причем какой именно источник сгенерировал прерывание можно узнать только войдя в некоторый абстрактный "обработчик прерываний от PWM" и проанализировав соответствующий бит в нем. Если два источника в PWM сгенерировали прерывания одновременно, появляются непредсказуемые задержки в их обработке. Хотелось бы узнавать о наличии одного из прерываний по опросу, но не получается: запретишь соответствующий источник - флаг не выставляется, запретишь прерывание от PWM - естественно, умирают оба прерывания. МОжет, кто знает обходной маневр?

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

Я бы даже сказал, что сброс DMA после передачи каждого пакета вредит. Если убрать сброс, то при первом включении посылки идут нормально. Потом, если мастер отрубается, все включается вновь, но криво. Чтобы побороться с кривизной поставил сторожевой таймер, с частотой чуть меньшей, чем частота посылок. В прерывании по приему посылки от DMA таймер сбрасывается, если приема нет, срабатывает прерывание от таймра, в котором сбрасывается DMA. Результат достаточно скромный в 7 из 10 случаев отрубания мастера и срабатывания таймера имеется сдвиг на байт.

Теперь возникла задача передавать данные по SPI из s3c2440 в lpc1768 , причем последний по-прежнему работает мастером. Проблема опять та же: ведомый s3c2440 посредством DMA передает сначала конец предыдущей посылки, потом все остальное, кроме конца, т.е имеем сдвиг данных. Лекарство, использованное ранее для приема ведомым, - включать/выключать DMA после получения каждого пакета - не работает. Может, кто сталкивался?

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

Проблема по всей видимости аппаратная. Переключил все действо на другой SPI порт, задержка исчезла. Однако, осталась другая: последний байт, принятый по SPI через DMA оказывается первым байтом следующей посылки. Т.е послал 80 01 C0 03 E0 07 F0 0F, а принял 0F 80 01 C0 03 E0 07 F0. Может, кто-нибудь сталкивался?

Приветствую участников форума! У меня 2 контроллера (LPC1768 и s3c2440) соединены по протоколу SPI. При этом LPC1768 в роли ведущего выдает через свой SSP контроллер, сконфигурированный как SPI, посылку в 8 байт с частотой 10 кГц. Прием посылки в s3c2440 организован через DMA, сконфигурированный для чтения 8 байт, после этого должно возникать прерывание. Проблема в том, что прерывания начинают появляться ~через 15 сек после включения обмена, далее все вовремя, но байты оказываются сдвинутыми на 1. Данные из ведущего появляются вовремя (смотрел по осциллографу).

Возьму на заметку,спасибо, но я с таймером разобрался. Сейчас в прерываниях UARTa ковыряюсь.