[AHTOXA 18]

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

Условия эксперимента. Я смотрел осциллограммы двух функций. Вот эта отключает чипселект по RXNE:

void testRXNE(SPI_TypeDef* spi){
    CS::On();
    spi->DR = 0xAA;
    while (!(spi->SR & SPI_SR_RXNE));
    spi->DR;
    spi->DR = 0xAA;
    while (!(spi->SR & SPI_SR_RXNE));
    CS::Off();
    spi->DR;
}

А вот эта - по BSY:

void testBSY(SPI_TypeDef* spi){
    CS::On();
    spi->DR = 0xAA;
    while (!(spi->SR & SPI_SR_TXE));
    spi->DR = 0xAA;
    while ((spi->SR & SPI_SR_BSY));
    CS::Off();
    spi->DR;
}

(Считывание DR в конце функций производится после сброса чипселекта, чтобы не влиять на время реакции.)

Проверял на F103 и F407. Результаты совпадают. (Картинки с F103)

Легенда: Жёлтый - клок, синий - чипселект.

Результаты.

Первое. Всё-таки BSY не ждёт окончания передачи последнего клока. На маленьких частотах это особенно заметно (картинка идентична для обеих функций):

Второе. На больших скоростях BSY возникает даже раньше, чем RXNE! (100ns в клетке) :

Вывод. Я не знаю, для чего придумали флаг BSY, но для управления чипселектом он точно не подходит:)

 

[HHIMERA 0]

"Песец... серебристый."(С)

 

    spi->DR = 0xAA;
    while ((spi->SR & SPI_SR_BSY));
}

Note: 1 During discontinuous communications, there is a 2 APB clock period delay between the

write operation to SPI_DR and the BSY bit setting. As a consequence, in transmit-only

mode, it is mandatory to wait first until TXE is set and then until BSY is cleared after writing

the last data.

Проверял на F103 и F407.

А я думал, что на STM32F0XX... только там такое прокатывает...

Вывод. Я не знаю, для чего придумали флаг BSY, но для управления чипселектом он точно не подходит:)

Ну да!!! Если SPI запускать только на передачу, то придётся выдумать свой флаг... отличный от даташитовского...

 

Вывод: не надо изобретать велосипед и плодить сущности... а читать даташит...

"Всё уже придумано до нас!"(С)

[AHTOXA 18]

Note: 1 During discontinuous communications, there is a 2 APB clock period delay between the

write operation to SPI_DR and the BSY bit setting. As a consequence, in transmit-only

mode, it is mandatory to wait first until TXE is set and then until BSY is cleared after writing

the last data.

Дык, я так и делал, специально два байта отправляю, после первого жду TXE. То есть, после отправки второго у меня гарантированно "continuous communications".

А я думал, что на STM32F0XX... только там такое прокатывает...

Ничего не понял. Что прокатывает? Какое "такое"?

Ну да!!! Если SPI запускать только на передачу, то придётся выдумать свой флаг... отличный от даташитовского...

 

Вывод: не надо изобретать велосипед и плодить сущности... а читать даташит...

"Всё уже придумано до нас!"(С)

Вы не согласны с моими выводами? Тогда покажите, как использовать "даташитовский флаг" BSY для управления чипселектом.

[ViKo 1]

Первое. Всё-таки BSY не ждёт окончания передачи последнего клока. На маленьких частотах это особенно заметно (картинка идентична для обеих функций):

Развертка какая по времени?

Второе. На больших скоростях BSY возникает даже раньше, чем RXNE! (100ns в клетке) :

Какая тактовая частота у процессора? Что-то много времени проходит.

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

Проверил на своем коде. Обратите внимание, чип селект поднимается до объединения по или. А в другом случае - после!

