Форум по операционной системе GNU/Linux и свободному программному обеспечению
Текущее время: 20 мар 2019, 12:38

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 30 ]  На страницу 1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: периферийные шины
Непрочитанное сообщениеДобавлено: 31 окт 2018, 20:02 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11636
Откуда: Харьков
Меня в этом смысле интересуют а). I²C и б). SPI ... (возможно, но не очень, RS-485, Modbus, CAN) , т.е. шины, а). на которые можно без дополнительной работы паяльником подключать периферийные устройства, б). чтобы производилось множество таких устройств в). низкой стоимости.

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

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


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
 Заголовок сообщения: Re: периферийные шины
Непрочитанное сообщениеДобавлено: 31 окт 2018, 20:11 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11636
Откуда: Харьков
Olej писал(а):
Меня не интересует аппаратная и протокольная часть (т.е. как работают протоколы), а только то, как их использовать из Linux ... чаще всего это одноплатные ARM компьютеры.

1-я ссылка - с форума Orange Pi - i2c или SPI.
Откуда почерпнём, что на основе только эмпирических экспериментов:
- без всяких аппаратных фокусов...
- SPI обеспечивает дальность до 20 метров...
- I²C - гарантировано 3-5 метров...
- с питанием устройств от внешних источников дальность может быть больше.

[url=https://ru.wikipedia.org/wiki/I²C]I²C[/url] позволяет:
- 100 кбит/с
- до 112 свободных адресов для подключения периферии на одну шину.
Цитата:
Изображение


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


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
 Заголовок сообщения: Re: периферийные шины
Непрочитанное сообщениеДобавлено: 24 ноя 2018, 17:59 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11636
Откуда: Харьков
Код:
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)
— адрес чипа
— адрес регистра
— значение регистра


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
 Заголовок сообщения: Re: периферийные шины
Непрочитанное сообщениеДобавлено: 24 ноя 2018, 18:06 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11636
Откуда: Харьков
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: -- -- -- -- -- -- -- --                         


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
 Заголовок сообщения: Re: периферийные шины
Непрочитанное сообщениеДобавлено: 26 ноя 2018, 14:22 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11636
Откуда: Харьков
Выше показанное - это был Orange Pi / Armbian.
Но и в Rapsberry Pi с i2cdetect та же история: и с установкой и с использованием...


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
 Заголовок сообщения: Re: периферийные шины
Непрочитанное сообщениеДобавлено: 26 ноя 2018, 14:26 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11636
Откуда: Харьков
Olej писал(а):
Но и в Rapsberry Pi с i2cdetect та же история: и с установкой и с использованием...

Хорошая статья о использовании устройств на I²C из кода C : I2c в Linux из пространства пользователя


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
 Заголовок сообщения: Re: периферийные шины
Непрочитанное сообщениеДобавлено: 19 фев 2019, 12:54 
Не в сети
Интересующийся

Зарегистрирован: 24 ноя 2012, 20:49
Сообщения: 5
Здравствуйте!
Не могли бы вы поделиться своим собственным опытом использования SPI в Linux и на голом железе?

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

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


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
 Заголовок сообщения: Re: периферийные шины
Непрочитанное сообщениеДобавлено: 19 фев 2019, 20:43 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11636
Откуда: Харьков
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.


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
 Заголовок сообщения: Re: периферийные шины
Непрочитанное сообщениеДобавлено: 22 фев 2019, 20:50 
Не в сети
Интересующийся

Зарегистрирован: 24 ноя 2012, 20:49
Сообщения: 5
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), где данная возможность, на мой вкус, более чем вычурная, грозит на больших скоростях пропуском данных и тд и тп.
А как думаете Вы?


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
 Заголовок сообщения: Re: периферийные шины
Непрочитанное сообщениеДобавлено: 24 фев 2019, 21:37 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11636
Откуда: Харьков
littlegene писал(а):

За ссылку спасибо. Я этого не видел.
Полностью это:
Обзор шины SPI и разработка драйвера ведомого SPI устройства для embedded Linux (Часть первая, обзорная)
Обзор шины SPI и разработка драйвера ведомого SPI устройства для embedded Linux (Часть вторая, практическая)
Немного смущает, что это 2011 год.


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 30 ]  На страницу 1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB
[ Time : 0.120s | 18 Queries | GZIP : On ]