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

[SasaVitebsk]

При инициализации с делителем на 64 (с другими не проверял). SPI3 (с другими не проверял). stm407 на 168МГц (с другими не проверял).
После записи в регистр DR необходимо выждать задержку до проверки флага BSY в регистре SR. Иначе байт может потерятся (затерется следующим).
То есть флаг занятости выскакивает с задержкой. Причём задержка приличная, успеваю выйти и войти в процедуру.
После установки задержки всё устаканилось.

[Flexz]

наверное не просто так в RM написано

Note: Do not use the BSY flag to handle each data transmission or reception. It is better to use the
TXE and RXNE flags instead.

[KnightIgor]

наверное не просто так в RM написано

Поддерживаю. Для полнодуплексного (даже если только передача нужна) SPI завершение передачи нужно проверять по... RXNE (и забыть о TXE или BSY, т.к. STM32F не поддерживает аппаратное формирование SS в режиме мастера!). Тогда будет абсолютная уверенность, что байт ушел, а следующий его не затрет по пути: ведь пока байт выдвигается по MOSI, входящий байт вдвигается по MISO тем же тактовым сигналом. Это означает, что флаг RXNE все равно возникнет, пусть позже TXE, зато наверняка после последнего такта. Нужно помнить чистить RXNE путем чтения DR перед записью туда:

1. Прочесть DR.
2. Записать в DR байт для передачи.
3. Ждать RXNE (будь-то тупо или путем реакции на прерывание).
4. Перейти к п.1., если еще есть данные для передачи.

Сообщение отредактировал KnightIgor - Nov 16 2012, 22:44

[AHTOXA]

Это означает, что флаг RXNE все равно возникнет, пусть позже TXE, зато наверняка после последнего такта.

Кстати, не факт, что после. В зависимости от режима SPI, RXNE может возникать на середине последнего такта (если данные на приёме защёлкиваются по переднему фронту). Вот тут-то наверное и может пригодиться BSY. (Хотя я лично просто делаю несколько nop-ов перед отпусканием CS)

[ViKo]

Кстати, не факт, что после. В зависимости от режима SPI, RXNE может возникать на середине последнего такта (если данные на приёме защёлкиваются по переднему фронту). Вот тут-то наверное и может пригодиться BSY. (Хотя я лично просто делаю несколько nop-ов перед отпусканием CS)

Пробую понять SPI от STM32. Действие битов SSM, SSI не соответствует описанным в документации. В Интернете фантазируют, кто во что горазд.
Насчет RXNE и BSY. Похоже, они переключаются одновременно в конце передачи.
Но задержка на полтакта для программного снятия CS не нужна. Потому что выборка (защелкивание) данных ведомым устройством как раз и произойдет в момент, когда возникнет RXNE. А дальше пусть такт заканчивается, все равно. Главное, чтобы время удержания данных на входе ведомого устройства не оказалось меньше нормы. Но это наносекунды. С учетом работы программы, беспокоиться не о чем.
Если же ведомое устройство - какой-нибудь регистр, то нужно правильно выбрать полярность тактов SCK.

[AHTOXA]

Насчет RXNE и BSY. Похоже, они переключаются одновременно в конце передачи.

Что значит "похоже"? Как вы это выяснили?
Нет, не одновременно.

Но задержка на полтакта для программного снятия CS не нужна. Потому что выборка (защелкивание) данных ведомым устройством как раз и произойдет в момент, когда возникнет RXNE.

А если на пару наносекунд позже?
Понимаете, базируясь на RXNE, вы устраиваете гонки - кто первый примет последний бит. Если сначала примет устройство, потом STM-ка, то всё в порядке. А если в гонке победит STM-ка, то CS будет сброшен раньше чем нужно, и вся посылка будет потеряна.

[ViKo]

Что значит "похоже"? Как вы это выяснили?

по картинке

А если на пару наносекунд позже?

У нас есть команды проверки флага, перехода, если установился, подготовки байта (CS) для засылки в порт, засылки в порт. Даже на 168 MHz тактовой это займет не один десяток ns. Пара nop, что вы добавляете, составит ~1/4 от всего количества команд.

Вытащил из "мусорника"...

вытащите из чего угодно не "мусор", а программирование битов SSM и SSI.

