USB cable connection to DGT Bluetooth board problem

[Eric Singer]

I'm having an issue with picochess and using a standard USB cable to connect the Rikomagic and the e-board.   I've tested the USB cable connection using "DGT BoardTester" application with my Windows laptop and it tests okay.   So the cable is not the issue.

 

The first problem is the startup script is using /dev/ttyUSB0 device which does not appear in the /dev directory (Even with a fresh boot and the cable and board connected).

 

miniand@miniand:/dev$ ls -l /dev/ttyUSB0
ls: cannot access /dev/ttyUSB0: No such file or directory

There's a device that appears under /dev/serial/by-id that looks promising

 

miniand@miniand:/dev$ ls -l /dev/serial/by-id/usb-DGT_DGT_Chessboard-if00
lrwxrwxrwx 1 root root 13 Oct 14 15:30 /dev/serial/by-id/usb-DGT_DGT_Chessboard-if00 -> ../../ttyACM0

 

This is linked to the /dev/ttyACM0 device, however that does not work when I try Stockfish with it.

 

miniand@miniand:/dev$ /home/miniand/git/Stockfish/src/stockfish dgt /dev/ttyACM0
Stockfish  121006 by Tord Romstad, Marco Costalba and Joona Kiiski
dgtnix-debug:debug mode set to DGTNIX_DEBUG_WITH_TIME
dgtnix-debug:opening driver in normal mode
dgtnix-debug:Sending _DGTNIX_SEND_RESET to the board
dgtnix-debug:Sending _DGTNIX_SEND_BRD to the board
dgtnix-debug:Sending _DGTNIX_SEND_SERIALNR to the board
dgtnix-debug:Sending _DGTNIX_SEND_BUSADDRESS to the board
dgtnix-debug:Sending _DGTNIX_SEND_VERSION to the board
dgtnix-debug:Sending _DGTNIX_SEND_TRADEMARK to the board
dgtnix-debug:Sending _DGTNIX_SEND_UPDATE to the board
dgtnix-debug:/dev/ttyACM0 does not respond to the init query.
dgtnix-debug:the driver is closed
dgtnix-debug:opening driver in normal mode
dgtnix-debug:Sending _DGTNIX_SEND_RESET to the board
dgtnix-debug:Sending _DGTNIX_SEND_BRD to the board
dgtnix-debug:Sending _DGTNIX_SEND_SERIALNR to the board
dgtnix-debug:Sending _DGTNIX_SEND_BUSADDRESS to the board
dgtnix-debug:Sending _DGTNIX_SEND_VERSION to the board
dgtnix-debug:Sending _DGTNIX_SEND_TRADEMARK to the board
dgtnix-debug:Sending _DGTNIX_SEND_UPDATE to the board
^C

Luckily I figured out the Bluetooth setup and that works great, so that's the only way I can play at this point.

 

Eric

 

[Shivkumar Shivaji]

Its hard to tell exactly what is happening without a live Bluetooth DGT board. However, when I look up the device for me, its /dev/serial/by-id/usb-FTDI_USB__-__Serial-if00-port0.

Is the USB port that is on the bluetooth DGT board not an FTDI chip? Jan might know. You can try to see if linux on the desktop has the same issue.

Shiv

 

Eric

 

--
You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group, send email to picochess+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jan Krabbenbos]

The USB on the Bluetooth board is not FTDI. I guess the signature of the USB port in Linux tells the OS it is a modem, this happens also on Mac OS X (which is another Unix variant). I still have to figure out how this should be solved on OS X and have not had time to look at this issue under any Linux version.

Regards,

Jan

Met vriendelijke groet,

Jan Krabbenbos

jan.kra...@gmail.com

[Shivkumar Shivaji]

Thanks Jan. What is the chipset of the USB on the bluetooth board? I unfortunately don't have a bluetooth DGT board and can't help debug.

Shiv

[Eric Singer]

I'm looking into this as well.

 

Here's what the lsusb command shows the DGT board as (when using the cable)

 

Bus 003 Device 003: ID 04d8:000a Microchip Technology, Inc. CDC RS-232 Emulation Demo

I bet that's different on a none bluetooth DGT board

 

Eric

On Monday, October 15, 2012 10:47:12 AM UTC-4, sshivaji wrote:

Thanks Jan. What is the chipset of the USB on the bluetooth board? I unfortunately don't have a bluetooth DGT board and can't help debug.

Shiv

On Oct 14, 2012, at 11:12 PM, Jan Krabbenbos <jan.kra...@gmail.com> wrote:

The USB on the Bluetooth board is not FTDI. I guess the signature of the USB port in Linux tells the OS it is a modem, this happens also on Mac OS X (which is another Unix variant). I still have to figure out how this should be solved on OS X and have not had time to look at this issue under any Linux version.

Regards,

Jan

On 15 okt. 2012, at 01:56, Shivkumar Shivaji <sshi...@gmail.com> wrote:

