Disclaimer: I am not involved in any way in the diygadget.com company. Neither am I involved in the TIAO GBoard manufacturing. If you have issues loading a GIMX firmware on a TIAO GBoard, please ask for help on the TIAO forum first.
Earlier this year, diygadget.com has released the TIAO GBoard. Thanks to diygadget.com for donating a TIAO GBoard and 90€ to the GIMX project!
At this time the board is sold at a special price of $21.99 (regular price is $29.99). Of course it is somewhat more expensive than building the adapter yourself, but it is a very good option for people that don’t want to get through the hassle of making a DIY USB adapter. Another good point for buying this board is stability: disconnecting something when manipulating the board is very unlikely.
Photo courtesy of diygadget.com.
This board embeds a FT231X chip and an atmega32u4 chip. Those chips can be easily connected together using jumpers. The board exposes all the pins of the chips through headers at the cost of a bigger size. This means it is possible to use it for other projects. For example it should be possible to convert it to an Arduino Leonardo -compatible board.
It has two mini USB female plugs:
- the one on the left side is connected to the FT231X and has to be connected to the PC
- the one on the right side is connected to the atmega32u4 and has to be connected to the console (or to the PC when loading a firmware)
There are three activity leds on the board:
- RL indicates when data is being received
- TL indicates when data is being transmitted
- LED indicates when the atmega32u4 is reset
One of the very first tests I did was to test the USB to serial chip which is a FT231X from FTDI. For this task I have a small benchmark tool called gserial_test that measures the trip delay of a typical GIMX packet (2-byte header + 64-byte HID report). I’ll try to say more about this tool in a further blog post. The test showed the FT231X is working as expected. On Windows you have to adjust the “Latency Timer” setting.
Loading a firmware on the board is explained on the TIAO wiki. As a GNU/Linux user I tried using dfu-programmer and loading was successful. Using dfu-programmer or Atmel’s FLIP tool on Windows should work fine as well. The procedure is slightly harder than using the Teensy loader (which can only work with genuine Teensy boards).
To test that a firmware runs as expected on the TIAO GBoard, I connected the board to my PS4 and ran GIMX a whole night. During this long run test, some macros kept the PS4 active, sending left button presses followed by right button presses, in a loop. The commands were still taken by the PS4 after about 10 hours, which shows the board is performing as expected!
This release fixes a few bugs and adds GT Force, Driving Force and Driving Force Pro emulations, for PS2. Thanks to Pawel for submitting source code for these new wheel emulations!
More info on the forum: link.
This release fixes two bugs: Dualshock 4 inputs not working when using the bluetooth connection method (#369), and Xbox 360 controller not working on Windows 10 (#368).
More info on the forum: link.
To speed up my development, I’ll try using the dummy_hcd kernel module, which allows to emulate an OTG port connected to the computer.
dummy_hcd is missing on my GNU/Linux distribution (Linux Mint 17.3), so I had to build it myself:
apt-get source linux-image-`uname -r`
cp /boot/config-`uname -r` .config
cp /usr/src/linux-headers-`uname -r`/Module.symvers .
# select → Device Drivers → USB support → USB Gadget Support → USB Peripheral Controller → Dummy HCD
make -j 4 M=drivers/usb/gadget
sudo cp drivers/usb/gadget/udc/dummy_hcd.ko /lib/modules/`uname -r`/kernel/drivers/usb/gadget/udc/
sudo depmod -a
Adding the following line to /etc/fstab makes it easier to mount the gadget file system:
gadget /dev/gadget gadgetfs noauto,user,group 0 0
Creating a udev rule in /etc/udev/rules.d/99-gadgetfs.rules allows to automatically mount the gadget filesystem when dummy_hcd is loaded:
ACTION=="add", DEVPATH=="/module/dummy_hcd" SUBSYSTEM=="module" RUN+="/bin/mkdir /dev/gadget" RUN+="/bin/mount /dev/gadget"
ACTION=="remove", DEVPATH=="/module/dummy_hcd" SUBSYSTEM=="module" RUN+="/bin/umount /dev/gadget" RUN+="/bin/rmdir /dev/gadget"
To apply this rule without rebooting:
sudo udevadm control --reload-rules
dummy_hcd can be loaded using modprobe:
sudo modprobe dummy_hcd
or automatically loaded at boot time adding this line to /etc/module:
The gadget can finally be controlled using the /dev/gadget/dummy_udc file.
I received my C.H.I.P.s!
The C.H.I.P. project was launched on Kickstarter in May 2015.
This tiny Linux board has two interesting features:
- it is very cheap ($9 + shipping)
- it has a USB HOST port and a USB OTG port
The USB OTG port can be programmed to behave as a USB device, which means it can replace the DIY USB adapter!
My first experiments will focus on making serialusb able to use the OTG port using gadgetfs.
This release fixes a bug in the mouse calibration tool (#363).
More info on the forum: link.
In recent weeks, I have been working on serialusb, a cheap USB proxy for input devices.
This tool can act as a USB proxy using the well-known DIY USB adapter.
Combined with usbmon and wireshark, it allows to generate and inspect USB captures.
Read the github project page to learn about the capabilities, the limitations, and the usage instructions of serialusb.
I’ve tested it successfully with the following hosts and devices:
- PC + Logitech G502 gaming mouse
- PC + Dell USB keyboard
- PC + Logitech Driving Force GT
- PC + Logitech RumblePad 2
- PS3 + Logitech Driving Force GT
- PC or PS3 + Dualshock 3
- PC or PS4 + Hori Pad Fps plus
- PC or Xbox 360 + Xbox 360 controller
- PC or Xbox One + Xbox One controller
If you have a DIY USB adapter and any of the following host + device combination, please consider making a USB capture and send it to me:
- Xbox One + Logitech G920
- Xbox One + Xbox One controller with 3.5mm stereo headset jack (USB PID = 0x02dd)