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

[Golikov A.]

Всем привет!

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

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

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

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

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

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

[jcxz]

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

Что-то у Вас неправильно с процессом останова SSP+DMA.
Как Вы DMA выключаете? Просто запрещаете его работу?
Учитываете, что в DMA тоже есть FIFO? И если просто сделать запрет каналу, то данные там могут остаться.
Да и останов у Вас наверное неверный раз в выходном FIFO SSP данные могут остаться. Не должно так быть.

Останов по переполнению это значит, что:
Вы запрограммировали DMA (два канала: TX и RX) на передачу/приём с SSP некоторого фиксированного блока (размер TX == размеру RX (или кратны)).
И останов нужно делать только в прерывании завершения этого блока (или если блоки кратны - по завершении наибольшего (когда оба блока завершены)).
А если Вы делаете стоп посередине (зачем-то), то сами себе злобный буратино. Тогда должны позаботиться об опустошении всех FIFO перед след. операцией.

Раз у Вас SSP-slave, то ещё наверное нужно после останова DMA, ожидания завершения активности SSP и запрета SSP, вычитать RX-FIFO SSP. Он вроде не сбрасывается при запрете SSP.
А в TX-SSP у Вас и не должно остаться данных, если как я описал будете работать.

[Golikov A.]

Не будет...
Да сейчас я себе злобный буратино, но жизнь то она многообразная...
Интересно я один делаю тесты на устойчивость?

SSP-Slave, значит выдает данные только по клоку мастера. Вы начали ответный обмен, показали что у вас есть данные, положили их в буфер, настроили ДМА, тот их радостно набил в FIFO свое и SSP, все готовы, на низком старте. А тут мастер взял и сдох, или перегрузился, или передумал... дальше что?

Я фифо DMA смогу почистить, выключил канал, включил и оно якобы чистое (правда почему то в приемном 1 байт застревает, в ответном не знаю, не проверял). А вот фифо SSP никак выходное не почистишь...

Добавил требование после сброса обмена клочить на то чтобы выдавилось FIFO SSP

В обратную сторону, данные переменной длины, но никто не застрахован от того что во время инициализации или просто по дури мастер не напихает левых данных на вход. У меня входной буфер 1Кбайт, это больше нормальной посылки, DMA в штатном режиме никогда до конца его не набивает, и прерывания никакого нет на окончание посылки. Работа идет с принятой частью.

Но вот теперь у нас появился злобный мастер буратина, который взял и выдал свой клок на ногу клока SSP, что дальше? У нас весь буфер забит под завязку, данные не обработаются, не сойдется контрольная сумма и прочая байда, чтобы не было проблем DMA настроено на выключение после приема 1024 байт, и в целом оно это делает.
Но по какой-то неведомой причине после того как я его заново включаю оно мне досылает последний байт, хоть убейся об него...

То есть я так понимаю почему то не снимается бит запроса канала DMA от SSP, и как только тот включается, он сразу получает запрос и выполняет его, а в приемнике SSP лежит последний принятый байт. И вот это я не смог побороть.







------------------------------------------------------------------------------------------
Провел серию проверок, по ходу дела DMA на выход не набивает FIFO SSP целиком, а кладет по одному байтику по мере опустошения, по сигналы FIFO - пусто. Но 1 байт при обрыве обмена все же останется, это надо учитывать.

Вопрос как очистить выставленный запрос на канале DMA остается...

---------------------------------------------------------------------------------------------------------------------
Ну вот, если правильно локализовать проблему становиться понятно как с ней бороться.

Зависали не FIFO и не буферы, зависал сигнал запроса от SSP.

Правильный порядок сброса каналов
1. Отключаем каналы DMA
2. Ждем их выключения
3. Отключаем DMA на SSP
4. сбрасываем входное FIFO SSP (читаем 8 раз)
5. сбрасываем выходное FIFO SSP (тут надо мастеру вычитать 1 возможно оставшийся байт или перейти в мастер режим и выдавить его)
6. перенастраиваем каналы DMA
7. дожидаемся включения
8. включаем DMA в SSP

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

Но в любом случае, такой перезапуск приводит систему в начальное состояние (с точностью до байта в выходном FIFO) и ура!