Its hard to tell exactly what is happening without a live Bluetooth DGT board. However, when I look up the device for me, its /dev/serial/by-id/usb-FTDI_USB__-__Serial-if00-port0.

Is the USB port that is on the bluetooth DGT board not an FTDI chip? Jan might know. You can try to see if linux on the desktop has the same issue.

Shiv

On Sun, Oct 14, 2012 at 1:04 PM, Eric Singer <mytu...@yahoo.com> wrote:

I'm having an issue with picochess and using a standard USB cable to connect the Rikomagic and the e-board.   I've tested the USB cable connection using "DGT BoardTester" application with my Windows laptop and it tests okay.   So the cable is not the issue.

 

The first problem is the startup script is using /dev/ttyUSB0 device which does not appear in the /dev directory (Even with a fresh boot and the cable and board connected).

 

miniand@miniand:/dev$ ls -l /dev/ttyUSB0
ls: cannot access /dev/ttyUSB0: No such file or directory

There's a device that appears under /dev/serial/by-id that looks promising

 

min...@miniand:/dev$ ls -l /dev/serial/by-id/usb-DGT_DGT_Chessboard-if00

lrwxrwxrwx 1 root root 13 Oct 14 15:30 /dev/serial/by-id/usb-DGT_DGT_Chessboard-if00 -> ../../ttyACM0

 

This is linked to the /dev/ttyACM0 device, however that does not work when I try Stockfish with it.

 

min...@miniand:/dev$ /home/miniand/git/Stockfish/src/stockfish dgt /dev/ttyACM0

[Shivkumar Shivaji]

Definitely makes sense that you look at this! I get

Bus 007 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

for the USB DGT board.

I see a lot of google results when querying your string. Not exactly sure why it does not work for you. For debugging, seems like the following command can be a good start:

udevadm info --query=all --name="/dev/ttyACM0" --attribute-walk

can be a good start. There is also material at http://www.linuxquestions.org/questions/linux-hardware-18/udev-rule-not-working-880563/

Can't recommend much beyond probing further starting with the above command. Mine returns:

 looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb7/7-2/7-2:1.0/ttyUSB0':

    KERNELS=="ttyUSB0"

    SUBSYSTEMS=="usb-serial"

    DRIVERS=="ftdi_sio"

    ATTRS{latency_timer}=="1"

    ATTRS{port_number}=="0"

for the parent device. I suspect the driver that is being loaded is either incorrect or you need a udev symlink. No real knowledge of how the particular usb-serial driver load works, just guessing. This issue is relevant to me because I only run Mac or Linux. If this issue is not resolved, it wont make sense for me to get the Bluetooth DGT board in the future!

Shiv

[Eric Singer]

This is what I get

 

root@miniand:/home/miniand# udevadm info --query=all --name="/dev/ttyACM0" --att   ribute-walk

 

  looking at device '/devices/platform/sw-ohci.1/usb3/3-1/3-1:1.0/tty/ttyACM0':
    KERNEL=="ttyACM0"
    SUBSYSTEM=="tty"
    DRIVER==""

 

  looking at parent device '/devices/platform/sw-ohci.1/usb3/3-1/3-1:1.0':
    KERNELS=="3-1:1.0"
    SUBSYSTEMS=="usb"
    DRIVERS=="cdc_acm"
    ATTRS{bInterfaceNumber}=="00"
    ATTRS{bAlternateSetting}==" 0"
    ATTRS{bNumEndpoints}=="01"
    ATTRS{bInterfaceClass}=="02"
    ATTRS{bInterfaceSubClass}=="02"
    ATTRS{bInterfaceProtocol}=="01"
    ATTRS{supports_autosuspend}=="1"
    ATTRS{bmCapabilities}=="2"

 

  looking at parent device '/devices/platform/sw-ohci.1/usb3/3-1':
    KERNELS=="3-1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 2"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="80"
    ATTRS{bMaxPower}=="500mA"
    ATTRS{urbnum}=="50"
    ATTRS{idVendor}=="04d8"
    ATTRS{idProduct}=="000a"
    ATTRS{bcdDevice}=="0100"
    ATTRS{bDeviceClass}=="02"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{speed}=="12"
    ATTRS{busnum}=="3"
    ATTRS{devnum}=="2"
    ATTRS{devpath}=="1"
    ATTRS{version}==" 1.10"
    ATTRS{maxchild}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{authorized}=="1"
    ATTRS{manufacturer}=="DGT"
    ATTRS{product}=="DGT Chessboard"

 

  looking at parent device '/devices/platform/sw-ohci.1/usb3':
    KERNELS=="usb3"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="e0"
    ATTRS{bMaxPower}=="  0mA"
    ATTRS{urbnum}=="31"
    ATTRS{idVendor}=="1d6b"
    ATTRS{idProduct}=="0001"
    ATTRS{bcdDevice}=="0300"
    ATTRS{bDeviceClass}=="09"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{speed}=="12"
    ATTRS{busnum}=="3"
    ATTRS{devnum}=="1"
    ATTRS{devpath}=="0"
    ATTRS{version}==" 1.10"
    ATTRS{maxchild}=="1"
    ATTRS{quirks}=="0x0"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{authorized}=="1"
    ATTRS{manufacturer}=="Linux 3.0.36-t1+ ohci_hcd"
    ATTRS{product}=="SW USB2.0 'Open' Host Controller (OHCI) Driver"
    ATTRS{serial}=="sw-ohci"
    ATTRS{authorized_default}=="1"

 

  looking at parent device '/devices/platform/sw-ohci.1':
    KERNELS=="sw-ohci.1"
    SUBSYSTEMS=="platform"
    DRIVERS=="sw-ohci"

 

  looking at parent device '/devices/platform':
    KERNELS=="platform"
    SUBSYSTEMS==""
    DRIVERS==""

