Linux работа с i2c

i2c-tools и десятибитные адреса

Утилиты из i2c-tools поддерживают только стандартные 7-битные адреса или ещё и расширенные 10-битные?

В коде i2ctransfer находится такой комментарий:

В документации ядра тоже сказано, что поддержки нет:

Но в этой статье описаны какие-то манипуляции с i2c-tools, читать и писать 10-битные адреса (i2c-tools, похоже, не патченый). Но я так и не могу понять, как мне прочитать два байта с условного устройства 0x30 по адресу 0x5010 . Судя по описанию формата адреса, его нужно сформировать определённым образом, но в статье на вики ST всё как-то очень просто. Помогите, пожалуйста, мне тупому составить правильную команду!

Почему на материнках не выводят i2c?

Скажем чтобы подключать датчики температуры, управление вентиляторами, итп.

Как непрерывно получать данные от АЦП в Linux

Есть небольшой скрипт Python 3 который читает I2C АЦП, он оцифровывает датчик, частота дискретизации несколько килогерц, а я читаю несколько сотен раз в секунду и этого явно недостаточно.

Правильно я понимаю, что даже если перепишу на Си (что совершенно не проблема) — не получу нужной частоты дискретизации?

400 кгц / 12 бит данные + адрес + паузы и так далее = килогерц 5-10 в теории выжать можно. Но вот в чем производить такое циклическое чтение?

Допустим, можно написать драйвер низкоуровневый поверх I2C — поможет? В теории, там и отклик быстрее будет и таймер точнее и всё прочее.

Как считать температуру с датчика TMP100, подключен через i2c переходник к компу.

К компу подключен переходник UMFT201XB для конвертирования из com порта в i2c данных. Датчик tmp100 по i2c общается. Нашел этот пример http://arduinolab.pw/index.php/2019/05/16/datchik-temperatury-tmp100/ Пробую как там послать команды через com порт так:

95 01 20 — конфигурация регистра 95 00 — reset регистра и пробую читать так 95 00 00 Правильно ли я это делаю, пытаюсь повторить тот пример для arduino.

FT2232C/D/H работа с I2C

Есть платка на базе Future Technology Devices International, Ltd FT2232C/D/H Dual UART/FIFO IC. Заявлена поддержка I2C. Как ее получить?

Втыкаю — /dev/i2c* не появляется новое. Есть некий ftdi_sio драйвер. Есть libftdi и даже pylibftdi как обертка для питошки.

До меня начинает доходить, что чуда не будет. Чип дает bitbang ногодрыжный интерфейс, а дальше ручками. Да, есть обертки, может есть pullup на алишной плате.

Чтобы получить I2c на FT2232C:

1. нужно bitbangить? 2) на всякий спрошу у опытных, а может снифер можно на этой штуке изобразить?

Может есть готовые программы или драйвер-обертки.

I2cdetect не видит устройство

Здравствуйте, не получается через команду i2cdetect определить устройства на встраиваемом модуле с процессором intel 3930, при этом если заменить тут же модуль с процессором на арме, то все видит. Также dmesg | grep i2c показывает строку slave address not acknowledged (7bit mode). Может вдруг кто подскажет что это значит?

Rust stm32 i2c slave

Не могу найти, есть ли всё таки сейчас в рамках rust-embedded (или rtfm) i2c slave.

Я хочу сделать i2c proxy, т.е. чтобы CPU ходил физически к одному устройству, думая, что там много разных.

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

Ощущение, что этот кусок не заимплементили и надо дописать чутка.

i2c на 64 битах

Посоны, у кого-нибудь i2c работает на 64 битах?

Ловлю вот это, когда java приложение пытаюсь запустить:

Та же система на 32 битах работает! Вот и вопрос, это косяк в драйвере или что-то нужно изменить в джава-приложении? Я в джаве лох, буду рад подсказкам. Есть ли там разница, собирается приложение под 32 или 64 jdk?