;;;1059     id |= SPI1->DR;                // Memory capacity
0005a0  8980              LDRH     r0,[r0,#0xc]
;;;1060     // while (SPI1->SR & SPI_SR_BSY);    // ждать, если SPI занят
;;;1061     SMSS_OFF();
0005a2  8311              STRH     r1,[r2,#0x18]
0005a4  4318              ORRS     r0,r0,r3            ;1059

Можно предположить, что BSY возникает после пересылки из DR в сдвиговый регистр, когда начинает работать автомат пересылки.

А заканчивается, когда прочитан последний бит (в середине последнего такта). Дальше слово пересылается из сдвигового регистра в DR, и устанавливается RXNE.

Вывод. Я не знаю, для чего придумали флаг BSY, но для управления чипселектом он точно не подходит:)

Вот с этим не согласен. Аргументы уже высказывал... "А по-моему, они одинаковые!" (с) - для данной задачи.

[AHTOXA 18]

Развертка какая по времени?

1us в клетке.

Какая тактовая частота у процессора? Что-то много времени проходит. Неплохо бы взглянуть на ассемблерный код. Возможно, разница по времени возникает из-за разных команд.

Частота 72Мгц. Код:

    f012 0f01     tst.w    r2, #1
    d0fb          beq.n    8000a60 <testRXNE(SPI_TypeDef*)+0x20>
    f44f 5c80     mov.w    ip, #4096; 0x1000
    f2c4 0c01     movt    ip, #16385; 0x4001
    2110          movs    r1, #16
    f8cc 1010     str.w    r1, [ip, #16]

Во втором случае код идентичный (только бит другой проверяется).

То есть, собственно на установку ножки идёт 4 команды. Это всяко меньше, чем 250 нс. Так что полученная разница - это разница именно между RXNE и BSY.

Проверил на своем коде. Обратите внимание, чип селект поднимается до объединения по или. А в другом случае - после!

Этой сентенции не осилил.

Вот с этим не согласен. Аргументы уже высказывал... "А по-моему, они одинаковые!" (с) - для данной задачи.

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

[ViKo 1]

Этой сентенции не осилил.

В моем листинге - три команды.

Первая читает из DR в R0.

Вторая загружает в GPIO BSRR, устанавливает CS в 1.

Третья объединяет по или старшие байты идентификатора в R3 с младшим, только что прочитанным в R0.

Хотя по C тексту установка CS идет последней. Компилятор Keil, оптимизация -O3. Зачем переставил, не знаю!

 

Когда же проверял по BSY (закомментированная команда), всё шло по написанному.

 

Насчет осциллограмм. (удалил неправильное)

Флаги сформировались по фронту последнего такта (в данном случае). Определяется установками CPHA, CPOL. И задержка - некая аппаратная, вдобавок к программной. Что позволяет надеяться, что CS для ведомого устройства будет выдержан с запасом. пмсм :)

[Tahoe 0]

Первое. Всё-таки BSY не ждёт окончания передачи последнего клока. На маленьких частотах это особенно заметно (картинка идентична для обеих функций):

Насколько я понимаю, эта картинка сделна в SPI MODE == 00b

Сейчас не с руки посмотреть, но что-то мне подсказывает, что при SPI_MODE == 01b, поведение будет совсем иным, т.е. BSY сбросится после заднего clock edge.

[ViKo 1]

Сейчас не с руки посмотреть, но что-то мне подсказывает, что при SPI_MODE == 01b, поведение будет совсем иным, т.е. BSY сбросится после заднего clock edge.

Да, наверное. Только это не "совсем иное". BSY будет сброшен после перепада, по которому данные читаются. Дальше такты не нужны. И CS тоже.

[Tahoe 0]

На форуме ST были разборки с SPI_NSS и флагами, года полтора назад. Не могу никак ссылку найти, может кто поделится актуальной? Там про флаги, в т.ч. про BSY было разжевано.

[HHIMERA 0]

Не секрет, что все эти флаги не обязательны...

Что мешает заменить их NOP'ами и посмотреть... сколько тактов нужно на загрузку, сколько на трансфер и т.д. ???

[AHTOXA 18]

Насколько я понимаю, эта картинка сделна в SPI MODE == 00b

Сейчас не с руки посмотреть, но что-то мне подсказывает, что при SPI_MODE == 01b, поведение будет совсем иным, т.е. BSY сбросится после заднего clock edge.

Да. При смене фазы и BSY и RXNE срабатывают после заднего edge. Но тут есть ещё одно соображение - многие микросхемы работают в нескольких mode. Например, в 0 и 3. И далеко не факт, что они при этом допускают соответствующее изменение момента CS.

 

BSY будет сброшен после перепада, по которому данные читаются. Дальше такты не нужны. И CS тоже.

Уф. Ну нельзя же так - тупо повторять голословные утверждения. Я ж вам аргументировал. Вон, и в википедии, по ссылке выше, - тоже SS нарисован после последнего такта.

Вот вам ещё. Диаграмма из даташита микросхемы AT25640:

Как видите, она явно требует, чтобы CS держался до окончания последнего такта. Если вы думаете, что это просто приблизительная картинка, то вот вам другая, показывающая, что считать такты они умеют (обратите внимание, 15 тактов вместо 16):

Кстати, именно с этой микросхемой я и имел проблемы "раннего отпускания чипселекта".

[VCucumber 0]

Можно я тут со своими аналогичными глупостями влезу ?

Вот тут я приводил тестовый код для F407, показывающий глюк SPI http://electronix.ru/forum/index.php?s=&am...t&p=1125779

 

uint8_t i;
// отправляем несколько байт
	for(i = 11; i < 14; i++)
	{
		while (!(SPI1->SR & SPI_I2S_FLAG_TXE));
		SPI1->DR = i;
// здесь необходимая задержка, чтобы SPI не клинило
		Delay_us(1);
	}
// очищаем буфер (м.б. FIFO) приемника
	while ((SPI1->SR & SPI_I2S_FLAG_RXNE))
		i = SPI1->DR;
// ждем готовности передатчика и отправляем байт
	while (!(SPI1->SR & SPI_I2S_FLAG_TXE));
	SPI1->DR = (uint8_t)123;
// ждем готовности приемника и принимаем отправленный байт
	while (!(SPI1->SR & SPI_I2S_FLAG_RXNE));
// если SPI сглючил, зажигаем LED
	if (SPI1->DR != (uint8_t)123)
		STM_EVAL_LEDOn(LED5);

 

Глюк лечится как раз добавлением около 15 нопов при 168мгц. При понижении тактовой SPI относительно тактовой процессора количество нопово нужно пропорционально увеличить.

SPI1, мастер, CS программный, режимы 0 и 3, тактовые по максимуму.

 

Если считаете, что код кривой, поясните чайнику, как надо.

 

[AHTOXA 18]

Вот тут я приводил тестовый код для F407, показывающий глюк SPI

А если перенести задержку вот сюда:

    // очищаем буфер (м.б. FIFO) приемника
    while ((SPI1->SR & SPI_I2S_FLAG_RXNE))
    {
        i = SPI1->DR;
        Delay_us(1);
    }

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

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

[VCucumber 0]

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

 

Изменено 12 января, 2013 пользователем Огурцов

[ViKo 1]

Вот вам ещё. Диаграмма из даташита микросхемы AT25640:

Как видите, она явно требует, чтобы CS держался до окончания последнего такта. Если вы думаете, что это просто приблизительная картинка, то вот вам другая, показывающая, что считать такты они умеют (обратите внимание, 15 тактов вместо 16):

Пусть будет так. Только в даташите по ссылке для RDSR у них нарисовано уже 16 тактов. :rolleyes: Наверное, писатели временами читают форумы.

У меня на Atmel - давняя идиосинкразия. В частности, на их умение считать такты. :laughing: