I’ve been working lately on improving manufacturability of my products. As a first result, I’m changing board revision of USB Host Shield to 1.21. The main difference between revisions 1.0 and 1.21 is level converters and jumpers in SMT packages. Picture on the right shows the very first panel [...]]]>

A panel of rev.1.21 shields

I’ve been working lately on improving manufacturability of my products. As a first result, I’m changing board revision of USB Host Shield to 1.21. The main difference between revisions 1.0 and 1.21 is level converters and jumpers in SMT packages. Picture on the right shows the very first panel of rev.1.21 board fresh from the oven.

Functionally, the board is the same. However, schematic has changed a little in part where control signals go through level converters. Therefore, it is important to use the right schematic when troubleshooting or hacking the shield. Downloads section has been rearranged and documentation for both variants added and labeled. I also posted closeup pictures of new board in store listings for the shield and bare PCB. I still have several rev1.0 boards available, they should be all gone by the end of the week so when you buy a board this week, you may get an old version. If you have a preference, let me know.

Lastly, from now on USB Host Shields comes bundled with stackable headers, the famous 4uconn part numbers 18688 and 18689. “Bundled” here means that by default they come in a bag, un-soldered. However, if you prefer, I can solder them for you – send me an e-mail after the purchase stating that you’d like your headers soldered and indicate the direction, female or male side up.

Oleg.

USB isolation is good for you. Isolated DAC makes better sound, isolated oscilloscope produces cleaner trace, and making line voltage measurements with isolated instruments helps us live longer. However, USB isolation often comes with a cost of extra USB cable, which may become excessive if we take [...]]]>

USB A to B connectors back to back

USB isolation is good for you. Isolated DAC makes better sound, isolated oscilloscope produces cleaner trace, and making line voltage measurements with isolated instruments helps us live longer. However, USB isolation often comes with a cost of extra USB cable, which may become excessive if we take into account precious desk space taken by said cable, as well as time spent on finding and untangling it.

I made several attempts to build a short cable which would also be able to bear load of USB isolator. Finally, while searching for a source of PCB mounted USB male B-type connector, I found this little marvel on eBay.

There is not much to say about it. It is short rigid adapter with USB A-type connector on one end and B-type on the other. The following picture shows typical arrangement – USB isolator connected to my Bitscope with USB adapter holding isolator in the air.

Of course, this little adapter can be used for connecting many other devices. Another picture shows our beloved Arduino connected to a USB port of a laptop computer. Here the weak spot of the adapter is clearly seen – since A and B connectors are turned 180 degrees, connected device would be turned upside down. For isolator it doesn’t matter much; however, operating Arduino’s Reset button and connecting shields would be difficult.

Adapter is available from several sources on eBay. Prices vary from $0.90 to $2.00, often with free shipping. The search string is “USB 2.0 Male to Printer Scanner A-B Converter Adapter”. Enjoy!

Oleg.

USB Isolator connected to Bitscope using short cable

Using USB adapter to connect Arduino to a PC

This is the third part of a series of articles written to describe development of interface between Arduino and popular game controllers using USB Host Shield. Previous parts:

Revision 0.4 – 13th January 2010

Part 3. Develop the Bluetooth USB and HCI interface used in [...]]]>

Wiimote controller wit USB Host Shield

This is the third part of a series of articles written to describe development of interface between Arduino and popular game controllers using USB Host Shield. Previous parts:

• Part 1. Introduction
• Part 2. PS3 controller interface

Revision 0.4 – 13th January 2010

Part 3. Develop the Bluetooth USB and HCI interface used in the support of the Wiimote and PS3 game controller, and also some utilities needed to analyse and configure these devices.

1. USB Interface
As before, we first look at the descriptors for the USB dongle using the USB_Desc sketch. The result is:

Start
Device descriptor:
Descriptor Length:    12
Descriptor type:      01
USB version:          0110
Device class:         E0
Device Subclass:      01
Device Protocol:      01
Max.packet size:      10
Vendor  ID:           0A12
Product ID:           0001
Revision ID:          0134
Mfg.string index:     00
Prod.string index:    00
Serial number index:  00
Number of conf.:      01
Configuration descriptor:
Total length:         006C
Num.intf:             02
Conf.value:           01
Conf.string:          00
Attr.:                80
Max.pwr:              32
Interface descriptor:
Intf.number:          00
Alt.:                 00
Endpoints:            03
Intf. Class:          E0
Intf. Subclass:       01
Intf. Protocol:       01
Intf.string:          00
Endpoint descriptor:
Endpoint address:     81
Attr.:                03
Max.pkt size:         0010
Polling interval:     01
Endpoint descriptor:
Endpoint address:     82
Attr.:                02
Max.pkt size:         0040
Polling interval:     00
Endpoint descriptor:
Endpoint address:     02
Attr.:                02
Max.pkt size:         0040
Polling interval:     00
Interface descriptor:
Intf.number:          01
Alt.:                 00
Endpoints:            02
Intf. Class:          E0
Intf. Subclass:       01
Intf. Protocol:       01
Intf.string:          00
Endpoint descriptor:
Endpoint address:     83
Attr.:                01
Max.pkt size:         0000
Polling interval:     01
Endpoint descriptor:
Endpoint address:     03
Attr.:                01
Max.pkt size:         0000
Polling interval:     01
Interface descriptor:
Intf.number:          01
Alt.:                 01
Endpoints:            02
Intf. Class:          E0
Intf. Subclass:       01
Intf. Protocol:       01
Intf.string:          00
Endpoint descriptor:
Endpoint address:     83
Attr.:                01
Max.pkt size:         0009
Polling interval:     01
Endpoint descriptor:
Endpoint address:     03
Attr.:                01
Max.pkt size:         0009
Polling interval:     01
Interface descriptor:
Intf.number:          01
Alt.:                 02
Endpoints:            02
Intf. Class:          E0
Intf. Subclass:       01
Intf. Protocol:       01
Intf.string:          00
Endpoint descriptor:
Endpoint address:     83
Attr.:                01
Max.pkt size:         0011
Polling interval:     01
Endpoint descriptor:
Endpoint address:     03
Attr.:                01
Max.pkt size:         0011
Polling interval:     01