I tried creating a symlnk from ttyACM0 to  ttyUSB0 and changed the permissions, but that didn't work.   I also booted Ubuntu on my laptop and connected the DGT Bluetooth eboard and I still didn't get a driver that creates the ttyUSB0, so kind of stuck with using the bluetooth interface for now.

 

Eric

[Jan Krabbenbos]

The MicroChip CDC is correct. It is not a separate chipset like the FTDI, but a microprocessor with build-in USB support. 

According to the forum on MicroChip's web site, it should be supported. And this site has some additional info https://www.ridgerun.com/developer/wiki/index.php/How_to_use_USB_CDC_ACM_and_MS_composite_Linux_gadget_driver but might be somewhat outdated. I searched google with "linux usb cdc"

Regards,

Jan

[Shivkumar Shivaji]

Though I don't have the device, I see the problem. The cdc_acm modem device module is loaded ! Jan's comment is right on. Try the suggestion of the following link. For vendor Id and product I'd use what is in the third paragraph of your last email.

You have to remove the cdc_acm module and force a different module on the device. If this procedure works, there is a way to automate this process by blacklisting the cdc_acm module.

http://ubuntuforums.org/showthread.php?t=2003466

Shiv

--

[Eric Singer]

 

Thanks Jan and Shiv, I try this when I get home this evening and report back what happens.

 

Eric

[Jan Krabbenbos]

Shiv,

Thanks for this information too. Very useful.

Regards,

Jan

[Eric Singer]

I tried what the link described.

 

rmmod cdc_acm

 

and then

 

modprobe usbserial vendor=0x04d8 product=0x000a

 

and I did get the ttyUSB0 device

 

root@miniand:/dev# ls -l /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 Oct 16 16:24 /dev/ttyUSB0

However it still doesn't work

 

root@miniand:/dev# /home/miniand/git/Stockfish/src/stockfish dgt /dev/ttyUSB0

Stockfish  121006 by Tord Romstad, Marco Costalba and Joona Kiiski
dgtnix-debug:debug mode set to DGTNIX_DEBUG_WITH_TIME
dgtnix-debug:opening driver in normal mode
dgtnix-debug:Sending _DGTNIX_SEND_RESET to the board
dgtnix-debug:Sending _DGTNIX_SEND_BRD to the board
dgtnix-debug:Sending _DGTNIX_SEND_SERIALNR to the board
dgtnix-debug:Sending _DGTNIX_SEND_BUSADDRESS to the board
dgtnix-debug:Sending _DGTNIX_SEND_VERSION to the board
dgtnix-debug:Sending _DGTNIX_SEND_TRADEMARK to the board
dgtnix-debug:Sending _DGTNIX_SEND_UPDATE to the board

dgtnix-debug:/dev/ttyUSB0 does not respond to the init query.

 

Here's the udevadm attributewalk output

 