[jcxz]

SSP-Slave, значит выдает данные только по клоку мастера. Вы начали ответный обмен, показали что у вас есть данные, положили их в буфер, настроили ДМА, тот их радостно набил в FIFO свое и SSP, все готовы, на низком старте. А тут мастер взял и сдох, или перегрузился, или передумал... дальше что?
Я фифо DMA смогу почистить, выключил канал, включил и оно якобы чистое (правда почему то в приемном 1 байт застревает, в ответном не знаю, не проверял). А вот фифо SSP никак выходное не почистишь...

Вы уверены?
Вообще-то у канала нет бита выключения, а только бит разрешения. И я сильно сомневаюсь, что при его запрещении, FIFO канала очистится. Вроде в UM это явно не указано.
Оно даже может не очищаться при подаче аппаратного RESET на процессор.

Добавил требование после сброса обмена клочить на то чтобы выдавилось FIFO SSP

Вы сначала выясните где именно у вас байты остаются в каком FIFO - SSP или DMA. Может оба нужно выфлушивать.
Странно у вас как-то система построена - часть может вдруг сброситься (мастер), а остальная - нет. Может это надо как-то исправить? Сброс общий для обоих сделать.

В обратную сторону, данные переменной длины, но никто не застрахован от того что во время инициализации или просто по дури мастер не напихает левых данных на вход. У меня входной буфер 1Кбайт, это больше нормальной посылки, DMA в штатном режиме никогда до конца его не набивает, и прерывания никакого нет на окончание посылки. Работа идет с принятой частью.

Не понимаю - в чём тут проблема?
Программируете DMA на какой-то блок данных. Даже пускай не зная сколько передаст мастер. Когда этот блок закончится - придёт прерывание, в нём запрограммируете на след. блок, пока он заполняется - разгребаете предыдущий.
Если у Вас перегрузился мастер, то заводИте ещё реакцию на прерывание от снятия сигнала CS и в этом ISR чистите (выфлушиваете) FIFO. SSP на это время надо наверное перевести в режим мастер
(с отключенными пинами). А для мастера требование - задержка от момента старта ПО до ближайшей транзакции по SSP достаточная для очистки.

[Golikov A.]

Вы уверены?
Вообще-то у канала нет бита выключения, а только бит разрешения. И я сильно сомневаюсь, что при его запрещении, FIFO канала очистится. Вроде в UM это явно не указано.
Оно даже может не очищаться при подаче аппаратного RESET на процессор.

уверен из юзер мануала

бит называется E - channel enable, не знаю как это понятие перевести иначе как включение канала

также не знаю как перевести иначе следующее высказывание из описания

A channel can be disabled by clearing the Enable bit. This causes the current AHB
transfer (if one is in progress) to complete and the channel is then disabled. Any data
in the FIFO of the relevant channel is lost

канал выключается - данные в фифо теряются.

Вы сначала выясните где именно у вас байты остаются в каком FIFO - SSP или DMA. Может оба нужно выфлушивать.

как почистить фифо ДМА мы уже разобрались строкой выше. Теперь надо понять как работает ваще ДМА.
При запуске оно набивает 4 слова в свое фифо, и одно слово кладет в FIFO SSP. SSP - отдаст его только по чипселекту и клоку, а на его место сразу ляжет новое слово из ДМА. Если при запущенном обмене его прервать, больше клоков не будет, тогда одно слово останется в FIFO SSP, очистить его иначе как считать мастером невозможно. Кстати при не ДМА обмене там может быть до 8 слов.

Странно у вас как-то система построена часть может вдруг сброситься (мастер), а остальная - нет. Может это надо как-то исправить? Сброс общий для обоих сделать.

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

Не понимаю - в чём тут проблема?
Программируете DMA на какой-то блок данных. Даже пускай не зная сколько передаст мастер. Когда этот блок закончится - придёт прерывание, в нём запрограммируете на след. блок, пока он заполняется - разгребаете предыдущий.

Какой размер блока? Сообщения переменной длинны, реагировать на них надо как только так сразу. Настроить на минимальную длину и постоянно ворошить блоки, зачем?Сейчас для ДМА выделен буфер 1КБайт, оно туда кладет данные спокойно, а проц этот буфер время от времени проверяет, и если там есть целое сообщение обрабатывает.