The device descriptor is straight forward, but the configuration descriptor shows two interfaces and the second interface has alternate settings. The usage of the different endpoints is described here: Bluetooth Endpoint Usage

The second interface (interface one) is used for isochronous bandwidth related to carrying voice channels and we do not use this for Bluetooth HID, so they will be ignored.

We have four endpoints to consider:

The control endpoint (endpoint 0): This is used to send control messages and HCI commands.

The interrupt endpoint (endpoint 0×81): Where HCI events are received from the USB dongle.

The input endpoint (endpoint 0x 82): The bulk endpoint where ACL reports are received from the connected Bluetooth device.

The output endpoint (endpoint 0×02): The bulk endpoint where ACL reports are sent to the connected Bluetooth device.

These four endpoints discovered are registered as pipes to the USB Host library.

  /* Initialize data structures for endpoints of device 1*/
    ep_record[ CONTROL_PIPE ] = *( Usb.getDevTableEntry( 0,0 ));  //copy endpoint 0 parameters
    ep_record[ EVENT_PIPE ].epAddr = 0x01;    // Bluetooth event endpoint
    ep_record[ EVENT_PIPE ].Attr  = EP_INTERRUPT;
    ep_record[ EVENT_PIPE ].MaxPktSize = INT_MAXPKTSIZE;
    ep_record[ EVENT_PIPE ].Interval  = EP_POLL;
    ep_record[ EVENT_PIPE ].sndToggle = bmSNDTOG0;
    ep_record[ EVENT_PIPE ].rcvToggle = bmRCVTOG0;
    ep_record[ DATAIN_PIPE ].epAddr = 0x02;    // Bluetooth data endpoint
    ep_record[ DATAIN_PIPE ].Attr  = EP_BULK;
    ep_record[ DATAIN_PIPE ].MaxPktSize = BULK_MAXPKTSIZE;
    ep_record[ DATAIN_PIPE ].Interval  = 0;
    ep_record[ DATAIN_PIPE ].sndToggle = bmSNDTOG0;
    ep_record[ DATAIN_PIPE ].rcvToggle = bmRCVTOG0;
    ep_record[ DATAOUT_PIPE ].epAddr = 0x02;    // Bluetooth data endpoint
    ep_record[ DATAOUT_PIPE ].Attr  = EP_BULK;
    ep_record[ DATAOUT_PIPE ].MaxPktSize = BULK_MAXPKTSIZE;
    ep_record[ DATAOUT_PIPE ].Interval  = 0;
    ep_record[ DATAOUT_PIPE ].sndToggle = bmSNDTOG0;
    ep_record[ DATAOUT_PIPE ].rcvToggle = bmRCVTOG0;
    Usb.setDevTableEntry( BT_ADDR, ep_record );

The VID and the PID of the Bluetooth dongle should be checked to ensure compatibility. The CSR is the only dongle currently supported, but others have been found compatible and may be added later.
The device is configured and the interface 0 then set. At this stage we have communication with the Bluetooth dongle and can now start to communicate over Bluetooth.

2. Listen while we talk
We are now in a position to send HCI commands to the Bluetooth dongle over the control pipe, but first need to set up a process to read the interrupt pipe regularly. The events received on the interrupt pipe may not be directly related to the commands sent, so they must be processed as they arrive. As the USB host, we control the data transfers; we do not have to buffer large amounts of data, we only pull over the pipe what we can handle at any time. Also in the spirit of our “reduced host” for both USB and Bluetooth, we do no have to process all of the 36 possible events in the Bluetooth specification; we process only the ones we need for each application and ignore the rest. Significant events are communicated to the higher level routines through a set of flags.
We also commence reading the ACL input endpoint in case ACL events are ready there too. These are ignored until connection is made, but are read in case they block HCI events.
At this stage we handle only these HCI events:

#define EV_COMMAND_COMPLETE  0x0e
#define EV_COMMAND_STATUS    0x0f
#define EV_CONNECT_COMPLETE  0x03
#define EV_DISCONNECT_COMPLETE 0x05
#define EV_NUM_COMPLETE_PKT  0x13
#define EV_INQUIRY_COMPLETE  0x01
#define EV_INQUIRY_RESULT    0x02
#define EV_REMOTE_NAME_COMPLETE  0x07
#define EV_INCOMING_CONNECT  0x04
#define EV_ROLE_CHANGED  0x12

And we use these flags:

/* HCI event flags*/
#define HCI_FLAG_CMD_COMPLETE 0x01
#define HCI_FLAG_CMD_STATUS 0x02
#define HCI_FLAG_CONN_COMPLETE 0x04
#define HCI_FLAG_DISCONN_COMPLETE 0x08
#define HCI_FLAG_CONNECT_OK 0x10
#define HCI_FLAG_INQUIRY_COMPLETE 0x20
#define HCI_FLAG_REMOTE_NAME_COMPLETE 0x40
#define HCI_FLAG_INCOMING_REQUEST 0x80
 
//Macros for event flag tests
#define hci_cmd_complete (hci_event_flag & HCI_FLAG_CMD_COMPLETE)
#define hci_cmd_status (hci_event_flag & HCI_FLAG_CMD_STATUS)
#define hci_connect_complete (hci_event_flag & HCI_FLAG_CONN_COMPLETE)
#define hci_disconnect_complete (hci_event_flag & HCI_FLAG_DISCONN_COMPLETE)
#define hci_connect_ok (hci_event_flag & HCI_FLAG_CONNECT_OK)
#define hci_inquiry_complete (hci_event_flag & HCI_FLAG_INQUIRY_COMPLETE)
#define hci_remote_name_complete (hci_event_flag & HCI_FLAG_REMOTE_NAME_COMPLETE)
#define hci_incoming_connect_request (hci_event_flag & HCI_FLAG_INCOMING_REQUEST)

3. Sending HCI Commands

To send HCI commands such as HCI reset we send a class specific output via the control pipe