root@miniand:/dev# udevadm info --query=all --name="/dev/ttyUSB0" --attribute-walk

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/platform/sw-ohci.1/usb3/3-1/3-1:1.1/ttyUSB0/tty/ttyUSB0':
    KERNEL=="ttyUSB0"
    SUBSYSTEM=="tty"
    DRIVER==""

  looking at parent device '/devices/platform/sw-ohci.1/usb3/3-1/3-1:1.1/ttyUSB0':
    KERNELS=="ttyUSB0"
    SUBSYSTEMS=="usb-serial"
    DRIVERS=="generic"
    ATTRS{port_number}=="0"

  looking at parent device '/devices/platform/sw-ohci.1/usb3/3-1/3-1:1.1':
    KERNELS=="3-1:1.1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usbserial_generic"
    ATTRS{bInterfaceNumber}=="01"
    ATTRS{bAlternateSetting}==" 0"
    ATTRS{bNumEndpoints}=="02"
    ATTRS{bInterfaceClass}=="0a"
    ATTRS{bInterfaceSubClass}=="00"
    ATTRS{bInterfaceProtocol}=="00"
    ATTRS{supports_autosuspend}=="1"

 

  looking at parent device '/devices/platform/sw-ohci.1/usb3/3-1':
    KERNELS=="3-1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 2"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="80"
    ATTRS{bMaxPower}=="500mA"

    ATTRS{urbnum}=="18"

    ATTRS{idVendor}=="04d8"
    ATTRS{idProduct}=="000a"
    ATTRS{bcdDevice}=="0100"
    ATTRS{bDeviceClass}=="02"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{speed}=="12"
    ATTRS{busnum}=="3"

    ATTRS{devnum}=="4"

    ATTRS{devpath}=="1"
    ATTRS{version}==" 1.10"
    ATTRS{maxchild}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{authorized}=="1"
    ATTRS{manufacturer}=="DGT"
    ATTRS{product}=="DGT Chessboard"

  looking at parent device '/devices/platform/sw-ohci.1/usb3':
    KERNELS=="usb3"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="e0"
    ATTRS{bMaxPower}=="  0mA"

    ATTRS{urbnum}=="85"

Here's the lsmod output

 

root@miniand:/dev# lsmod
Module                  Size  Used by
usbserial              34183  0
8192cu                512561  0

 

Thanks,

Eric

On Tuesday, October 16, 2012 10:59:55 AM UTC-4, jkrabbenbos wrote:

Shiv,

Thanks for this information too. Very useful.

Regards,

Jan

On 16 okt. 2012, at 14:50, Shivkumar Shivaji <sshi...@gmail.com> wrote:

Though I don't have the device, I see the problem. The cdc_acm modem device module is loaded ! Jan's comment is right on. Try the suggestion of the following link. For vendor Id and product I'd use what is in the third paragraph of your last email.

You have to remove the cdc_acm module and force a different module on the device. If this procedure works, there is a way to automate this process by blacklisting the cdc_acm module.

http://ubuntuforums.org/showthread.php?t=2003466

Shiv

On Oct 16, 2012, at 3:20 AM, Eric Singer <mytu...@yahoo.com> wrote:

This is what I get

 

ro...@miniand:/home/miniand# udevadm info --query=all --name="/dev/ttyACM0" --att   ribute-walk

[Shivkumar Shivaji]

You are very close!

The difference I have for the the USB DGT board is below. The generic usbserial driver does not seem to work. Of course, one can modify the dgtnix code to make it work. However, it should be possible for you to get regular serial output without too much trouble. Try a different driver instead of generic usb-serial. There should be a driver which performs the equivalent of ftdi_sio without specific host management code. Will see if I find more info later tonight. My Udevadm output is below for the standard USB DGT board. dmesg output might also be useful.

Shiv

Udevadm info starts with the device specified by the devpath and then

walks up the chain of parent devices. It prints for every device

found, all possible attributes in the udev rules key format.

A rule to match, can be composed by the attributes of the device

and the attributes from one single parent device.

  looking at device '/devices/platform/sw-ohci.1/usb3/3-1/3-1:1.0/ttyUSB0/tty/ttyUSB0':

    KERNEL=="ttyUSB0"

    SUBSYSTEM=="tty"

    DRIVER==""

  looking at parent device '/devices/platform/sw-ohci.1/usb3/3-1/3-1:1.0/ttyUSB0':

    KERNELS=="ttyUSB0"

    SUBSYSTEMS=="usb-serial"

    DRIVERS=="ftdi_sio"

    ATTRS{latency_timer}=="1"

    ATTRS{port_number}=="0"

[Shivkumar Shivaji]

Just looked up usb-serial.c for fun. There is a funny relevant code comment:

 "The \"generic\" usb-serial driver is only for testing and one-off prototypes.\n"

"Tell linu...@vger.kernel.org to add your device to a proper driver.\n"

Thus, I think it is necessary to look for the right driver. We might have to look online.

Shiv

[Eric Singer]

Thanks Shiv,

 

I'm going to be away for a few days.  I'll have pick this back up when I return.

 

Eric

ro...@miniand:/dev# ls -l /dev/ttyUSB0

crw-rw---- 1 root dialout 188, 0 Oct 16 16:24 /dev/ttyUSB0

However it still doesn't work

 

ro...@miniand:/dev# /home/miniand/git/Stockfish/src/stockfish dgt /dev/ttyUSB0

Stockfish  121006 by Tord Romstad, Marco Costalba and Joona Kiiski
dgtnix-debug:debug mode set to DGTNIX_DEBUG_WITH_TIME
dgtnix-debug:opening driver in normal mode
dgtnix-debug:Sending _DGTNIX_SEND_RESET to the board
dgtnix-debug:Sending _DGTNIX_SEND_BRD to the board
dgtnix-debug:Sending _DGTNIX_SEND_SERIALNR to the board
dgtnix-debug:Sending _DGTNIX_SEND_BUSADDRESS to the board
dgtnix-debug:Sending _DGTNIX_SEND_VERSION to the board
dgtnix-debug:Sending _DGTNIX_SEND_TRADEMARK to the board
dgtnix-debug:Sending _DGTNIX_SEND_UPDATE to the board
dgtnix-debug:/dev/ttyUSB0 does not respond to the init query.

 

Here's the udevadm attributewalk output

 

ro...@miniand:/dev# udevadm info --query=all --name="/dev/ttyUSB0" --attribute-walk

ro...@miniand:/dev# lsmod

[Shivkumar Shivaji]

Jan, Eric,

Eric, No problem on being away. When you are back, start with Jan's page - https://www.ridgerun.com/developer/wiki/index.php/How_to_use_USB_CDC_ACM_and_MS_composite_Linux_gadget_driver and then see if you can make the linux gadget serial driver work - e.g. http://www.support.emtrion.de/doku.php?id=linux:linux_hico7723_usb_gadget with picochess.

Jan, How was the windows driver for the USB DGT board made? Did you program directly against the cdc-acm api using USB modem api (using say usbser.sys) or did you have a way to communicate with the micro controller's USB peripheral in serial mode? Maybe my question is trivial, but this is very new territory for me. This is the difference in linux between using "cdc_acm" and "usbserial". This might also answer your email question on why Linux and Mac OS X treat this device as a modem. It seems like a technical decision -- http://mcuee.blogspot.com/2011/08/usb-cdc-acm-is-really-meant-for-usb.html

I have not played with serial devices except when debugging dgtnix. It does not seem hard to use the acm device in direct serial mode from what I read on the web. Now thinking about it, I wonder why usbserial failed. It is possible that the dgtnix code has to change slightly, but I really don't understand why (if standards are followed by this device) :)

Shiv

[Eric Singer]

I'm back, however I haven't figured anything out yet.   I tried removing all the serial and usb related modules and issuing a modprobe ftdi_sio vendor=0x04d8 product=0x000a

That created two devices

 

root@miniand:/home/miniand# lsmod
Module                  Size  Used by
8192cu                512561  0
ftdi_sio               30625  0
cdc_acm                18935  0
usbserial              34183  1 ftdi_sio

root@miniand:/home/miniand#  rmmod ftdi_sio
root@miniand:/home/miniand#  rmmod usbserial
root@miniand:/home/miniand#  rmmod cdc_acm

 

root@miniand:/home/miniand# lsmod
Module                  Size  Used by
8192cu                512561  0

root@miniand:/home/miniand# modprobe ftdi_sio vendor=0x04d8 product=0x000a

root@miniand:/home/miniand# lsmod
Module                  Size  Used by
ftdi_sio               30625  1
usbserial              34183  3 ftdi_sio
8192cu                512561  0

root@miniand:/home/miniand# ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Oct 22 19:35 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 Oct 22 19:35 /dev/ttyUSB1

root@miniand:/home/miniand# /home/miniand/git/Stockfish/src/stockfish dgt /dev/ttyUSB0

Stockfish  121006 by Tord Romstad, Marco Costalba and Joona Kiiski
dgtnix-debug:debug mode set to DGTNIX_DEBUG_WITH_TIME
dgtnix-debug:opening driver in normal mode
dgtnix-debug:Sending _DGTNIX_SEND_RESET to the board

dgtnix critical:sendMessageToBoard: write() error
: No such device

root@miniand:/home/miniand# /home/miniand/git/Stockfish/src/stockfish dgt /dev/ttyUSB1

Stockfish  121006 by Tord Romstad, Marco Costalba and Joona Kiiski
dgtnix-debug:debug mode set to DGTNIX_DEBUG_WITH_TIME
dgtnix-debug:opening driver in normal mode
dgtnix-debug:Sending _DGTNIX_SEND_RESET to the board
dgtnix-debug:Sending _DGTNIX_SEND_BRD to the board
dgtnix-debug:Sending _DGTNIX_SEND_SERIALNR to the board
dgtnix-debug:Sending _DGTNIX_SEND_BUSADDRESS to the board
dgtnix-debug:Sending _DGTNIX_SEND_VERSION to the board
dgtnix-debug:Sending _DGTNIX_SEND_TRADEMARK to the board
dgtnix-debug:Sending _DGTNIX_SEND_UPDATE to the board

dgtnix-debug:/dev/ttyUSB1 does not respond to the init query.

So, not sure where to go from here.  

 

If I try this method

http://www.support.emtrion.de/doku.php?id=linux:linux_hico7723_usb_gadget

Can I echo commands to the DGT board just to see if there's a response?

 

Thanks Shiv!

 

In the meantime, I think I'll use the bluetooth and play a game with it against my Mephisto Vancouver 68020 and see how picochess play against it.

 