Если у Вас перегрузился мастер, то заводИте ещё реакцию на прерывание от снятия сигнала CS

А вот тут вас ждут 2 разочарования.
1 - нет такого прерывания, а в добавок этот чипселект может быть на 1 порту, там нет даже GPIO прерывания (они только на 0 и 2 портах)
2 - работа SSP требует опускания и поднимания чипселекта на каждое слово обмена

А для мастера требование - задержка от момента старта ПО до ближайшей транзакции по SSP достаточная для очистки.

при условии что он не знает ни момент начала очистки ни момент своего старта, требование невыполнимо

[jcxz]

бит называется E - channel enable, не знаю как это понятие перевести иначе как включение канала

Вот именно что "enable". У меня был опыт с TI C5502, в котором при подаче RESET на CPU, проц сбрасывался, а данные в FIFO DMA оставались.

также не знаю как перевести иначе следующее высказывание из описания
канал выключается - данные в фифо теряются.

Ну хорошо если так.

как почистить фифо ДМА мы уже разобрались строкой выше. Теперь надо понять как работает ваще ДМА.
При запуске оно набивает 4 слова в свое фифо, и одно слово кладет в FIFO SSP. SSP - отдаст его только по чипселекту и клоку, а на его место сразу ляжет новое слово из ДМА.

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

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

Кто-ж так построил систему? Почему так? А почему не постоянный или кратный некоторому целому размеру DMA?
Ну даже так - по прерыванию снятия CS тогда надо выполнять процедуру очистки FIFO и определения принятого размера.
Но лучше всё-таки сделать корректно - дополнять все транзакции до некоторого размера, кратного размеру блока DMA.

1 - нет такого прерывания, а в добавок этот чипселект может быть на 1 порту, там нет даже GPIO прерывания (они только на 0 и 2 портах)

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

2 - работа SSP требует опускания и поднимания чипселекта на каждое слово обмена

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

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

При 8МГц и длине слова == 1байт, у вас всего 1мкс чтобы успеть заполнить след. слово. Это довольно мало.
Лучше это время увеличить, для того и существует FIFO.
Использование burst-запросов никак не влияет на гранулярность транзакций.
Я всегда разрешаю burst независимо от кратности всей DMA-транзакции - всё прекрасно работает.

[Golikov A.]

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

Я всегда разрешаю burst независимо от кратности всей DMA-транзакции - всё прекрасно работает.

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