// used in control endpoint header for HCI Commands
#define bmREQ_HCI_OUT  USB_SETUP_HOST_TO_DEVICE|USB_SETUP_TYPE_CLASS|USB_SETUP_RECIPIENT_DEVICE
#define HCI_COMMAND_REQ    0  
void hci_reset(void)
{
   hci_event_flag = 0; // clear all the flags
   buf[0] = 0x03;
   buf[1] = 0x0c;
   buf[2] = 0x00;
   HCI_Command(3 , buf);
  return;
}
//perform HCI Command
byte HCI_Command( unsigned int nbytes, char* dataptr ) {
    hci_command_packets--; 
    hci_event_flag &= ~HCI_FLAG_CMD_COMPLETE;
    return( Usb.ctrlReq( BT_ADDR, ep_record[ CONTROL_PIPE ].epAddr, bmREQ_HCI_OUT, HCI_COMMAND_REQ, 0x00, 0x00 ,0, nbytes, dataptr ));
}

4. Bluetooth HCI Utility
Our first sketch to access the Bluetooth dongle will be a utility to gather data from the Bluetooth dongle itself and also to make Bluetooth inquires and connections. The sketch is structured as a state machine to maintain non blocking behavior and so enable the event task to run regularly. The blueutils sketch is loaded into the Arduino, and a CSR bluetooth dongle connected to the USB shield. Running the sketch returns the following over the serial port:

freeMemory() reports:   1513
CSR Initialized
HCI Reset complete
ACL Data Packet Length: 672
SCO Data Packet Length: 48
Total ACL Data Packets: 4
Total SCO Data Packets: 1
HCI Version:            3
HCI Revision:           3164
LMP Version:            3
Manufacturer Id:        10
LMP Subversion:         3164
Local Name:
Local Bluetooth Address:  00158316C075
Search for devices
Search complete
Devices Found :         0
Wait for Incoming Connect Request

This confirms we are talking to the dongle and gives useful information especially the bluetooth address hardcoded into the dongle.

5. Connecting Wiimote Game Controller
The connection process is different for the Wiimote and the PS3, so we will look at these in turn.

The wiimote has two methods of connection know as soft connect and hard connect. We look at the soft connect mode here. In soft connect mode a connection is made from the Arduino to the Wiimote, and to enable this the Bluetooth address of the wiimote must be discovered.

The blueutils sketch is run again, and when the message comes on the serial port of “Search for devices”, the “1″ and “2″ buttons on the Wiimote are pressed simultaneously. The search will take about 10 seconds and at the end return something similar to:

freeMemory() reports: 1513
CSR Initialized
HCI Reset complete
ACL Data Packet Length: 672
SCO Data Packet Length: 48
Total ACL Data Packets: 4
Total SCO Data Packets: 1
HCI Version:            3
HCI Revision:           3164
LMP Version:            3
Manufacturer Id:        10
LMP Subversion:         3164
Local Name:
Local Bluetooth Address:  00158316C075
Search for devices
Search complete
Devices Found :         1
Found BDADDR: 0022AA8A06A3  Class:  042500  Mode: 1 Offset: 69C9 

Remote Name:  0 Nintendo RVL-CNT-01
Connected to device

Here the Arduino has found the Wiimote and used the discovered Bluetooth Address to make a connection to it.

6. Connecting PS3 Game Controller
The PS3 Game Controller connection process is the other way round. The PS3 controller make the connection to the Arduino. The PS3 controller does not respond to requests for inquiry or connection.

To initate the connection the PS3 controller needs to know the Bluetooth Address of the Arduino. MotioninJoy can be used to set a USB dongle address into the PS3 contoller or alternatively sixpair.c under linux. These read the USB dongle bluetooth address and set this into the PS3 controller.

Since we know the Arduino Bluetooth address from the utility above “Local Bluetooth Address: 00158316C075″ and we have ability using PS3LCD or the PS3 library to set the host Bluetooth Address, we can also use that method.

When the PS3 is programmed with the correct USB dongle Bluetooth address, the following is dsplayed when the “PS” buuton on the PS3 Game Controler is pressed at the “Wait for Incoming Connect Request” prompt.

freeMemory() reports:   1513
CSR Initialized
HCI Reset complete
ACL Data Packet Length: 672
SCO Data Packet Length: 48
Total ACL Data Packets: 4
Total SCO Data Packets: 1
HCI Version:            3
HCI Revision:           3164
LMP Version:            3
Manufacturer Id:        10
LMP Subversion:         3164
Local Name:
Local Bluetooth Address:  00158316C075
Search for devices
Search complete
Devices Found :         0
Wait for Incoming Connect Request
Connected to device

This is the second part of a series of articles written to describe development of interface between Arduino and popular game controllers using USB Host Shield. Previous parts:

Revision 0.6 – 13th January 2010

Part 2: Develop the USB interface to the PS3 controller

1.       USB Reduced Hosts

Full USB hosts such as Windows [...]]]>

Sony PS3 controller

This is the second part of a series of articles written to describe development of interface between Arduino and popular game controllers using USB Host Shield. Previous parts:

• Part 1. Introduction

Revision 0.6 – 13th January 2010

Part 2: Develop the USB interface to the PS3 controller

1.       USB Reduced Hosts

Full USB hosts such as Windows and Linux based computers can manage a large variety of different USB devices and load appropriate USB drivers for each device. There is an enumeration or discovery phase where the host gathers information on the attached USB device and uses this information for the driver selection and configuration. In small embedded applications this is not possible or required to support this variety, so the application usually only supports a few devices, often only one. This means the discovery process can be much reduced since the results are already known. This will reduce the memory required for the application by hard coding the device configuration into the application.

Though the configuration will be hard coded, we still need to initially gather the information from the device itself and other sources.

The existing device drivers mentioned above for Windows and Linux are important in our development process. The Windows drivers are usually complete, but not available in source form. Linux drivers are available in source form, though not always as complete. Device manufacturers are usually very reluctant to provide information required to build a driver or embedded application. So we rely on copying Linux code or “sniffing” Windows code to give us guidance.

 2.        PS3 Game Controller USB Interface

The first thing is to get the device and configuration descriptors. This may be documented, but often not, so we will collect direct from the USB device itself. This may be done under Windows using a program such as USBView or using the Arduino and the host shield.

Using USBView: USBView Software

The PS3 controller is connected to the PC and then selected in USBView. The following descriptor information is delivered for the Sony PS3 controller when connected via USB.