Eric

[Shivkumar Shivaji]

You can't emulate ftdi_sio with this usb serial port.

At this point, I would recommend trying out g-serial. I think none of these solutions will work out of the box, but you can echo and see what you are getting (like you indicated). 

If you have time and are curious, you can debug the DGTNIX driver line by line for your bluetooth connection and the USB connection using the usb-serial driver and compare. usb-serial however does not have buffering or some of the advanced things that you have via ftd_sio.

Its hard to recommend much more at this point without having the device. The fact that you have a working connection and one that does not work is good. You can probably see if you get terminal output and compare the 2 connections. The original link sent by Jan allows you to test cdc_acm, which might be useful as well. The DGT protocol is documented and available from http://www.dgtprojects.com/site/index.php/dgtsupport/developer-info/downloads/cat_view/131-developers

Shiv

[Wolfgang Zugrav]

Hello Shiv, Eric!

 

Any updates to the Blutooth problem? The users of DGT Bluetooth board version are getting more and more..

At least a friend of mine in Brasil and me, as we both own now a DGT Bluetooth...

 

- Wolfgang

Am Dienstag, 23. Oktober 2012 21:29:45 UTC+2 schrieb sshivaji:

You can't emulate ftdi_sio with this usb serial port.

At this point, I would recommend trying out g-serial. I think none of these solutions will work out of the box, but you can echo and see what you are getting (like you indicated). 

If you have time and are curious, you can debug the DGTNIX driver line by line for your bluetooth connection and the USB connection using the usb-serial driver and compare. usb-serial however does not have buffering or some of the advanced things that you have via ftd_sio.

Its hard to recommend much more at this point without having the device. The fact that you have a working connection and one that does not work is good. You can probably see if you get terminal output and compare the 2 connections. The original link sent by Jan allows you to test cdc_acm, which might be useful as well. The DGT protocol is documented and available from http://www.dgtprojects.com/site/index.php/dgtsupport/developer-info/downloads/cat_view/131-developers

Shiv

On Oct 22, 2012, at 4:49 PM, Eric Singer <mytu...@yahoo.com> wrote:

I'm back, however I haven't figured anything out yet.   I tried removing all the serial and usb related modules and issuing a modprobe ftdi_sio vendor=0x04d8 product=0x000a

That created two devices

 

ro...@miniand:/home/miniand# lsmod

Module                  Size  Used by
8192cu                512561  0
ftdi_sio               30625  0
cdc_acm                18935  0
usbserial              34183  1 ftdi_sio

root@miniand:/home/miniand#  rmmod ftdi_sio
root@miniand:/home/miniand#  rmmod usbserial
root@miniand:/home/miniand#  rmmod cdc_acm

 

ro...@miniand:/home/miniand# lsmod

Module                  Size  Used by
8192cu                512561  0

ro...@miniand:/home/miniand# modprobe ftdi_sio vendor=0x04d8 product=0x000a

ro...@miniand:/home/miniand# lsmod

Module                  Size  Used by
ftdi_sio               30625  1
usbserial              34183  3 ftdi_sio
8192cu                512561  0

ro...@miniand:/home/miniand# ls -l /dev/ttyUSB*

crw-rw---- 1 root dialout 188, 0 Oct 22 19:35 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 Oct 22 19:35 /dev/ttyUSB1

ro...@miniand:/home/miniand# /home/miniand/git/Stockfish/src/stockfish dgt /dev/ttyUSB0

Stockfish  121006 by Tord Romstad, Marco Costalba and Joona Kiiski
dgtnix-debug:debug mode set to DGTNIX_DEBUG_WITH_TIME
dgtnix-debug:opening driver in normal mode
dgtnix-debug:Sending _DGTNIX_SEND_RESET to the board
dgtnix critical:sendMessageToBoard: write() error
: No such device

ro...@miniand:/home/miniand# /home/miniand/git/Stockfish/src/stockfish dgt /dev/ttyUSB1

Stockfish  121006 by Tord Romstad, Marco Costalba and Joona Kiiski
dgtnix-debug:debug mode set to DGTNIX_DEBUG_WITH_TIME
dgtnix-debug:opening driver in normal mode
dgtnix-debug:Sending _DGTNIX_SEND_RESET to the board
dgtnix-debug:Sending _DGTNIX_SEND_BRD to the board
dgtnix-debug:Sending _DGTNIX_SEND_SERIALNR to the board
dgtnix-debug:Sending _DGTNIX_SEND_BUSADDRESS to the board
dgtnix-debug:Sending _DGTNIX_SEND_VERSION to the board
dgtnix-debug:Sending _DGTNIX_SEND_TRADEMARK to the board
dgtnix-debug:Sending _DGTNIX_SEND_UPDATE to the board
dgtnix-debug:/dev/ttyUSB1 does not respond to the init query.

[Shivkumar Shivaji]