[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. И здесь Вы неправы Оно называется прерыванием таймаута.

[Golikov A.]

Пробросить один сигнал периферии на 2 ноги не выходит, видать там мультиплексор...

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

природная лень, помноженная на здравый смысл.
Разбитие входного сообщения и отправка его по частям сулит дикий гемор с детекцией и индикацией ошибок. А выравнивать все сообщения до максимально большого - просадка по скорости обмена. Если у вас есть хорошие идея я открыт. Мне предстоит еще езернет перепихать в CAN.
езернет - есесно ТСР, то есть получение по нему проблем не вызывает, приходит целая понятная посылка.

Не надо. Это Вы что-то не так делаете. Ищите ошибку у себя. SSP (даже слэйв) в LPC не требует дёрганья CS на каждое слово.

не путаете модель LPC? Я сутки своему пытался объяснить что ему не надо дергать CS на каждый байт, а ему хоть бы хны, пока cs не дернешь второго байта не отдает... В мануале написано дергать каждый раз
Есть 3 режима SSP: SPI - требует дергать на каждый байт (мы говорим про слейв). Microwire - позволяет дергать на фрейм, но обмен идет через один по протоколу микроваер, то есть принимается каждый второй байт от мастера, а между ними считаются выходными байтами, и еще формат от тексаса, там обмен по 1 линии данных...
у филипса менялась реализация SSP, в каких то процах работает только так, в каких то можно на фрейм херачить.

Если у вас именно LPC1768 и есть SSP-slave который работает с кадровой синхронизацией я бы очень хотел это увидеть, потому что это решит некоторые мои проблемы

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

Просто мой авторитет ниже руководства, которое эту плату через 1.5 недели отправит на другой конец света. И новый вариант я туда повезу сам если ее не успеют переделать за 1.5 недели, а ее не успеют Во второй ревизии поправим, а пока надо решать что есть...

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

Да как бы 8 проект на этом проце, и все были с SSP, после такого некоторые свои виденья начинают казаться частями мануала. SSP-slave не было, потому вот так вышло.

[jcxz]

Пробросить один сигнал периферии на 2 ноги не выходит, видать там мультиплексор...

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

Разбитие входного сообщения и отправка его по частям сулит дикий гемор с детекцией и индикацией ошибок.

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

не путаете модель LPC? Я сутки своему пытался объяснить что ему не надо дергать CS на каждый байт,

У меня был LPC1758. Но думаю - это не играет роли. SSP у NXP почти не меняется со времён ARM7 ещё. И во всех CPU одинаковый.
У меня было не совсем в тему для Вас: не SSP, а SPI был. Связка: SPI+DMA+таймер. Никаким CS не дёргал.

Дело не в этом. Само это Ваше дёрганье противоречит природе SPI-интерфейса. И в принципе не должно быть такого.
Всё микросхемы работающие как SPI-слэйв все предполагают работу с опущенным CS, а по снятию CS делают сброс логики SPI (со сбросом счётчика клоков).
У Вас где-то ошибка.
Вы прочитали мой совет по поводу burst-запросов?
Ещё помнится в том проекте со слэйв SPI, CS у нас не использовался, но мы на него заводили лог. 0.
Иначе он не работал, даже если был выбран мультиплексором для GPIO, а не SPI.

Просто мой авторитет ниже руководства, которое эту плату через 1.5 недели отправит на другой конец света. И новый вариант я туда повезу сам если ее не успеют переделать за 1.5 недели, а ее не успеют Во второй ревизии поправим, а пока надо решать что есть...

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

[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-сигналов (см. описание на них).

[Golikov A.]

Это короткий проводок, может даже - сопля на соседнюю ногу. какие тут разъёмы??

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

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

Вот это ценно, да действительно в CPHA = 1 можно чипселект держать в 0, там есть про это приписка, спасибо. Значит я правильно помнил что видел на осциллографе обмен без дергающегося чипселекта и какую-то запись про это, думал может другой проц, ан нет этот славно!!!! спасибо спасибо спасибо... блин на денек бы раньше, уже все переписал...

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

Вверх присылает данные по TCP первому контроллеру, а тот их дальше гонит по SPI как мастер уже на LPC1768. С верху приходят пакеты от 1 до 513 байт длинной, такими я их и шлю дальше обвешав контрольной суммой и длинной. Разбивка на пакеты потребует ответов о статусе каждого пакета - усложнение трафика. То есть пока не вижу большого бонуса в этом. Разьве только прерывание по окончанию пакета вместо поллинга длинны. А мусорные байты в канале так и остаются мусорными и так же гадят обмен и переполняют буфер...

Если-же приходит менее 4-х байт и потом - пауза, то по прошествии
времени таймаута выставляются single-запросы к DMA, которые обслуживаются одиночными операциями DMA.

ага таймаут понятно... кстати в таком раскладе 1 чтение всегда забивает полностью фифо DMA и ему надо как бы разом избавиться от всего груза, а пока шли 1 2 и 3 байты оно уже могло пытаться... Не уверен, но может это понадежнее...

В чем преимущество burst? Я понимаю если идут 32 битные данные которые надо разом записывать в память, тут я понимаю смысл burst, а если данные 1 байтные в чем бизнес?

[jcxz]

Вверх присылает данные по TCP первому контроллеру, а тот их дальше гонит по SPI как мастер уже на LPC1768. С верху приходят пакеты от 1 до 513 байт длинной, такими я их и шлю дальше обвешав контрольной суммой и длинной. Разбивка на пакеты потребует ответов о статусе каждого пакета - усложнение трафика. То есть пока не вижу большого бонуса в этом. Разьве только прерывание по окончанию пакета вместо поллинга длинны. А мусорные байты в канале так и остаются мусорными и так же гадят обмен и переполняют буфер...

Если мастеру не нужен ответ на предыдущую посылку, то зачем ждать? Мастер шлёт следующую, а в обратном канале ему возвращается состояние о полученной ранее посылке
(нормально получена или с ошибкой) и на основании этого он решает - повторить с какой-то позиции или гнать дальше. В слове состояния можно хранить например какой-то номер последовательности
для принимаемого потока байт и увеличивать каждый раз на сумму принятых байт при удачном приёме (аналогично номерам последовательности TCP-сокета).

Если как Вы пишете - Вы обвешиваете контрольной суммой и длиной данные, то получается у Вас уже должна быть разбивка на пакеты.
А как Вы её делаете если у Вас пакет не обрамлен CS? В моём способе CS как раз служит для определения границ пакета (стандартно для большинства SPI-микросхем памяти и пр.).
В Вашем случае Вам нужно предпринимать ещё какие-то действия для определения границ пакета (делать канальное кодирование).
У вас передача получается подобно UART, т.е. - байтовый поток. А в таком случае из потока байт нужно выделять пакеты.
А раз Вы вводите контрольную сумму, значит - возможны помехи, значит метод выделения границ пакетов должен быть устойчив к этим помехам.
Тут получается излишнее усложнение на ровном месте.

В чем преимущество burst? Я понимаю если идут 32 битные данные которые надо разом записывать в память, тут я понимаю смысл burst, а если данные 1 байтные в чем бизнес?

Вы забываете, что шина через которую DMA обменивается с памятью - сильно загруженный ресурс. Её же может в это время интенсивно использовать CPU, исполняя код.
Если-б она была всё время свободна, то не было бы разницы как писать - побайтно или пакетом.
Но она свободна очень редко. Вот в эти то дырки и должен влезть DMA. FIFO в 4 слова в DMA, в 4 раза снижает требования по доступности шины.
И к тому же думаю, что транзакции обмена по шине идут в пакетном режиме (типа как с SDRAM-памятью): вначале - адрес, упр. инфа, потом - неск. слов данных.
И к тому-же DMA должен сперва считать эти данные в своё 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.

[Golikov A.]

Переписал, да чудо - чудесное. Наконец то заработало как надо, с фазой = 1 можно чип селект держать в 0 всю посылку, по нему засинхронизовал, моя довольна...
Теперь нет 2 стороннего проводка с медленным переключением, все полетело.

Попутно пересмотрел обмен и не включаю больше 1 канала ДМА, чтоб уж наверняка.

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


Про ДМА вот я теперь в раздумьях... то есть между ДМА и периферией не проложены отдельные каналы, и ДМА 2 раза занимает одну и ту же шину
сначала на забор в буфер свой, а потом на выгрузку?

[jcxz]

Про ДМА вот я теперь в раздумьях... то есть между ДМА и периферией не проложены отдельные каналы, и ДМА 2 раза занимает одну и ту же шину
сначала на забор в буфер свой, а потом на выгрузку?

См. UM страница 12 (1.10 Block diagram).
А что-ж Вы думаете - к каждой периферии проложена не одна, а пачка шин по количеству bus-master-ов в МК???
Да ещё на входе каждой периферии тогда нужен будет мультиплексор шин с арбитражом доступа.
Я только в DSP (C5502) помню двухпортовую внутреннюю ОЗУ, а 2-портовой периферии не видел нигде

[Golikov A.]

однако ДМА поддерживается весьма небольшим числом блоков, потому думал может к ним проложили канал ДМА отдельно. Но не важно, даже если не так, то все блоки с ДМА за мостами AHB-APB. То есть чисто теоретически если проц не долбиться в периферию на этих шинах, ДМА может спокойно занять их и никому не помешать.
Я не прав?

Хотя ДМА контроллер с другой стороны и ответ будет в том как работает Multilayer AHB Matrix, если там все шины в кучу, то да пипец, конкуренция, а если есть слои, и шины коммутируемы, то все совсем по другому...

[jcxz]

однако ДМА поддерживается весьма небольшим числом блоков, потому думал может к ним проложили канал ДМА отдельно.

Как это - небольшим? Вы неправы. Любая точка адресного пространства, доступная CPU, доступна и DMA.

Но не важно, даже если не так, то все блоки с ДМА за мостами AHB-APB. То есть чисто теоретически если проц не долбиться в периферию на этих шинах, ДМА может спокойно занять их и никому не помешать.

А Вы посмотрите на сегменты шин к RAM. Если CPU непрерывно обращается к этой памяти, то DMA всегда будет получать отлуп.
Такая ситуация думаю может быть если CPU крутится в коротком цикле исполняя код из данного сегмента ОЗУ. Тогда он постоянно делает предвыборки из-за условных переходов.
но вобщем - всё это гадания на кофейной гуще....

[Golikov A.]

Доступ к периферии у ДМА ограничен, не знаю можно ли достучаться в нее как обмен память-память, но как обмен периферия - что и обратно, число блоков невелико,
на той же схеме желтеньким отмечено


по картинке один блок рам висит на одной шине, а другой на другой. Думаю это как раз сделано чтобы можно было процу долбиться по одному каналу, а ДМА по другому, но в целом вы правы, картинки не дают представления о том как там оно сделано на самом деле...

[jcxz]

Доступ к периферии у ДМА ограничен, не знаю можно ли достучаться в нее как обмен память-память, но как обмен периферия - что и обратно, число блоков невелико,
на той же схеме желтеньким отмечено

Нет. Жёлтым отмечена периферия, которая может генерить сигналы DMA-запросов. Только и того.
А работать (осуществлять обмен) GPDMA может с любой периферией.
Я работал и с SPI и с GPIO через GPDMA.

по картинке один блок рам висит на одной шине, а другой на другой. Думаю это как раз сделано чтобы можно было процу долбиться по одному каналу, а ДМА по другому

Да, думаю - для того и задумывалось. Ну не считая того, что 32К блок отколючается в sleep (или наоброт - не отключается в sleep, запамятовал

[Golikov A.]

написано что периферийный блоки поддерживающие GP_DMA
GPIO и SSP входит. SPI - нет. В таблице запросов тоже нет. Нет запроса нет передачи.

Конечно можно через адресное пространство, адрес - адрес и по какому, нибудь таймеру, но это уже извращения)


Ну в целом понятно.

[jcxz]

написано что периферийный блоки поддерживающие GP_DMA
GPIO и SSP входит. SPI - нет. В таблице запросов тоже нет. Нет запроса нет передачи.
Конечно можно через адресное пространство, адрес - адрес и по какому, нибудь таймеру, но это уже извращения)

Тем не менее SPI+GPDMA+таймер - работало на ура
Это не извращение. По другому было никак - SPI-слэйв работает на большей частоте, чем SSP-слэйв. Нам SSP не хватало по частоте.

[Golikov A.]

а синхронизация как? Прерывание по первому пришедшему байту?
SSP - мастер быстрее SPI мастера, а SSP slave медленнее... чудно

я все думал зачем они 2 одинаковых модуля в проце держат...

[jcxz]

а синхронизация как? Прерывание по первому пришедшему байту?

Точно уже не помню.
Вроде так:
спад CS - в ISR от GPIO программируем цепочку SPI+GPDMA+таймер;
сигнал SCLK заводим на счётный вход таймера, его настраиваем на сброс и генерацию DMA-request каждый 16-й клок (16 битные слова).
Размер блока был фиксированный и заранее известный - по прерыванию от завершения DMA отключаем всё хозяйство.
Данные шли от FPGA с нашей прошивкой, так что была возможность в ней сделать увеличенную паузу от спада CS до начала SCLK, чтобы
всё успело запрограммироваться. Но при необходимости можно было сделать и предварительное программирование цепочки SPI+GPDMA+таймер
по фронту предыдущего CS.

SSP - мастер быстрее SPI мастера, а SSP slave медленнее... чудно

Так SPI - проще - транзисторов и паразитных емкостей меньше, поэтому наверное и быстрее

[бомж]

Всем привет!

Есть такая проблемка на LPC1768 настроен SSP в режиме slave
...

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

Я вот так справился с такой проблемой:

Код

void clear_buffer_ssp0 (void)
{
    uint8_t Dummy;
    
    Dummy = Dummy;
    
    /* Clear all remaining data in TX FIFO */
    while (1){
        if (LPC_SSP0->SR & SSP_SR_TFE) break;
        Dummy = LPC_SSP0->DR;                  //equating the SPDR to Dummy Varaible
    }  
}

[Golikov A.]

Я вот так справился с такой проблемой:

ну плохо вы справились и не с той проблемой...

читая из регистра данных вы вычитываете входные данные а не выходные - это первая ошибка
while(1) - это вторая ошибка
делать такое для SSP-slave - третья ошибка
не утруждать себя попытками понимания задачи - четвертая ошибка

Ну а в целом вы молодец, спасибо что ответили...

[бомж]

> ну плохо вы справились и не с той проблемой...

У меня LPC1788 мастер, читает 46 байт из LPC1768 слейв.
LPC1768 читает два ЦАПа, обрабатывает данные, как только собирается 10 результатов, выдаёт импульс в порт на линию связи. LPC1788 при появлении на этой линии заднего фронта читает 46 байт.

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

Код, который я привёл, вызывается в LPC1768 перед тем как выдать импульс готовности данных для LPC1788. Этот код великолепно работает, делая именно то, что нужно. Простите, что неправильно Вас понял, я решил было, что у Вас такая же проблема.

>читая из регистра данных вы вычитываете входные данные а не выходные - это первая ошибка
- чушь!

>while(1) - это вторая ошибка
- не ошибка, а просто не очень красиво. Придирка!

>делать такое для SSP-slave - третья ошибка
- чушь!

>не утруждать себя попытками понимания задачи - четвертая ошибка
- Прежде, чем такое писать, иногда проще попробовать, это не займёт много времени.


Ну хорошо, красивей будет так:

Код

void clear_buffer_ssp0 (void)
{
    volatile uint8_t Dummy;
    
    while (!(LPC_SSP0->SR & SSP_SR_TFE))  
        Dummy = LPC_SSP0->DR;  
}

Оговорился, LPC1768 читает два АЦП.

Почему я не могу отредактировать свой пост?

[Golikov A.]

>читая из регистра данных вы вычитываете входные данные а не выходные - это первая ошибка
- чушь!

Интересно..., а как вы получаете данные? Из какого регистра вы их забираете? И как в этом случае проц понимает что вы читаете данные, а не очищаете выходное фифо? Как получить данные из входного фифо?

>while(1) - это вторая ошибка
- не ошибка, а просто не очень красиво. Придирка!

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

красивей будет так while (!(LPC_SSP0->SR & SSP_SR_TFE))

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

>делать такое для SSP-slave - третья ошибка
- чушь!

Поясню. Вы висите в while до тех пор пока не очиститься выходная очередь, в случае slave выходная очередь очиститься только после того как данные вычитает мастер. Если мастер не будет клочить линию, данные не уйдут никогда и вы будете висеть в while вечно. По мне - это плохое решение. Да я понимаю что вы думали что вы вычитываете выходное фифо, потому цикл и без мастер кончиться, но нет, тут вы в обломчиках...

>не утруждать себя попытками понимания задачи - четвертая ошибка
- Прежде, чем такое писать, иногда проще попробовать, это не займёт много времени.

Если вы что-то запустили и оно дало ожидаемый результат, совсем не обязательно что оно работает как планировалось. Доказательство работоспособности тестированием процесс значительно более длинный и сложный, нежели доказательство работоспособности архитектурой. Вам придется провести несколько экспериментов и правильно интерпретировать результат прежде чем вы поймете где ошиблись. В этом случае гораздо проще прочитать страницу
423 Ref manual

15:0 DATA Write: software can write data to be sent in a future frame to this
register whenever the TNF bit in the Status register is 1, indicating that
the Tx FIFO is not full. If the Tx FIFO was previously empty and the
SSP controller is not busy on the bus, transmission of the data will
begin immediately. Otherwise the data written to this register will be
sent as soon as all previous data has been sent (and received). If the
data length is less than 16 bits, software must right-justify the data
written to this register.
Read: software can read data from this register whenever the RNE bit
in the Status register is 1, indicating that the Rx FIFO is not empty.
When software reads this register, the SSP controller returns data from
the least recent frame in the Rx FIFO. If the data length is less than 16
bits, the data is right-justified in this field with higher order bits filled with
0