Device Descriptor:
bcdUSB:             0x0200
bDeviceClass:       0x00
bDeviceSubClass:    0x00
bDeviceProtocol:    0x00
bMaxPacketSize0:    0x40 (64)
idVendor:           0x054C (Sony Corporation)
idProduct:          0x0268
bcdDevice:          0x0100
iManufacturer:      0x01
iProduct:           0x02
iSerialNumber:      0x00
bNumConfigurations: 0x01
ConnectionStatus:   DeviceConnected
Current Config Value: 0x01
Device Bus Speed:   Full
Device Address:     0x01
Open Pipes:         2
Endpoint Descriptor:
bEndpointAddress:   0x02
Transfer Type:      Interrupt
wMaxPacketSize:     0x0040 (64)
bInterval:          0x01
Endpoint Descriptor:
bEndpointAddress:   0x81
Transfer Type:      Interrupt
wMaxPacketSize:     0x0040 (64)
bInterval:          0x01

The report shows two additional endpoints besides the control endpoint (endpoint 0). The first of these is an input endpoint (0×02) and is where the host will receive reports from the PS3 game controller when anything changes. The second (0×81) is an output endpoint and is where the host can send reports to the PS3 controller, though these can also be sent via special messages on the control endpoint 0.

Taking the same report for the Madcatz PS3 shows that it also has almost identical information. It also shows with identical idVendor and idProduct. The only difference is in the MaxPacketSize0 which is 8 for the Madcatz. This difference is managed automatically by the USB library.

To read the device and configuration descriptors using the Arduino, we install the USB Host Shield and download the following USB_Desc sketch. The sketch uses this Modified USB Host Library. The library was modified from the version from Oleg to give a longer time for the device to deliver the descriptors. However in the non blocking code we need later, we also need sometimes not to wait at all. Therefore an additional change is made to allow for waiting or not.

The sketch reports the following descriptors with a bit more detail:

Start
freeMemory() reports 683
Device descriptor:
Descriptor Length:    12
Descriptor type:      01
USB version:          0200
Device class:         00
Device Subclass:      00
Device Protocol:      00
Max.packet size:      40
Vendor  ID:           054C
Product ID:           0268
Revision ID:          0100
Mfg.string index:     01
Prod.string index:    02
Serial number index:  00
Number of conf.:      01
Configuration descriptor:
Total length:         0029
Num.intf:             01
Conf.value:           01
Conf.string:          00
Attr.:                80
Max.pwr:              FA
Interface descriptor:
Intf.number:          00
Alt.:                 00
Endpoints:            02
Intf. Class:          03
Intf. Subclass:       00
Intf. Protocol:       00
Intf.string:          00
Unknown descriptor:
Length:               09
Type:                 21
Contents:             110100012294000705
Endpoint descriptor:
Endpoint address:     02
Attr.:                03
Max.pkt size:         0040
Polling interval:     01
Endpoint descriptor:
Endpoint address:     81
Attr.:                03
Max.pkt size:         0040
Polling interval:     01
memoryMin() reports 336

Also here you see the reports from freeMemory and memoryMin(), which for this example were added to check the memory consumption of the USB stack. These are not usually present in the report. There is also an unknown report which is a class report for the HID device. The large difference between freeMemory and memoryMin in this example is due to a 256 byte buffer being defined for the configuration data plus there is also about 100 bytes of stack in data memory used by the USB library. The text strings were moved to program memory with a special print function, otherwise it would not fit into the available data memory of an ATMega168.

 
3.           Configuring the USB library to connect the PS3 game Controller

Having obtained the descriptor information, this is coded into the USB configuration of the USB library. The library requires a structure for each endpoint to contain this data and this structure is then provided to the library using the Usb.setDevTableEntry() function. 

/* Endpoint information structure               */
 
/* bToggle of endpoint 0 initialized to 0xff    */
 
/* during enumeration bToggle is set to 00      */
 
typedef struct {       
 
    byte epAddr;        //copy from endpoint descriptor without bit 7 if set
 
    byte Attr;          // Endpoint transfer type.
 
    unsigned int MaxPktSize;    // Maximum packet size.
 
    byte Interval;      // Polling interval in frames.
 
    byte sndToggle;     //last toggle value, bitmask for HCTL toggle bits
 
    byte rcvToggle;     //last toggle value, bitmask for HCTL toggle bits
 
} EP_RECORD;

We then also make a check to confirm that the device connected is the one which we support by checking the VID and PID in the device descriptor.If this is successful we set the configuration for the device and then we have three pipes connected to the PS3 device from the Arduino and communication is established.

