Libusb error pipe

Good morning, I'm trying to use the CC2531 with a Beaglebone running Debian for the first time. Previously I used a Beaglebone running Angstrom with the CC2531 with success. Now I'm getting...

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account


Closed

Otxandio opened this issue

Sep 1, 2016

· 13 comments


Closed

LIBUSB_ERROR_PIPE

#5

Otxandio opened this issue

Sep 1, 2016

· 13 comments

Comments

@Otxandio

Good morning,

I’m trying to use the CC2531 with a Beaglebone running Debian for the first time. Previously I used a Beaglebone running Angstrom with the CC2531 with success. Now I’m getting this error and all my efforts to solve it are in vane. Ant help would be very appreciate

root@beaglebone:~/CC2531/CC2531# python ./sniffer.py -c 25
[GPS_reader][ERR] cannot open /dev/ttyUSB0
[CC2531][17168] driving CC2531 USB Dongle @ USB bus 1 & address 2, with serial 17168
Traceback (most recent call last):
File «./sniffer.py», line 255, in
main()
File «./sniffer.py», line 240, in main
ccs = prepare_receiver(chans)
File «./sniffer.py», line 123, in prepare_receiver
ss = [receiver(cc) for cc in ccs]
File «/root/CC2531/CC2531/receiver.py», line 101, in init
self._cc.init()
File «/root/CC2531/CC2531/CC2531.py», line 232, in init
self._set_config(0)
File «/root/CC2531/CC2531/CC2531.py», line 182, in _set_config
ret = self.com.controlWrite(0x00, 9, c, 0, »)
File «build/bdist.linux-armv7l/egg/usb1.py», line 1350, in controlWrite
sizeof(data), timeout)
File «build/bdist.linux-armv7l/egg/usb1.py», line 1329, in _controlTransfer
mayRaiseUSBError(result)
File «build/bdist.linux-armv7l/egg/usb1.py», line 133, in mayRaiseUSBError
__raiseUSBError(value)
File «build/bdist.linux-armv7l/egg/usb1.py», line 125, in raiseUSBError
raise __STATUS_TO_EXCEPTION_DICT.get(value, __USBError)(value)
usb1.USBErrorPipe: LIBUSB_ERROR_PIPE [-9]

@mitshell

It looks like you are not allowed to write to the USB port. I have no idea why it fails here, maybe ensure no other driver is trying to control the dongle ?

@Otxandio

OK, thanks for the quick answer mitshell. I’ve just checked that no driver is bound to the dongle.

root@beaglebone:~/CC2531/CC2531# usb-devices
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs= 1
P: Vendor=0451 ProdID=16ae Rev=43.10
S: Manufacturer=Texas Instruments
S: Product=CC2531 USB Dongle
C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)

Should some driver must appear there or it’s correct?

@Otxandio

Still stuck with the problem. Unbinding the driver the error changes:
root@beaglebone:# echo -n «1-1» > /sys/bus/usb/drivers/usb/unbind
root@beaglebone:/CC2531/CC2531# python ./sniffer.py -c 25
[GPS_reader][ERR] cannot open /dev/ttyUSB0
[CC2531][13139] driving CC2531 USB Dongle @ USB bus 1 & address 2, with serial 13139
Traceback (most recent call last):
File «./sniffer.py», line 255, in
main()
File «./sniffer.py», line 240, in main
ccs = prepare_receiver(chans)
File «./sniffer.py», line 104, in prepare_receiver
ccs = map(CC2531, get_CC2531())
File «/root/CC2531/CC2531/CC2531.py», line 147, in init
self.open()
File «/root/CC2531/CC2531/CC2531.py», line 165, in open
self.com.claimInterface(self.IF)
File «build/bdist.linux-armv7l/egg/usb1.py», line 1183, in claimInterface
libusb1.libusb_claim_interface(self.__handle, interface),
File «build/bdist.linux-armv7l/egg/usb1.py», line 133, in mayRaiseUSBError
__raiseUSBError(value)
File «build/bdist.linux-armv7l/egg/usb1.py», line 125, in raiseUSBError
raise __STATUS_TO_EXCEPTION_DICT.get(value, __USBError)(value)
usb1.USBErrorNotFound: LIBUSB_ERROR_NOT_FOUND [-5]

I cannot bind the dongle to any other driver, only to usb driver. Any advice?

