Linux за българи: Форуми

Хардуер - Olinuxino A20
OS - Debian
Компилатор - freepascal, Lazarus
Ползвам Assign, Reset, Read и Close от тези File handling functions ($2).

Програмката чете съдържанието на 3 файла. То може да е "0" или "1", което отговаря на нивото, подадено от 3 датчика, свързани към GPIO изводи, зададени да работят като входове.

Не ми харесва да отварям, чета и затварям постоянно файловете, докато се случи това, което очаквам.

Как да го направя "културно"?

grep

http://en.wikipedia.org/wiki/Inotify ($2)
По-просто няма накъде  ;D

Предполагам, че искаш да четеш GPIO файлове в  /sys, прав ли съм? В такъв случай inotify няма да ти помогне, защото това не са инстински файлове. Остава да ги poll-ваш на някакъв период или да потърсиш как може да се генерира прекъсване при промяна на стойността. При Raspberry PI има питонски модул RPi.GPIO за тази цел, но за Olinuxino не съм се интересувал.

Предполагам, че искаш да четеш GPIO файлове в  /sys, прав ли съм?

Точно така.

При Raspberry PI има питонски модул RPi.GPIO за тази цел, ...

Благодаря за инфото! Прочетох за него и много ми хареса, че ми препоръчват да ползвам Arduino :) Засега ще остана на четене на файловете докато събера данни за евентуалните пропуснати събития, натоварване на процесора и времена при нормално поведение на системата.
Това нещо ще позволява и ще следи минаването на човек през турникет - онези с три рамена на 120 градуса.

примери с inotify в bash скриптове: http://techarena51.com/index.php/inotify-tools-example/
може да свърши работа.

А иначе се казва търнстил (Turnstile), щото турникет е уред за спиране на кръвотечение.

Малко встрани от темата - нищо не помага колега ..винаги ще има хора дето да 'гласуват' ...тъй де минават (ти ме разбра) с чужди карти. Тези датчици в повечето случаи само отчитат коя карта е минала.. Докат не се мине на нещо по-сериозно няма управия...

напр. ето тва работи даже на raspberry Pi
http://www.raspberrypi.org/facial-recognition-opencv-on-the-camera-board/

а и кода е отворен (е не е Паскал ами С/С++ ама какво от това - трябва да се върви напред)
http://sourceforge.net/projects/opencvlibrary/
http://opencv.org/


П.П. Инак ето така се прави на С/C++
http://www.linux.com/learn/tutorials/765810-beaglebone-black-how-to-get-interrupts-through-linux-gpio

П.П. Инак ето така се прави на С/C++
http://www.linux.com/learn/tutorials/765810-beaglebone-black-how-to-get-interrupts-through-linux-gpio

Това с фронтовете се коментира и тук и в питонския модул. За съжаление, работата на GPIO като входове в Olinuxino въобще не е документирана. Утре ще разгледам.
В момента правя точно това - следя фронтовете, но програмно (в моята програма).

Аз не съм много сведущ точно по темата, но доколкото разбирам ти правиш poll а пича от линка получава прекъсване или ползва някакъв друг механизъм който не е  poll обаче - щото задава callback функция - та си помислих че може да ти помогне (ще трябва да с мине на С/С++ обаче)


П.П. Между другото по въпроса за Паскал-а, по принцип ако ползваш тези е по-бързо
{$I-} // Turn off checking. This way all errors go into the IOResult variable
{$I+} // Turn it back on; errors will lead to an EInOutError exception

също и ако не четеш файла като текстов ами като двоичен
http://wiki.freepascal.org/File_Handling_In_Pascal#Binary_files

и ...тук вече не съм сигурен дали ще мине номера ако не го затвориш преди следващото четене ами направиш само
Seek(0, soBeginning);
дали ще прочете новото състояние или ще трябва твърдо да го затвориш и да отваряш наново...

Благодаря за насоките!

... или ще трябва твърдо да го затвориш и да отваряш наново...

Не съм наясно и за друго - ако отворя файла за четене и го оставя отворен, дали това ще пречи на процеса, който пише в този файл и дали ще има някаква полза от подобно спестяване на постоянното отваряне/затваряне в бързодействието и натоварването. И дали ако файлът е бил отворен и ако това не пречи на пишещия процес, ще е отворен ли и след промяната на съдържанието му?
Но, май много се задълбавам. Ще пусна нещото така и след като видя как се държи ще му мисля.

