вывожу через интерфейс байт 0xAA. трижды. я не могу догнать, что здесь происходит. почему первый раз отличается от остальных. может, lsb идет первым? тогда вроде все сходится. скажите, что здесь все так или что не так.

У вас сигнал enable всегда в низком уровне? По логике этот сигнал должен быть в высоком уровне, далее он переходит в низкий и начинается передача данных. По завершению передачи, этот сигнал обратно переходит в высокий уровень. Это вывод SPI_NSS у stm32.

Далее заметил, в Салеа Лоджике, всегда тактовые импульсы обозначаются со стрелочкой, у вас этого нет. Вы точно ни чего не пропустили в настройке?

Перед выводом данных переводит в низкое? В первом случае уже было в низком, потому никакого перевода нет?

Вот смотрите как должно быть при правильной работе spi. Как только enable переводится из высокого уровня в низкий, начинается работа spi. Далее посмотрите на тактовые импульсы. У вас анализатор не знает что на CS тактовые импульсы. Тактовый импульс должен быть со стрелочкой. И у вас они разной формы еще.

Вы вывод NSS(это enable) настраивали софтово или аппаратно? Увидеть бы код настройки модуля spi.

Как только enable переводится из высокого уровня в низкий, начинается работа spi.

я думаю, ничего не начинается. это - две операции, которыми мы сами управляем. независимо. низкий уровень устанавливается когда мы его там устанавливаем (reset gpio). при этом ничего не происходит автоматически. просто слэйв не воспринимает синхросигнал при высоком уровне. но у меня единственный мастер и единственных слэйв. поэтому уровень всегда низкий (просто физически посажен у слэйва на gnd. зачем чем-то "управлять", если в этом нет необходимости?).

а передача данных (clk + mosi) начинается только когда мы пишем что-нибудь в регистр SPI_DR. естественно, если spi enabled и прочее все правильно сконфигурировано.

с моим случаем я уже разобрался. нужно было просто cpol & cpha в SPI_CR1 установить как надо. было не так как хотел, потому и выглядело для меня диковато. ну и LSBFIRST сбросить. сейчас все выглядит как хочу.

стрелочек у меня нет, и думаю, это неважно. у меня другая версия, другое устройство, и они меня не не напрягуют (точнее, их отсутствие).

вообще, спасибо всем за комментарии.

а кто-нибудь имеет опыт с st7735? у меня, собственно, весь сыр-бор из-за этого дивайса. в интернете везде - практически тот же самый код на си, пытаюсь его воспроизвести на асм, все происходит как и ожидаю, за исключением некотоых странностей.

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

так вот, в большинстве случаев этот пин меня "слушается". т.е. заземлил, передал команду, если есть данные - установил на пин единицу и передал данные. но в некотых случаях посреди передачи он сам (точно я его не трогаю!) прыгает туда-сюда. что может быть причиной? gpio PA0 со стороны stm32. может, он какой-то "особенный", и я его с кем-то использую совместно? больше ничего в голову не приходит.

обнаружил следующее. если отключаю этот пин от дисплея, оставляю только соединенным с logic analyzer'ом, то все проходит как надо. может, у кого есть идеи? может, как-то по-особенному этот gpio сконфигурировать нужно, чтобы при подключении к дисплею он не "дергался"? могу манипулировать только выходным stm32.

проблема решена. с помощью бывшего коллеги. если кто-то угадает, в чем была причина, подтвержу. примитивно, должен был сам СРАЗУ сделать правильно. но раз сразу допустил такое, то потом начинаешь искать причину где угодно, только не там. в конце-концов или кто-то тыкает носом, или до самого доходит, но гораздо позже. так как "у меня все правильно" : )

Предположу что дело было либо в настройке GPIO, либо в настройке альтернативной функции.

я не могу себе представить, чтобы с ошибках в настройках вами указанных это выглядело бы как случайная помеха.в любом случае, ответ неправильный. еще две попытки : )

Судя по диаграмме могу предположить,что ошибка в генерации SPI CLOCK сигнала. Уж очень сигнал не стабильный.

а где он нестабильный? с ним как раз все красиво.

а где он нестабильный? с ним как раз все красиво

Передача второго байта на диаграмме.

да нет, это все сродни тому, где я причину тоже причину искал : ). анализатор сам по себе устройство с определенной погрешностью. но это все не то. ответ значительно проще. там, где его не ищут (я не искал).

Что ещё приходит в голову так это:

1) конфигурация slave как 3 Line SPI вместо 4 Line 4 SPI

2) ошибка с заведением питания на чип драйвера..

Так в чём проблема была?

"а смеяться не будете?" (с)

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

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

уже много десятилетий наступаю на эти грабли (о! увидел чудо!), вместо того, чтобы проверить примитивные вещи.

Не ошибается только тот, кто ничего не делает.(c)

Главное ошибка найдена и проблема решена.