LPC1768+DMA+SSP, Как правильно сбросить переполненный канал Опции

[Golikov A.]

Всем привет!

Есть такая проблемка на LPC1768 настроен SSP в режиме slave
входные данные при помощи DMA перегружаться в буфер 1024 байта.

если на вход напихать данных так штук 2000, то буфер переполняется, для сброса этого дела
я
1. выключаю DMA каналы,
2. дожидаюсь что пропал битик включения канала
3. вычитываю буфер FIFO SSP
4. переинициализирую DMA канал

и мне приходит последний байт, хоть убейся об него...

Такая же переинициализация в середине обмена - все хорошо, а по переполнению вот такая фигня.

Кто сталкивался, как победить?

Как почистить кроме входного еще и выходной SPP FIFO?

[Golikov A.]

ну теперь разбивкой на пакеты будет сигнал CS, который о благо в CHPA=1 режиме можно опускать на весь пакет. До этого я делал это через дополнительный проводок, синхронизовал кадр, а разбивка по длине, как и в ТСР который по сути тоже байтовый поток. Единственное что пакеты не постоянной длинны, потому что они такие приходят сверху и добивать короткие до полного - тяжко для обмена, а резать длинные на коротки - тяжко для меня)

Проблема в том что не известно сколько слейв будет готовить ответ на запрос, то есть нельзя утверждать что сразу будет готов ответ. Для этого тот же проводок что синхронизовал кадр использовался в другую сторону для индикации готовности данных. И только тогда мастер по SPI вычитывал ответ. С более короткими пакетами все тоже самое. То есть либо надо чтобы слейв гарантированно мгновенно отвечал - а это невозможно у него есть приоритетная задача, либо отвечал через гарантированный таймаут - что задержет обмен когда слейв не занят.

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

Максимальная скорость, без накладных и задержек, и достаточно просто, как мне показалось...

И к тому же думаю, что транзакции обмена по шине идут в пакетном режиме (типа как с SDRAM-памятью): вначале - адрес, упр. инфа, потом - неск. слов данных.
И к тому-же DMA должен сперва считать эти данные в своё FIFO по шине, а потом ещё записать (опять по шине) в ОЗУ.

А я думаю что DMA пишет все фифо за раз, не зависимо от того как оно его набивало по 4 символа или по 1. Потому burst или нет тут роли не играет. Важнее как часто ДМА пытается занять шину для сброса данных в память. В burst эти акции в 4 раза реже, вроде как, может это лучше при конкуренции с другими ДМА и процом....

Ну надеюсь 2 канала, работающие по очереди не нагнут невозможно проц

[jcxz]

потому такое решение...
Максимальная скорость, без накладных и задержек, и достаточно просто, как мне показалось...

Ну: хозяин - барин

А я думаю что DMA пишет все фифо за раз, не зависимо от того как оно его набивало по 4 символа или по 1. Потому burst или нет тут роли не играет. Важнее как часто ДМА пытается занять шину для сброса данных в память. В burst эти акции в 4 раза реже, вроде как, может это лучше при конкуренции с другими ДМА и процом....

Про какое FIFO Вы говорите? FIFO своё - да, думаю как только он обнаружит окно на шине, то сколько у него есть столько и передаст в ОЗУ.
А вот FIFO периферии он читает в зависимости от пришедшего сигнала (burst или single) и если burst - от заданного размера пакета в DMACCxControl.
Ведь он не знает сколько там данных. Если пришёл burst-запрос, он смотрит какой размер пакета задан у него в DMACCxControl и такую транзакцию чтения на шину и запускает.

Ну надеюсь 2 канала, работающие по очереди не нагнут невозможно проц

По общей средней пропускной способности - нет. Но могут быть кратковременные затыки.
Я когда разбирался с проблемами при работе SSP+DMA с SPI-FLASH и SPI-FRAM на частотах 20-30МГц с аппаратным SSEL (LPC1758 и LPC1778), обнаружил что общая пропускная способность обеспечивается
полностью на данных частотах, но изредка (раз в неск. секунд) на сигнале SSEL возникают короткие просечки порядка 1мкс и меньше. Поймал на осцилле.
Похоже, что иногда DMA не успевал подкачивать (или откачивать данные). Снижение частоты до 10МГц не решило проблемы, только стало реже проявляться.
Думаю, это из-за того, что CPU чаще работает из очереди предвыборки, заранее загруженной, но иногда читает из памяти (при ветвлениях в программе), и иногда могут быть
периоды времени, когда он длительное время читает только из памяти (вермишельный код из переходов).
После этого на LPC17xx я не использую больше аппаратный SSEL.

Но это помогает так как SSP работает в мастер-режиме. И при FIFO underflow просто приостанавливает клок. У Вас-же в слэйв это не поможет - клок слэйву не остановить,
Так что нужно быть очень аккуратным на таких частотах SSP. И вообще в слэйве.

У меня есть проект на LPC1758 где 7 каналов DMA могут быть заняты одновременно и 4 из них - для SSP (2 для ADS1298 и 2 для SD-карты).
И ничего - работает. Но там все SPI-слэйв с программным SSEL.