Я пытаюсь Грока, что «начинается транзакция» в библиотеке SPI. Это не имеет ничего общего с транзакциями, верно? Это больше похоже на определение канала для общения с одним удаленным устройством на шине, используя конкретный выбор, справа? Я не вижу ничего, что гарантирует атомность или любое другое свойство, обычно связанное с термином транзакции. Это даже не начинается с транзакции на автобусе. Так просто сбивает с толку имя?

Правильно, он настраивает «транзакцию». Это стандартный API Arduino:
https: // www.Ардуино.cc/en/reference/spibegintransaction

В любом случае мы расширяем/добавляем некоторые API:
https: // github.com/stm32duino/wiki/wiki/api#spi

Хорошо, теперь ты полностью смущен .

Я не Arduino Whiz, но, насколько я могу судить, SPI.Begin Transaction возвращается к Полу Стоффегену: https: // www.Dorkbotpdx.org/blog/paul/sp ... in_arduino и был специально создан для обеспечения атомных транзакций.

Код, который я читаю в ядре STM (a), не реализует какую-либо форму атома и (b), предоставляя (странно в моих глазах) автоматическое переключение настроек на основе PIN-кода CS, фактически способствуя использованию, которое работает Точно противостоять цели начала Arduino.

Я только что посмотрел на один из официальных ядер рук, и совершенно ясно, что смысл начала транзакции заключается в реализации атомичности (что означает этот термин, дух). Видеть https: // github.com/arduino/arduinocore- ... #L108-L119

Если я не упущу то, что я бы сказал, что в библиотеке SPI есть две ошибки: (1) это обеспечивает начало транзакции, но не в состоянии реализовать атомичность, и (2) оно реализует расширение API, которое не может работать после реализации атомности.

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

Что такое «IT -режим» и как он здесь актуален?

[тв - Пт 10 августа 2018 г. 5:14] - Если я не упущу то, что я бы сказал, что в библиотеке SPI есть две ошибки: (1) это обеспечивает начало транзакции, но не в состоянии реализовать атомичность, и (2) оно реализует расширение API, которое не может работать после реализации атомности.

Я вижу (1) - это проблема, но не то, как (2) было бы проблемой?

Насколько я вижу, расширение CSPIN просто обеспечивает внутреннее хранилище шипения, проиндексированное CSPIN. Атомность просто требует блокировки прерываний во время транзакции. Понятия не имею, почему они будут взаимоисключающими?

Разве главная/единственная цель передачи (PIN -код, ...) 'Набор функций, чтобы иметь возможность писать код, который в конечном итоге выполняет такие операции, как это:
SPISettings *s1(...), *s2(...); beginTransaction(PA10, s1); beginTransaction(PA11, s2); transfer(PA10, ...); transfer(PA11, ...);

Ах - ты немного щедрый с термином «атомность». Что касается API ARDIUUNO, это просто означает «отключить любые прерывания, которые могут нам на автобусе SPI».

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

Блокирующие прерывания обеспечат тот же уровень атомичности, что и стандартный API Arduino API.

[тв - Пт 10 августа 2018 г. 7:05] - Что такое «IT -режим» и как он здесь актуален?

Межрептивной режим.

Использование драйвера SPI HAL_SPI_TransmitReceive

Хм, я чувствую, что вы, ребята, расщепляете волосы здесь. Чрезвычайно ясно, что цель начала транзакции состоит в том, чтобы обеспечить какую -то атомность, и вы создаете расширения, которые полезны только в том случае, если они специально нарушают атомность. Это просто плохая практика.

@fpistm, независимо от того, используете ли вы прерывания со SPI, не является проблемой. Прочитайте оригинальную статью Пола (я связал с ней). Прерывание выходит на штифт GPIO с радио. Обработка прерывания требует разговора с радио через SPI. Но основной петлей также использует SPI, поэтому, если прерывание по радио поступает, в то время как основной цикл использует SPI, он все испортит. Не имеет ничего общего с использованием прерываний для устройства SPI.

