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, разве что по таймаут - что немного сокращает скорость обмена.