sed e това което ти трябва. Стрийминг редактор.

Това са файловете в свързаните с GPIO директории:

root@a20-OLinuXino:/opt# ls -l /sys/class/gpio/gpio47_ph2/
total 0
-rw-r--r-- 1 root root 4096 Nov 26 11:30 active_low
lrwxrwxrwx 1 root root    0 Nov 26 11:30 device -> ../../../gpio-sunxi
-rw-r--r-- 1 root root 4096 Nov 25 17:51 direction
-rw-r--r-- 1 root root 4096 Nov 26 11:30 edge
drwxr-xr-x 2 root root    0 Nov 26 11:30 power
lrwxrwxrwx 1 root root    0 Nov 25 17:51 subsystem -> ../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Nov 25 17:51 uevent
-rw-r--r-- 1 root root 4096 Nov 26 11:33 value
root@a20-OLinuXino:/opt# ls -l /sys/class/gpio/gpio50_ph10/
total 0
-rw-r--r-- 1 root root 4096 Nov 26 11:33 active_low
lrwxrwxrwx 1 root root    0 Nov 26 11:33 device -> ../../../gpio-sunxi
-rw-r--r-- 1 root root 4096 Nov 26 11:30 direction
-rw-r--r-- 1 root root 4096 Nov 26 11:33 edge
drwxr-xr-x 2 root root    0 Nov 26 11:33 power
lrwxrwxrwx 1 root root    0 Nov 26 11:30 subsystem -> ../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Nov 26 11:30 uevent
-rw-r--r-- 1 root root 4096 Nov 26 11:33 value

ph2 е конфигуриран като изход, а ph10 - като вход. И за двата, файловете uevent са празни.

Явно има някаква възможност за генериране на прекъсвания, но ще трябва да се чете, но пък документация ...

Не съм наясно и за друго - ако отворя файла за четене и го оставя отворен, дали това ще пречи на процеса, който пише в този файл и дали ще има някаква полза от подобно спестяване на постоянното отваряне/затваряне в бързодействието и натоварването. И дали ако файлът е бил отворен и ако това не пречи на пишещия процес, ще е отворен ли и след промяната на съдържанието му?
Но, май много се задълбавам. Ще пусна нещото така и след като видя как се държи ще му мисля.

Няма процес, който да пише там. Промяна на съдържанието не се случва на практика - просто когато го отвориш и прочетеш ти се сервират актуалните данни.

Пробвай да компилираш този пример: https://www.ridgerun.com/developer/wiki/index.php/Gpio-int-test.c и виж дали ще работи на olinuxino-то ти

Няма процес, който да пише там. Промяна на съдържанието не се случва на практика - просто когато го отвориш и прочетеш ти се сервират актуалните данни.

Нещо повече :) ! Оказа се, че файловете и директориите в /sys/class се създават чак когато бъдат потърсени, напр. с ls

В известен смисъл е така, макар че ми стана интересно как стигна до този извод.

Такива файлове няма на практика - нито се създават, нито се модифицират, нито се трият, всичко с псевдо файловите системи е една илюзия :)

В известен смисъл е така, макар че ми стана интересно как стигна до този извод.

При ls -l се вижда дата и час на създаване на файловете/директориите и това е моментът, когато за пръв път съм погледнал съдържанието на дадената директория, а не моментът на стартиране на системата, както си мислих досега.

Ами нормално е това. Макар че за някои директории или файлове там може и да е boot time-а датата. Това не са истински файлове така или иначе, нормално е да нямат дата на създаване. Грубо казано, всичко работи на базата на hook-ове в VFS слоя и вместо наистина да имаш някакъв файл, има някакъв callback, който се вика когато  четеш от файла или листваш съдържанието на директория. Конкретно как е реализиран sysfs не знам, но предполагам е сходно с procfs - листването на директорията всъщност е обхождане на един свързан списък от структури. Структурата може да има поле за дата на създаване, но обикновено е NULL - тогава dentry-то се попълва с настоящата дата.

