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 ноги с разных портов настроить, прокинется сигнал с одной на другую? ведь они должны соединиться внутри... может так и прерывание можно с порта на порт перенести