[тв - Пт 10 августа 2018 г. 8:07] - Хм, я чувствую, что вы, ребята, расщепляете волосы здесь. Чрезвычайно ясно, что цель начала транзакции состоит в том, чтобы обеспечить какую -то атомичность, и вы создаете расширения, которые полезны только в том случае, если они специально нарушают атомность. Это просто плохая практика.

Он не нарушает атомичность - если будет реализовано блокировка прерывания, можно было бы использовать стандартные вызовы API, и они будут функционировать точно так же, как библиотеки Arduino.

Материал CSPIN обеспечивает альтернативу традиционному API и на самом деле будет работать намного лучше в 99% вариантов использования (все, что не использует SPI от прерываний), чем текущий API. Но это только потому, что текущий API вряд ли когда -либо используется правильно. Эндранзикция редко называется, и начинает транзакция не так часто называют достаточно часто...

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

Вы можете подать вопрос для этого, чтобы отслеживать его.

Материал CSPIN обеспечивает альтернативу традиционному API и на самом деле будет работать намного лучше в 99% вариантов использования (все, что не использует SPI от прерываний), чем текущий API. Но это только потому, что текущий API вряд ли когда -либо используется правильно. Эндранзикция редко называется, и начинает транзакция не так часто называют достаточно часто... У вас есть пример, который использует материал CSPIN? Или какой-то псевдокод, который показывает свои преимущества?

Wrt "работать намного лучше", вы смотрели на реализацию? Для настройки любых настроек изменение SPI_INIT называется, что является довольно длинной функцией, которая получает каждый бит регистра от первых принципов, так сказать, и вызывает HAL на загрузку. Если бы вы заменили этот материал на какой -то оптимизированный код, вы бы пошли быстрее. Если вы хотите кэшировать вещи, как насчет добавления некоторых частных переменных, которые он подсказывает класс, где конфигурация регистра сохраняется, чтобы повторное введение-это всего лишь пара записей в регистрах с уже вычисленными и проверенными значениями? Ничего из этого не нужно ввести странные расширения API...

[тв - Пт 10 августа 2018 г. 14:44] - Материал CSPIN обеспечивает альтернативу традиционному API и на самом деле будет работать намного лучше в 99% вариантов использования (все, что не использует SPI от прерываний), чем текущий API. Но это только потому, что текущий API вряд ли когда -либо используется правильно. Эндранзикция редко называется, и начинает транзакция не так часто называют достаточно часто... У вас есть пример, который использует материал CSPIN? Или какой-то псевдокод, который показывает свои преимущества?

Wrt "работать намного лучше", вы смотрели на реализацию? Для настройки любых настроек изменение SPI_INIT называется, что является довольно длинной функцией, которая получает каждый бит регистра от первых принципов, так сказать, и вызывает HAL на загрузку. Если бы вы заменили этот материал на какой -то оптимизированный код, вы бы пошли быстрее. Если вы хотите кэшировать вещи, как насчет добавления некоторых частных переменных, которые он подсказывает класс, где конфигурация регистра сохраняется, чтобы повторное введение-это всего лишь пара записей в регистрах с уже вычисленными и проверенными значениями? Ничего из этого не нужно ввести странные расширения API...

Я никогда не видел, чтобы этот API использовал... Рассмотрим следующий сценарий:

Сенсовый экран TFT, подключенный к одной шине SPI, но с отдельными контактами CS для дисплея и контроллера сенсорного экрана.

1) Использование API CSPIN

Библиотека TFT и Touch Library Оба называют SPI.BegintRansaction () из их функций begin (), указав их булавки и настройки CS.

В будущем, когда из любой библиотеки вызывается какой -либо метод считывания/записи/передачи SPI, этот метод SPI проверяет, если он такой же CS PIN. Если нет, то spi_init () вызывается для изменения настройки для запрошенного PIN -кода CS перед выполнением операции IO.

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

2) В традиционном API.

Обе библиотеки всегда Позвоните в BeginTransaction () перед выдачей чтения/записи автобуса. begintransaction () всегда вызывает spi_init (). Так что даже если вы делаете несколько TFT.print () вызовы, затем один вызов touch (), spi_init () вызывается для каждого вызова библиотеки.

