[jcxz 184]

55 минут назад, AHTOXA сказал:

Если вы не видите проблем, это не означает, что их нет.

На приведённых картинках проблем нет. 

Цитата

Существуют устройства, которые отменяют транзакцию, если CS снят до окончания нужного количества тактов SCLK.

Покажите где на приведённых картинках "CS снят до окончания нужного количества тактов SCLK"?

Цитата

Ну я и не ожидал, что вы поймёте. Умение читать  и понимать - это не ваше.

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

[AHTOXA 14]

47 минут назад, jcxz сказал:

Покажите где на приведённых картинках "CS снят до окончания нужного количества тактов SCLK"?

Хорошо, для особо одарённых я повторю картинку:

Для альтернативно одарённых повторю: синий - CS, жёлтый - SCLK.

Вот вам картинка, как это должно быть (из технического описания микросхемы AT25640):

Опять не видите? Сочувствую. Но не удивлён.

[VladislavS 29]

Поднять тактовую до положенных 5-10 МГц и ни одно прерывание не успеет CS поднять раньше чем надо.

[jcxz 184]

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

Хорошо, для особо одарённых я повторю картинку:

Для альтернативно одарённых повторю: синий - CS, жёлтый - SCLK.

Ещё раз: Судя по этой картинке выставление бита на шину происходит по спаду SCLK, захват бита с шины - по спаду SCLK. И никакого криминала в этой осциллограмме нет - CS можно снимать там где он снимается.

Вы понимаете написанное?

И я говорил конкретно о материале приведённом по вашей ссылке:  https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=107951&page=5&tab=comments#comment-1127161

а не о чём-то другом. 

Опять начали выкручиваться "как уж на скоровородке" приводя не относящиеся к делу картинки? Сперва ляпнуть что-то не по делу, а потом выкручиваться - это ваш стиль.

[AHTOXA 14]

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

Ещё раз: Судя по этой картинке выставление бита на шину происходит по спаду SCLK, захват бита с шины - по спаду SCLK. И никакого криминала в этой осциллограмме нет - CS можно снимать там где он снимается. 

Во-первых, CS на картинке снят ДО спада SCLK. Так что, вы, дружище, снова сели в лужу. Уже в который раз. Во-вторых, даже если подчинённое устройство захватывает данные по фронту SCLK, то проблемы всё ещё возможны. Потому что во-первых, устройство может не успеть захватить сигнал по фронту до спада CS (многие устройства гораздо медленнее, чем 168МГц STM-ка). А во-вторых, некоторые устройства требуют удерживать CS до последнего такта SCLK. И отменяют транзакцию, если снять CS хоть на полтакта раньше.

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

И я говорил конкретно о материале приведённом по вашей ссылке

Этот материал тоже есть по ссылке. Чуть ниже. Читать надо внимательнее.

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

Опять начали выкручиваться "как уж на скоровородке" приводя не относящиеся к делу картинки?

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

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

Сперва ляпнуть что-то не по делу, а потом выкручиваться - это ваш стиль. 

Не скромничайте, это как раз ваш стиль. Интересно, что теперь придумаете, как будете выкручиваться.

4 часа назад, VladislavS сказал:

Поднять тактовую до положенных 5-10 МГц и ни одно прерывание не успеет CS поднять раньше чем надо. 

Я ловил проблемы как раз на 10 МГц SPI. Там картинка была не столь явной, но CS снимался раньше, чем нужно. Правда, без прерываний, по опросу.

[ViKo 1]

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

[haker_fox 60]

5 minutes ago, ViKo said:

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

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

Ну и не по теме: ну почему у DMA нет связных списков... рррр!

[Reflector 0]

2 hours ago, haker_fox said:

Ну и не по теме: ну почему у DMA нет связных списков... рррр!

Есть, у STM32H7 :)

[AHTOXA 14]

3 часа назад, ViKo сказал:

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

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

[Reflector 0]

18 hours ago, jcxz said:

Судя по этой картинке выставление бита на шину происходит по спаду SCLK, захват бита с шины - по спаду SCLK. И никакого криминала в этой осциллограмме нет - CS можно снимать там где он снимается.

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

Изменено 18 мая, 2020 пользователем Reflector

[ViKo 1]

16 минут назад, AHTOXA сказал:

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

