Страница 1 из 3

периферийные шины

Добавлено: 31 окт 2018, 20:02
Olej
Меня в этом смысле интересуют а). I²C и б). SPI ... (возможно, но не очень, RS-485, Modbus, CAN) , т.е. шины, а). на которые можно без дополнительной работы паяльником подключать периферийные устройства, б). чтобы производилось множество таких устройств в). низкой стоимости.

Меня не интересует аппаратная и протокольная часть (т.е. как работают протоколы), а только то, как их использовать из Linux ... чаще всего это одноплатные ARM компьютеры.

P.S. Интерфейсы I2c и SPI вовсю используются в Arduino, так что на их ресурсах можно почерпнуть множество любопытной информации.

Re: периферийные шины

Добавлено: 31 окт 2018, 20:11
Olej
Olej писал(а): Меня не интересует аппаратная и протокольная часть (т.е. как работают протоколы), а только то, как их использовать из Linux ... чаще всего это одноплатные ARM компьютеры.
1-я ссылка - с форума Orange Pi - i2c или SPI.
Откуда почерпнём, что на основе только эмпирических экспериментов:
- без всяких аппаратных фокусов...
- SPI обеспечивает дальность до 20 метров...
- I²C - гарантировано 3-5 метров...
- с питанием устройств от внешних источников дальность может быть больше.

I²C позволяет:
- 100 кбит/с
- до 112 свободных адресов для подключения периферии на одну шину.
Изображение
SPI, Serial Peripheral Interface:
Простота аппаратной реализации:
- более низкие требования к энергопотреблению по сравнению с I²C и SMBus;
- возможно использование в системах с низкостабильной тактовой частотой;
- ведомым устройствам не нужен уникальный адрес, в отличие от таких интерфейсов, как I²C, GPIB или SCSI.
Изображение
Изображение

Re: периферийные шины

Добавлено: 24 ноя 2018, 17:59
Olej

Код: Выделить всё

olej@orangepione:~$ aptitude search i2c-tools
p   i2c-tools                                           - heterogeneous set of I2C tools for Linux                     

Код: Выделить всё

olej@orangepione:~$ sudo apt-get install i2c-tools
[sudo] password for olej: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Suggested packages:
  libi2c-dev python-smbus
Recommended packages:
  read-edid
The following NEW packages will be installed:
  i2c-tools
0 upgraded, 1 newly installed, 0 to remove and 48 not upgraded.
Need to get 57.6 kB of archives.
After this operation, 196 kB of additional disk space will be used.
Get:1 http://cdn-fastly.deb.debian.org/debian stretch/main armhf i2c-tools armhf 3.1.2-3 [57.6 kB]
Fetched 57.6 kB in 0s (114 kB/s)
Selecting previously unselected package i2c-tools.
(Reading database ... 82849 files and directories currently installed.)
Preparing to unpack .../i2c-tools_3.1.2-3_armhf.deb ...
Unpacking i2c-tools (3.1.2-3) ...
Setting up i2c-tools (3.1.2-3) ...
Processing triggers for man-db (2.7.6.1-2) ...
olej@orangepione:~$ uname -a
Linux orangepione 4.14.18-sunxi #24 SMP Fri Feb 9 16:24:32 CET 2018 armv7l GNU/Linux
Работа с i2c
данный пакет имеет программы
i2cdetect — проверка подключенных устройств — выводит адреса подключенных устройств
i2cdump — снятие дампа данных
i2cget — получение значения нужного регистра в подключенном устройстве. Опрашивается в формате i2cget
i2cset — запись значения в регистр подключенного устройства, команда в формате i2cset
где:
— i2c шина (0 или 1)
— адрес чипа
— адрес регистра
— значение регистра

Re: периферийные шины