Понимаете, базируясь на RXNE, вы устраиваете гонки - кто первый примет последний бит. Если сначала примет устройство, потом STM-ка, то всё в порядке. А если в гонке победит STM-ка, то CS будет сброшен раньше чем нужно, и вся посылка будет потеряна.

Грубо говоря, они примут одновременно. Если не обращать внимания на скорость распространения сигналов по плате (~ 20 sm за 1 ns) и на разные пороги срабатывания триггеров в STM и ведомом устройстве (при нормальных фронтах SCK вряд ли разбежка будет больше 1 ns). Если SCK в ведомое устройство доберется с опозданием, то, очевидно, и CS так же опоздает.
Во всяком случае, задержка именно на полтакта не нужна. Нужно смотреть на время удержания для конкретного ведомого устройства. В некоторых тормозных оно может быть большим, в некоторых равно 0.

[AHTOXA]

по картинке

Думаю, что врёт картинка. Потому что в тексте не так. (И из опыта - тоже не так.)
BSY сделан для управления чипселектом, а чипселект надо держать до конца байта, а не до гипотетического момента, когда нам думается, что ведомое устройство уже приняло байт.

У нас есть команды проверки флага, перехода, если установился, подготовки байта (CS) для засылки в порт, засылки в порт. Даже на 168 MHz тактовой это займет не один десяток ns. Пара nop, что вы добавляете, составит ~1/4 от всего количества команд.

Да ради бога, если вам нравится делать устройства, работа которых зависит от погоды на Марсе - делайте, как вам угодно. Только потом не удивляйтесь, если ваш девайс перестанет работать с новой партией микросхем. Вам два человека хором говорят, что RXNE и BSY - это не одно и то же, и что они ходили по этим граблям. Но выбор, конечно, за вами.

Именно на STM32F207. НА STM32F103 разрешал отдельной командой. Иначе - никак.

У меня на 10x тоже одной командой:

Код

    RCC->APB1ENR |= RCC_APB1ENR_SPI2EN;
    SPIx->I2SCFGR &= ~SPI_I2SCFGR_I2SMOD;
    SPIx->CR2 = 0;
    SPIx->CR1 = SPI_CR1_MSTR | divisor | SPI_CR1_SSM | SPI_CR1_SSI | SPI_CR1_SPE | phase | cpol;

И работает. ЧЯДНТ?

[ViKo]

... а чипселект надо держать до конца байта, а не до гипотетического момента...

Не надо

И работает. ЧЯДНТ?

Что нам скажет товарищ HHIMERA?

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

Код

  SPI1->CR1 = SPI_CR1_SSI | SPI_CR1_BR_0 | SPI_CR1_MSTR;        // Fpclk/4
  SPI1->CR2 = SPI_CR2_SSOE;
...
  SPI_Cmd(SPI1, ENABLE);        // разрешить SPI1

два человека хором говорят, что RXNE и BSY - это не одно и то же, и что они ходили по этим граблям

И я прошелся когда-то давным-давно, и ничего не заметил:

Код

inline uint8_t SFMByte_send(uint8_t data) {
  while (!(SPI1->SR & SPI_SR_TXE));    // ждать освобождения
  SPI1->DR = data;            // послать данные
  while (!(SPI1->SR & SPI_SR_RXNE));    // ждать байта в приемнике (конца передачи)
//  while (SPI1->SR & SPI_SR_BSY);    // другой способ дождаться конца передачи
  return SPI1->DR;

[AHTOXA]

Не надо

Я лично сталкивался с устройствами, которые отбрасывали посылку, если чипселект не удерживать до окончания клоков. Но раз вам не надо, то конечно, дело ваше.
Вообще, у вас очень странная позиция. Если вы утверждаете, что нет разницы между RXNE и BSY, то почему вы упёрлись в использование RXNE? Чисто чтоб поспорить?
Короче, утомили вы меня, не стану больше вас отговаривать от глупых поступков. Да и вообще зря я это начал, сразу было понятно, что бесперспективняк.

[Tahoe]

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

Скажу больше, я даже сталкивался с камнем, который защелкивал CS фронтом последнего клока. Хотя, формально, это не был SPI, просто serial interface.