Передача ядру указателя на пользовательскую функцию.

[Vil84]

 Здравствуйте, коллеги.
 Помогите, пожалуйста, разобраться с проблемой. Я переписываю под Linux DOS-овскую программу, с внесением большого числа изменений. Самая главная проблема возникла при необходимости обработки прерываний от  com-порта. В DOS-овской программе меняется вектор прерываний и на соответствующий уровень прерываний устанавливается мой обработчик, путём передачи процессору указателя на функцию - часть моей программы.
 Соответственно, теперь мне нужно указатель на мой обработчик передать написанному мною модулю ядра. Помогите найти информацию, каким образом можно это осуществить. Модуль уже написан, ждёт указателя. Меня устроит man - знать бы, какую функцию смотреть. Спасибо большое за ответ!

[Yurror]

Ну передать ядру указатель легко. Только вот я не уверен что код будет исполняться нормально и не похоронит ОС или приолжение.

лучше закопай труппик и напиши по человечески

тебе нужны какие-то экзотические режимы работы с COM портом? или просто читать данные пришедшие на него?
ты уже тут задавал этот вопрос. тебе ответили. и послали читать именно ту документацию которую надо прочитать.

Давай так, ты наконец рассказываешь что там за хрень с портом, а мы тебе рассказываем как все организовать без залезания на уровень ядра.
Пока не докажешь всем доходчиво и аргументированно почему тебе кровь из носа надо именно прямой доступ к оборудованию считаем что ты пытаешься скомпилить досовское приложение не понимая
- ни основ работы компьютера
- ни основ работы современных ОС
- ни RS-232
- ни языка Си/С++

[Vil84]

 Задача - обмениваться данными с АЦП, и, анализируя эти данные, выполнять различные операции - от записи их в память до выдачи команд исполняющим механизмам. Данные приходят примерно каждые 24 миллисекунды, и терять их нельзя.
 Я не вижу другого способа обработки сигнала, пришедшего от АЦП на ком-порт. Постоянное опрашивание ком-порта мне не подходит, потому что за время между двумя сигналами - около 20 миллисекунд - программа может не успеть выполнить все необходимые операции. К тому же, в старт-стопном режиме обмена данными я не могу рассчитывать на чёткие временные интервалы между двумя сигналами.
 Насколько я понимаю, обработка прерываний от ком-порта в этом случае - самый правильный способ. Программа реагирует на пришедший в порт байт именно по факту его получения, а не затрачивая постоянно ресурсы на непрерывный опрос. Если существуют какие-либо другие методы обработки информации в подобном режиме - поделитесь, пожалуйста, информацией. Я вам буду очень благодарен.

[scsiman]

Если не ошибаюсь, речь идёт о реалтайме, что в "обычном" линуксе недостижимо. На мой взгляд, имеет смысл смотреть в сторону realtime-OS типа QNX (если оно ещё живо).

[Vil84]

 Да-да, я тоже читал про такой RT-Linux. А почему, по-вашему, нельзя просто реагировать на прерывания в обычном линуксе? Теоретически ведь в этом ничего сложного нет...

[Yurror]

Vil84, давай больше технической инфы
Таки АЦП гонит данные через стандартный UART? скорость обмена какая?
Тогда нехрен выпендриваться делай блокирующее чтение данных. Как только будет принят первый байт микросхема USART поместит его в приёмный буфер (4-8 байт всего) и выставит флаг прерывания. Он будет обработан практически мгновенно не незагруженой системе. Вызовится обработчик в который ты так отчаяно пытаешься залезть. Этот обработчик весьма быстро скопирует этот байт прямо в выделеный тобою буффер в user-space и отданный команде read. Дальше вызовится процедура планировщика которая из всех спящих процессов пнет именно твой птому что именно ему пришли в этот момент данные.

Системы реального времени
- это не значит бездумно лезть в ядро
- это надо понимать как оно устроено и как отреагирует на разные события
- это заранее просчитанные возможные состояния системы и врямя обработки разных задач

К тому же, в старт-стопном режиме обмена данными я не могу рассчитывать на чёткие временные интервалы между двумя сигналами.

А теперь по русски. Че сказать хотел? Чёткие временные интервалы тебе обеспечены будут если на системе больше ни чего другого крутиться не будет, что может притормозить обработку сигнала когда будет вызван другой процесс вместо твоего. Опять же только необходимые процессы в системе, система приоритетов и выбор правильного планировщика заданий позволят тебе сделать гарантированное время откликак по RS232'у порту из обычной пользовательской программы. Это на порядки проще чем писать свои обработчики прерываний не особо понимая что делаешь.

Насколько я понимаю, обработка прерываний от ком-порта в этом случае - самый правильный способ.

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

Программа реагирует на пришедший в порт байт именно по факту его получения

