Olej писал(а):Я думаю, что не только можно, но и нужно.
Благодарю.
Ситуация классическая, как я думаю. Удалось поднять, не сразу, spidev на Orange pi (win) и поиграться (соединив MOSI/MISO) через spidev_test (и spidev_fdx). Посмотреть, что на осциллографе: отправка, доставка, их параметры(частота, нужные задержки, умение ими регулировать трансферы) и оценить, что данный SPI-модуль на orange из опций работы драйвера умеет, а чего нет. Вроде бы, все что нужно по минимуму - есть.
Поскольку опыта с этим нет, от слова совсем, хотелось бы получить пожелания (в общих чертах), о том, как лучше всего построить протокол обмена с подключенным на другой стороне, находящимся в разработке контроллером, одна из функций которого - сбор внешних данных и доставка их по SPI в Linux из своего внутреннего буфера.
Поскольку точек зрения тут может быть несколько, хотелось бы получить рекомендации мастеров этого дела.
Итак, Linux SPI-Master тактирует все взаимодействие и ведет обмен c единственным внешним SPI-Slave (CS0)
Вопрос 1.
В статье
https://habr.com/en/post/123266/
я не нашел (и не понял) четкого разделения того момента, когда именно в Linux нужно писать протокольный драйвер уровня ядра. Те замечания (4 штуки), которые высказаны в адрес spidev, как мне кажется, совсем не критичны для нашего случая... (Но это может только кажется.)
Не могли бы пояснить, разрабатывали ли сами такой драйвер и в чем была его необходимость.
Вопрос 2.
Авторы драйвера spidev описывают пример применения SPI_IOC_MESSAGE(4).
* So for example one transfer might send a nine bit command (right aligned
* in a 16-bit word), the next could read a block of 8-bit data before
* terminating that command by temporarily deselecting the chip; the next
* could send a different nine bit command (re-selecting the chip), and the
* last transfer might write some register values.
OK!
В самом первом (из группы связанных трансферов) идет команда, по которой на SPI-Slave, грубо говоря, выставляются данные для отправки, "отбираемые" следующим трансфером?
Не могли бы вы прокомментировать этот момент. То есть SPI-Slave через DMA (или каким то иным образом) выставляет данные в "синхронном сдвиговом регистре"?
(Вообще, это не моя задача (и не мое профильное образование), и к сожалению, я мало что понял, читая mikroelektronika.com. Но это нужно для понимания принципов будущего обмена)
2.1 Должен ли пользовательский протокол указывать длину выставленных SPI-Slave данных, чтобы ближайший трансфер, забирая максимально возможную порцию, по этой длине мог определить, сколько фактически полезных данных было передано (принято). Каковы альтернативы. Иными словами хотелось бы знать, как разработчик программы на "голом железе" должен поступить в этом случае.
2.2.Хороша ли практика с использованием циклического буфера внешних данных на стороне SPI-Slave (HEAD-пишет новые данные в буфер, TAIL - отдает имеющиеся данные на SPI шину).
По-моему это самый простой и надежный способ организовать "производитель-потребитель"?
Вопрос 3.
Считаете ли вы целесообразным в такой простой схеме обмена использовать доставку какого-либо события (например о наличии все тех же данных на контроллере) - прямиком в Linux.
(по прерываниям на пинах "гребенки" (знаю, что в RaspberryPi это штатная возможность, а на апельсинках - проблемы) или другим доступным интерфейсам)
То есть в этом случае мы имеем гетерогенную среду (с большой долей инерционности Linux), где данная возможность, на мой вкус, более чем вычурная, грозит на больших скоростях пропуском данных и тд и тп.
А как думаете Вы?