[jcxz 184]

2 минуты назад, haker_fox сказал:

Так читается моё сообщение? Сорян, ничего даже подобного не было.

Я имею в виду что то, что я предлагал, вроде как очевидное решение.

[haker_fox 60]

10 minutes ago, tonyk_av said:

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

Я не помню деталей, но в периферии младших STM32 (на базе Cortex-M0) были какие-то нестыковки, требующие программных уловок.

10 minutes ago, jcxz said:

И что же там "кривого"?

Вот и я бы хотел услышать от уважаемого @EdgeAligned аргументацию🙏

10 minutes ago, jcxz said:

.....или МК выбран не удачно.  

Да, это не XMC, который умеет всё🤣🤣🤣🤣

Just now, jcxz said:

Я имею в виду что то, что я предлагал, вроде как очевидное решен

Не спорю, что очевидное) Тем не менее, я до него сам не дошёл))) Что ж, наверное это нормально - постоянно учиться и узнавать что-то новое))))

[jcxz 184]

4 минуты назад, haker_fox сказал:

Да, это не XMC, который умеет всё🤣🤣🤣🤣

Да даже не XMC. Даже простейшие LPC17xx, которые уже дедушки Cortex-M-строения, даже в них выдержка между двумя транзакциями по SPI (выдержка для CS=high) делается автоматом. Без всякого поллинга каких-то BUSY.

Т.е. - писать следующее передаваемое слово в регистр данных можно сразу. Просто выдача его на MOSI задержится автоматически на нужное время CS=high. И ничего не надо поллить.

PS: О XMC даже речи нет.  

[EdgeAligned 53]

1 час назад, haker_fox сказал:

Вот и я бы хотел услышать от уважаемого @EdgeAligned аргументацию🙏

Я уже ж аргументировал ранее. (сейчас пишу со смартфона на улице, много букв писать сложно). 

Есть и другие методы контроля завершения передачи. Например, RXNE в обычном режиме, он генерирует прерыапние. Давно известный метод 

С таймером решение может и прикольное, но мусорное. 

[jcxz 184]

15 минут назад, EdgeAligned сказал:

Есть и другие методы контроля завершения передачи. Например, RXNE в обычном режиме, он генерирует прерыапние. Давно известный метод 

Советую вам ознакомиться с мануалом на STM32 и работой его SPI. Прежде чем что-то советовать или критиковать. Ибо опять пишете о том, о работе чего понятия не имеете.

RXNE в STM32 никак не поможет для определения освобождения SPI (снятия busy-флага).

15 минут назад, EdgeAligned сказал:

С таймером решение может и прикольное, но мусорное. 

"Мусорные" - это ваши советы.

 

PS: Открываем мануал на STM32, читаем:

Цитата

Procedure for disabling the SPI:
The correct disable procedure is (except when receive only mode is used):
1. Wait until FTLVL[1:0] = 00 (no more data to transmit).
2.  Wait until BSY=0 (the last data frame is processed).
3.  Disable the SPI (SPE=0).
4.  Read data until FRLVL[1:0] = 00 (read all the received data).

[EdgeAligned 53]

Прочитали? Отлично. А теперь трезво подумайте, зачем там таймер . И не начинайте опять срач. Уважительно относитесь к коллегам! Уважительно, понимаете? Вот. 

[jcxz 184]

1 час назад, EdgeAligned сказал:

Прочитали? Отлично. А теперь трезво подумайте, зачем там таймер .

И зачем же? Просветите нас, мусорных.  

1 час назад, EdgeAligned сказал:

Уважительно относитесь к коллегам! Уважительно, понимаете? Вот. 

Правда что-ли? Уважительно это:

2 часа назад, EdgeAligned сказал:

С таймером решение может и прикольное, но мусорное.

так что-ли?

 

PS: Про ШИМ вы уже надеюсь просветились, что это такое? "коллега"  

[EdgeAligned 53]

Я просто оставлю это здесь. Не благодарите.

[Arlleex 131]

7 часов назад, jcxz сказал:

Часто я (для экономии таймеров и упрощения кода (чтобы всё в одном ISR было)), такое делаю отправкой/приёмом слова через тот же SPI. Но - отправкой с неактивным CS. Получается просто как небольшая задержка.

Тоже так делаю, но для UART, в реализациях ModBus RTU. После активации передатчика, формирую интервал "тишины" длительностью в 2 UART-фрейма, предварительно отключив ножку TX от UART-модуля. Просто, быстро, ресурсоэффективно.
 

7 часов назад, tonyk_av сказал:

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

Нет, бывает периферия, спроектированная Кутрапаллями за 20 минут с учетом изучения HDL с нуля. Вот потом и нужно извращаться...
 

7 часов назад, jcxz сказал:

Да даже не XMC. Даже простейшие LPC17xx...

Ага, SPI классный, зато болячка перекочевала в UART))

[jcxz 184]

5 минут назад, Arlleex сказал:

Тоже так делаю, но для UART, в реализациях ModBus RTU. После активации передатчика, формирую интервал "тишины" длительностью в 2 UART-фрейма, предварительно отключив ножку TX от UART-модуля. Просто, быстро, ресурсоэффективно.

С SPI можно SCLK/MOSI и не переключать на GPIO. Хотя (если хочется красивой осциллограммы) никто не мешает и переключить.

[tonyk_av 31]

Я может чё упустил, поэтому сразу извинюсь, что не проштудировал предыдущие страницы.
А в чём сложность дождаться освобождения SPY? Обычно, он работает на высоких частотах, поэтому потратить  пару-тройку десятков тактов на ожидание освобождения не очень затратно. К чему этот огород таймерами?

7 minutes ago, Arlleex said:

Просто, быстро, ресурсоэффективно.

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

[Arlleex 131]

8 минут назад, tonyk_av сказал:

А в чём сложность дождаться освобождения SPY? Обычно, он работает на высоких частотах, поэтому потратить  пару-тройку десятков тактов на ожидание освобождения не очень затратно.

Ну, не всегда он быстр, особенно в контексте современных МК: CPU под 200 МГц, а SPI-чип только до 10 МГц, например.
 

Цитата

К чему этот огород таймерами?

Например, когда драйвер умеет оптимально для конкретной периферии МК выбрать способ очередной транзакции: записью CPU или настройкой DMA. Бывает, периферия прекрасно "кооперируется" с DMA-контроллером, но при этом же внутренние сигналы завершения транзакции не умеют формировать прерывания. Поэтому заводят поллинг.
 

Цитата

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

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

[EdgeAligned 53]

Не забывайте, что обсуждение идет в ключе RTOS, а RTOS - это иной, особый подход. Ну и тем более, что решение показал выше на картинке. Кто понял - молодец. Кто не понял - поймет со временем и опытом.