I dont have a DGT bluetooth board to test. However, Eric's workaround using the USB bluetooth adapter like he indicated seemed to work fine for him -- https://github.com/jromang/Stockfish/wiki/DGT-Bluetooth-eboard-configuration. Try that solution. He even has a youtube video with it working. Directly using USB on DGT bluetooth boards does NOT work yet.

On other notes, Jean has integrated my analysis/book/training mode changes. Will release a new version soon, if he is not planning to add more changes. My CTG to polyglot converter is almost there now. Will advertise it here when its done. The benefit is that CTG books can then (after conversion) work with picochess. One can also use the converted polyglot books in other GUIs such as chessx, scid, scidvsPC etc.

Shiv

[Eric Singer]

Hi Everyone,

 

I've finally created a script that will automatically setup the bluetooth connection if a bluetooth dongle and DGT Bluetooth board is found.  The script's name is pico_dgt bt and should be placed in the /usr/local/bin directory.

 

The other attachments is my modification to the /etc/init.d/stockfish initization script.  The change calls my bluetooth script and if it can setup the bluetooth connection then it executes stockfish with the /dev/rfcomm0 device.  If for some reason it can not connect to a bluetooth DGT board then it connects to the standard /dev/ttyUSB0 device.

 

Hopefully this script and init script change can be included in the next image so bluetooth board users don't have to go through all my manual steps.   Just write the image and boot the Rikomagic MK802 up and it configures itself.

 

Thanks,

Eric

 

[Jean-Francois Romang]

Hello Eric,

This is GREAT :-) Of course, it will be integrated in the next image !

Jean-Francois

2012/12/30 Eric Singer <mytu...@yahoo.com>

Eric

 

--

You received this message because you are subscribed to the Google Groups "PicoChess" group.

[Eric Singer]

Let me know when you have a test image, would be glad to download and check to make sure it works properly.

 

Wasn't too hard of a script and believe me, I was getting tired of having to re-setup the bluetooth everytime I downloaded an image. LOL

 

Eric

[Shivkumar Shivaji]

That can be arranged quite soon.

Sorry to hear that you had to re-setup bluetooth every image. However, seems like this problem will end soon!

Shiv

[Gabriel Leperlier]

Great Eric.
Thanks
Gab

--

[Eric Singer]

I've modified the Bluetooth detection and connection script to look for the Revelation II board.   I'm not sure how well it will work, since I do not own a Revelation II board to test with.

Eric

[Jonas Žnidaršič]

I will test this ASAP.

Dne nedelja, 26. januar 2014 21:28:55 UTC+1 je oseba Eric Singer napisala:

I've modified the Bluetooth detection and connection script to look for the Revelation II board.   I'm not sure how well it will work, since I do not own a Revelation II board to test with.

 

-Izmet