@mitshell

Sorry, but I have no idea why it fails. Maybe try, after a fresh plugin of
the dongle on the beaglebone, to determine if any driver take control over
it automatically, e.g. a serial link emulator driver or some other generic
driver for USB peripheral… Check with standard Linux command: lsusb -v,
lsmod / modprobe / modinfo, /sys/bus/usb/devices…
/sys/kernel/debug/usb/devices… /proc/bus/usb/devices… directories and
files.

Let me know if you find a solution to the problem.
Regards
Benoit

2016-09-06 11:41 GMT+02:00 Otxandio notifications@github.com:

Still stuck with the problem. Unbinding the driver the error changes:
root@beaglebone:# echo -n «1-1» > /sys/bus/usb/drivers/usb/unbind
root@beaglebone:/CC2531/CC2531# python ./sniffer.py -c 25
[GPS_reader][ERR] cannot open /dev/ttyUSB0
[CC2531][13139] driving CC2531 USB Dongle @ USB bus 1 & address 2, with
serial 13139
Traceback (most recent call last):
File «./sniffer.py», line 255, in
main()
File «./sniffer.py», line 240, in main
ccs = prepare_receiver(chans)
File «./sniffer.py», line 104, in prepare_receiver
ccs = map(CC2531, get_CC2531())
File «/root/CC2531/CC2531/CC2531.py», line 147, in init
self.open()
File «/root/CC2531/CC2531/CC2531.py», line 165, in open
self.com.claimInterface(self.IF)
File «build/bdist.linux-armv7l/egg/usb1.py», line 1183, in claimInterface
libusb1.libusb_claim_interface(self.__handle, interface),
File «build/bdist.linux-armv7l/egg/usb1.py», line 133, in mayRaiseUSBError
__raiseUSBError(value)
File «build/bdist.linux-armv7l/egg/usb1.py», line 125, in raiseUSBError
raise __STATUS_TO_EXCEPTION_DICT.get(value, __USBError)(value)
usb1.USBErrorNotFound: LIBUSB_ERROR_NOT_FOUND [-5]

I cannot bind the dongle to any other driver, only to usb driver. Any
advice?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA9wH6q2-gAYv3waZR2w1-5S4Nxbew6lks5qnTVQgaJpZM4Jyjm9
.

@Otxandio

I’ve tried a fresh installation of Angstrom and the result is the same. That’s quite odd because I have another Beaglebone with the same SO version and the CC2531 works perfectly on it. Still trying to find a solution.

So far I found the same error using Ubuntu, Debian and Angstron in Beaglebone and Ubuntu in a laptop.

@vpelletier

Hello, python-libusb1 developer here (lurking on a few projects which use my module).

I think you should ask on the libusb mailing list, this looks like the kind of low-level issue they may know of.
To write the report mail you may want to build libusb with verbose logging enabled (python-libusb1 follows LD_LIBRARY_PATH semantics so you can use a local build easily) and enabling it (USBContext.setDebug, see also libusb_set_debug documentation), and maybe use ltrace to avoid having to guide them through all the python details (or maybe to discover something weird on the python level).

@Otxandio

OK, thanks a lot vpelletier. I’ll proceed as you say.

@Otxandio

I’ve built the last release of libusb using the option —enable-debug-log end the error output is just the same. I’m a little bit lost, how can I obtain more accurate info to write the report mail? I’m very sorry for my lack of skills, my apologies.

P.S. Tested in Fedora too with the same result.

@vpelletier

There is one more step before the library outputs debug logging, it is by calling «setDebug» on the usb context in python. From a very quick look into CC2531 source it seems you should add:

    ctx.setDebug(usb1.LOG_LEVEL_DEBUG)

in CC2531.py (right after creating the context).
Someone happens to have recently reported an issue on libusb mailing list when trying to use a device with verbose logging — and from python too (although with another wrapper, pyUSB). By quickly browsing the thread you should get an idea of what may be useful to include in your report.

@Otxandio

Oh, I see. I read about setDebug but I didn’t know where I should add it.

Thanks a lot for your help and for enhancing my knowledge. And now, get to work!

@Otxandio

Hello again folks,

I’ve sent the email to libusb mailing list, it’s waiting for approval.

