>
В драйвере devadc-l783m.so реализован круговой буфер размером до 0x20000 байт, организующий промежуточное хранение данных, поступающих от платы. >В имеющемся примере организована буферизация более 20 циклов АЦПирования по 2800 отсчетов.
Если драйвер содержит свой внутренний кольцевой буфер , зачем при обработке клиентского запроса на чтение ему ждать очередного прерывания? М.б. отдельная нить драйвера может следить за прерываниями и наполнять круговой буфер, а обработчик io-read - сразу отдавать клиенту непрочитанную часть этого буфера.
Не хотелось расписывать все особенности, но, видимо, придется
Драйвер, о котором идет речь, имеет 2 режима (см. usemsg): с фиксированием кольцевого буфера и с активной кольцевой буферизацией. Если взглянуть на сорцы, очевидно, что ожидание прервания происходит в 2-х случаях:
1. Если выбран режим ir_fixed и ожидается поступление актуальных данных;
2. Если данных в буфере нет (в этом случае, действительно, будет производиться ожидание прерывания - поступление данных в буфер).
Предупреждая возможный вопрос - фиксирование буфера введено исключительно в отладочных целях и на практике может быть полезно лишь в редких случаях.
>
Правильно ли я понял суть вопроса: будет ли иметься возможность отлаживать код драйвера (so-объекта) без коренного изменения кода, т.е. без >объединения исходных кодов драйвера и io-adm?
Да, правильно. Положим в IDE собраны клиентская программа c открытием и чтением данных, ресурс-менеджер io-adm и драйвер adc-sample.so Как все это совместно проверить-отладить с помощью IDE?
Спасибо.
Насколько мне известно, gdb (а следовательно и IDE) позволяет отлаживать so-объекты. Прошу коллег, которые ближе знакомы с отладкой в IDE, дать дополнительные рекомендации по данному вопросу.