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

[Golikov A.]

Всем привет!

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

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

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

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

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

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

[Golikov A.]

Не хватает авторитета попросить схемотехника допаять доп. проводок на соседние ноги CPU???

Колхоз.... там же шлейф между 2 устройств, на разъемы, а потом сопли? Хорошо все равно не получиться а хоть как-то уже сделали. Правильнее и красивее 2 ревизию сделать. Были бы совсем вилы конечно бросили бы соплю, но пока обойдемся красивой платкой

А зачем это надо?
Я Вам советовал внешне сигнал пробросить дополнительно на другой порт, чтобы получить прерывание по срезу CS.
Это можно сделать и сверху, проводком допаять, чтобы не переразводить.

Просто было интересно можно или нет, и опять же решает проблему некрасивых соплей, но не вышло...

Дело не в этом. Само это Ваше дёрганье противоречит природе SPI-интерфейса. И в принципе не должно быть такого.

Я с вами согласен%) но к сожалению проц нет. В реф мануале приведены картинки, на которых между байтами чипселект возвращается в 1 и все тут... возможности оставить его в 0 мануал не дает, а проц не воспринимает. Такое поведение только в режим microwire а в этом режиме скорость ниже в 2 раза.
Кстати ответная часть на проце другой фирмы где SPI - master по умолчанию тоже молотит чипселектом каждое слово, я даже по первости с этим сражался, пока не узнал что LPC этого и ждет...

Вы прочитали мой совет по поводу burst-запросов?

Прочел, но дело не в этом. Я же вижу могу просто очередь фифо читать, если чип селект не дергать, данные не идут. Тут надо принять этот факт и все

"Дикий гемор" - это у Вас сейчас, в текущей реализации. Потому что не сделали правильно.

Научите правильно.
посылки вида
команда - 1 байт, данные - 0 до 512 байт
ответ такой же

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

обрабатываю ошибки:
таймаут на подготовку ответ
неготовность принять посылку (2 посылка без получения ответа)
ошибка контрольной суммы в обоих направлениях

На верху это вырождается в прошла посылка - не прошла, и своей логикой действий....

как теперь это сделать правильно?




--------
читаю про burst передачу.

The burst size is the amount of data that is transferred when the DMACBREQ signal goes
active in the source peripheral.

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

[jcxz]

Колхоз.... там же шлейф между 2 устройств, на разъемы, а потом сопли? Хорошо все равно не получиться а хоть как-то уже сделали. Правильнее и красивее 2 ревизию сделать. Были бы совсем вилы конечно бросили бы соплю, но пока обойдемся красивой платкой

Что-то мы на разных языках похоже говорим...
Мы же вроде о том, как получить прерывание по спаду сигнала CS приходящего на Ваш МК? Этот сигнал у Вас вроде заведён на вход SSEL?
И я Вам посоветовал дополнительно завести его ещё на одну из ног GPIO 0го или 2го порта. Для этого достаточно бросить проводок с одной ноги МК
на другую этого-же самого МК. Это короткий проводок, может даже - сопля на соседнюю ногу. какие тут разъёмы???

Я с вами согласен%) но к сожалению проц нет. В реф мануале приведены картинки, на которых между байтами чипселект возвращается в 1 и все тут... возможности оставить его в 0 мануал не дает, а проц не воспринимает. Такое поведение только в режим microwire а в этом режиме скорость ниже в 2 раза.

А Вы внимательнее мануал прочитайте Посмотрите там есть вариант CPHA = 1. В этом случае как раз и не надо дёргать SSEL на каждое слово.

Научите правильно.
посылки вида
команда - 1 байт, данные - 0 до 512 байт
ответ такой же

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

обрабатываю ошибки:
таймаут на подготовку ответ
неготовность принять посылку (2 посылка без получения ответа)
ошибка контрольной суммы в обоих направлениях

На верху это вырождается в прошла посылка - не прошла, и своей логикой действий....

как теперь это сделать правильно?

Я понял Вы говорите от имени МК с SPI-слэйвом, принимающего пакеты от другого МК (верха)?
Всем обменом заведует верх.
Обмен в режиме - "запрос-ответ"?

Если да, то например такой протокол:
Мастер (верх) посылает пакеты слэйву. Размер пакетов кратен 16 байт (или другое число, настраиваете DMA на такой размер, будет N блоков DMA).
При необходимости пакет дополняется в хвосте словами заполнения до кратного размера.
В заголовке пакета мастер указывает код команды и его реальную длину без учёта заполнения (при необходимости, если длину нельзя определить на основе кода команды).
Слэйв по спаду CS начинает приём пакета и контролирует его целостность по заголовку, CRC и по факту фронта CS на границе 16-байтного элемента (от неожиданных сбросов верха).
В обратном канале (MISO) слэйв всегда в заголовке пакета передаёт своё слово состояния.
Там кроме прочего будет бит готовности.
При получении пакета с командой от верха, ISR слэйва сбрасывает бит готовности и программирует DMA для след. транзакции.
В то же время он отправляет полученную команду от верха на обработку прикладному процессу.
Если, пока прикладной процесс обрабатывает данный пакет, придёт след. запрос от верха, то в обратном канале верх получит "неготов" - будет знать, что данный запрос не был выполнен.
Верх может так многократно опрашивать слэйв, посылая ему пакеты.
Как тока прикладной процесс закончит обработку запроса, он в выходной буфер помещает результат и после этого устанавливает флаг готовности.
Если ответ может быть произвольной длины и длина заранее не известна верху, то она должна быть включена в слово состояние слэйва, возвращаемое в обратном канале.

Вот как-то примерно так. Будет вполне себе кадр-ориентированный обмен хорошо ложащийся на SSP+DMA.
Только не надо забывать про опасность, что SSP в режиме слэйв на такой скорости SSP может не успеть прокачать данные из-за занятости шины CPU!
Очень аккуратно надо со слэйв-режимом LPC. Это его существенная недоработка (LPC), что нельзя выставить приоритет доступа к шине для GPDMA выше чем для ядра. (((

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

Нет, Вы не правы. Я же написал уже, что всегда использую burst, независимо от кратности пересылок 4байтам. Нет никаких левых байтов.
Мне кажется там всё прозрачно в описании.
Посмотрите на регистр SSPnMIS. А теперь представьте, что когда Вы работаете через DMA, то сигналы прерывания идут уже не на CPU как IRQ, а на GPDMA как DMA-запросы
(имхо - на аппаратном уровне так и сделано). Так вот - сигнал RXMIS - это burst-запрос для RX-DMA, а сигнал RTMIS - это single-запрос для RX-DMA.
Когда в RX-FIFO приходит 1ый байт (запускается счётчик таймаута), затем 2ой (без паузы) - ничего не происходит, и только когда приходит 4-ый, SSP выставляет burst-запрос к DMA,
DMA выполняет пакетную транзакцию на размер указанный в конфиге (4 байта) если может. Если-же приходит менее 4-х байт и потом - пауза, то по прошествии
времени таймаута выставляются single-запросы к DMA, которые обслуживаются одиночными операциями DMA.
В общем - работа DMA-запросов от SSP должна быть подобна работе соотв. IRQ-сигналов (см. описание на них).