Перейти к содержанию
    

stm32f407 SPI обнаружил косяк

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

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

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

Цитата

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

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

Цитата

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

500KHz.png

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

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

at25640_wr.gif

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

500KHz.png

Для альтернативно одарённых повторю: синий - 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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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 снимался раньше, чем нужно. Правда, без прерываний, по опросу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 minutes ago, ViKo said:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 hours ago, haker_fox said:

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

Есть, у STM32H7 :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

18 hours ago, jcxz said:

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

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

Изменено пользователем Reflector

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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


/*
  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, что гарантирует, что началась пересылка последнего байта,
   и приемопередатчик занят. */

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...