device_descriptor = (USB_DEVICE_DESCRIPTOR *) &buf;
 
    if(
 
    (device_descriptor->idVendor != PS3_VID) ||(device_descriptor->idProduct != PS3_PID)  ) {
 
        Serial.println("Unsupported USB Device");
 
          while(1);  //stop  

 4.        Communication with the Game controller from a sketch

Having established communication we now have to send commands and receive reports in the format the PS3 game controller requires. This format is somewhat described in the documents mentioned in the first article and emulated in the software for linux and python. This information was probably obtained from “sniffing” the interaction of the game controller to a PS3. I do have a USB sniffer from Ellisys which could connect between a PS3 and the controller, but I do not have a PS3. So I relied on published information and also “sniffed” the connection between the game controller and a PC running the Motioninjoy software.

Motioninjoy is probably the most complete PC application to support the PS3 controller so should offer the best information. To sniff the connection I used a PC based program called SnoopyPro

Between the setting of the configuration and the receipt of data on the input pipe , there are two commands sent to the PS3 game controller. The first sets the game controller to send 01 type reports to the input pipe whenever any changes occur on the controller.
SetupPacket:
0000: 21 09 f4 03 00 00 04 00
bmRequestType: 21
DIR: Host-To-Device
TYPE: Class
RECIPIENT: Interface
bRequest: 09
TransferBuffer: 0×00000004 (4) length
0000: 42 0c 00 00

This can be performed using the USB library by:

#define PS3_F4_REPORT_LEN 4
#define HID_REPORT_FEATURE 3
#define PS3_F4_REPORT_ID  0xF4
prog_char feature_F4_report[] PROGMEM = {0x42, 0x0c, 0x00, 0x00};
 
  /* Set the PS3 controller to send reports */
    for (i=0; i<PS3_F4_REPORT_LEN; i++) buf[i] = pgm_read_byte_near( feature_F4_report + i);
    rcode = Usb.setReport( PS3_ADDR, ep_record[ CONTROL_PIPE ].epAddr, PS3_F4_REPORT_LEN,  PS3_IF, HID_REPORT_FEATURE, PS3_F4_REPORT_ID , buf );
    if( rcode ) {
        Serial.print("Set report error: ");
        Serial.println( rcode, HEX );
        while(1);  //stop
    }

Here the report content was held in program memory.

The second command packet is not essential, but sets the LEDs on the game controller so that it stops flashing and goes to light LED 1 constantly. This command is developed later to control all the LED and rumble. 

SetupPacket:

0000: 21 09 01 02 00 00 30 00

bmRequestType: 21

  DIR: Host-To-Device

  TYPE: Class

  RECIPIENT: Interface

bRequest: 09 

TransferBuffer: 0×00000030 (48) length

0000: 00 ff 00 ff 00 00 00 00 00 02 ff 27 10 00 32 ff

0010: 27 10 00 32 ff 27 10 00 32 ff 27 10 00 32 00 00

0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

This can be performed using the USB library by: 

#define PS3_01_REPORT_LEN 48
#define HID_REPORT_OUTPUT  2
#define PS3_01_REPORT_ID  0x01
prog_char output_01_report[] PROGMEM = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                                     0x00, 0x02, 0xff, 0x27, 0x10, 0x00, 0x32, 0xff,
                                     0x27, 0x10, 0x00, 0x32, 0xff, 0x27, 0x10, 0x00,
                                     0x32, 0xff, 0x27, 0x10, 0x00, 0x32, 0x00, 0x00,
                                     0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                                     0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
};
 
   /* Set the PS3 controller LED 1 On */
    for (i=0; i<PS3_01_REPORT_LEN; i++) buf[i] = pgm_read_byte_near( output_01_report + i);
    rcode = Usb.setReport( PS3_ADDR, ep_record[ CONTROL_PIPE ].epAddr, PS3_01_REPORT_LEN,  PS3_IF, HID_REPORT_OUTPUT, PS3_01_REPORT_ID , buf );
    if( rcode ) {
        Serial.print("Set report error: ");
        Serial.println( rcode, HEX );
        while(1);  //stop
    }

01 type reports can now be read from the input pipe using: 

/* Poll PS3 interrupt pipe and process result if any */
 
void PS3_poll( void )
 
{
    byte rcode = 0;     //return code
    /* poll PS3 */
    rcode = Usb.inTransfer(PS3_ADDR, ep_record[ INPUT_PIPE ].epAddr, PS3_01_REPORT_LEN, buf );
    if( rcode != 0 ) {
       return;
    }
    process_report();
    return;
}

5.        Interpreting and using PS3 reports

The 01 type reports are formatted as follows:

//Structure which describes the type 01 input report
typedef struct {
    unsigned char ReportType;     //Report Type 01
    unsigned char Reserved1;      // Unknown
    unsigned int  ButtonState;    // Main buttons
    unsigned char PSButtonState;  // PS button
    unsigned char Reserved2;      // Unknown
    unsigned char LeftStickX;     // left Joystick X axis 0 - 255, 128 is mid
    unsigned char LeftStickY;     // left Joystick Y axis 0 - 255, 128 is mid
    unsigned char RightStickX;    // right Joystick X axis 0 - 255, 128 is mid
    unsigned char RightStickY;    // right Joystick Y axis 0 - 255, 128 is mid
    unsigned char Reserved3[4];   // Unknown
    unsigned char PressureUp;     // digital Pad Up button Pressure 0 - 255
    unsigned char PressureRight;  // digital Pad Right button Pressure 0 - 255
    unsigned char PressureDown;   // digital Pad Down button Pressure 0 - 255
    unsigned char PressureLeft;   // digital Pad Left button Pressure 0 - 255
    unsigned char PressureL2;     // digital Pad L2 button Pressure 0 - 255
    unsigned char PressureR2;     // digital Pad R2 button Pressure 0 - 255
    unsigned char PressureL1;     // digital Pad L1 button Pressure 0 - 255
    unsigned char PressureR1;     // digital Pad R1 button Pressure 0 - 255
    unsigned char PressureTriangle;   // digital Pad Triangle button Pressure 0 - 255
    unsigned char PressureCircle;     // digital Pad Circle button Pressure 0 - 255
    unsigned char PressureCross;      // digital Pad Cross button Pressure 0 - 255
    unsigned char PressureSquare;     // digital Pad Square button Pressure 0 - 255
    unsigned char Reserved4[3];   // Unknown
    unsigned char Charge;         // charging status ? 02 = charge, 03 = normal
    unsigned char Power;          // Battery status ?
    unsigned char Connection;     // Connection Type ?
    unsigned char Reserved5[9];   // Unknown
    unsigned int AccelerometerX;  // X axis accelerometer Big Endian 0 - 1023
    unsigned int Accelero         // Y axis accelerometer Big Endian 0 - 1023
    unsigned int AccelerometerZ;  // Z axis accelerometer Big Endian 0 - 1023
    unsigned int GyrometerX;      // Z axis Gyro Big Endian 0 - 1023
 
} TYPE_01_REPORT;

The state of the game controller buttons is contained in the ButtonState and PSButtonState variables mapped as follows: 

#define buSelect    (PS3Report->ButtonState & 0x0001)
#define buLAnalog   (PS3Report->ButtonState & 0x0002)
#define buRAnalog   (PS3Report->ButtonState & 0x0004)
#define buStart     (PS3Report->ButtonState & 0x0008)
#define buUp        (PS3Report->ButtonState & 0x0010)
#define buRight     (PS3Report->ButtonState & 0x0020)
#define buDown      (PS3Report->ButtonState & 0x0040)
#define buLeft      (PS3Report->ButtonState & 0x0080)
#define buL2        (PS3Report->ButtonState & 0x0100)
#define buR2        (PS3Report->ButtonState & 0x0200)
#define buL1        (PS3Report->ButtonState & 0x0400)
#define buR1        (PS3Report->ButtonState & 0x0800)
#define buTriangle  (PS3Report->ButtonState & 0x1000)
#define buCircle    (PS3Report->ButtonState & 0x2000)
#define buCross     (PS3Report->ButtonState & 0x4000)
#define buSquare    (PS3Report->ButtonState & 0x8000)
#define buPS        (PS3Report->PSButtonState & 0x01)