More info that can be helpful. I’ve got another Beaglebone where the system is working. The version of the packages in that one are:
Angstrom v2012.12
python-core 2.7.3-r0.3.7
libusb1 version 1.0.9-r1.3
python-libusb1-1.3.0
pyserial-release2_4

Sadly I tried to recreate that environment in the new Beaglebone without success. However, the error is slightly different.

root@beaglebone:~/CC2531/CC2531# python ./sniffer.py -c 25
[GPS_reader][ERR] cannot open /dev/ttyUSB0
[CC2531][13139] driving CC2531 USB Dongle @ USB bus 1 & address 2, with serial 13139
Traceback (most recent call last):
File «./sniffer.py», line 255, in
main()
File «./sniffer.py», line 240, in main
ccs = prepare_receiver(chans)
File «./sniffer.py», line 123, in prepare_receiver
ss = [receiver(cc) for cc in ccs]
File «/home/root/CC2531/CC2531/receiver.py», line 101, in init
self._cc.init()
File «/home/root/CC2531/CC2531/CC2531.py», line 232, in init
self._set_config(0)
File «/home/root/CC2531/CC2531/CC2531.py», line 182, in _set_config
ret = self.com.controlWrite(0x00, 9, c, 0, »)
File «/usr/lib/python2.7/site-packages/usb1.py», line 1145, in controlWrite
sizeof(data), timeout)
File «/usr/lib/python2.7/site-packages/usb1.py», line 1125, in _controlTransfer
raise libusb1.USBError(result)
libusb1.USBError: LIBUSB_ERROR_PIPE [-9]

Looks like the problem is clearly related with Python. Any other package that could be important for this matter?

@mitshell

OK, my fault, commit b24652c4 introduced an error on a controlWrite() operation. Has been corrected now. Sorry for that

@Otxandio

Thank you very much mitshell. The problem is solved with the new version.
I really appreciate all your help pals.
Best regards.

Источник

I’m trying to make a little driver to communicate with an USB thermometer, using java library Libusb (org.usb4java.LibUsb). I’m testing it on a Raspeberry Pi (3b) with vanilla linux-arm.

My problem is that I don’t succeed in transferring a control transfer to the device. I get the error:

org.usb4java.LibUsbException: USB error 9: Control transfer failed: Pipe error

Here is my code:

Main class:

public class usbDriver {

    public static void main(String[] args) {
        Communication2 com = new Communication2();
        try {
            com.trouverDevice();
            com.preparerCom();
            com.testCom();
            com.terminerCom();
        } catch (Exception e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }
}

Communication2 class: 

public class Communication2 {

/** vendor ID du thermometre */
private static final short VENDOR_ID = 0x1941;

/** product ID du thermometre  */
private static final short PRODUCT_ID = (short) 0x8021;

/** interface active du thermometre  */
private static final byte INTERFACE_ID = 0x0;

/** endpoint sur l'interface active du thermometre  */
private static final byte ENDPOINT_ID = (byte) 0x81;

private Context contexte = null;
private Device device = null;
DeviceHandle handle = null;

private boolean pret;
private boolean detach = false;
private boolean trouve = false;

public Communication2() {
    pret = false;
}

public void trouverDevice() throws SecurityException, UsbException{
    // avec libUsb
    // Create the libusb context
    Context context = new Context();

    // Initialize the libusb context
    int result = LibUsb.init(context);
    if (result < 0)
    {
        throw new LibUsbException("Unable to initialize libusb", result);
    }
    // Read the USB device list
    DeviceList list = new DeviceList();
    result = LibUsb.getDeviceList(context, list);
    if (result < 0)
    {
        throw new LibUsbException("Unable to get device list", result);
    }
    try
    {
        // Iterate over all devices and list them
        for (Device device: list)
        {
            int address = LibUsb.getDeviceAddress(device);
            int busNumber = LibUsb.getBusNumber(device);
            DeviceDescriptor descriptor = new DeviceDescriptor();
            result = LibUsb.getDeviceDescriptor(device, descriptor);
            if (result < 0)
            {
                throw new LibUsbException(
                    "Unable to read device descriptor", result);
            }
            if (descriptor.idVendor() == VENDOR_ID && descriptor.idProduct() == PRODUCT_ID){
                System.out.println("Thermometre Pearl NC-7004 detecté !");
                System.out.println(descriptor.toString());
                this.device = device;
                this.trouve=true;
            } 
        }
    }
    finally
    {
        // Ensure the allocated device list is freed
        //LibUsb.freeDeviceList(list, true);
    }
    // Deinitialize the libusb context  
}

