Можно вводить задержки на стороне STM32 между отправкой/приемом байтов. Но это снижает скорость обмена.

Уже думаю над асинхронным протоколом, чтобы на каждый отправленный байт STM32 ждал подтверждения приема этого байта в виде ответного байта со стороны STM8S

DarkNet - блог о темной стороне интеренета. @darknets

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

Как правило слейв без определенной команды отправляет или статус или 0xFF Их можно просио игнорировать

Наладил обмен на поллинге между STM32 и STM8S, работает. Но все равно стабильность зависит от медленного устройства, если пригрузить STM8S, уже не успевает обрабатывать.

Так сам спи не медленный, просто не успевает обработаться. Если ввести подтверджение, то только хуже станет

Уже думаю над асинхронным протоколом, чтобы на каждый отправленный байт STM32 ждал подтверждения приема этого байта в виде ответного байта со стороны STM8S

может лучше i2c? там клок стретчинг искаропки есть.

Он ужасен, медленный ппц

Так сам спи не медленный, просто не успевает обработаться. Если ввести подтверджение, то только хуже станет

да, скорость снизится, но гарантированно будет успевать принимать при любой загруженности STM8S

Во всяком случае дисплей 20*4 пересовать на 100кГц занимает больше секунды

дисплей да, у меня со слейвами обмен запрос/ответ, максимум 128 байт что запрос что ответ

может лучше i2c? там клок стретчинг искаропки есть.

что за клок стретчинг?

да, скорость снизится, но гарантированно будет успевать принимать при любой загруженности STM8S

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

но гарантированно примет, а сейчас мастер отправил и ждет от слейва ответа. А слейв может не успеть принять и ничего не ответит

что за клок стретчинг?

слейв может дать понять мастеру что он не успевает пережевывать то что тот шлет

https://stackoverflow.com/questions/24862372/i2c-slave-clock-stretching

но гарантированно примет, а сейчас мастер отправил и ждет от слейва ответа. А слейв может не успеть принять и ничего не ответит

Не путай прием с обработкой

хорошо - гарантированно успеет принять в буфер в программе

в стмовском и2ц это реализовано прижиманием scl пока не отработает прерывание

а не в буфер самого SPI

сделай паузы между отправками, на частоту передачи это не повлияет (клок), но даст времени для обработки

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

хорошо - гарантированно успеет принять в буфер в программе

дма нету чтоб не возиться с прерываниями?

хорошо - гарантированно успеет принять в буфер в программе

а времени для рабоиы с данными всеравно не останется. Кста, у стм8 есть дма?

подстраивать паузы под самый медленный?

подстраивать паузы под самый медленный?

под тот с которым щас общаешься

STM8S003 - нет

если общаешься с обоими сразу - то под самый медленный, да

в линуксе например частота клока для каждого слейва отдельно задается

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

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

но как-то ненадежно выглядит

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

а вариант с подтверждением приема каждого байта?

мастер отправил байт к примеру 0x47 и до отправки следующегшо байта ждет от слейва 0x47

Даже если взять в пример пеку, вроде мощный проц, но я умудрялся челу подвесить пк просто отправляя данные по уарт на 115200 без пауз

мастер отправил байт к примеру 0x47 и до отправки следующегшо байта ждет от слейва 0x47

в два раза уменьшает пропускную способность

ну а паузы тоже уменьшат

Даже если взять в пример пеку, вроде мощный проц, но я умудрялся челу подвесить пк просто отправляя данные по уарт на 115200 без пауз

я умудрялся повесить пеку уровнив пассатижи на клавиатуру

мастер отправил байт к примеру 0x47 и до отправки следующегшо байта ждет от слейва 0x47

Слей же не умеет сам говорить, а если ты начнешь клок дергать, то это передача будет

а вариант с подтверждением приема каждого байта?

да возьми ты уже и2ц

там и асинхронность, и подтверждения.

слейв примет байт и отправил такой же в качестве подтверждения

там и асинхронность, и подтверждения.

Это только стм'овская фишка подтверждение? Оно не описано в стандарте на и2ц?

Это только стм'овская фишка подтверждение? Оно не описано в стандарте на и2ц?

нет, стандартная. http://i2c.info/wp-content/images/i2c.info/command.gif

уже сделано под SPI, I2C придется программный лепить

слейв примет байт и отправил такой же в качестве подтверждения

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

Что за данные, требующие большой скорости?

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

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

много слейвов и нужно их как можно чаще оправшивать

много слейвов и нужно их как можно чаще оправшивать

CS я так понял нет?

есть

SPI же заложен

У каждого слэйва свой cs подведен?

да

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