@gat3way и аз имам няколко въпроса по темата - понеже файловете не съществуват а се имитират при опит за четене - какво ще стане ако имаме напр. такъв файл с размер от 1 байт и:
1. Отваряме файла, четем един байт, спим 1 сек., четем (още) един байт:
- нормално ще ни симулира текущото състояние отново и ние ще го прочетем (въпреки че е след края на файла);
- грешка - четене след края на файла (тъй като размера на файла е 1 байт) ..нищо че файла е измислен и може да ни го даде да го прочетем като следващ байт;
т.е. въпроса е дали е задължително да се прави seek(0) преди всяко четене

2. Кешира ли се от ОС напр. същата ситуация от по-горе като почваме да четем всеки път от началото за по-сигурно обаче ОС гледа в кеша гледа дата (и понеже никой друг не достъпвал файла и дата и час същите) и решава че това в кеша му е същото и не чете новото състояние..
т.е. въпроса е дали трябва да се затваря и отваря файла всеки път за да изчисти кеша

За кеша нямам спомени ObjectPascal дали можеше да му се оказва по някакъв начин да не го ползва подобно на O_DIRECT в С/С++


та затова предполагам колегата всеки път отваря-затваря файла което много го бави - въпросът е може ли да спести seek(0) всеки път, а отварянето и затварянето?

П.П. или дай инфо ако знаеш как може да си направи собствен "hook в VFS слоя" да му вика callback при нужда. Аз му дадох един линк - ама или при него не сработи ли не успя да го подкара (не разбрах и аз какво стана) ...дали не е щото беше С/С++ а не ObjectPascal - не знам  8)

Аз му дадох един линк - ама или при него не сработи ли не успя да го подкара (не разбрах и аз какво стана) ...дали не е щото беше С/С++ а не ObjectPascal - не знам  8)

Не съм пробвал да го подкарвам. След като пробвам чрез polling ще мисля какво ще правя.

Ей развалихте ми гледането на The Interview :)

@gat3way и аз имам няколко въпроса по темата - понеже файловете не съществуват а се имитират при опит за четене - какво ще стане ако имаме напр. такъв файл с размер от 1 байт и:
1. Отваряме файла, четем един байт, спим 1 сек., четем (още) един байт:
- нормално ще ни симулира текущото състояние отново и ние ще го прочетем (въпреки че е след края на файла);

Четенето на вторият байт ще ти даде грешка (EOF).

- грешка - четене след края на файла (тъй като размера на файла е 1 байт) ..нищо че файла е измислен и може да ни го даде да го прочетем като следващ байт;
т.е. въпроса е дали е задължително да се прави seek(0) преди всяко четене

Не мисля че seek ще сработи, при procfs поне по спомени не работеше, може да са го имплементирали за sysfs. В общият случай отваряш и четеш наново.

2. Кешира ли се от ОС напр. същата ситуация от по-горе като почваме да четем всеки път от началото за по-сигурно обаче ОС гледа в кеша гледа дата (и понеже никой друг не достъпвал файла и дата и час същите) и решава че това в кеша му е същото и не чете новото състояние..
т.е. въпроса е дали трябва да се затваря и отваря файла всеки път за да изчисти кеша

Не се минава през никакво кеширане, то и няма смисъл. Получаваш данните на момента :)

П.П. или дай инфо ако знаеш как може да си направи собствен "hook в VFS слоя" да му вика callback при нужда.

Отново говоря за procfs, със sysfs не съм толкова запознат - там има относително добре документирано API, в общият случай си регистрираш "файл" заедно с няколко callback-а които ще ти се викат при четене/писане/etc. Предполагам и със sysfs е подобно. В момента наизуст не мога да говоря, защото последно съм имал вземане-даване с това преди доста време, но мога да изкопая ако нещо ти трябва.

П.П userspace процес не знам да може да го прави това, трябва да го имплементираш като kernel модул естествено.

А иначе ако говориш за hook-ване на VFS нещата по-абстрактно и ако много държиш да си цапаш ръцете, има много места където можеш да се "захванеш". Линукския ring0 malware обиквено модифицира IDT таблицата, създава си копие и си пренасочва определени системни повиквания към негови си функции, това е лесният начин да правиш абсолютно всякакви гаври с файлове, без значение от файлова система - примерно да криеш файлове, да променяш незабележимо съдържание на файлове и т.н. Това е доста добре изпипан модел и продължава да работи. Разните "подсилени" линукс ядра малко или много може да те бият през ръцете естествено.