caxapa.ru :: Не обязательно инициализация информационного обмена (когда вначале передается команда и/или адрес), но обязательно сигнал квитирования. Даже если по SPI гнать одни только данные (без команд управления), то всегда будет ненулевая вероятность нарушения синхронности передачи (звон или помеха в цепи CLK и ... опа!). Сигнал квитирования укажет явно о начале очередного фрейма и обязывает сбросить счетчик тактовых сигналов в начале приема.

reZident (12.06.2023 23:55, просмотров: 98) ответил POV на Позанудствую, ибо формулировку неверную вижу я...

Не обязательно инициализация информационного обмена (когда вначале передается команда и/или адрес), но обязательно сигнал квитирования. Даже если по SPI гнать одни только данные (без команд управления), то всегда будет ненулевая вероятность нарушения синхронности передачи (звон или помеха в цепи CLK и ... опа!). Сигнал квитирования укажет явно о начале очередного фрейма и обязывает сбросить счетчик тактовых сигналов в начале приема.

Ответить

- ХЗ, обо что у вас разговор, но обычно, по фронту SS, у слэйва информаццыя переносится из сдвигового регистра в цэлевой. - mse homjak(13.06.2023 00:16)
  - Это "обычно" имеет отношение к оставшимся 0,01% применения. Что-то типа сдвиговых регистров. - POV(13.06.2023 07:54)
    - Танунах...Все ЦАПы, АЦПы, синтезаторы и всё прочее работают имана так: фронт CS фиксирует состояние сдвигового регистра во внутренний рабочий. - mse homjak(13.06.2023 10:33)
      - Не согласен. У многих АЦП за одну транзакцию по SPI можно установить произвольное количество регистров от 1 до максимума, который позволяет внутренний счетчик. Или взять те же SerialFlash в которых буфер под килобайт. Это скольки же разрядный там регистр по-твоему, если значение его устанавливается одним чохом по фронту CS? О.о - reZident(13.06.2023 10:41)
        
        И что? Фронт CS фиксирует содержимое сдвигового регистра во внутренние. Просто этот регистр "под килобайт". Или таких устройств может стоять вязанка, но всё равно, логика работы именно такая: сколько бы бит не прошло через сдвиговый регистр, всё равно, по фронту CS, текущее состояние сдвигового, перепишется во внутренний. И, жэлательно, чтобы всё это делалось автоматом. А логика этого автомата, забота разрабоччика. - mse homjak(13.06.2023 10:59)
        
        Это твое личное представление разработчика, который проектировал SPI в FPGA. Было ведь такое, а? ;-) А по факту - нет, в самом общем случае CS это всего лишь сигнал квитирования, который определяет начало (и конец) транзакции. - reZident(13.06.2023 11:16)
        
        Ну? А что делает конец транзакции? Прально, фиксирует состояние сдвигового регистра. Кстате, то АЦП, что вы проедложили в качестве примера, не совсем катит, т.к. оно работает не по командам проца, а формирует запрос по DRDY. И то, если оно одно в системе, бо если кого-то в цепи надо прописать, то АЦП можэт потечь крышей. Когда устройств много, извольте дёргать CS. И такое устройство нельзя цеплять в цепь каскадом. В общем, пропиретарщина. Для контраста можэте глянуть mse homjak(35 знак., 13.06.2023 12:00)
        
        Чё вы в сдвиговый регистр уперлись? В SerialFalsh и/или EEPROM буферное ОЗУ это по-вашему тоже сдвиговый регистр чоли? Оно ведь заполняется по кольцу (кольцевому счетчику адресов) во время транзакции записи. Нехилый в SF (где буфер 256 байт) 2048-разрядный регистр забубенили! А потом ведь из этого "регистра" идет запись во Flash, которая по всему выходит тоже 2048 разрядов имеет? Или как? - reZident(13.06.2023 12:20)
        
        Если оно задвигается по последовательному каналу, то да, сдвиговый регистр. Какая разница, скока там разрядов, если вы двигаете его по одному битику? ЖЫТАГ вообще можэт десятки килобайт жопка к жопке сдвигать. mse homjak(697 знак., 13.06.2023 12:58)
        
        Та я ведь и непротив, если вы согласитесь, что CS это сигнал квитирования (флаг, семафор, назовите его как хотите), а не еще один тактовый сигнал. - reZident(13.06.2023 13:07)
        
        Ну да, пусть семафор. Тока по этому семафору сдвиговый регистр должэн переписаться в регистр рабочий. По банальной причине: когда у вас начнёца следующая транзакцыя, эти данные будут испорчены и устройство перейдёт в режим суетолога. До тех пор, пока данные снова не устаканяца. - mse homjak(13.06.2023 13:25)
        
        Да нету прямой связи между фронтом CS и (пере)записью каких-либо унутренних регистров! Внутренняя логика устройства может работать совсем от другого тактового сигнала и начать обрабатывать (пере-записывать принятые или подкидывать в последовательный канал выходные данные) еще до завершения транзакции. CS это лишь признак начала/окончания транзакции и усё! Он управляет логикой интерфейса связи, а не логикой работы самого устройства. - reZident(13.06.2023 13:46)
        
        Да, можэт. От тот техасский АЦП из этой серии. Воткнуть его в цэпочку устройств, нельзя. Для работы его нужно выделить в отдельный загончик. По входу он должэн ловить только то, что нужно только ему. Т.е. это голимая пропиретарщина. Я вам это ужэ пол-дня объясняю. Причом нет никакой причины, чтобы нельзя было сделать по уму. Обычное рукожопие. - mse homjak(13.06.2023 14:04)
        
        А я вам объясняю, что нету прямой связи между CS и внутренней логикой работы устройства. Взять тот же STM32. У него сдвиговый регистр максимум 16-разрядный, а передавать через SPI можно ажно килобайты без "отмашки" каждых 2 байт CS-ом, не так ли? Потому, что унутренний конвейер позволяет подтаскивать данные в сдвиговый регистр SPI и производить перезапись в/из него согласно своей унутренней логике работы модуля SPI. Фронт CS, то бишь NSS лишь запрещает тактировать reZident(133 знак., 13.06.2023 14:33)
        
        Можно. Но в регистрах управления есть биты, отвечающие за это. Т.е. можно (было бы) отмахивать CS каждое слово, а можно не обмахивать. Можно было бы пользовать устройства типа ЕЕПРОМ, с последовательной многобайтной записью и можно было бы пользовать устройства с фиксированной длиной слова. Причом, используя ДМА. А так, налицо какая-то херня, когда имеем, вроде бы, полный набор для скоростной работы с узлом без участия процэссора, но вынуждены сидеть в цыкле и mse homjak(24 знак., 13.06.2023 14:48)
        
        Хужэ того, чтобы привести работу CS в нормальное состояние, достаточно просто вывести на него сигнал ~BUSY. Фсио. Ну, разве что, подмешать к нему TXempty, если BUSY формируется через жопу(скорее всего). Делов-то. А имеем откровенное рукожопство, замешанное на похуизме. Пипл хавает. - mse homjak(13.06.2023 17:44)
        
        Будто бы флеш не знает, что у неё записано на момент фронта CS. В ней и так зафиксировано. Речь об устройствах ввода, типа АЦП или регистров - действительно удобно фиксировать состояние именно по CS - по началу транзакции. - Nikolay_Po(13.06.2023 10:49)
        
        Вот цитата про Chips Select из описания ADS1220 (что под рукой оказалось). Обратите внимание, что 1) фронт (переход из 0 в 1) CS лишь сбрасывает логику SPI и 2) если м/с одна на шине, то устанавливать CS в "1" не требуется, CS может быть "0" постоянно. Это все доказывает, что нихрена фронт CS не служит защелкой последовательных данных в параллельные. reZident(651 знак., 13.06.2023 10:59, ссылка)
- именно - POV(13.06.2023 00:03)

ARM, RISC-V контроллеры