так это же нарушит работу SPI, CS там же что-то аппаратно включает

нет

то есть, не обязательно

можно смуксить его как гпио и дергать руками как угодно

там а зачем он тогда вообще нужен?

для SPI

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

чтоб слейв понимал что та болтовня что щас идет на MOSI/SCK - это для него

тоже вариант

пока заложу в настройки каждого слейва клок и значения пауз

это "понимание" можно сделать как хардварно (замуксив ногу на контроллер SPI), либо софтварно (замуксив как гпио, и например включая спи в хендлере прерывания его дрыганья)

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

"замуксив ногу на контроллер SPI" расшифруй

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

Тогда подтверждение по cs или и2ц

"замуксив ногу на контроллер SPI" расшифруй

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

Т.е. начинаем работу как обычно, мастер прижимает слейв к земле, отправляет первый байт и переводит cs в режим входа с подтяжкой к земле и ждет пока слейв вход не дернет в высокий уровень

Т.е. начинаем работу как обычно, мастер прижимает слейв к земле, отправляет первый байт и переводит cs в режим входа с подтяжкой к земле и ждет пока слейв вход не дернет в высокий уровень

да, типа того.

А вот в момент когда слейв дернет в высокий уровень, SPI самого слейва не посчитает что работа закончена и что-то там выключит?

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

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

а тебе точно-точно надо подтверждать прям каждый байт? потому что у меня когда-то стмка (32f1) без особых проблем принимала посылки в десяток-сотню байт на 10мгц и не давилась.

без стикеров, непрошенной рекламы и игр в русский форум оформляйте вопрос в одно сообщение вопросы со словом «кто» игнорируются don't ask for ask интересно. сколько ещё будете обсуждать одно и тоже?

а тебе точно-точно надо подтверждать прям каждый байт? потому что у меня когда-то стмка (32f1) без особых проблем принимала посылки в десяток-сотню байт на 10мгц и не давилась.

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

32f1 на какой частоте работала?

у STM8S - 16 МГц

24мгц

в даташите stm32f1 написано что частота клока в слейв моде может быть до 12мгц то есть если слать сплошным потоком - это ~600нс на байт interrupt latency у cortex-m3 - 12 циклов на входе, 12 на выходе, это ~1мкс. то есть на максимальной скорости оно работать на прерываниях не должно и не будет, но с дма тупо сложить в память можно успеть. а лучше конечно уменьшить частоту на порядок.

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

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

сделать *buf++ = SPI_DR не успевает? что-то я с трудом верю.

Уже думаю над асинхронным протоколом, чтобы на каждый отправленный байт STM32 ждал подтверждения приема этого байта в виде ответного байта со стороны STM8S

Danil: стандартные страдания получение данных по запросу через SPI детектед. Стандартное решение #1: дополнительный провод от слейва к мастеру для сигнала готовности данных. Стандартное решение #2: опрос слейва после таймааута гарантированной готовности данных. Стандартное решение #3: Поллинг слейва на предмет готовности данных. Стандартный вариант #4: Использование другого интерфейса - I2C, UART etc.

написал уже давно про твои грабли с опросом слейвов по SPI

Данил, спасибо за развернутый ответ. Но ты пишешь в общем, а дъявол в деталях.

всё едят этот кактус, только каждый по своему

вариант #1 - нужен ещё 1 провод от слейва до мастера по которому будешь сигналить, что ответ готов

"Стандартное решение #1: дополнительный провод от слейва к мастеру для сигнала готовности данных. " СS в этом качестве можно использовать или собьет механизм работы SPI слейва?

"Стандартное решение #1: дополнительный провод от слейва к мастеру для сигнала готовности данных. " СS в этом качестве можно использовать или собьет механизм работы SPI слейва?

Может в ардуину? Ибо до тебя ещё недели две доходить будет !?

вариант #2 - отправил пакет на слейв и ждёшь гарантированное время, за которое самый тупой слейв все обработает и подготовит ответ. после этого сливаешь пакет со слейва в мастер

вариант #3 постоянно анализировать что выдает слейв в момент передачи байта - если там не сигнал "все готово" то опрашиваем дальше. Но это будет работать только если сделаешь некий командный протокол поверх SPI

слейв принимает мусор если быстро сыпется от мастера

в итоге слейв не видит запроса

Короче, я всё. Я пытался объяснить уже по всякому, но ты не въезжаешь в SPI пока

В анаохию, рравда

ты не отвечаешь на конкретные вопросы, а излагаешь теорию

слейв принимает мусор если быстро сыпется от мастера

ээ так может у тебя приходит мусор? осцилом смотрел?

не смотрел

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