The Accelerometer and Gyro values are in Big Endian format and need byte swapping before use as an unsigned integer value.

The following example program shows how the values can be used from the report. The example used the LCD display connected to the USB Host Shield. The example also controls the LED and rumble motors. This example does not use the library described below. PS3 LCD sketch.

A menu item is provided in the example to read and set the Bluetooth Device Address of the Game controller. This is used in the pairing process for the game controller when in Bluetooth mode. This setup can alternatively be done with sixpair.c under linux, or Motioninjoy under windows.

6.        A PS3 Game Controller Library

The PS3_USB library adds support for the Sony PS3 Game controller to the Arduino by USB cable on the USB Host Shield from Circuits@Home. It allows a sketch to gather information from the PS3 Game Controller including buttons, joysticks and accelerometers. It also allows output to the LED and rumble features of the Game controller. Additional function is provided to read and write Bluetooth addresses for pairing in Bluetooth mode.

The library requires the USB Host Shield to be installed and uses the libraries developed for the shield, it is not compatible with other USB ports at present. The shield and the libraries do consume memory considerable resources on the Arduino; though they can be supported on most Arduino variants even the ATMega168 based boards with 1K of RAM.

Connections:
The USB Host shield is assembled and links configures depending on the Arduino variant used. The shield supports 3.3V and 5V Arduino in different configurations. The GPIO connections are not required by this library, but another library MaxLCD exists to support an optional LCD display on this interface if required. The USB Host shield uses digital pins D7 through D13 and these pins are not available to the sketch for other purposes. Power for the USB device is derived from the Arduino, so sufficient power must be provide from the USB or external power supply.
The Sony PS3 Game controller is connected by USB cable to the USB A connector on the host shield. The library is tested with the Sony Controller PS3 Game controller and also the Madcatz wireless PS3 game controller which is wireless connected from the game controller to a Madcatz USB dongle. The Madcatz does not support the rumble feature.

Methods:

void init(void);

A method to perform low level initialisation of the PS3 class, should be called in the setup() function to perform hardware initialisation of the USB Host Shield before calling task().

void task( void );

This method must be called regularly to manage the all events occurring on the USB port. Calls to this routine should be made in the range of once per millisecond to 20 times per second. The report data from the PS3 Game Controller will not be available if this routine is not called regularly.

unsigned char getStatus(void);

This method returns an unsigned character to show the status of the USB and PS3 connection. Bits are used as follows:
bit 0: statusDeviceConnected Set when a USB device is plugged into the USB port on the Host Shield
bit 1: statusUSBConfigured Set when a valid PS3 device is detected and configured
bit 2: statusPS3Connected Set when the PS3 device is connected and sending reports based on changes on the controller (buttons pressed, joystick moved,..)
bits 3: statusReportReceived Set when a report is received from the PS3 controller that a change has occurred on one of the parameters. This bit is cleared by the stat_report_received() method;

bool statConnected(void);

This method returns the state of the statusPS3Connected bit for the attached device.

bool statReportReceived(void);

This method returns the state of the statusReportReceived bit for the attached device. Calling this method also clears the bit if set.

bool buttonChanged(void);

This method returns true if a Game Controller button has been pressed or released, since the last call to this method.

bool buttonPressed(unsigned char button);

This method returns the state of the Game Controller button specified in the call. True if button pressed. Buttons are:

#define buSelect 0
#define buLAnalog 1
#define buRAnalog 2
#define buStart 3
#define buUp 4
#define buRight 5
#define buDown 6
#define buLeft 7
#define buL2 8
#define buR2 9
#define buL1 10
#define buR1 11
#define buTriangle 12
#define buCircle 13
#define buCross 14
#define buSquare 15
#define buPS 16

void LEDRumble(unsigned char ledrum);

This method sets the state of the LEDs and rumble motors on the Game Controller. Ledrum values are:

#define psLED1 0x01
#define psLED2 0x02
#define psLED3 0x04
#define psLED4 0x08
#define psRumbleHigh 0x10
#define psRumbleLow 0x20

unsigned int getMotion(unsigned char accel);

This method returns the value read from the accelerometer or Gyro in the Game Controller. Values are in range 0 to 1023 with 512 as centre. Accel values are:

#define AccelerometerX 0
#define AccelerometerY 1
#define AccelerometerZ 2
#define GyrometerZ 3

unsigned char getJoystick(unsigned char joystick);

This method returns the value read from the joystick on the Game Controller. Values are in range 0 to 255. Joystick values are:

#define leftJoystickX 0
#define leftJoystickY 1
#define rightJoystickX 2
#define rightJoystickY 3

unsigned char getPressure(unsigned char button);

This method returns the value read for the button pressure on the Game Controller. Values are in range 0 to 255. Button values are:

#define buUp 4
#define buRight 5
#define buDown 6
#define buLeft 7
#define buL2 8
#define buR2 9
#define buL1 10
#define buR1 11
#define buTriangle 12
#define buCircle 13
#define buCross 14
#define buSquare 15

void setBDADDR(unsigned char * bdaddr);

This method sets the master Bluetooth address to the PS3 Game Controller. The master Bluetooth address is the address where the Game controller will attempt to make a Bluetooth connection when pairing. Bdaddr[6] is a six unsigned char array containing the Bluetooth address with least significant byte first.

void getBDADDR(unsigned char * bdaddr);

This method gets the master Bluetooth address in the PS3 Game Controller. The master Bluetooth address is the address where the Game controller will attempt to make a Bluetooth connection when pairing. Bdaddr[6] is a six unsigned char array containing the Bluetooth address with least significant byte first.

Memory usage:
The library is fairly complex and takes about 5000 bytes of program memory depending on the methods actually used. Due to the complexity and data buffers the data memory usage is about 350 bytes. Since no warning is generated at compile time of data memory usage, care should be taken to monitor and manage consumption. MemoryFree() can be used to check data memory usage. While this fits onto the AtMega168, it may be better to use a larger device if additional code/libraries are complex or if a large number of serial.print() functions are used.

Example sketch:
The test sketch included in the download demonstrates many of the capabilities of the library.
Get Arduino PS3 Library here