    public boolean preparerCom() throws Exception{

        if (!this.trouve) return false;

        this.contexte = new Context();
        int result = LibUsb.init(contexte);

        // reclamer le handle
        System.out.println("claim device handle");
        this.handle = new DeviceHandle();
        result = LibUsb.open(this.device, handle);
        if (result != LibUsb.SUCCESS) throw new LibUsbException("Unable to open USB device", result);

        detach = LibUsb.hasCapability(LibUsb.CAP_SUPPORTS_DETACH_KERNEL_DRIVER);
        detach = true; // pour forcer le claim sur le kernel
        detach = detach && (LibUsb.kernelDriverActive(handle, INTERFACE_ID)==1?true:false);
        System.out.println(LibUsb.hasCapability(LibUsb.CAP_SUPPORTS_DETACH_KERNEL_DRIVER));
        System.out.println((LibUsb.kernelDriverActive(handle, INTERFACE_ID)));
        System.out.println(detach);

        // Detach the kernel driver
        if (detach)
        {
            System.out.println("tentative de detacher le kernel");
            result = LibUsb.detachKernelDriver(handle,  INTERFACE_ID);
            if (result != LibUsb.SUCCESS) throw new LibUsbException("Unable to detach kernel driver", result);
        }
        detach = true;  

        System.out.println("claim interface");
        result = LibUsb.claimInterface(handle, INTERFACE_ID);
        if (result != LibUsb.SUCCESS) throw new LibUsbException("Unable to claim interface", result);

        this.pret=false;
        return this.pret;
    }


    public void testCom(){
        if (!this.pret) return;

        ByteBuffer buffer = ByteBuffer.allocate(18);


        // LibUsb.fillControlSetup(buffer, (byte)0x80, (byte)0x6,
        //      (short)0x1, (short)0x0, (short)0x1200);

        ByteBuffer buffer2 = ByteBuffer.allocateDirect(18);

        int transfered = LibUsb.controlTransfer(handle,(byte)0x80,(byte)0x6,(short)0x1,(short)0x0,buffer2,2000L);
        if (transfered < 0) throw new LibUsbException("Control transfer failed", transfered);
        System.out.println(transfered + " bytes sent");

        String test;
        String test2;
        if (buffer2.hasArray()) {
            for(int i =0;i<buffer2.array().length;i++){
                System.out.format("%02x",buffer2.array()[i]);
            }


             test=  new String(buffer.array(),
                    buffer.arrayOffset() + buffer.position(),
                    buffer.remaining());
        } else {
            final byte[] b = new byte[buffer.remaining()];
            buffer.duplicate().get(b);
            test =  new String(b);
        }
        System.out.println(test);
    }


    public void terminerCom() throws Exception{
        if (this.pret){
            if (this.detach)
            {
                int result = LibUsb.attachKernelDriver(handle,  INTERFACE_ID);
                if (result != LibUsb.SUCCESS) throw new LibUsbException("Unable to re-attach kernel driver", result);
            }

            LibUsb.close(this.handle);
            this.trouve = false;
            this.pret = false;
        }
    }
}

The error occurs when I call LibUsb.ControlTransfer(), trying to transfer a GET_DESCRIPTOR control packet. Here is the complete return of the code with device descriptor info: 

> Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 Per Interface
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x1941
idProduct 0x8021
bcdDevice 1.00
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
claim device handle
false
0
false
claim interface
org.usb4java.LibUsbException: USB error 9: Control transfer failed: Pipe error
at usbDriver.Communication2.testCom(Communication2.java:171)
at usbDriver.usbDriver.main(usbDriver.java:36)
root@raspberrypi:/home/pi/Desktop/execUsbDriver# java -jar usbDriver_executable.jar
java.lang.IllegalArgumentException: handle must not be null
at org.usb4java.LibUsb.controlTransfer(Native Method)
at usbDriver.Communication2.testCom(Communication2.java:170)
at usbDriver.usbDriver.main(usbDriver.java:36)

I think the pipe is well initialized (Handle seems ok, interface was successfully claimed too). Also the Libusb doc indicates :

LIBUSB_ERROR_PIPE if the control request was not supported by the
device

So I guess I’m just misdoing the control request. If you know the code to send a GET_DESCRIPTOR request properly I’d be glad to test it!

Источник

Вы здесь

E502 + Python

Здравствуйте.
Пытаюсь написать скрипт для работы с модулем E502 через библиотеку libusb1, но пока не очень выходит; чтение регистров работает, а вот запись — нет

import usb1
from struct import pack, unpack

context = usb1.USBContext()
handle = context.openByVendorIDAndProductID( 0x2A52, 0xE502 )
handle.claimInterface(0)

# Запрос скорости USB-интерфейса
print( handle.controlRead( 0xC0, 0x6, 0, 0, 1 ) ) # выдает 1, как положено

# Запись в регистр FPGA
handle.controlWrite( 0x60, 0x200+0x114, 0, pack( "I", 1) ) # вызывает LIBUSB_ERROR_PIPE, а зеленый светодиод LED2 на мгновение тухнет

В общем, исключение LIBUSB_ERROR_PIPE вызывают любые попытки что-либо записать в модуль и есть подозрение, что я явно что-то делаю не так…