Таки отреагирует имеено на пришедшие байты. Именно по факту получения. Без лишнего гемороя.


Я тут конечно распинаюсь, но ты мне нифига не веришь и сидишь пальцем у виска крутишь. Тогда другой вопрос: а ты пробовал чтобы говорить что это не работает? код в студию! сдается мне там будет страшный копец который вообще не должен работать. мы все дружно поржём и скажем как на самом деле надо было написать.
Если реально сильно быстро и сильно критично повесь туда ARM на гигагерц, выкини вообще 232й интерфейс (довольно медленнная штука), прямо в арм вшей всю логику.

RT-Linux это кстати ядерные задачи которые именно обработчики прерываний и + обычный линукс который сам крутится рядом с ними как одна из задач. как то приблизительно так.

Пользователь решил продолжить мысль [time]Wed Feb  9 20:27:11 2011[/time]:
от куда 24 милисекунды? расчётное подлетное время? я умножил 24000 на 8 и получил сильно знакомую цифру в 192000 (bps надо полагать). Признавайся ты именно так получил эту цифру =)
Открою секрет. там не 8 бит на каждый байт. как минимум 10: старт бит, 8 бит данных, опциональный бит чётности и стоп бит. Бит данных может быть кстати меньше.

[Vil84]

Вызовится обработчик в который ты так отчаяно пытаешься залезть. Этот обработчик весьма быстро скопирует этот байт прямо в выделеный тобою буффер в user-space и отданный команде read. Дальше вызовится процедура планировщика которая из всех спящих процессов пнет именно твой птому что именно ему пришли в этот момент данные.

Ну так правильно! Именно это мне и нужно! Но как технически это осуществить - я не знаю.

Я тут конечно распинаюсь, но ты мне нифига не веришь и сидишь пальцем у виска крутишь. Тогда другой вопрос: а ты пробовал чтобы говорить что это не работает? код в студию! сдается мне там будет страшный копец который вообще не должен работать. мы все дружно поржём и скажем как на самом деле надо было написать.

Я потому и пишу на форум, что не могу это правильно сделать. И прошу у вас помощи. Мне не нужен готовый код, который я вставлю и у меня всё полетит. Но если вы дадите мне какие-либо учебные материалы или примеры - этого будет достаточно.
Пользователь решил продолжить мысль 10 Февраля 2011, 10:46:15:

Таки АЦП гонит данные через стандартный UART?

Да

скорость обмена какая?

4800

от куда 24 милисекунды? расчётное подлетное время? я умножил 24000 на 8 и получил сильно знакомую цифру в 192000 (bps надо полагать). Признавайся ты именно так получил эту цифру =)

Столько нужно для получения 9 битов - 8 значащих и один - чётности. Или нет?

[alexander.pronin]

ТС, если мне память не изменяет, что-то уже было.
Еще раз скажу, что у всех микросхем USART есть FIFO. По памяти, на 16 байт.
Далее считаем время заполнения FIFO так.
Пусть скорость 19200 бит/c.
Примем 10 бит на байт, для простоты.
1/ 19200 * 10 *16 = 0,008333333 сек или 8.3 мс
Чтобы ничего не пропало даром берем интервал считывания в 2 раза ниже - 4 мс.
И считываем весь FIFO USART так
cat /dev/ttyS0 >> file_buffer
Точка.
ЗЫ. Можно организовать FIFO канал, чтобы не писать прямо в файл.
ЗЫ2. Чуть не забыл.
Используйте многопроцессность и таймер. Этого джентальментского набора хватит для решения любых Ваших задач.

[Yurror]

Тут прога вычитывающая байтики из порта и на каждый полученный байтик отсылающая ответ.
Минимальная обработка полученной информации ((unsigned char)buf[ i ] > 3 ? 0 : 1)

на скоростях 4800bps только ОЧЕНЬ МЕДЛЕННЫЙ ЛЕНИВЕЦ не успеет отреагировать.

(Нажмите, чтобы показать/скрыть)

Код: (main.c) [Выделить]

/*
    Читать до просветления здесь
    http://www.easysw.com/~mike/serial/serial.html
    и здесь
    http://www.rostovlinux.ru/content/view/806/56/
*/
#include <stdio.h>   /* Standard input/output definitions */
#include <string.h>  /* String function definitions */
#include <unistd.h>  /* UNIX standard function definitions */
#include <fcntl.h>   /* File control definitions */
#include <errno.h>   /* Error number definitions */
#include <termios.h> /* POSIX terminal control definitions */
#include <stdlib.h>
#include <sys/signal.h>
#include <sys/types.h>
#include <sys/epoll.h>

#define BAUD B4800
#define PORT "/dev/ttyS0"
#define DATABITS CS8
#define STOPBITS 0 /* 1 - 0 | 2 - CSTOPB */