(http://fekali.com/collection)

 

[Eric Singer]

Good luck and let me know.   The Revelation II FAQ shows that the board shows up as a Bluetooth device called "PCS-REVII-xxxxx", so the script looks for that and uses "1234" as the pin.

Just unzip the file and replace the one of the same name under /usr/local/bin

Eric

[Jonas Žnidaršič]

I tested with the latest 0.18s image for Raspberry Pi.

I simply replaced the already existing pico_dgt_bt script in /home/pi/git/Stockfish, did NOT touch the startup script in /etc/init.d as it already points to the old script location and I didn't want to mess around too much.

Rebooted, but connection did not work because standard bluetooth utilities are missing on the 0.18s image. Dunno why.

After installing bluez-utils (sudo apt-get install bluez-utils), I rebooted and PicoChess 0.18 started automagically with my Revelation II board.

I report the script WORKING on Raspberry Pi. Thank you.

Stay tuned for Rikomagic report ...

-Izmet

(http://fekali.com/collection)

Dne ponedeljek, 27. januar 2014 01:22:55 UTC+1 je oseba Eric Singer napisala:

[Jonas Žnidaršič]

I downloaded the latest official (0.18) image for Rikomagic, but could not make it work with Revelation II and the new script.

At first it would not connect at all. After sudo apt-get upgrade I managed to connect running the script manually, but not on boot. After connecting manually, PicoChess hangs trying to send "pic018" to the clock, gives up after few minutes. Here's the output:

miniand@miniand:~$ sudo /home/miniand/git/Stockfish/src/stockfish dgt /dev/rfcomm0

Stockfish DD by Tord Romstad, Marco Costalba and Joona Kiiski

dgtnix-debug:debug mode set to DGTNIX_DEBUG_WITH_TIME

dgtnix-debug:opening driver in normal mode

dgtnix-debug:Sending _DGTNIX_SEND_RESET to the board

dgtnix-debug:Sending _DGTNIX_SEND_BRD to the board

dgtnix-debug:Sending _DGTNIX_SEND_SERIALNR to the board

dgtnix-debug:Sending _DGTNIX_SEND_BUSADDRESS to the board

dgtnix-debug:Sending _DGTNIX_SEND_VERSION to the board

dgtnix-debug:Sending _DGTNIX_SEND_TRADEMARK to the board

dgtnix-debug:Sending _DGTNIX_SEND_UPDATE to the board

dgtnix-debug:Received _DGTNIX_BOARD_DUMP from the board

dgtnix-debug:|r|n|b|q|k|b|n|r|

dgtnix-debug:|p|p|p|p|p|p|p|p|

dgtnix-debug:| | | | | | | | |

dgtnix-debug:| | | | | | | | |

dgtnix-debug:| | | | | | | | |

dgtnix-debug:| | | | | | | | |

dgtnix-debug:|P|P|P|P|P|P|P|P|

dgtnix-debug:|R|N|B|Q|K|B|N|R|

dgtnix-debug:Received _DGTNIX_SERIALNR from the board

dgtnix-debug:serial number 00001

dgtnix-debug:Received _DGTNIX_BUSADDRESS from the board

dgtnix-debug:bus address 0-0x1

dgtnix-debug:Received _DGTNIX_VERSION from the board

dgtnix-debug:version  0.57

dgtnix-debug:Board initialised

The board was found - code: 5

dgtnix-debug:Received _DGTNIX_TRADEMARK from the board

dgtnix-debug:trademark DGT Projects - Digital Game Technology.

This Revelation II board is produced by DGT.

Firmw. ver.  0.57 051113/Bootloader ver.  3.02 230513/Serial nr: 0000000001:

dgtnix-debug:Sending _DGTNIX_SEND_UPDATE_NICE to the board

Sending message:pic018

dgtnix-debug:Sending message to clock

dgtnix critical:sendMessageToClock: write() error. Retrying.. 

: Input/output error

dgtnix critical:sendMessageToClock: write() error. Retrying.. 

: Input/output error

dgtnix critical:sendMessageToClock: write() error. Retrying.. 

: Input/output error

dgtnix critical:sendMessageToClock: write() error. Retrying.. 

: Input/output error

dgtnix critical:sendMessageToClock: write() error. Retrying.. 

: Input/output error

dgtnix critical:sendMessageToClock: write() error. Retrying.. 

: Input/output error

dgtnix critical:sendMessageToClock: More than 5 retries, exiting.

: Input/output error

miniand@miniand:~$ 

Dne ponedeljek, 27. januar 2014 21:22:53 UTC+1 je oseba Jonas Žnidaršič napisala:

[Eric Singer]

Excellent!   I wonder what Bluetooth utilities are install with 0.18s?  Maybe the next image can contain the bluez_utils

[Shivkumar Shivaji]

Thanks Eric! I can commit your script we can add bluez_utils to the next image. Revelation compability is a good plus for the few that have a unit.

Shiv

--
You received this message because you are subscribed to the Google Groups "PicoChess" group.

To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.

[Eric Singer]

This is confusing, the 0.18s works with the Revelation II, however the 0.18 doesn't because of the clock is missing?   Seems like there must be different executables for one to work right and the other to not.

Eric

[Shivkumar Shivaji]

I think 0.18s works on the Raspberry PI with the Rev II but 0.18 on the rikomagic does not work on the Rev II.

Jonas, did you get the rikomagic to work with the Rev II before? (Prior to using the new bluetooth setup)

Shiv

--

You received this message because you are subscribed to the Google Groups "PicoChess" group.

To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.

[Jonas Žnidaršič]

No, I don't think I have.

Dne torek, 28. januar 2014 01:11:18 UTC+1 je oseba sshivaji napisala:

Jonas, did you get the rikomagic to work with the Rev II before? (Prior to using the new bluetooth setup)

-Izmet

http://fekali.com/collection

 

[Jonas Žnidaršič]

I mean, I don't thik I ever even tried.

I always had some trouble with my version of Rikomagic (wifi won't work with linux), as I apparently have some Chinese non-standard version, according to online fora. Hence I pretty much didn't touch it, moved to Pi and Odroid-XU (darn fast.)

Dne torek, 28. januar 2014 02:04:10 UTC+1 je oseba Jonas Žnidaršič napisala:

[Eric Singer]

Okay, so we shouldn't be too quick to consider your Rikomagic problem as a real problem and the only action so far is to include the bluez_utils on the images (and of course my new script)..

 

Thanks for testing this Izmet

[Eric Singer]

Someone has been make videos

 

http://www.youtube.com/watch?v=YfHMKHzafkY&feature=youtu.be

 

Very nice!

Eric

[Jean-Francois Romang]

Very nice video from Jonas :-)
Thanks for the link !

--

[Shivkumar Shivaji]

Thanks Eric. Just merged this into the official picochess tree - https://github.com/jromang/Stockfish/blob/dgt/pico_dgt_bt

Shiv

To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.