I used the VM110 board with Linux (ubuntu) for some time. It worked fine with the driver [libk8055.sourceforge.net/]. Now, I bought another 2 cards. But unfortunately I got the “new” version VM110N. This board does not work with the “old” driver.
With a debugger I found that reading from the usb device just returned 6 bytes and not 8.
in <libk8055.c>
/* Actual read of data from the device endpoint, retry 3 times if not responding ok */
static int ReadK8055Data(void)
{
int read_status = 0, i = 0;
if (CurrDev->DevNo == 0) return K8055_ERROR;
for(i=0; i < 3; i++)
{
read_status = usb_interrupt_read(CurrDev->device_handle, USB_INP_EP, (char *)CurrDev->data_in, PACKET_LEN, USB_TIMEOUT);
^^^^here only 6 bytes were returned
if ((read_status == PACKET_LEN) && (CurrDev->data_in[1] == CurrDev->DevNo )) return 0;
if (DEBUG)
fprintf(stderr, "Read retry\n");
}
return K8055_ERROR;
}
Further I found, the last 4 bytes (of the 6 bytes read) contain the values of the counters 1 + 2.
Does anyone have an idea how to fix this (maybe some information about the new data structure of the K8055N board or maybe a linux driver which works with the old and the new VM110(N) boards).
Thanks for your answer! I already found the link before. So I realized that the last 4 bytes must be correct. Also the fist byte seem to represent the digital input in the right way. the second byte seem to be the problem.
The debugger (DDD, Kubuntu 12.04 LTS) give for CurrDev->data_in
/000/n{f/003/000/004/000/ (after three times pressing digital input 1 and four times digital input 2) The second byte (+ next 2 bytes) seem to be the problem.
I have no idea what’s about the /n{f/ value.
The first byte is the digital input value.
In the second byte there is some difference compared to the old K8055/VM110:
The second byte is the card address jumper setting + 11.
IIRC that libk8055 uses libusb. I’ve never used that one, only libusb2 under FreeBSD. Porting the libk8055 to libusb2 might be needed.
You can check out the “emulate-legacy-k8055” branch from the git repository of the K8055 open source project. The code in the /client directory should compile under Linux and is based on libusb2. The TclTk demo will also run under Linux and will communicate with a plain old K8055 using that client code. That should tell you if it is a libusb issue.
The hint from VEL255 is the trick! Thank you very much!
I added just one line to make both board versions running with that library [libk8055.sourceforge.net/].
[code]
/* Actual read of data from the device endpoint, retry 3 times if not responding ok */
static int ReadK8055Data(void)
{
int read_status = 0, i = 0;
if (CurrDev->DevNo == 0) return K8055_ERROR;
for(i=0; i < 3; i++)
{
read_status = usb_interrupt_read(CurrDev->device_handle, USB_INP_EP, (char *)CurrDev->data_in, PACKET_LEN, USB_TIMEOUT);
if ((read_status == PACKET_LEN) && (CurrDev->data_in[1] == CurrDev->DevNo )) return 0; /* works with K8055 / VM110 */
if ((read_status == PACKET_LEN) && (CurrDev->data_in[1] == CurrDev->DevNo +10)) return 0; /* works with K8055N / VM110N */
if (DEBUG)
fprintf(stderr, "Read retry\n");
}
return K8055_ERROR;
}[/code]
In a quick test with the included test program k8055 I could read from both cards simultaneously. The result looks reasonably
Indeed, the jumper setting value indicates the type of the card: K8055/VM110 or K8055N/VM110N.
I’m happy to read you got the new card working in Linux too!