SPI bus в виде задачи в RTOSe Опции

[lazarev andrey]

здрасьте народ.
недавно начал изучать freertos. кое как слабал usb устройство из примеров .
дошел в данный момент до описания обмена данными по SPI. по SPI данные и читаются и записываются, микросхем куча и все разные.
по сути: начинаю обмозговывать как бы описать обмен по SPI в виде отдельной задачи (или двух одна на чтение другая на запись).
вроде если переписать пример serial и comtest, то должно работать, только еще добавить обращение непосредственно к отдельной взятой микросхеме.

у кого какие мысли?
может у кого то есть уже реализованные варианты?

ЕСЛИ ТЕМА БРЕД -> ГРОХНИТЕ ЕЕ

[aaarrr]

Зачем в одну задачу увязывать работу с кучей разных микросхем? Делите сам SPI между разными задачами.

[lazarev andrey]

рассматриваю также и такой вариант. все относительно в этом мире

[Terminator]

Отдельная задача для SPI скорее всего будет бесполезной тратой ресурсов. Прислушайтесь к aaarrr

[Aurochs]

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

[Axel]

SPI - аппаратный ресурс, который "шарится" между различными задачами, поэтому отдельная SPI-задача может иметь смысл (ИМХО). Правда нормально это будет работать, если при этом не требуется перенастройки (скорость, полярность клока и т.д.).

[aaarrr]

SPI - аппаратный ресурс, который "шарится" между различными задачами, поэтому отдельная SPI-задача может иметь смысл (ИМХО).

Странный вывод. SPI-задача может иметь смысл, например, если не хочется блокировать вызывающую задачу при отсутствии DMA (не частый случай, прямо скажем). А вот зачем создавать ее на пустом месте, когда можно и так замечательно расшарить ресурс mutex'ами - не понимаю.

[zltigo]

когда можно и так замечательно расшарить ресурс mutex'ами - не понимаю.

Когда ресурс занимается минимальным действием по "байт переслать" в симплексе, то можно и mutex. Если за работой с SPI стоит протокол, то отдельная задача занимающаяся обслуживанием SPI совершенно естественна. Кроме прикрытия SPI mutex-ами, во многих случаях естественнее смотрится очередь сообщений/указателей на сообщения. И критические секции имеют право на жизнь тоже. Варианты.....

[aaarrr]

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

Для SPI это, пожалуй, и составляет большинство применений.

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

Протокол обычно стоит за чем-то, висящим на SPI. Тогда работу с этим "чем-то" логично вынести в отдельную задачу, оставив сам SPI на более низком уровне.

Кроме прикрытия SPI mutex-ами, во многих случаях естественнее смотрится очередь сообщений/указателей на сообщения. И критические секции имеют право на жизнь тоже. Варианты.....

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

[zltigo]

Для SPI это, пожалуй, и составляет большинство применений.

Или нет. У меня за SPI "микросхемы" редко, все больше FPGA, да другие контроллеры.

Протокол обычно стоит за чем-то, висящим на SPI. Тогда работу с этим "чем-то" логично вынести в отдельную задачу, оставив сам SPI на более низком уровне.

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

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

Очередь по сложности нефатально отличается от мютекса, а в конкретно поминаемом случае FreeRTOS вообще не отличается.

[aaarrr]

Или нет. У меня за SPI "микросхемы" редко, все больше FPGA, да другие контроллеры.

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

Хочу только заметить, что у топикстартера "микросхем куча и все разные".

Очередь по сложности нефатально отличается от мютекса, а в конкретно поминаемом случае FreeRTOS вообще не отличается.

Разница в том, что очередь должен кто-то обслуживать.

[zltigo]

Хочу только заметить, что у топикстартера "микросхем куча и все разные".

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

Разница в том, что очередь должен кто-то обслуживать.

Вызывающая передачу задача и обработчик события завершения передачи.

[aaarrr]

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

Только не надо доводить до абсурда. Откуда такие крайности? Или у вас на SPI единственная FPGA с разлапистым протоколом, или "непойми чего". Другие варианты не рассматриваете?
В общем случае работа с SPI сводится к передаче и приему N байт с предварительной установкой и последующим снятием CS, мьютекс тут как раз на месте.

[zltigo]

Или у вас на SPI единственная FPGA с разлапистым протоколом, или "непойми чего". Другие варианты не рассматриваете?

Рассматриваю - кучка контроллеров с похожими, или одинаковыми протоколами.

В общем случае работа с SPI сводится к передаче и приему N байт с предварительной установкой и последующим снятием CS, мьютекс тут как раз на месте.

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

[aaarrr]

Рассматриваю - кучка контроллеров с похожими, или одинаковыми протоколами.

Хорошо, давайте рассмотрим случай, когда на шине одновременно присутствуют устройство с протоколом (например, SD/MMC карта в SPI-режиме) и без (например, 25-я еепромка для хранения каких-нибудь мелочей). Что будем делать?

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

Да имейте же меру в упрощениях и вырождениях! Это верно, только если слейв один и достучатся до него пытается только одна задача.

[zltigo]

Хорошо, давайте рассмотрим случай, когда на шине одновременно присутствуют устройство с протоколом (например, SD/MMC карта в SPI-режиме) и без (например, 25-я еепромка для хранения каких-нибудь мелочей). Что будем делать?

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

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

С чего-бы это вдруг? Две задачи проверяют занятость общей части железа обслуживающего несколько слейвов и не лезут в него, пока занято. Если в ту-же '25' лезут изредка, а SD нагружен изрядно, то можно уже и подумать, а дергать-ли каждый раз системный мютекс при работе с SD, или пусть обращение изредка тупенько поспит/повисит на сканировании железного (или банального софтового) флага.

[aaarrr]

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

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

Если в ту-же '25' лезут изредка, а SD нагружен изрядно, то можно уже и подумать, а дергать-ли каждый раз системный мютекс при работе с SD, или пусть обращение изредка тупенько поспит/повисит на сканировании железного (или банального софтового) флага.

А почему бы не дергать? С SD работа идет здоровыми блоками, дерганье мьютекса ни на чем не скажется. А спать/висеть на сканировании флага - как-то не комильфо.


Конечно, каждый из рассмотренных подходов имеет право на существование в своих условиях. Но если вернуться к теме, то увязывание работы "кучи разных микросхем" в одну задачу в общем случае не представляется правильным. Так же, например, как увязывание 25 и SD.

[zltigo]

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

Eстественно, на железо надо смотреть - оно не названо.

А почему бы не дергать?

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

А спать/висеть на сканировании флага - как-то не комильфо.

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

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

О чем и речь

[lazarev andrey]

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

по сути то, да. SPI у меня для тупых задач, никаких там протоколов, никаких огромных объемов передаваемых данных.
это уж я как обычно задумался над тем, а как бы вот так скрестить много устройств на шине под управлением РТОСа.
у меня один мастер - МК. и куча слэйвов, там отличие только в том, что в парочке надо поменять полярность тактирующего сигнала, да для удобства количество бит за передачу.

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

[SergeiCh]

работают флаги в железе.

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