Добавлено: 24 ноя 2018, 18:06
Olej
Olej писал(а):
данный пакет имеет программы
i2cdetect — проверка подключенных устройств — выводит адреса подключенных устройств
i2cdump — снятие дампа данных
i2cget — получение значения нужного регистра в подключенном устройстве. Опрашивается в формате i2cget
i2cset — запись значения в регистр подключенного устройства, команда в формате i2cset
где:
— i2c шина (0 или 1)
— адрес чипа
— адрес регистра
— значение регистра

Код: Выделить всё

olej@orangepione:~$ sudo i2cdetect -l
i2c-0	i2c       	DesignWare HDMI                 	I2C adapter

Код: Выделить всё

olej@orangepione:~$ sudo  i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: 30 31 -- -- -- -- -- 37 -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: 50 -- -- -- -- 55 -- -- -- -- 5a -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         

Re: периферийные шины

Добавлено: 26 ноя 2018, 14:22
Olej
Выше показанное - это был Orange Pi / Armbian.
Но и в Rapsberry Pi с i2cdetect та же история: и с установкой и с использованием...

Re: периферийные шины

Добавлено: 26 ноя 2018, 14:26
Olej
Olej писал(а):Но и в Rapsberry Pi с i2cdetect та же история: и с установкой и с использованием...
Хорошая статья о использовании устройств на I²C из кода C : I2c в Linux из пространства пользователя

Re: периферийные шины

Добавлено: 19 фев 2019, 12:54
littlegene
Здравствуйте!
Не могли бы вы поделиться своим собственным опытом использования SPI в Linux и на голом железе?

Достаточно ли использования spidev или пришлось писать что-то дополнительно/взамен.
Далее, каковы особенности и риски использования SPI (и spidev) при достаточно интенсивном обмене между Linux (через гребенку на одноплатнике) и подключенным на другой стороне микроконтроллером, использующим свой SPI модуль в режиме slave (требования к его ПО, правильной буферизации, управлению потоком данных, наиболее предпочтительные варианты протоколов обмена, и т.п.).

В общем, можно ли обсуждать здесь эти вопросы (если таковые возникнут). Или лучше подыскать другое место в сети.

Re: периферийные шины

Добавлено: 19 фев 2019, 20:43
Olej
littlegene писал(а): Не могли бы вы поделиться своим собственным опытом использования SPI в Linux и на голом железе?
Я прямо сейчас, около года уже, не подходил к одноплатникам ... по крайней мере, к их аппаратным ресурсам - только разрабатывал и разрабатываю по удалённому VPN/SSH конкретному заказчику системы компьютерного зрения на таких одноплатниках.
Поэтому не могу быстро поднять свои записи по экспериментам с периферией.
littlegene писал(а): Достаточно ли использования spidev или пришлось писать что-то дополнительно/взамен.
Далее, каковы особенности и риски использования SPI (и spidev) при достаточно интенсивном обмене между Linux (через гребенку на одноплатнике) и подключенным на другой стороне микроконтроллером, использующим свой SPI модуль в режиме slave (требования к его ПО, правильной буферизации, управлению потоком данных, наиболее предпочтительные варианты протоколов обмена, и т.п.).

В общем, можно ли обсуждать здесь эти вопросы (если таковые возникнут). Или лучше подыскать другое место в сети.
Я думаю, что не только можно, но и нужно.
У меня на рабочем столе даже лежит пара готовых к работе одноплатников: Orange Pi One и Rapsberry Pi 2. И полная коробка периферийной мелочёвки, закупавшейся ещё для Arduino.

Если будет хоть один желающий обсуждать эксперименты - я тут же оживлю это хозяйство и повторю эксперименты.

Есть ещё 2 ресурса, посвящённых а). Orange Pi и б). Arduino.ru (и ещё здесь Форум arduino.ua) - где можно почерпнуть интересные детали по SPI.

Re: периферийные шины

Добавлено: 22 фев 2019, 20:50
littlegene
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), где данная возможность, на мой вкус, более чем вычурная, грозит на больших скоростях пропуском данных и тд и тп.
А как думаете Вы?

Re: периферийные шины

Добавлено: 24 фев 2019, 21:37
Olej