[Zelepuk 0]

допустим в системе есть

\dev\SPIdev0

как в контектсе Си будет выглядеть запрос и обмен по устройству SPI?

можно ли применить функции работы с файлами из стандартной библиотеки, если SPIdev0 - это файл?

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

незнаю как подступиться

[sasamy 9]

незнаю как подступиться

 

В первую очередь - смотреть документацию

http://lxr.free-electrons.com/source/Docum...tion/spi/spidev

http://lxr.free-electrons.com/source/Docum...pi/spidev_fdx.c

http://lxr.free-electrons.com/source/Docum...i/spidev_test.c

[xor.kruger 0]

Вот по этой ссылке есть как раз подобный пример.

[Lampus 0]

допустим в системе есть

\dev\SPIdev0

Во-первых, скорее всего имеется в виду /dev/spidevB.X,

где B - номер шины, X - номер Chip-Select'а.

как в контектсе Си будет выглядеть запрос и обмен по устройству SPI?

Если требуетсмя half-duplex обмен данными, то тупо read()/write() из файла устройства. Если нужен full-duplex обмен данными, то это придётся делать через соответсвующий ioctl(). Ссылки на примеры выше уже привели.

можно ли применить функции работы с файлами из стандартной библиотеки, если SPIdev0 - это файл?

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

незнаю как подступиться

Правильный метод - написать модуль ядра, который будет предоставлять userspace прриложению интерфейс через атрибуты sysfs или символьное устройство. Городить огород через spidev не очень светлая мысль, а если понадобится прерывание обрабатывать или GPIO дёргать? Будете /dev/mem мучать?

[Zelepuk 0]

Во-первых, скорее всего имеется в виду /dev/spidevB.X,

где B - номер шины, X - номер Chip-Select'а.

 

Если требуетсмя half-duplex обмен данными, то тупо read()/write() из файла устройства. Если нужен full-duplex обмен данными, то это придётся делать через соответсвующий ioctl(). Ссылки на примеры выше уже привели.

 

Правильный метод - написать модуль ядра, который будет предоставлять userspace прриложению интерфейс через атрибуты sysfs или символьное устройство. Городить огород через spidev не очень светлая мысль, а если понадобится прерывание обрабатывать или GPIO дёргать? Будете /dev/mem мучать?

Интересно, можно подробнее об этом, что такое sysfs ?

[kurtis 0]

Смотрите в исходниках Documentation/filesystems/sysfs.txt или поиском в гугл

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

[gosha 0]

допустим в системе есть

\dev\SPIdev0

как в контектсе Си будет выглядеть запрос и обмен по устройству SPI?

можно ли применить функции работы с файлами из стандартной библиотеки, если SPIdev0 - это файл?

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

незнаю как подступиться

Стандартно: через системные вызовы : open("/devspi"), ioctl("/devspi"), read("/devspi"), write("/devspi"), close("/devspi"), select("/devspi")

Все, что пишется ф-ей по write-: уходит в spi

Все, что читается по read- ,берется из буфера драйвера (ранее пришло из spi)

select("/devspi") - ожидание прихода данных по spi

можно организовать ввод/вывод не read()/write()?, а через ioctl()

 

 

[Lampus 0]

Если кому интересно, можете почитать мои старые статьи на эту тему:

http://habrahabr.ru/blogs/linux/123145/

http://habrahabr.ru/blogs/linux/123266/

Может содержать некоторые ошибки, ибо когда писал, только начинал вникать в эту тему, но в целом понимание основных структур давать должно.

Что касается прриведённого там примера драйвера, то там для "полного счастья" следует все совместно используемые данные выносить в структуру с общей блокировкой.

[Alesha 0]

Правильный метод - написать модуль ядра, который будет предоставлять userspace прриложению интерфейс через атрибуты sysfs или символьное устройство. Городить огород через spidev не очень светлая мысль, а если понадобится прерывание обрабатывать или GPIO дёргать? Будете /dev/mem мучать?

 

Собственно никто не мешает включить поддержку в ядре gpio в sysfs. Через /dev/spidev можно вполне себе производить первоначальную отладку программы, религия это не запрещает, а в книге по Linux Device Drivers именно этот и описывается как опциональный первоначальный вариант разработки драйвера через userspace, т.к. имеется возможность использовать дебаггер и не перезагружать постоянно модули

[Olej 0]

Во-первых, скорее всего имеется в виду /dev/spidevB.X,

где B - номер шины, X - номер Chip-Select'а.

 

Если требуетсмя half-duplex обмен данными, то тупо read()/write() из файла устройства. Если нужен full-duplex обмен данными, то это придётся делать через соответсвующий ioctl(). Ссылки на примеры выше уже привели.

 

Правильный метод - написать модуль ядра, который будет предоставлять userspace прриложению интерфейс через атрибуты sysfs или символьное устройство. Городить огород через spidev не очень светлая мысль, а если понадобится прерывание обрабатывать или GPIO дёргать? Будете /dev/mem мучать?

 

"Модули ядра Linux" + с примерами того, что вам надо.