[Arlleex 131]

39 минут назад, ViKo сказал:

У меня вот какой опыт, из записей своих извлёк. И в теме я то же писал.

 

Зачем намеренно рушить автомат работы SPI-блока (не чтением DR, от которого зависит поведение флага RXNE) и чему-то удивляться потом?

Если хотите поллингом - будьте добры считывать DR после каждого события RXNE. Если по прерываниям - там же считывайте и DR при надобности.

В этом случае можно использовать RXNE в качестве ориентира для CS (и то под вопросом - повезет/не повезет, исходя из опыта @AHTOXA и @Reflector).

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

[ViKo 1]

Зачем вы комментируете обнаруженное, осмысленное и решенное много лет назад? Всё, что мне нужно было, я сделал.

Вообще, временнЫе диаграммы в RM разрисованы. На них BSY и RXNE срабатывают одновременно в конце пересылки.

Не понимаете, о чем сигнализирует флаг BSY? ОГО.

[jcxz 184]

9 часов назад, Reflector сказал:

SPI так же считает, раз данные по спаду SCLK захвачены, значит можно этот момент считать окончанием передачи и сбрасывать BSY, но некоторые устройства при таком подходе реально не работают. Например, SPI дисплеи(ST7735) у меня отказываются запускатся если делитель для SPI 64 и больше, но они работают если добавить задержку перед поднятием NSS, тогда оно происходит не в середине последнего периода.

Там у меня опечатка: на осциллограмме выставление бита - по спаду, захват - по фронту. Хотя, думаю, это и так ясно из контекста.

"Некоторые не работают" - ну и что-ж? Понятно, что у некоторых SPI-чипов есть свои особенности: некоторым нужно активировать CS, затем подождать какое-то время и только потом начинать обмен; другим - наоборот: после завершения транзакции какое-то время держать CS. Всё это описано в мануалах на эти чипы.

Но я вообще-то писал о конкретной осциллограмме, которую комментировал, а не обо всех SPI-чипах в мире вместе взятые. И о том, что на той осц. происходит. А там всё вполне в норме с точки зрения именно шины SPI. И SPI-чипы без спец.требований по таймингам CS относительно SCLK, а с типичными требованиями по задержкам фронта/спада CS относительно перепадов SCLK, вполне нормально будут работать согласно той осц.

12 часов назад, ViKo сказал:

О, так это всё та же тема тянется. Там я писал, проверяйте, что TXE сработал, затем, что BUSY завершился. И тогда снимайте CS. 

Зачем? Достаточно дождаться RXNE.

12 часов назад, haker_fox сказал:

Единственное, что меня смутило в периферии - отсутсвтие прерывания по BUSY. Не знаю, может быть превык к LPC где почти на каждый чих периферии есть прерывание.

А Вы не задумались "почему так сделано"? Думаете в STM такие дураки сидят, что не предусмотрели того, что необходимо? 

Раз не сделали, значит считают, что оно не нужно. Значит знают, что всё решается просто и без этого.

Хоть до некоторых здешних обитателей это пожалуй никогда не дойдёт....  

[jcxz 184]

В 17.05.2020 в 17:56, AHTOXA сказал:

Что значит "не относящиеся к делу"? Две картинки, на одной - форма сигнала, которая получается, если управлять CS по RXNE, вторая - как требуется по спецификации устройства. Вторую картинку пришлось повторить, потому что некоторые особо одарённые товарищи не знают, как должно быть.

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

А ещё можно рисунок с забора сфотать и выложить как доказательство. Вполне в вашем стиле.

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

2. Даже на той картинке, что вы прицепили в качестве типа "доказательства" нет ничего противоречащего осциллограмме на картинке. Ибо: если производитель желает указать на какие-то требования временных соотношений одного сигнала относительно другого, он это явно указывает. Делая риски и сноски на осциллограмме.

А ваши картинки скорее походят на заборное творчество.

[haker_fox 60]

59 minutes ago, jcxz said:

Думаете в STM такие дураки сидят, что не предусмотрели того, что необходимо?

Ну зачем же сразу дураки... Мало ли особенностей периферии. По-началу не подумали, а теперь уже прерывание некуда добавлять, например.

 

 

[jcxz 184]

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

Ну зачем же сразу дураки... Мало ли особенностей периферии. По-началу не подумали, а теперь уже прерывание некуда добавлять, например.

Ну во-первых: Свободных битов в регистрах управления SPI ещё целый вагон.

Во-вторых: Откройте мануал на свежий, недавно сделанный STM32WB55 и увидите, что SPI там сильно доработан, много что изменили, но тем не менее прерывания по BUSY так и не добавили.

Так что вариант "не подумали" явно не из этой истории. Значит они считают, что не нужно оно.

[AHTOXA 14]

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

Там у меня опечатка: на осциллограмме выставление бита - по спаду, захват - по фронту. Хотя, думаю, это и так ясно из контекста. 

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

Ну ничего, картинку я верну, и снова макну тебя куда следует. Итак.

Картинка:

Как я понял, новая версия такая: выставление - по спаду, захват по фронту. (Так вообще бывает? Что-то сомневаюсь. Ну да ладно). Итак, поциент на полном серьёзе утверждает, что можно выставлять свой бит данных по спаду SCK, при этом уже сняв CS! Это ли не клиника? Или поциенту неважно, примет ли ведомое устройство его блок данных?

Я ещё раз повторю, чтобы исключить возможность каких-то увёрток: последний спад SCK происходит при снятом CS!

Ну и на закуску картинка от создателя шины SPI, фирмы Motorola:

Как видно, время удержания CS после завершающего перепада SCK обозначено явно. (Вот ссылка на документ, из которого взята картинка).

В общем, Славик, ты обделался снова. Уже даже не смешно.

 

[jcxz 184]

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

Итак, поциент на полном серьёзе утверждает, что можно выставлять свой бит данных по спаду SCK, при этом уже сняв CS!

Ложь! Я такого нигде не утверждал. 

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

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

Опять ложь! Моё первое сообщение:

В 17.05.2020 в 11:40, jcxz сказал:

2. Из картинок по той ссылке, не видно никаких проблем в работе. Для первой картинки очевидно, что выдвигание бита на шину происходит по спаду SCLK, а защёлкивание - по фронту SCLK. А чтобы вообще всё было красиво, лучше использовать режим SPI с пассивным состояние SCLK==1.

PS: Впрочем - это мой последний ответ вам. Более вы для меня не существуете. Оскорбления, хамство и переход на личности - здесь вам нет равных, общайтесь далее с собой. Даже отвечать противно...

Все остальные легко могут найти примеры SPI-слэйвов выдвигающих данные по спаду SCLK во многих мануалах (для режима 0 при этом первый бит выдвигается на шину по спаду CS). Объяснять очевидное не считаю более нужным.

[ViKo 1]

Эка вас разбирает, бойцы. Нашли, за какой фронт воевать. 

[AHTOXA 14]

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

Ложь! Я такого нигде не утверждал.  

Я специально процитировал твоё утверждение перед этим. И там это явно утверждается.

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

Опять ложь! Моё первое сообщение: 

Цитата

2. Из картинок по той ссылке, не видно никаких проблем в работе. Для первой картинки очевидно, что выдвигание бита на шину происходит по спаду SCLK, а защёлкивание - по фронту SCLK. А чтобы вообще всё было красиво, лучше использовать режим SPI с пассивным состояние SCLK==1. 

 

Значит, "выдвигание бита на шину по спаду SCLK" после снятия CS - это "никаких проблем в работе"? Да это просто клиника!

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

Все остальные легко могут найти примеры SPI-слэйвов выдвигающих данные по спаду SCLK во многих мануалах

Со снятым CS? Ну-ну. Потрясающее упорство в своём невежестве.

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

это мой последний ответ вам

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