  • Ответить

Re: E502 + Python

При использовании libusb1 напрямую, та же петрушка: чтение работает, запись — нет. 

#include <libusb-1.0/libusb.h>
#include <iostream>
using namespace  std;

int main () {
    auto printData = []( unsigned char * pData, const unsigned int & size ) {
        cout << "Data: ";
        for ( int i = 0; i < size; ++i ) cout << " " << (unsigned)pData[i] << " ";
        cout << endl; };

    libusb_context * ctx;
    libusb_init( &ctx );
    libusb_device_handle * dev_handle;

    dev_handle = libusb_open_device_with_vid_pid( ctx, 0x2A52, 0xE502 );

    unsigned char data [4] = {0,0,0,0};
    cout << libusb_control_transfer( dev_handle, 0x60, 0x11, 0x314, 0, &data[0], 4, 0 ) << endl; // -9

    cout << libusb_control_transfer( dev_handle, 0xC0, 0x81, 0, 0, &data[0], 1, 0 ) << endl; // 1
    printData( &data[0], 4 ); // 2

    libusb_exit( ctx );
    return 0;
}
  • Ответить
Сотрудник «Л Кард»
Здесь с 17.04.2014
Сообщений: 1,207

Re: E502 + Python

Добрый день.
В качестве requestType у Вас при записи используется 0x60, что соответствует резервному типу (3 << 5), хотя должно быть 0x40 (2 << 5 — vendor request).
Запрос  handle.controlWrite( 0x40, 0x11, 0x200+0x114, 0,  pack( «I», 1) ) исключения не выдает.

  • Ответить
Сотрудник «Л Кард»
Здесь с 17.04.2014
Сообщений: 1,207

Re: E502 + Python

При этом:
handle.controlWrite( 0x40, 0x11, 0x200+0x114, 0,  pack( «I», 0) ) — светодиод LED1 гаснет
handle.controlWrite( 0x40, 0x11, 0x200+0x114, 0,  pack( «I», 1) ) — светодиод LED1 горит

Светодиод LED2 указывает активность по usb. Соответственно он кратковременно мигает, когда модуль принимает USB запрос. Когда посылали запрос типа Reserved он приходил устройству, оно его принимало (мигание LED2) и возвращало на него ошибку, указывая, что такие запросы не поддерживаются, и соответственно libusb возвращал LIBUSB_ERROR_PIPE

  • Ответить
Сотрудник «Л Кард»
Здесь с 17.04.2014
Сообщений: 1,207

Re: E502 + Python

Правда мне кажется проще написать обертку под python для e502api (хотя у меня самого опыта такого нет, но вроде одним из преимуществ python является относительно простая интеграция с С-библиотеками), чем реализовывать все ее функции поверх libusb….