Bluetooth

Part 1: Introduction

1.       Background These articles describe how to interface PS3 and Wiimote game controllers directly onto the Arduino using the USB Host Shield. These controllers have not previously been directly connected to an Arduino due to the USB and Bluetooth interfaces and protocols used, and their relative complexity. The [...]]]>

Bluetooth

Part 1: Introduction

1.       Background
These articles describe how to interface PS3 and Wiimote game controllers directly onto the Arduino using the USB Host Shield. These controllers have not previously been directly connected to an Arduino due to the USB and Bluetooth interfaces and protocols used, and their relative complexity. The game controllers are a good match to the capabilities of the Arduino, and to the imagination of Arduino users, they have not only buttons and joysticks, but also motion sensing, and other goodies which deserve to be in the hands and ideas of Arduino users. Also I hope these articles provide some guidance for people to develop other USB host and Bluetooth applications for small embedded processors.
Arduino already comes in versions which have USB and Bluetooth interfaces, but these are not suitable for our chosen game controllers. When used in USB mode, the PS3 controller is a USB device and needs to talk to a USB host. The normal Arduino USB interface is also a device, so not compatible. When in Bluetooth mode, both of these game controllers use the Bluetooth HID protocol and this is not compatible with the commonly used Bluetooth modules which support only the RFCOMM Serial Port Protocol. Arduino users have successfully used a PC as an intermediary between the game controllers and the Arduino, so the PC is host to both devices.

These articles were written by Richard who is new to the Arduino, blogs, github, libraries, etc, so please give me any help and feedback on how I might improve or correct these articles and software.

This video shows the PS3 controller and the Wiimote bluetooth working on the basic Atmega168 Arduino.
Introduction Youtube Video

Recently a new Arduino shield has been developed by Oleg here at Circuits@Home, which provides a USB host interface directly onto the Arduino. This shield is based on the MAX3421E USB controller IC from Maxim, which can operate in both device and host modes. Oleg has also created libraries for the basic functions of the MAX3421E and USB host operation. I have previously used the MAX3421E with success on other processors and decided to try to add support for our game controllers using this shield. There are significant challenges to this due to the complexity of the protocols and the limited flash and SRAM space on the base Atmega168 based Arduino.

The code developed here is licensed under the LGPL License and should be fairly easy to port to other USB host controllers. Given the recent explosion in availability of microcontrollers with integrated USB OTG or reduced host, from Atmel, Microchip and others, then I would expect quite a few derived versions.

You will see as the code develops the fairly high complexity of the protocols involved, and such development effort is only really justified in a case like this where no off the shelf alternative has been found. There are integrated USB host solutions from GHI Electronics and FTDI Vinculum, but these again do not support the Bluetooth HID yet. They do support many other devices and classes including mass storage, serial, and HID, they can be interfaced to Arduino and do not put such a drain on the memory and programming of the Arduino.

2.       The PS3 Controller

I have used two PS3 different game controllers; the first is a Sony Six Axis Dual Shock 3 Wireless controller, and the second is the Madcatz Wireless six axis controller. The Sony has a USB connector and also operates in Bluetooth mode for wireless. The Madcatz comes with its own USB dongle, so uses a proprietary wireless protocol instead of Bluetooth. The PS3 controller is well documented and supported already with drivers and applications on Windows and Linux besides the PS3 itself, so there is plenty of interface information available.

 

The PS3 controller has a large number of buttons which can be read as digital values and some as analog pressure values. There are two joysticks which can be read with analog values to 8 bit resolution, and also 4 LED’s which can be remotely controlled. There are additionally a 3 axis accelerometer and a single axis gyro which give outputs based on the motion of the controller. The Sony controller additionally has two rumble motors.

The following sources have been used to find information and code examples for the PS3 controllers:

PS3 Wiki General

PS3 using Python

PS3 under Linux

SixAxis on Windows

PS3 Windows Driver

3.       Wiimote Controller

The Wiimote has less buttons than the PS3 controller and the characteristic stick shape. Though less well endowed with buttons and joysticks than the PS3 controller it has a 3 axis accelerometer, rumble, Infra-Red Camera, speaker and LED. It also has an expansion port where additional devices including 3 axis Gyro and remote joystick can be connected.

The Wiimote does not have a direct USB connection and only works under Bluetooth.

The following sources have been used to find information and code examples for the Wiimote Controllers:

Wiimote Wiki General

Wiimote Information

Wiimote Wiki: Detail

Wiimote using Linux

4.       Arduino

I chose to use the lowest spec AtMega168 based Arduino and this forced me to be always conscious of the amount of Flash and data memory used. I made extensive use of the MemoryFree library to keep track of the usage of the 1K of RAM. I tried to limit were possible the number and size of data buffers, and to keep the number of text strings as low as possible.

Original MemoryFree

I later modified MemoryFree to allow capture and storage of minimum values. This enables the viewing of free memory at the deepest level of the function calls, where any problems occur.

Modified MemoryFree

 
In terms of processing power the Arduino does not seem to limit performance. Some complexity is added to the code because it is necessary to avoid blocking code. Blocking code would prevent some of the background processes running. These processes are not absolutely time critical, but must be called regularly. The time taken to write a serial string is usually OK, the time to wait for a key press would not be.

5.       USB  Host Shield

The Circuits at Home USB host shield is based on the Maxim MAX3421E USB controller IC. This IC can operate in device and host modes, though the Arduino library only supports the host mode. The USB host shield offers a number of interface options for different Arduino types using 3.3V or 5V power supplies. There is also two 8 bit GPIO ports and a library to support an LCD display on this port.

The USB Host Shield is described and well documented here on the Circuits@Home website.

Full construction information is provided including schematic and PCB layout, or PCB and built boards are available in the on-line store.

The USB shield uses the following Arduino hardware resources which are then not available for other purposes:
Digital Pin 7 used for MAX_RESET
Digital Pin 8 used for GPX
Digital Pin 9/PWM used for INT
Digital Pin 10/PWM used for SS
Digital Pin 11/PWM used for MOSI
Digital Pin 12 used for MISO
Digital Pin 13/LED used for SCLK

Power for the USB host shield is taken from the Arduino and also powers the USB device. Care must be taken to ensure the total supply current required is available from the Arduino and its power source.

