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

[Golikov A.]

Всем привет!

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

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

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

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

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

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

[Golikov A.]

У Вас неоптимально сконфигурён DMA для SSP. Там надо разрешить блоковую передачу. тогда будет ложить не по слову, а сразу будет половину SSP FIFO заполнять. при возможности.
См. DMACCxControl::SBSize и DBSize.

что есть оптимально? SPI работает на 8МГц клока, при тактовой проца 100, ограничение слейв режима . Времени на передачу очередного символа полно, тем более в DMA есть FIFO, что мне даст браст передача в этом случае? Только что из выходного фифо надо будет чистить ни 1 а 4 символа. И что я на вход смогу получать только сообщения кратные 4? Чет мне кажется это как раз не оптимально...

Кто-ж так построил систему? Почему так? А почему не постоянный или кратный некоторому целому размеру DMA?

адаптация езернет системы на SPI. Сохранение протокола, ничего поделать нельзя.

Кто Вам мешает его завести на любой пин 0го или 1го порта или EINT?

Тяжелая судьба программиста, как схемотехник завел и сделал, так и будет.

Не понял... Зачем?????? wacko.gif
Обычно CS опускается в начале всей транзакции и поднимается в конце.

А вот это прям отдельная!!!!!!! Потому что так работает slave SSP в этом проце. Он зараза по чипселекту байты из фифо в сдвиговый перекладывает и обратно. Потому если им не дергать на каждое слово, то получите только 1 слово из всего сообщения, это прям ваще все поломало!
я планировал этот Чипселект использовать как кадровая синхронизация, а вот хрен там! Опять же я не ожидал что в SSP нет прерывания на прием символа. Ровно как я что-то был не в курсе что 1 порт не является портом с прерыванием.

А вот оно так сложилось, и первая ревизия платы такая, не выбрасывать же ее теперь.
Потому у меня по проводку готовности данных происходит еще и кадровая синхронизация. И фронты я полингом отлавливаю... эх...

В общем стечение обстоятельств

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

[jcxz]

адаптация езернет системы на SPI. Сохранение протокола, ничего поделать нельзя.

И кто же мешает дополнять эти кадры padding-ом до некоторого нужного размера?
Надеюсь - хоть канальный уровень протокола обмена у вас какой-то прописан, который поможет определить фактическую длину кадра?

Тяжелая судьба программиста, как схемотехник завел и сделал, так и будет.

Авторитета у вас нет
У нас если я скажу, что нужно переделать схему - переделывают, переразводят.
И в удалённых проектах, в которых участвовал - тоже.

А вот это прям отдельная!!!!!!! Потому что так работает slave SSP в этом проце. Он зараза по чипселекту байты из фифо в сдвиговый перекладывает и обратно. Потому если им не дергать на каждое слово, то получите только 1 слово из всего сообщения, это прям ваще все поломало!

Не надо. Это Вы что-то не так делаете. Ищите ошибку у себя. SSP (даже слэйв) в LPC не требует дёрганья CS на каждое слово.
Разрешите хотя-бы burst-запросы. Возможно что у Вас SSP выставляет burst-запрос к DMA, а раз он запрещён в DMA и не отрабатывается, то
он остаётся висеть необслуженным и SSP новых запросов не ставит, ждёт пока первый обслужится.
Вобщем - что-то Вы не так делаете.
И не надо наговаривать на проц.
SSP там хороший и прямой. Просто куча проектов уже на нём с использованием связки SSP+DMA

в курсе что 1 порт не является портом с прерыванием.
А вот оно так сложилось, и первая ревизия платы такая, не выбрасывать же ее теперь.
Потому у меня по проводку готовности данных происходит еще и кадровая синхронизация. И фронты я полингом отлавливаю... эх...

Так перед тем как садиться схему делать и ПО писать, сперва следует мануал на МК изучить, чтобы такого не было

правильно не 1 микросекунда, а 100 тактов. И это время не на вспоминание следующего слова, а на выбор его из памяти для ДМА и на решение всех его конфликтов. А так как в ДМА есть еще фифо на 4 слова, то получается 400 тактов. в Таком раскладе браст просто даст борьбу ДМА раз в 400 тактов, а не барст раз в 100 тактов и все... так даже как то понадежнее выглядит.

А теперь ещё учтите, что в это самое время CPU выполняет программу и может читать код по этой-же самой шине. И что приоритет у CPU выше чем у DMA (к сожалению).
И что читать он может сразу пакет, и что flash имеет тактовую не 100МГц, а всего максимум 20.
У меня в реальности были проблемы с SSP+DMA даже с разрешёнными пакетными запросами на частоте 20МГц (при аппаратно-формируемом SSEL (SPI-мастер) возникали
просечки в сигнале SSEL). Из-за того что изредка не успевали данные из ОЗУ считываться. Поэтому я стараюсь не использовать на LPC17xx аппаратно-формируемый SSEL.
А у вас ещё более жёсткая ситуация.
К тому-же у Вас слэйв - это ещё хуже. Могут возникать underflow FIFO. Тут очень аккуратно надо продумывать работу CPU во время такой транзакции, чтобы он
не занимал полностью шину.

чудно... надо будет попробовать, хотя я чет не очень понимаю как приняв меньше барста будет осуществлена транзакция... на передачу понятно, он передает по 4, и в конце сколько осталось, а на приеме то наверняка будет ждать заполнения на 4, иначе как он 4 от 1 отличит...

Как я понимаю - SSP автоматом определяет какой запрос ставить - burst или simple в зависимости от заполненности FIFO. Если в FIFO менее 4 слов, то,
думаю, SSP будет ждать поступления 4 слов или, по истечению таймаута, выставит simple-запрос.

И по приёму 1го слова тоже есть прерывание в SSP. И здесь Вы неправы Оно называется прерыванием таймаута.