Raspberry pi adc: MPC3001 с использованием python и spidev

Я пытаюсь использовать АЦП MPC3001 с Raspberry pi через SPI с использованием Python. При этом я получаю странные результаты:

Код, который я использую:

import sys
import spidev

spi = spidev.SpiDev()
spi.open(0,0)

def readAdc(channel):
    r = spi.xfer2([1, 8 + channel << 4, 0])
    return ((r[1]&3) << 8) + r[2]

while True:
    print readAdc(0)
    time.sleep(0.5)

выполнение приведенного выше сценария при измерении центральной точки делителя напряжения приводит к случайному переключению между двумя значениями: 504 и 1016.

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

504 --> 00111111000

1016 --> 01111111000

Я предполагаю, что случайно где-то «создаю» 1.

Может ли кто-нибудь указать мне правильное направление. заранее спасибо

Кстати: это я, или нет достойной документации для spidev lib?


python raspberry-pi adc
person Toon Hooy    schedule 03.05.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

В листе данных рис. 5-2 показано, в чем проблема. . Данные, возвращаемые устройством, бит за битом, выглядят следующим образом (где X = безразлично, а Bx - это битовый номер x данных; B0 - это LSB, а B9 - MSB):

BYTE0:  X  X  0 B9 B8 B7 B6 B5 
BYTE1: B4 B3 B2 B1 B0 B1 B2 B3
BYTE2: B4 B5 B6 B7 B8 B9  X  X

Если вы измените оператор возврата на это:

return ((r[0] & 0x1F) << 5) | ((r[1] >> 3) & 0x1F)

это может сработать.

Но на вашем месте я бы не стал доверять мне (у меня больше нет оборудования, на котором я мог бы что-нибудь протестировать). Я думаю, что лучше всего распечатать отдельные значения байтов в r и обдумать результат, пока он не станет иметь смысл. Имейте в виду, что некоторые реализации SPI позволяют считывать данные по нарастающему или спадающему фронту. Если вы ошиблись, ваши данные никогда не будут иметь смысла.

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

Кстати, я согласен с вами насчет спидев. Я перешел на quick2wire, и тогда все пошло гораздо более гладко. Это лучше написано и намного лучше задокументировано.

person Paul Cornelius    schedule 04.05.2017
comment
Эээ, я думаю, вместо того, чтобы использовать побитовое и (&) при объединении битов из каждого байта в ответ ((r [0] & 0x1F) ‹---------------- 5) & ((r [1] ›› 3) & 0x1F) (который всегда будет возвращать 0, так как два значения никогда не будут иметь перекрывающихся единиц), вы должны использовать побитовое или (|)), т.е. return ((r [0] & 0x1F) ‹---------------- 5) | ((r [1] ›› 3) & 0x1F) - person barny; 04.05.2017
comment
Да, внес поправки в пост. - person Paul Cornelius; 05.05.2017