The MAX3421 is documented in Datasheets, programming guide, and application notes by Maxim:

MAX3421E Datasheet

MAX3421E Programming Guide

Maxim Application Notes

Oleg at Circuits@Home has provided Arduino libraries for the MAX3421E function and the USB host function. Small modifications were necessary in these to support the game controllers, mainly in the NAK handling to ensure non blocking behaviour. The changes should not interfere with existing applications using the libraries and may be incorporated to the standard library.

USB Host Shield Library

The library is based on code from Maxim for the ARM processor, but this original code is not complete:

Original Maxim ARM Code

USB is a complex protocol and even though much is done automatically by the MAX3421E, some knowledge of the USB protocol is needed. As primers, these are good sources:

USB in a Nutshell

USB Standards

After that the best references are the USB protocol specifications:

USB Specification

USB HID Specifications

6.       Bluetooth Dongles

Bluetooth USB dongles come from many suppliers and there is no way to support them all in a simple embedded application. I have used devices which are based on the Cambridge Silicon Radio(CSR) Bluecore 4. These devices are common and low cost at less than $5 each. The dongle is used is based on the BC41B143A chip. The data sheet is here:

BC41B143A Datasheet

The dongle conforms to the Bluetooth specification for an HCI interface and is available here:

Bluetooth 2.0 Specification

Bluetooth HID Specification

The dongle used came packaged like this:

 
A more general Bluetooth protocol tutorial is available from palowireless.

7.       My Development Process and Following Articles

I decided to split the development and these articles into the following steps:

Part 2: Develop the USB interface to the PS3 controller. This allowed me to gain experience of the Arduino and the USB shield. It also provides a quick working wireless solution using the Madcatz game controller.

Part 3: Develop the Bluetooth USB and HCI interface used in the support of the Wiimote and PS3 game controller, and also some utilities needed to analyse and configure these devices.

Part 4: Develop the Wiimote support over Bluetooth

Part 5: Develop the PS3 support over Bluetooth

 
This article is provided under the Creative Commons Share Alike License

Associated software code developed by the author is licensed under the LGPL License.

Another HID example has been added to Github repository of USB Host Shield for Arduino (which you can purchase in my store) . Richard Ibbotson sent me this nice piece of code along with some pictures. He also posted a short description of his sketch in [...]]]>

PS3 controller connected to Arduino USB Host Shield

Another HID example has been added to Github repository of USB Host Shield for Arduino (which you can purchase in my store) . Richard Ibbotson sent me this nice piece of code along with some pictures. He also posted a short description of his sketch in comments section:

I wrote a sketch for the interface of the PS3 controller over USB. I have two controllers, one Sony and one Madcatz wireless with a USB dongle. Both of these work fine to the USB host shield. I only made one minor change to the library to increase the NAK count. The sketch tests all the function, buttons, joysticks, accelerometer/gyro, leds and rumble. This is not yet under bluetooth just USB. I can set the host bluetooth adddress on the controller though which is needed for bluetooth pairing.

Did not make much attempt to reduce code or data size, so only have about 4K of program space and 240 bytes of data space left, but sketch is pretty long. The actual PS3 part is very small and could be made to a small library.

Next is to move to the bluetooth part, from what I have found on the direct USB, I am pretty confident this will fit even on the 168.

PS3 controller support opens some very interesting possibilities. Not only can it be used as a normal “joystick plus buttons” type of control, but you can also utilize it’s accelerometer/gyro. With wireless variant of the controller all kinds of very powerful radio control are possible. Who is going to be the first to make a mechanical dog, which follows you around and brings back the controller when you throw it away?

If you want to try the sketch, make sure you have the latest library code as well – there are some small but important changes made recently in NAK handling.

MadCatz wireless controller to USB Host Shield

Wireless mini keyboard connected to USB Host Shield

Here is an interesting project which uses MAX3421E breakout board to connect XBox360 wireless controller to old Nintendo Entertainment System. Francois Gervais used Cortex-M3 as an interface between Nintendo and a game controller. There are two other videos showing the details of the setup – check them out as well.

I decided to write this article after receiving several e-mails from people who bought my isolator. While setups described in [...]]]>

ADuM4160 PIN pin grounding

Q. I am getting “USB device not recognized” error message – what do I do? Also, since the isolator is soldered into my circuit, “reconnect peripheral” suggestion seems too difficult to follow.

I decided to write this article after receiving several e-mails from people who bought my isolator. While setups described in those e-mails were different, the problem was the same – a PC refusing to recognize the device connected through the isolator. Here I will try to explain what is happening and also share my ideas how to troubleshoot and possibly fix the problem.

When nothing is connected to USB port, the bus is held at ground level with pull down resistors on the host side. USB device, when connected, pulls one of bus lines up, often times also with a resistor connected to Vbus and data line. Host sees it, sends bus reset and tries to query the device. If device is answering, host keeps querying the device and eventually enumerates it. When device is enumerated, application takes over.

If device is not answering (like for example, when self-powered device is turned off), host will give up and post “Device not recognized” message. To get attention from the host, we need to generate bus event, i.e., disconnect the peripheral and connect it back again.

If we are dealing with typical copper-wire-connected USB host and peripheral, which end of USB cable gets disconnected and reconnected would not matter. However, when host and peripheral are talking through ADuM4160, this is not always the case. I tested about 50 different USB devices and found out that while breaking the connection on the peripheral side works every time, host side disconnect does or does not help depending on device.

It is possible to simulate device disconnect without breaking actual connection by pulling PIN pin of ADuM4160 to ground. Normally it is held at 5V by R8 pull up resistor. This resistor is located next to peripheral side USB connector and marked 1M above it. Left side of it, the one right below the “1M” mark is connected to PIN pin (12). The closest ground point is right pad of bypass capacitor, which sits above R8. An experimenter with good eyesight and steady hand can easily connect those two points with tweezers. However, if said experimenter is not feeling comfortable operating tweezers inside powered circuit, a safer arrangement is shown on the title picture.

Disconnecting peripheral, either directly or by driving PIN pin, with power applied to the isolator and host side connected, will most likely solve device detection problem. If you still having issues with the circuit, please let me know, I will try to help.

Oleg.