  • Ответить

Re: E502 + Python

Алексей L Card пишет:

Добрый день.
В качестве requestType у Вас при записи используется 0x60, что соответствует резервному типу (3 << 5), хотя должно быть 0x40 (2 << 5 — vendor request).
Запрос  handle.controlWrite( 0x40, 0x11, 0x200+0x114, 0,  pack( «I», 1) ) исключения не выдает.

Да, действительно. Просто не пришло в голову перепроверить по спецификации USB фразу из документации на модуль:

в поле bmRequestType указывается направления передачи блока данных, тип запроса всегда Vendor, приемником всегда выступает устройство (Device). Т.е. код 0x60 при передаче данных в модуль и 0xC0 при приеме из модуля.

Алексей L Card пишет:

Правда мне кажется проще написать обертку под python для e502api (хотя у меня самого опыта такого нет, но вроде одним из преимуществ python является относительно простая интеграция с С-библиотеками), чем реализовывать все ее функции поверх libusb….

Проще — это если бы обертка уже была написана smile А раз писать мне самому, то уж лучше сделать под свои задачи на низком уровне, чем делать прослойку на прослойку, а потом все равно окажется, что e502api меня чем-то не устраивает и все нужно переделать.

В любом случае, спасибо за ответ)

  • Ответить
Сотрудник «Л Кард»
Здесь с 17.04.2014
Сообщений: 1,207

Re: E502 + Python

asdf пишет:

Просто не пришло в голову перепроверить по спецификации USB фразу из документации на модуль

Да, действительно… спасибо, что указали. Документ поправим…

  • Ответить
Участник
Откуда: Мурманск
Здесь с 24.11.2018
Сообщений: 59

Re: E502 + Python

asdf пишет:

Правда мне кажется проще написать обертку под python для e502api (хотя у меня самого опыта такого нет, но вроде одним из преимуществ python является относительно простая интеграция с С-библиотеками), чем реализовывать все ее функции поверх libusb….

В свое время делал такую обертку. Иногда использую ее для тестов и для каких-нибудь быстрых демок.

asdf пишет:

А раз писать мне самому, то уж лучше сделать под свои задачи на низком уровне

Низкий уровень на python — звучит странно.
Когда начнете получать данные с АЦП, если у вас частота дискретизации достаточно высокая или много каналов, то можете упереться в производительность питона при парсинге потока данных.
Правда я не изучал как там льются данные по USB — работаю с АЦП по  Ethernet, возможно вам и не придется ничего парсить. Но если данные льются упакованными так же как при передаче по Ethernet, то парсить придется. Рекомендую для получения массивов данных использовать массивы numpy, а не родные питоновские контейнеры.

  • Ответить

Re: E502 + Python

Алексей L Card пишет:

Да, действительно… спасибо, что указали. Документ поправим…

Если соберетесь, то и про обращение к Flash-памяти поправьте, пожалуйста, потому что из фразы «Параметр команды: Адрес во Flash-памяти, соответствующий началу блока» вообще не очевидно, что этот адрес должен в wIndex находиться, а не в wValue, как при обращении к регистрам ПЛИС. Всю голову сломал, почему у меня по всей флешке 0xFF, пока про wireshark не вспомнил)
Кстати, а что такое bRequest 0x25 и 0x42? В документации про это, вроде, ни слова, но E502 на них отвечает.

  • Ответить

Re: E502 + Python

Евгений Рогожкин пишет:

Низкий уровень на python — звучит странно.
Когда начнете получать данные с АЦП, если у вас частота дискретизации достаточно высокая или много каналов, то можете упереться в производительность питона при парсинге потока данных.
Правда я не изучал как там льются данные по USB — работаю с АЦП по  Ethernet, возможно вам и не придется ничего парсить. Но если данные льются упакованными так же как при передаче по Ethernet, то парсить придется. Рекомендую для получения массивов данных использовать массивы numpy, а не родные питоновские контейнеры.

Да, я думал про производительность питона на этапе проектирования системы и все, что требует хоть какой-то частоты дискретизации, висит на отдельном микроконтроллере (который управляется по JTAG из той же программы на питоне). E502 мне только для калибровки нужен — там и 100Гц хватит. Но все равно, спасибо, что предупредили.

  • Ответить

Re: E502 + Python

asdf пишет:

Алексей L Card пишет:

Да, действительно… спасибо, что указали. Документ поправим…

Если соберетесь, то и про обращение к Flash-памяти поправьте, пожалуйста, потому что из фразы «Параметр команды: Адрес во Flash-памяти, соответствующий началу блока» вообще не очевидно, что этот адрес должен в wIndex находиться, а не в wValue, как при обращении к регистрам ПЛИС. Всю голову сломал, почему у меня по всей флешке 0xFF, пока про wireshark не вспомнил)