(1), очевидно, намного более эффективно, так как позволяет библиотеке SPI повторно использовать текущие настройки для каждого TFT.print () вызов, если не призван прикосновение ().

Да, поэтому, если библиотека SPI просто кэшировала последний использованный PIN -код CS и связанные с ним настройки, это было бы не менее эффективным.
Кроме того, вы точно подтвердили мое подозрение, то есть в том, что если начало транзакции/эндранзакции было внедрено правильно и фактически отключено прерывания, то прерывания будут отключены на всю жизнь вашего эскиза. Это может быть приятным взломом в случае вашего гипотетического наброска, но очень плохо для «официального ядра STM Arduino Core».
Концепция регистрации ряда шипений, чтобы их можно было предварительно оценить, а конкретные значения регистра кэшировали, а затем применение их только при необходимости является хорошим, но смешивание этого с началом транзакции ошибочно и просто неправильно. Извините за то, что я тупой, но у меня нет других слов для этого.

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

В случае SPI, BeginTransaction () только фактически отмечает начало атомной транзакции, если использование Enterrupt () называется первым. Если нет, то он используется только для настройки настройки SPI. Если вам придется просмотреть все различные библиотеки, которые используют SPI, вы обнаружите, что подавляющее большинство просто вызовов начало транзакции один раз, чтобы настроить порт SPI и даже не беспокоиться о конечном транзакциях.

Да, это плохо, но должно быть сохранено для совместимости.

Модификация API CSPIN хорошо работает в этом контексте, но, поскольку это специфична для STM32 (и HAL), она вряд ли когда -либо используется.

Прерывание вещи Пол С. пытался решить, - это скорее проблема, когда у вас есть только одно периферийное устройство SPI. Если у вас есть чип, у которого есть несколько периферийных устройств SPI, достаточно легко поместить прерывание устройства SPI SPI Happy Network и поставить интерфейс SDCARD SPI на другой. Проблема решена. Они не конфликтуют, и вам лучше использовать более продвинутое оборудование.

О да, CC3000, с которым он пытался иметь дело, большинство людей потеряли интерес, по нескольким причинам, но в основном с внедрением ESP8266, по крайней мере, для любителей.

Хейсан: Похоже, что ваш аргумент в том, что API Arduino настолько ужасен, что добавление еще одного плохо продуманного API-это хорошая вещь... Кроме того, вы пишете, что API редко используется правильно, что сильно отличается от того, что API ужасен. Пол умный парень, и он разработал API транзакции.
Рик: Вы утверждаете, что, поскольку существует другое решение, может также утолкнуть реализацию API и добавить запутанное плохо изучаемое ненужное расширение сверху?

Хотя я думаю, что сторонние ядра должны попытаться быть верным тому, что делает Arduino, Arduino Core - это движущаяся цель, которая изменяется по их прихоти и не имеет реальной спецификации, кроме веб -страниц.

Вы на самом деле используете эту функцию? Я думаю, что выполнение транзакций SPI в обработчике прерываний - очень глупый подход.

Оригинальный дизайн/идея транзакций SPI мог быть хорошим. Но, к сожалению, теперь Begin Transaction () - это рекомендуемый способ установить параметры SPI, независимо от того, намерены ли вы использовать транзакции или нет.

Вы используете дополнительный вызов с использованием Enterrupp. Это определение API, и это то, что ядра должны попытаться реализовать.

Расширения CSPIN API работают в рамках этой семантики. Хотя может быть лучше создать совершенно новый API с соответствующим образом названным функциями, вероятно, лучше придерживаться семантики, с которыми разработчики знакомы. Так что просто добавьте CSPIN в качестве первого аргумента ко всем вашим существующим вызовам SPI, и они внезапно становятся более эффективными приказом. Никаких других изменений или новых API для изучения.

[Рик Кимбалл - Пт 10 августа 2018 г. 20:07] - ...Вы на самом деле используете эту функцию? Я думаю, что выполнение транзакций SPI в обработчике прерываний - очень глупый подход.

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

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