/*
 * //none
 * PARITYON = 0;
 * PARITY = 0;
 * //odd
 * PARITYON = PARENB;
 * PARITY = PARODD;
 * //even
 * PARITYON = PARENB;
 * PARITY = 0;
 */
#define PARITYON PARENB
#define PARITY 0

#define MAX_EVENTS 10

/* 24ms */
#define TIMEOUT 24

#define BUFF_SIZE 1024

void com_port_on_read(int fd, char *buf, int size) {
    int i;
    for (i = 0; i < size; ++i) {
        char ch = ((unsigned char)buf[i] > 3 ? 0 : 1);
        /* шлём 0 если принятое число больше 3 иначе шлём 1 */
        write(fd, &ch, 1);
        printf("%02X ", (unsigned int)buf[i]);
    }
    printf("\n");
}

int main(int argc, char *argv[])
{
    int fd, epollfd, run;
    struct epoll_event event, events[MAX_EVENTS];
    /* place for old and new port settings for serial port */
    struct termios oldtio, newtio;
    /* open the device(com port) to be non-blocking (read will return immediately) */
    fd = open(PORT, O_RDWR | O_NOCTTY | O_NONBLOCK | O_NDELAY);
    if (fd == -1)
    {
         perror("open("PORT")");
         exit(EXIT_FAILURE);
    } else
        fcntl(fd, F_SETFL, 0);

    /* save current port settings */
    tcgetattr(fd, &oldtio);
    /* set new port settings for canonical input processing */
    /* Control options */
    newtio.c_cflag = BAUD | DATABITS | STOPBITS | PARITYON | PARITY | CLOCAL | CREAD;
    /* Input options */
    newtio.c_iflag = IGNPAR;
    /* Output options */
    newtio.c_oflag = 0;
    /* Line options */
    newtio.c_lflag = 0; /*ICANON*/
    newtio.c_cc[VMIN] = 0;
    newtio.c_cc[VTIME] = 0;
    tcflush(fd, TCIFLUSH);
    tcsetattr(fd, TCSANOW, &newtio);

    epollfd = epoll_create(1);
    event.data.fd = fd;
    event.events = EPOLLIN;
    epoll_ctl(epollfd, EPOLL_CTL_ADD, fd, &event);

    run = 1;
    while (run) {
        int n;
        int nfds = epoll_wait(epollfd, events, MAX_EVENTS, TIMEOUT);
        if (nfds == -1) {
            if (errno == EINTR)
                continue;
            perror("epoll_wait()");
            break;
        }

        if (nfds == 0) {
            /* TIMEOUT!!! */
            /* Здесь может например наглядно отрисовываться взрыв завода */
            printf("timeout\n");
            continue;
        }
        for (n = 0; n < nfds; ++n) {
            if (events[n].events & EPOLLIN) {
                char buf[BUFF_SIZE];
                int bytes = read(events[n].data.fd, buf, BUFF_SIZE);
                if (bytes <= 0) {
                    perror("read()");
                    run = 0;
                    break;
                }
                com_port_on_read(events[n].data.fd, buf, bytes);
            }
        }
    }
    /* restore old port settings */
    tcsetattr(fd,TCSANOW,&oldtio);
    /* close the com port */
    close(fd);
    /* close epoll discriptor */
    close(epollfd);

    return (EXIT_SUCCESS);
}


Заметь в самом начале исходника есть ссылки. Тебя по ним раз сто посылали, но бестолку.
Слушайся дядю Юру и будет тебе счастье.

P.S. написано жутко криво и топорно. не учтено что буфер на отправку может временно переполниться.

[alexander.pronin]

Привычки использовать прерывания пошли от однопроцессного мышления (DOS).

[Yurror]

Алгоритм то обработки принимаемых значений сложный?
одно изменение АЦП сколько байт?

[Vil84]

 

Алгоритм то обработки принимаемых значений сложный?
одно изменение АЦП сколько байт?

Нет, алгоритм несложен, а одно изменение АЦП - 9 байт.
 Спасибо за пример, сейчас буду разбираться

[Yurror]

Прикрути буферизацию ввода/вывода и вперед.

[Vil84]

 To Yurror:
 Спасибо, дядя Юра , огромное за примерчик и, особенно, за вторую ссылку. Таки да, так значительно проще. Хотя переписываю чуть-чуть по-другому, но принцип тот же.

[alexander.pronin]

Еще добавлю для полноты картины, на всякий случай.
Если Вы имеете непрерывный поток данных, а иногда его надо как-то обрабатывать (писать в БД, рисовать графики, считать среднепотолочное и т.д.).
Делается 2 переключающихся дескриптора файлов. В один пишется, другой используется. По окончании обработки (использования) происходит переключение.
ЗЫ. Рад, что Вы встали на верную дорогу.