Как непрерывно получать данные от АЦП в Linux

начни с того что скомпилируй py файл в pyc, шустрее будет

и вообще код в студию

http://paste.org.ru/?22h66y

test adc
fd= 3
count= 5000, ms= 2616, maxv= 2603
count= 5000, ms= 2617, maxv= 60
count= 5000, ms= 2614, maxv= 2568
count= 5000, ms= 2616, maxv= 2599
count= 5000, ms= 2619, maxv= 2598
count= 5000, ms= 2617, maxv= 2600
count= 5000, ms= 2618, maxv= 2599
count= 5000, ms= 2616, maxv= 2600
count= 5000, ms= 2616, maxv= 2599
count= 5000, ms= 2619, maxv= 58

В общем, переписал на Си и уперся в 2 кГц максимум. Наверное это предел пока что. Но важно то что значения датчика то в районе 60 то 2600, а его максимум 12 бит (4096). Не похоже это на обращение отрицательного числа в доп коде вокруг нуля, далеко ему до 4096.

Прихожу к выводу, что проблема не в частоте оцифровке, а в датчике как таковом или даже в I2C АЦП. Буду проверять постепенно, начнут с АЦП.

Сишный код мне не нужен, забыл вообще все.

Устройство должно поддерживать такой режим.
Вот как в ардуинке есть считывание ацп, которое ты запускаешь, а оно когда заканчивает оцифровку — генерирует прерывание и ты сразу забираешь результат и стартует следующее считывание.

Вот и у тебя как-то плата должна в комп посылать прерывание, когда результат готов.
А как это прерывание ловить компом — фиг знает, может через компорт как-то можно сигнал сброса(или какой-то там сигнал есть, который достаточно замкнуть две ножки) поймать.

ну и шину i2c может быть можно разогнать
поднять ей частоту на обоих концах

стесняюсь спросить, нафейхоа такая скорость?

1. смотреть даташит АЦП, может он в принципе не умеет мгновенно оцифровывать, и упирается все не совсем в шину

2. пытаться нормальный драйвер писать, задержки юзерспейса какбы не нормированы (не реалтайм же)

Вангую у тебя 100% девайс не обеспечивает нужную скорость передачи данных. Тут без вариантов. Какая-нибудь программная реализация или говно китайское. Даташит посмотри для начала.

частота дискретизации несколько килогерц, а я читаю несколько сотен раз в секунду

для скоростных устройств нужен DMA буфер и в простанстве пользователя читать надо буферизованные данные от драйвера а не устройство напрямую. Как драйвер делает непрерывное чтение - многобуферная очередь или один кольцевой буфер - это уже детали реализации.

Поддерживает ли подобный режим I2C в ядре Linux - вот это скорее меня интересует. Но у меня есть четкая мысль, что похоже мне придется ставить МК, который будет озабочен данной задачей.

Второе что смущает - некорректные данные АЦП, которые нельзя объяснить что биты поехали - не похоже.

Сейчас буду проверять генератором - попробую оцифровать синус или пилу

Оцифровка пьезодатчика при помощи I2C ADC на Raspberry Pi 3. Но я выяснил чтобы не терять данные я могу просто включить там встроенный цифровой фильтр в АЦП и просто читать на 1 кГц не теряя семплы и не требуя такой большой скорости

У меня похоже неверные измерения в принципе, АЦП следует протестировать синусом или пилой

это все же не ответ на вопрос - зачем. ну да ладно, выше уже все верно написали юзерспейс не даст тебе рилтайм, само понятие рилтайм в оцифрованном виде это в первою очередь корректно выбранная частота квантования, не стоит пытаться с ходу забиратся в микросекунды, возможно модель можно построить гораздо проще. ну от питона ты и сам отказался, как сейчас не знаю, но старый gil приходил в 1мс, так что выводы уже можешь сделать не полагаясь на интуицию

Отметил тему как решенную: дело оказалось не в АЦП или скорости/равномерности его чтения, ошибочно полагал что я что-то пропускаю, потому не вижу семплы с реакцией датчика на вибрацию

Проверил генератором - идеальный синус и пила нужного размаха

Проблема в пьезодатчике, который я пытался оцифровать. Он выдает странные результаты, реакция конечно есть, прослеживается во времени, но не то что я ожидаю. Буду пробовать разобраться, либо пробовать другие датчики…