setar писал(а):есть идея попробовать использовать для работы с GPIO механизм inotify
Почитал я в гугле про работу этого механизма
Аналог кронтаба, только живет не по времени, а по событиям. Так что особых навыков программирования не нужно
Причем при наступлении события он элементарно запускает скрипт, который еще нужно как-то связать с нашей программой (а запускать по каждому событию разные скрипты (читай разные программы)- еще больший изврат, чем обращаться к пинам через файлы)
Отсюда имеем:
Плюсы(?): Можно собрать события со всех пинов в один поток (один файл) и прогой работать только с ним-единственным (опять же не знаю насколько это плюс, т.к. все-равно придется постоянно считывать данные с файла, преобразовывать в удобоваримый вид (лишние действия) и смотреть, что изменилось. Прерываниями в таком случае и не пахнет. Все прерывания заканчиваются на уровне выполнения скрипта)
Минусы: Помимо минусов, описаных в разделе плюсов
, файл изменился - да, а КАК он изменился мы не знаем, так что все равно нам придется читать файл пина и смотреть новое его значение - это раз.Два: механизм работает только на чтение, т.е. записывать в порты все равно придется "по-старинке"
Добавлено спустя 14 минут 22 секунды:
А вот из области программирования и не очень, есть у меня одна идейка, как подключить все 4 входа АЦП (ибо пока я нашел только 1 вход
)Итак, мы знает, что АЦП 1 а аналоговые входы мультиплексируются и управляют всем этим делом регистры процессора.
Значит будем лезть в регистры процессора? Как?
Есть в линуксе одна замечательная либа, называется ptrace.
И предназначена она для отладки процессов.
Вызов такой:
#include <sys/ptrace.h>
long int ptrace(enum __ptrace_request request, pid_t pid, void * addr, void * data)
потом в описании идет куча пояснений к разным параметрам и т.д. и .т.п бла-бла-бла....
Самое интересное:
Значения, описываемые ниже, позволяют читать/изменять регистры процессора дочернего процесса, а потому очень тесно связаны с аппаратной реализацией системы.
Набор доступных регистров включает в себя регистры общего назначения и регистры FPU (арифметического сопроцессора).
PTRACE_GETREGS, PTRACE_GETFPREGS, PTRACE_GETFPXREGS:
При этих значениях request, после обычной проверки прав доступа, производится копирование значений регистров общего назначения, регистров с плавающей точкой, дополнительных регистров с плавающей точкой дочернего процесса в переменную родительского процесса data. Копирование выполняется с помощью функций getreg() и __put_user(), аргумент addr игнорируется.
PTRACE_SETREGS, PTRACE_SETFPREGS, PTRACE_SETFPXREGS:
При этих значениях аргумента request выполняется запись в регистры процессора трассируемого процесса. В данном случае доступ к отдельным регистрам ограничивается. Значения регистров берутся из аргумента data. Аргумент addr игнорируется.
Осталось только узнать названия соответствующих регистров, и можно мультиплексить АЦП, да и что угодно делать! (В рамках одного процесса)
Тоесть поидее наши изменения регистров не затронут работу всей системы...
А вот тут уже пошел ембеддед... ибо регистры проца, и как их видит линь - это уже дело сугубо специфическое.
Вобщем я так понял, нужно смотреть сорсы ядра и самого ptrace для нашего линя.
Я в этом деле немного новичок, так что есть кто шарит получше, я буду только рад любой помощи
Добавлено спустя 29 минут 30 секунд:
Поискал в папке сорцов ядра файлики (*reg.h)
Кто такие папки mach-gemini, mach-l7200, mach-bcmring и т.д.???
И в какой из них и в каком файле находятся нужные регистры?