Так, как я описал, у меня работает во всех проектах (немногих), что с памятью, что с ЦАПами, с регистрами. Вообще не помню проблем с SPI.
Пока нет доказательств обратного, доверяю своим решениям.
 

[AHTOXA 14]

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

Пока нет доказательств обратного, доверяю своим решениям.

А осциллограммы не считаются доказательствами? :-)

[ViKo 1]

40 минут назад, AHTOXA сказал:

А осциллограммы не считаются доказательствами? :-)

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

[Arlleex 131]

ИМХО, @AHTOXA дело говорит.

Прецедент пойман? Пойман. Условия есть на картинках - желающие могут повторить.

Я не удивлен такому поведению SPI-флагов из-за, в целом, неудачной реализации модуля SPI в МК STM32.

У меня пока что тоже во всех проектах CS рулится по RXNE, BSY вообще не понял, зачем нужен, да и не сильно было интересно.

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

 

Другое дело - должен ли так себя вести RXNE? Наверное, нет. Но это вопрос уже к индусам (или кто там эти МК делает?).

[ViKo 1]

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

/*
  SPI устройстве M25PE40, MCU STM32F207. Код следующий. Конец Chip Select
  перенес до последнего чтения из DR. Первая закомментированная строка
  (проверка TXE) никогда не используется, осталась от прошлого.
  А использовалась проверка RXNE или проверка BSY. Скорость тоже выбиралась
  из двух вариантов: самая медленная (60 MHz / 256) и максимально допустимая
  (60 MHz / 4 = 15 MHz).
  */
uint32_t SFMID_read(void) {
  SMSS_ON();
  uint32_t id = 0;
  SPI1->DR = SFM_RDID;		// послать команду "RDID"
  while (!(SPI1->SR & SPI_SR_TXE)); // ждать освобождение передатчика
  SPI1->DR = SFM_DUMMY;		// послать пустой байт
  while (!(SPI1->SR & SPI_SR_RXNE));	// ждать байт в приемнике
  id = SPI1->DR;	    // High Impedance
  while (!(SPI1->SR & SPI_SR_TXE)); // ждать освобождение передатчика
  SPI1->DR = SFM_DUMMY;		// послать пустой байт
  while (!(SPI1->SR & SPI_SR_RXNE));	// ждать байт в приемнике
  id = SPI1->DR << 16;		// Manufacturer
  while (!(SPI1->SR & SPI_SR_TXE)); // ждать освобождение передатчика
  SPI1->DR = SFM_DUMMY;		// послать пустой байт
  while (!(SPI1->SR & SPI_SR_RXNE));	// ждать байт в приемнике
  id |= SPI1->DR << 8;		// Memory type
  // while (!(SPI1->SR & SPI_SR_TXE));	// ждать освобождение передатчика
  // while (!(SPI1->SR & SPI_SR_RXNE)); // ждать байт в приемнике
  while (SPI1->SR & SPI_SR_BSY);    // ждать, если SPI занят
  SMSS_OFF();
  id |= SPI1->DR;	    // Memory capacity
  // while (SPI1->SR & SPI_SR_BSY); // ждать, если SPI занят
//  SMSS_OFF();
  // Test = id;
  return id;
}

/* Посылаю в длинный последовательный регистр (или в ЦАП) последовательность из
   нескольких байтов. Читать ничего не читаю (не нужно, нечего). Так вот в таком
   случае определять завершение передачи способом */

  while (!(SPI3->SR & SPI_SR_RXNE));	// ждать конец передачи - так нельзя!

/* не годится! Потому что флаг RXNE установится после первой же пересылки байта.
   И не сбросится, пока не прочитаешь регистр данных DR.
   Так как мне не нужно было читать из SPI, то конец передачи обнаруживался
   "досрочно", при первой же проверке SR & SPI_SR_RXNE.
   В этом случае правильное решение - проверять BSY. */

  while (!(SPI3->SR & SPI_SR_TXE));    // ждать освобождение буфера передатчика
  while (SPI3->SR & SPI_SR_BSY);    // ждать освобождение приемопередатчика

/* Поскольку пересылка байтов может быть прервана в середине, то BSY тоже может
   иметь "разрыв". Спасает ожидание освобождения буфера передатчика перед
   проверкой BSY, что гарантирует, что началась пересылка последнего байта,
   и приемопередатчик занят. */