Вопрос про флешку снимается — уже сам понял, что ступил

  • Ответить
Сотрудник «Л Кард»
Здесь с 17.04.2014
Сообщений: 1,207

Re: E502 + Python

Евгений Рогожкин пишет:

Но если данные льются упакованными так же как при передаче по Ethernet, то парсить придется.

Протокол верхнего уровня одинаковый для обоих интерфейсов, включая поток данных.

asdf пишет:

Кстати, а что такое bRequest 0x25 и 0x42

Тогда проверю наличие всех кодов команд в описании при обновлении. Видимо несколько вспомогательных команд не попало в описание
Запрос 0x42 — это проверка статуса работы тестового наладочного режима (не предназначен для пользователей) — при открытии соединения проверяется, что модуль не находится в нем.
Запрос 0x25 — это получение доп. флагов с информацией о устройстве — признак наличия ethernet, индустриального исполнения и признак наличия и успешной загрузки прошивки FPGA.

  • Ответить
Сотрудник «Л Кард»
Здесь с 17.04.2014
Сообщений: 1,207

Re: E502 + Python

из не попавших еще команда принудительной перезагрузки прошивки ПЛИС (как раз из соседней темы…) и чтение/запись сетевых настроек.

  • Ответить
Сотрудник «Л Кард»
Здесь с 17.04.2014
Сообщений: 1,207

Re: E502 + Python

Обновил документацию (исправил указанную ошибку и добавил коды недостающих команд)

  • Ответить
Участник
Здесь с 15.07.2017
Сообщений: 5

Re: E502 + Python

Евгений Рогожкин пишет:

Низкий уровень на python — звучит странно.
Когда начнете получать данные с АЦП, если у вас частота дискретизации достаточно высокая или много каналов, то можете упереться в производительность питона при парсинге потока данных.
Правда я не изучал как там льются данные по USB — работаю с АЦП по  Ethernet, возможно вам и не придется ничего парсить. Но если данные льются упакованными так же как при передаче по Ethernet, то парсить придется. Рекомендую для получения массивов данных использовать массивы numpy, а не родные питоновские контейнеры.

При использовании numpy и deque нет проблем с обработкой потока с АЦП e14-140 на максимальной частоте (200 кГц), с одновременной отрисовкой графиков. И все на не самом мощном ноутбуке. Так что сделать обработку на python в принципе возможно.

  • Ответить
Участник
Здесь с 01.07.2022
Сообщений: 1

Re: E502 + Python

Добрый день. Пытаюсь присоединиться к e502 из Raspbian 10 с помощью встроенного Python’а. Библиотеки попробовал взять отсюда:https://build.opensuse.org/package/show/home:l-card/x502studio. E502_UsbGetDevRecordsList, X502_Create, X502_OpenByDevRecord отрабатывают успешно. Но все попытки сконфигурировать E502 приводят к прекращению коммуникациии без какой-либо диагностики. Что бы вы посоветовали?

  • Ответить
Участник
Здесь с 31.10.2022
Сообщений: 1

Re: E502 + Python

Сергей 84 пишет:

Евгений Рогожкин пишет:

Низкий уровень на python — звучит странно.
Когда начнете получать данные с АЦП, если у вас частота дискретизации достаточно высокая или много каналов, то можете упереться в производительность питона при парсинге потока данных.
Правда я не изучал как там льются данные по USB — работаю с АЦП по  Ethernet, возможно вам и не придется ничего парсить. Но если данные льются упакованными так же как при передаче по Ethernet, то парсить придется. Рекомендую для получения массивов данных использовать массивы numpy, а не родные питоновские контейнеры.

При использовании numpy и deque нет проблем с обработкой потока с АЦП e14-140 на максимальной частоте (200 кГц), с одновременной отрисовкой графиков. И все на не самом мощном ноутбуке. Так что сделать обработку на python в принципе возможно.

Добрый день, Сергей. Расскажите, пожалуйста, какие версии библиотек lcomp/lusbapi использовали, выкладывали ли что-нибудь на github?

  • Ответить

Быстрый ответ

Источник

Понравилась статья? Поделить с друзьями:

Читайте также:

  • Libusb error not supported
  • Libusb error not found
  • Libstdc 6 dll ошибка
  • Libscepad dll fallout 4 ошибка
  • Libreoffice ошибка при сохранении документа

    • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии