[toxxin 0]

Доброго времени суток!

Существует недопонимание взаимодействия верхнего(пользовательского) уровня ОС Android и уровня драйверов. Если конкретнее - есть отладочная плата на OMAP3530, на ней поднят Android 2.2. Необходимо написать тестовое приложение(пустой экран и кнопочка), которое при нажатии кнопки отправляет данные по интерфейсу SPI и соответственно вызывает прерывание при приеме. На уровне linux все понятно - пишем драйвер интерфейса SPI, загружаем драйвер и работаем с файликом устройства /dev/spi. Но вот виртуальная машина Dalvik вряд ли даст просто так записать данные в файл устройства на нижнем уровне, да и не правильно это. Отсюда вытекает предположение о существовании некоего класса который бы осуществлял бы это взаимодействие. Собственно вопрос - где можно про это почитать и какой механизм для этого используется??

Спасибо!

Изменено 2 марта, 2011 пользователем toxxin

[ashr 0]

А здесь почитать не пробовали. Есть подозрение, что из под Andoid вот просто так SPI доступен не будет.

[toxxin 0]

А здесь почитать не пробовали. Есть подозрение, что из под Andoid вот просто так SPI доступен не будет.

Пробовали... Не находиться вразумительных ссылок по этому вопросу, либо я не умею искать инфу написанную "английский по белому". Отсюда вытекает вопрос к тем кто сталкивался с этой проблемой.

[denyslb 0]

В оригинальном андроиде скорее всего такого класса не существует.

Насколько я знаю они пропагандируют искоренение возможности доступа userspace приложений напрямую к железу со специфическими протоколами, и унификацию доступа к обьектам (файловым, медиа, коммуникациям и т.п.)

 

Можно только сделать "прокладку" под существующий API Андроида, к примеру написать демона, который откроет на localhost TCP сокет, и принятые данные отправит в SPI или будет управлять параметрами SPI, соответственно под Dalvik пишется уже просто TCP client. Но данное решение будет кастомным под эту плату, конечно.

[ukpyr 0]

http://developer.android.com/sdk/ndk/index.html

[toxxin 0]

В оригинальном андроиде скорее всего такого класса не существует.

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

 

Если пересобарть ядро с драйвером и запустить драйвер под линуксом(а отладочная консоль у меня именно линуксовая; НЕ Далвик) - где мне его найти под андроидом? Может быть появится устройство - /proc/device ?

Изменено 9 марта, 2011 пользователем toxxin

[Lampus 0]

Есть такая штука как spidev. Как правило инициализируется в файле борды, для него указывается номер шины SPI и номер CS. После чего после загрузки образуются файлы вида /dev/spidevB.C, где B - номер шины, C - номер ChipSelect'а. А дальше открываешь его как файл и что надо читаешь/пишешь.

Если же речь идёт о драйвере для какой-то определённой железяки висящей на SPI-шине, то надо смотреть в сторону /sys/class/spi*/...

Рекомендую изучить документацию идущую с ядром в папке Documentation/spi

[ukpyr 0]

Если пересобарть ядро с драйвером и запустить драйвер под линуксом(а отладочная консоль у меня именно линуксовая; НЕ Далвик) - где мне его найти под андроидом? Может быть появится устройство - /proc/device ?

ищите в исходниках, спросите у производителя отладочной платы. Для простейшей работы с портами может хватить ioperm/outp

Но вот виртуальная машина Dalvik вряд ли даст просто так записать данные в файл устройства на нижнем уровне, да и не правильно это.

уже была ссылка - для прямого взаимодействия с железом/системой есть NDK, пишите свои классы-обертки для взаимодействия с нижним уровнем

Изменено 30 мая, 2011 пользователем ukpyr

[cat_drugs 0]

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

Есть устройство, работающее на Андроид и есть у этого устройства чип с драйверами под Linux. С самими драйверами, я думаю, проблем возникнуь не должно никаких - кросс-компиляция под нужную архитектуру и все. Вопрос в другом - как мне теперь работать с этим драйвером из уровня приложения? Я так нигде и не нашел информации по теме :( Можно ли это делать с помощью NDK? Если да, то где можно про это прочесть подробнее?

[superdetka 0]

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

Есть устройство, работающее на Андроид и есть у этого устройства чип с драйверами под Linux. С самими драйверами, я думаю, проблем возникнуь не должно никаких - кросс-компиляция под нужную архитектуру и все. Вопрос в другом - как мне теперь работать с этим драйвером из уровня приложения? Я так нигде и не нашел информации по теме :( Можно ли это делать с помощью NDK? Если да, то где можно про это прочесть подробнее?

 

Заботу о взаимодействии драйвера и прикладного приложения берет на себя ядро, ос. Если брать за основу, что всё в Linux файлы, то при загрузке некоторых драйверов создается интерфейс в виде файла в папке /dev. Этим интерфейсом вы можете пользоваться вызывая библиотечные функции типа read(), write(). Хотя я точно не знаю, библиотечные ли это функции или прямые системные вызовы. Read, write из user space ядро транслирует в вызовы драйвера. В коде драйверов есть структура типа такой :

 

struct file_operations fops = {

.read = device_read,

.write = device_write,

.open = device_open,

.release = device_release

};

 

В коде драйвера все эти функции должны быть определены. То есть открывая файл в приложении, вы выбираете устройсво, вызывая read, write, вы работаете с устройством. Весь путь трансляции этих вызовов в вызовы драйвера берет на себя ядро. Почему не возникают вопросы по поводу работы прикладного софта с обычным текстовым файлом? Ведь читая из текстового файла вы ведь тоже работаете с железом в виде контроллера жесткого диска, к примеру.

 

NDK для Андроида, это набор скомпилированных библиотек, необходимых для компиляции вашего софта на С/С++ у себя на машине(не Android). Такие же библиотеки лежат уже на Android машине в соответсвии с весрией Andtoid и NDK. Native это у них вроде язык С/С++, не Native - Java(SDK). Там есть еще GDB, и система сборки их. Все это уже скомпилировано под ARM.