Аппаратные ключи — по итогам статьи из Хабра

Вот такая пришла идея, подцепить пару таких микросхем к распбери и организовать свой hsm.

Как определить, какому i2c интерфейсу какой hdmi/dvi/vga/dp порт соответствует?

Есть в директории /dev/ такие i2c:

/dev/i2c-0 /dev/i2c-1 /dev/i2c-2 /dev/i2c-3 /dev/i2c-4 /dev/i2c-5

Если вызвать команду xrandr —verbose то там будут перечислены всякие интерфейсы, типа

Нет клика/тапа в событиях от тачскрина

Привет. Есть sbc, Digi ConnectCore 6UL SBC Pro, к нему прицеплен по LVDS какой-то экран. К экрану прицеплен тачскрин с контроллером tsc2007, заведенный в sbc через i2c. На sbc установлен DIGI Embedded Yocto 2.6. В ядре добавлена поддержка тачскринов и поддержка tsc2007 (собран как часть ядра, не модуль). Тачскрин видится в системе и двигает курсор мыши при нажатии, но никогда не присылает события «нажатие/тап по экрану», только ABS_X, ABX_Y и ABS_PRESSURE, соответственно нажать ни на что нельзя, курсор просто ползает по экрану за пальцем. Тачскрин двигает курсор только при работе через evdev, через libinput не удалось заставить. xinput_calibrator так же не получает события о нажатии, поэтому калибровку пройти не могу. Положение пальца на эране в DE (matchbox) соответствует положению курсора, т.е. калибровка в принципе не нужна. ts_calibrator (или как там его) так же не видит нажатий, да еще и сильное различие между пальцем и откликом на экране (похоже, что в tslib, которую я никак не настраивал, границы тача указаны как 65535, а в evdev берутся с железа как 4095 или что-то в этом роде).

В device tree прописан примерно так:

Передача firmware по i2c

Подскажите названия/модели любых устройств подключаемых к пк, где фирмварь для них передается по i2c.

запилить проект

Всех приветствую.
Чего-то я последнее время как-то заскучал в связи с чем появилась идея маленькой движухи.

Регулярно появляются задачи по управлению чем либо через i2c/spi. При этом какого-то готового коробочного решения нет. Все время приходится выдумывать велосипед. С другой стороны есть готовые проприетарные решения в виде коробочки подключаемой по usb и набору библиотек и утилит. При этом такая комбинация как правило имеет весьма простую аппаратную часть и весьма изощренное ПО.
Вот и подумалось мне, а не запилить ли небольшой проект по реверсу такой простой железки, чтобы ее можно было ЛУТ-ом на коленке реплицировать и использовать фирмачное ПО.
Прямая аналогия с saleae логическим анализатором, который легко делается из отладки для «кипариса» и 7 байт в eeprom, при этом получаешь мощное ПО по анализу и декодированию обмена на цифровых шинах.
Это была присказка.

Теперь сказочка.
Есть у меня на время (но довольно не ограниченное) такая штука как aardvark i2c/spi: https://www.totalphase.com/products/aardvark-i2cspi/

Внутри там mega16 и ft245, ну и немного обвязки для всякой защиты от дурака и КЗ. Платка выглядит весьма простой, можно даже схемотехнику перерисовать без особых напрягов.
Соответственно, есть мысль эту коробочку клонировать на современном уровне с открытыми спеками и при этом сделать совместимой с официальным ПО. Соответственно ищутся желающие для участия в реализации «джастфолулз».
Я бы может и сам все запилил, но у меня к сожалению не очень со временем и есть вероятность, что рано или поздно коробочку заберут и не получится.
В целом задачу я вижу как легкую для схемотехника уровня ардуины и соответствующего программиста.
Свою задачу я вижу только как поставщик картинок платы и подробные дампы обмена между ПК и МК в различных вариантах. Ну и здоровая критика процесса и результат, а так же активного потребителя результата.
Я делал тут управлялку на ней для одного устройства весьма быстро и успешно. Аналогичная хрень на ft232h получилась немного кривой и не до конца понятой (хотя со своими задачами тоже справлялась).

Banana Pi BPI-M2 Ultra / BPI-M2 Berry armbian

У кого работает такая железка — отзовитесь. Есть пара вопросов по ядру.

Источник

I2c в Linux из пространства пользователя

Наконец дошли руки до i2c в raspberry pi. Шина i2c в Linux доступна из ядра и из пространства пользователя благодаря модулю i2c-dev.
Как работать с i2c устройствами в linux рассмотрим на примере часов реального времени DS1307.
У меня модуль Tiny I2C Clock.

Стоит модуль копейки, но мне с ним очень не фортануло. Получил бракованную плату. Под батарейкой 3 закороченные дорожки.

У часов есть такие регистры:

Дальше в памяти расположен RAM, который можно использовать под собственные нужды.
Не забываем включить i2c на raspberry. Для этого в файле /boot/config.txt раскоментируйте строки:

Для работы с i2c уже есть специальные утилиты i2c-tools.
Для установки на raspberry pi:

Теперь можно найти все устройства на шине 1:

Обнаружены часы и модуль eeprom памяти с той же платы.
Сосредоточимся на часах. Согласно карте регистров выше видим, что нас интерисуют 6 первых регистров.

Вычитаем данные устройства с адресом 0x68:

Также в наличии команда i2cget. Вычитаем 0 байт.

Это все очень весело и интересно, но мы же и сами программы писать умеем.
Почитаем 6 байт из i2c устройства.
Для этого открываем файл /dev/i2c-1 (или 0, если у вас старая малина).
Указываем адрес устройства (у меня 0x68)
Дабы установить указатель чтения в начало, нужно записать 0.
Читаем данные.

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

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

Готово.
Помните, что работа с большинством i2c устройств таким образом — сущий изврат! В linux уже есть готовые драйвера для большинства устройств. И вам не нужно изобретать велосипед. Но об этом в следующей статье. Там мы посмотрим как скормить эти часы linux ядру и драйверу ds1307.

Источник

Implementing I2C device drivers in userspace¶

Usually, I2C devices are controlled by a kernel driver. But it is also possible to access all devices on an adapter from userspace, through the /dev interface. You need to load module i2c-dev for this.

Each registered I2C adapter gets a number, counting from 0. You can examine /sys/class/i2c-dev/ to see what number corresponds to which adapter. Alternatively, you can run “i2cdetect -l” to obtain a formatted list of all I2C adapters present on your system at a given time. i2cdetect is part of the i2c-tools package.

I2C device files are character device files with major device number 89 and a minor device number corresponding to the number assigned as explained above. They should be called “i2c-%d” (i2c-0, i2c-1, …, i2c-10, …). All 256 minor device numbers are reserved for I2C.

C example¶

So let’s say you want to access an I2C adapter from a C program. First, you need to include these two headers:

Now, you have to decide which adapter you want to access. You should inspect /sys/class/i2c-dev/ or run “i2cdetect -l” to decide this. Adapter numbers are assigned somewhat dynamically, so you can not assume much about them. They can even change from one boot to the next.

Next thing, open the device file, as follows:

When you have opened the device, you must specify with what device address you want to communicate:

Well, you are all set up now. You can now use SMBus commands or plain I2C to communicate with your device. SMBus commands are preferred if the device supports them. Both are illustrated below:

Note that only a subset of the I2C and SMBus protocols can be achieved by the means of read() and write() calls. In particular, so-called combined transactions (mixing read and write messages in the same transaction) aren’t supported. For this reason, this interface is almost never used by user-space programs.

IMPORTANT: because of the use of inline functions, you have to use ‘-O’ or some variation when you compile your program!

Full interface description¶

The following IOCTLs are defined:

ioctl(file, I2C_SLAVE, long addr)

Change slave address. The address is passed in the 7 lower bits of the argument (except for 10 bit addresses, passed in the 10 lower bits in this case).

ioctl(file, I2C_TENBIT, long select)

Selects ten bit addresses if select not equals 0, selects normal 7 bit addresses if select equals 0. Default 0. This request is only valid if the adapter has I2C_FUNC_10BIT_ADDR.

ioctl(file, I2C_PEC, long select)

Selects SMBus PEC (packet error checking) generation and verification if select not equals 0, disables if select equals 0. Default 0. Used only for SMBus transactions. This request only has an effect if the the adapter has I2C_FUNC_SMBUS_PEC; it is still safe if not, it just doesn’t have any effect.

ioctl(file, I2C_FUNCS, unsigned long *funcs)

Gets the adapter functionality and puts it in *funcs .

ioctl(file, I2C_RDWR, struct i2c_rdwr_ioctl_data *msgset)

Do combined read/write transaction without stop in between. Only valid if the adapter has I2C_FUNC_I2C. The argument is a pointer to a:

The msgs[] themselves contain further pointers into data buffers. The function will write or read data to or from that buffers depending on whether the I2C_M_RD flag is set in a particular message or not. The slave address and whether to use ten bit address mode has to be set in each message, overriding the values set with the above ioctl’s.

ioctl(file, I2C_SMBUS, struct i2c_smbus_ioctl_data *args)

If possible, use the provided i2c_smbus_* methods described below instead of issuing direct ioctls.

You can do plain I2C transactions by using read(2) and write(2) calls. You do not need to pass the address byte; instead, set it through ioctl I2C_SLAVE before you try to access the device.

You can do SMBus level transactions (see documentation file smbus-protocol for details) through the following functions:

All these transactions return -1 on failure; you can read errno to see what happened. The ‘write’ transactions return 0 on success; the ‘read’ transactions return the read value, except for read_block, which returns the number of values read. The block buffers need not be longer than 32 bytes.

The above functions are made available by linking against the libi2c library, which is provided by the i2c-tools project. See: https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/.

Implementation details¶

For the interested, here’s the code flow which happens inside the kernel when you use the /dev interface to I2C:

Your program opens /dev/i2c-N and calls ioctl() on it, as described in section “C example” above.

These open() and ioctl() calls are handled by the i2c-dev kernel driver: see i2c-dev.c:i2cdev_open() and i2c-dev.c:i2cdev_ioctl(), respectively. You can think of i2c-dev as a generic I2C chip driver that can be programmed from user-space.

Some ioctl() calls are for administrative tasks and are handled by i2c-dev directly. Examples include I2C_SLAVE (set the address of the device you want to access) and I2C_PEC (enable or disable SMBus error checking on future transactions.)

Other ioctl() calls are converted to in-kernel function calls by i2c-dev. Examples include I2C_FUNCS, which queries the I2C adapter functionality using i2c.h:i2c_get_functionality(), and I2C_SMBUS, which performs an SMBus transaction using i2c-core-smbus.c: i2c_smbus_xfer() .

The i2c-dev driver is responsible for checking all the parameters that come from user-space for validity. After this point, there is no difference between these calls that came from user-space through i2c-dev and calls that would have been performed by kernel I2C chip drivers directly. This means that I2C bus drivers don’t need to implement anything special to support access from user-space.

These i2c.h functions are wrappers to the actual implementation of your I2C bus driver. Each adapter must declare callback functions implementing these standard calls. i2c.h:i2c_get_functionality() calls i2c_adapter.algo->functionality(), while i2c-core-smbus.c: i2c_smbus_xfer() calls either adapter.algo->smbus_xfer() if it is implemented, or if not, i2c-core-smbus.c:i2c_smbus_xfer_emulated() which in turn calls i2c_adapter.algo->master_xfer().

After your I2C bus driver has processed these requests, execution runs up the call chain, with almost no processing done, except by i2c-dev to package the returned data, if any, in suitable format for the ioctl.

© Copyright The kernel development community.

Источник