Circuits@Home

Using Logitech Extreme 3D Pro joystick with Arduino HID library

oleg — Wed, 09 May 2012 07:30:33 +0000

Logitech joystick connected to Arduino

HID report parsing explained in the previous article works pretty well with properly aligned HID reports. The analog controls are placed on a byte or word boundary and buttons occupy dedicated fields. The majority of HID devices are designed this way, however, some other devices are not that simple to interface and today I’m going to show how to handle one of those.

A Logitech Extreme 3D Pro joystick is one nice HID device. It is good looking, well-built, and have a twist handle, which adds third axis to a stick making this model popular among FPV fliers since you can control pitch, roll and yaw with one hand. Also, X and Y axis are 10 bits which gives good precision. There is one problem with this joystick – its input report.

Logitech, in its infinite wisdom, decided to pack all the high and low resolution analog controls plus 12 buttons in 6 bytes of input report. The report looks like this – 10 bits of X, 10 bits of Y, and 4 bits of hat switch. After that, things become easier – one byte of Rz AKA “twist handle”, one byte of buttons, one byte of throttle (called “slider” in the report), and finally, one partially filled byte holding the rest of the buttons. Take a look at the screenshot below – two most important controls are not byte aligned, therefore, simple straightforward parsing of the report is not possible. Also, USBHID_descr won’t show this report correctly.

To demonstrate how to deal with this report I wrote a simple Arduino sketch. It was made by modifying an example from the previous article. I also made it as simple as possible – as soon as any of the controls changes its value, new report is printed on the serial terminal. The sample output is shown below followed by code explanation.

Start
HU Init
Addr:1
NC:1
 
Cnf:1
HU configured
 
Buf: FCF18780000000
X: 01FC Y: 01FC Hat Switch: 08 Twist: 80 Slider: 00 Buttons A: 00 Buttons B: 00
 
Buf: FCF18780000200
X: 01FC Y: 01FC Hat Switch: 08 Twist: 80 Slider: 02 Buttons A: 00 Buttons B: 00
 
Buf: FCF18783000200
X: 01FC Y: 01FC Hat Switch: 08 Twist: 83 Slider: 02 Buttons A: 00 Buttons B: 00
 
Buf: FCF18786000200
X: 01FC Y: 01FC Hat Switch: 08 Twist: 86 Slider: 02 Buttons A: 00 Buttons B: 00

The first important piece of the code is the report representation. To be able to access every control the following structure has been declared – compare it with the screenshot produced by my trusty Totalphase Beagle USB protocol analyzer:

struct GamePadEventData
{
  union { //axes and hut switch
    uint32_t axes;
    struct {
      uint32_t x : 10;
      uint32_t y : 10;
      uint32_t hat : 4;
      uint32_t twist : 8;      
    };
  };
  uint8_t buttons_a;
  uint8_t slider;
  uint8_t buttons_b;
};

Logitech input report

The Parse() method works similarly to the original code – it receives the report from the device and compares it with the stored copy of the previous reading. If reports are different, OnGamePadChanges() is called, which simply prints the report on the terminal. It can easily be modified to do something useful like change PWM pulse width to control motor speed, servo pulse or generate analog signal.

void JoystickReportParser::Parse(HID *hid, bool is_rpt_id, uint8_t len, uint8_t *buf)
{
	bool match = true;
 
	// Checking if there are changes in report since the method was last called
	for (uint8_t i=0; i<RPT_GAMEPAD_LEN; i++) {
		if( buf[i] != oldPad[i] ) {
			match = false;
			break;
		}
  }
  	// Calling Game Pad event handler
	if (!match && joyEvents) {
		joyEvents->OnGamePadChanged((const GamePadEventData*)buf);
 
		for (uint8_t i=0; i<RPT_GAMEPAD_LEN; i++) oldPad[i] = buf[i];
	}
}

This simple technique is very helpful when dealing with awkward reports. If you need help with parsing output from your HID reports or would like to see more detailed explanation of the code, please let me know.

Oleg.

Adjusting inverter control in Tektronix 7104 oscilloscope power supply

oleg — Mon, 23 Apr 2012 23:53:45 +0000

Access to 109V test point

In this short article I want to share a trick that I learned today while checking the power supply of my trusty Tektronix 7104 oscilloscope. Step A2 of calibration section of the manual calls for measuring/adjusting of pre-regulated 109V voltage on TP1326 test point. Typically, test point access for this step requires removing power supply cover which takes time and exposes high voltages. The test setup presented on a title picture( click on it to make it bigger) shows how to access this test point leaving power supply cover in place.

The power supply cover is at ground potential so don’t try to reach the test point with non-insulated probe. I used Tektronix Klip Chip IC probe threaded through nearby ventilation hole to grab the test point post. The post is clearly seen through a larger hole, through which an adjustment potentiometer R1293 is usually accessed. A flashlight is handy.

Next picture shows the closeup of the test connection. A test probe is supported by a “Third Hand” thingy – I wanted to observe voltage fluctuations in the course of two hours to make sure it stays within limits.

I’m hoping this trick will be useful for somebody dealing with similar power supply.

Oleg.

Developing Arduino code for HID Joystick

alex — Tue, 03 Apr 2012 16:06:02 +0000

This article focuses on how to use the existing USB code library and HID report descriptor info to implement joystick functionality. Human readable HID report descriptor and report information can be easily obtained using USBHID_desc.pde sketch – see previous article for details. This information will help you getting field details such as size and count info. Also, if you don’t have Arduino Mega or 2560 to run USBHID_desc, report descriptor for your device can be obtained using one of many PC tools known as USB analyzers, or even the official usb.org device verification tool. This article is written by Alex Glushchenko – a developer behind second revision of USB Host Library as well as majority of device support code.

As you may already know report is a data structure used by HID device to return the information about the certain device parameters such as joystick coordinates or button events, or receive new settings such as switching on/off LEDs on keyboard.

Report descriptor is a data structure which describes report or reports, if there are few in number, field sequence, sizes and counts. Each report descriptor consists of several items. Each item describes some field property. I am not going too deep into details on items, explaining only the most important ones which are absolutely necessary in writing your own report parser.

The items usually describe type of field (input/output/feature), minimum, maximum field values, units, value meaning (usage) etc.

The joystick I’m using can be seen on title picture (click on it to make it bigger). Here is how my joystick report descriptor looks like:

Usage Page Gen Desktop Ctrls(01)
Usage Game Pad
Collection Application
Collection Logical
Report Size(08)
Report Count(05)
Logical Min(00)
Logical Max(FF00)
Physical Min(00)
Physical Max(FF00)
Usage X
Usage Y
Usage Z
Usage Z
Usage Rz
Input(00000010)
Report Size(04)
Report Count(01)
Logical Max(07)
Physical Max(3B01)
Unit(14)
Usage Hat Switch
Input(01000010)
Unit(00)
Report Size(01)
Report Count(0C)
Logical Max(01)
Physical Max(01)
Usage Page Button(09)
Usage Min(01)
Usage Max(0C)
Input(00000010)
Usage Page Undef(00)
Report Size(01)
Report Count(08)
Logical Max(01)
Physical Max(01)
Usage
Input(00000010)
End Collection
Collection Logical
Report Size(08)
Report Count(07)
Physical Max(FF00)
Logical Max(FF00)
Usage
Output(00000010)
End Collection
End Collection

It may look puzzling at first sight, but soon it is going to look more clear to you. HID specification makes it possible for any host to know exactly what the certain report field means by introducing usages and usage tables.

Usage table specifies all possible controls and device setting IDs for a given class of devices, such as game controllers.

So, analyzing report descriptor dump you have to pay attention to usage table, usage, report size, report count, input and output items.

Now let’s see what we have in the dump. First we have five (line 6) input (line 16) fields X, Y, Z, Z, Rz for Game Pad (lines 11-15), 8-bit in size each (line 5), followed by 4-bit Hat Switch field, 12 buttons, 1-bit each, 8-bit field with unknown usage. 64 bit in total which is 8 bytes. You don’t have to calculate Output items unless you plan to make use of output report.

Now let me explain some details. Each report field or group of fields with the same properties is described by a number of items. Each field explanation ends with an Input, Output or Feature item. Take another look at the dump. Game Pad fields are five in number which is specified by Report Count(05), 8 bit in size Report Size(08) and individual usages for X, Y, Z, Z and Rz. Hat Switch is one field 4-bit in size, 12 buttons are described by Usage Page Button(09) and usage range specified by Usage Min(01) and Usage Max(0C).

Now you know how to interpret report descriptor dump. Let’s go down to code. There is a sample sketch called USBHIDJoystick.pde which we are going to look at. Just make sure you have the latest version of the USB Host library downloaded. With the current version of the USB Host library you do not have to write all the code from scratch, use HIDUniversal class to reuse the main functionality responsible for USB interaction. You have to inherit HIDReportParser class to implement report parser functionality and provide its address by SetReportParser method to HIDUniversal class instance. Files hidjoystickrptparser.h and hidjoystickrptparser.cpp contain all the interesting code.

struct GamePadEventData
{
	uint8_t X, Y, Z1, Z2, Rz;
};
 
class JoystickEvents
{
public:
	virtual void OnGamePadChanged(const GamePadEventData *evt);
	virtual void OnHatSwitch(uint8_t hat);
	virtual void OnButtonUp(uint8_t but_id);
	virtual void OnButtonDn(uint8_t but_id);
};
 
#define RPT_GEMEPAD_LEN		5
 
class JoystickReportParser : public HIDReportParser
{
	JoystickEvents		*joyEvents;
 
	uint8_t				oldPad[RPT_GEMEPAD_LEN];
	uint8_t				oldHat;
	uint16_t			oldButtons;
 
public:
	JoystickReportParser(JoystickEvents *evt);
 
	virtual void Parse(HID *hid, bool is_rpt_id, uint8_t len, uint8_t *buf);
};

Now consider Parse() method functionality. Because the event buffer allocated for the report is pretty large and the size of my joystick report is only 8 byte long, Parse() is called only once per each report.

void JoystickReportParser::Parse(HID *hid, bool is_rpt_id, uint8_t len, uint8_t *buf)
{
	bool match = true;
 
	// Checking if there are changes in report since the method was last called
	for (uint8_t i=0; i<RPT_GEMEPAD_LEN; i++)
		if (buf[i] != oldPad[i])
		{
			match = false;
			break;
		}
 
	// Calling Game Pad event handler
	if (!match && joyEvents)
	{
		joyEvents->OnGamePadChanged((const GamePadEventData*)buf);
 
		for (uint8_t i=0; i<RPT_GEMEPAD_LEN; i++) oldPad[i] = buf[i];
	}
 
	uint8_t hat = (buf[5] & 0xF);
 
	// Calling Hat Switch event handler
	if (hat != oldHat && joyEvents)
	{
		joyEvents->OnHatSwitch(hat);
		oldHat = hat;
	}
 
	uint16_t buttons = (0x0000 | buf[6]);
	buttons <<= 4;
	buttons |= (buf[5] >> 4);
	uint16_t changes = (buttons ^ oldButtons);
 
	// Calling Button Event Handler for every button changed
	if (changes)
	{
		for (uint8_t i=0; i<0x0C; i++)
		{
			uint16_t mask = (0x0001 << i);
 
			if (((mask & changes) > 0) && joyEvents)
				if ((buttons & mask) > 0)
					joyEvents->OnButtonDn(i+1);
				else
					joyEvents->OnButtonUp(i+1);
		}
		oldButtons = buttons;
	}
}

The logic is the same for all report fields. First the report buffer is checked against the previously saved one for the data changes. If changes found the appropriate event handler is invoked with the current state data passed as a function argument. In case of Game Pad the current state data is passed as structure pointer. In case of the Hat Switch the current state is passed as integer value.

Handling buttons is a bit more complicated. Lines 30-33 are responsible for finding out which buttons have changed their states since the last Parse() call. Cycling through each bit of the mask we find out the current state of the changed button. If the button is pressed, OnButtonDn() event handler is called. If the button released, OnButtonUp() event handler is called.

If your joystick report has different structure, all you have to do is modify the Parse method to change fields offsets and sizes. Pretty simple, isn’t it?

The last component of the code is actual event handlers. In this example they simply output game pad, hat switch and button states to the serial console. Again, the body of each function can easily be modified to perform something more useful.

void JoystickEvents::OnGamePadChanged(const GamePadEventData *evt)
{
	Serial.print("X: ");
	PrintHex<uint8_t>(evt->X);
	Serial.print("\tY: ");
	PrintHex<uint8_t>(evt->Y);
	Serial.print("\tZ: ");
	PrintHex<uint8_t>(evt->Z1);
	Serial.print("\tZ: ");
	PrintHex<uint8_t>(evt->Z2);
	Serial.print("\tRz: ");
	PrintHex<uint8_t>(evt->Rz);
	Serial.println("");
}
 
void JoystickEvents::OnHatSwitch(uint8_t hat)
{
	Serial.print("Hat Switch: ");
	PrintHex<uint8_t>(hat);
	Serial.println("");
}
 
void JoystickEvents::OnButtonUp(uint8_t but_id)
{
	Serial.print("Up: ");
	Serial.println(but_id, DEC);
}
 
void JoystickEvents::OnButtonDn(uint8_t but_id)
{
	Serial.print("Dn: ");
	Serial.println(but_id, DEC);
}

The full text of Arduino sketch plus parsers/callbacks is available on GitHub. The code works with USB Host Shield 2.0, it has been tested on Arduino UNO, Mega, as well as Mega 2560. Unlike USBHID_desc this code takes just a little more than 16K of program space. The joystick I use is a random eBay unit (note from Oleg: I have a wireless HID joystick which looks quite differently from this one, however, the report descriptor is the same. If you have similar one, try it – it may work with this code without any modifications). If you’re shopping for a joystick, make sure it has analog game pads, otherwise you will only see values 0×00, 0×80 and 0xff from them. Also, all HID devices are picky about power, if you see strange behaviour while running your Arduino from USB the first thing to do is switch to external supply.

Try this code and if you see any issues or errors, please leave a comment. Also, if you have other HID devices you’d like me to cover, please let me know.

Visualizing HID device reports and report descriptors

oleg — Tue, 03 Apr 2012 00:41:33 +0000

Human Interface Device class of USB devices has a unique property – a report descriptor which contains information about data that device is sending to the host as well as data that can be sent to the device. This property allows for variety of devices – keyboards, mice, joysticks, digital scales, uninterruptible power sources, GPS receivers, and even toy missile launchers to belong to a single class – HID. A vendor just needs to pick a usage table which contains controls similar to vendor’s device – every OS has a generic support for HID devices so in most cases specific device driver is not necessary. The report descriptor again makes this possible – it contains definitions or report fields therefore a generic parser can process reports from any arbitrary HID device. However, this generic parser will take too much space on small microcontroller systems such as Arduino due to the amount of constants that needs to be present in the program code.

It shall be noted that a HID report itself is a simple structure of fixed fields and when this structure is known a very lightweight parser can easily be developed. HID development in legacy USB library has stopped at this point; I thought people will just take a look at the spec and write report parser for their device. It soon became evident that very few are actually willing to do this and in rev.2.0 of the library the HID report parsing is semi-automatic – a report descriptor has to be analyzed first using USBHID_desc utility presented in this article and then actual reports for the device can be parsed using library facilities (an article about coding report parsing is here).

Even though report descriptor parsing is moved to a separate utility, it is still a heavy load for Arduino. The code, which at present only contains strings for keyboards, mice and joysticks, won’t fit into 32K Arduino – a Mega or 2560 is necessary. A screenshot of descriptor report output of a typical mouse can be seen on title picture. The explanation follows.

Usage Page Gen Desktop Ctrls(01)
Usage Mouse
Collection Application
Usage Pointer
Collection Physical
Usage Page Button(09)
Usage Min(01)
Usage Max(03)
Logical Min(00)
Logical Max(01)
Report Size(01)
Report Count(03)
Input(00000010)
Report Size(05)
Report Count(01)
Input(00000001)
Usage Page Gen Desktop Ctrls(01)
Usage X
Usage Y
Usage Wheel
Logical Min(81)
Logical Max(7F)
Report Size(08)
Report Count(03)
Input(00000110)
End Collection
End Collection

Mouse buttons are defined first. We can see that it is input item (line 13). They are buttons (line 6), which is also confirmed by logical min and max (line 9,10) – only two values, 0 and 1, are possible. The report size is one bit (line 11) and number of buttons is 3 (line 12).

The next item (line 16) is a filler for the rest of the first byte. It specifies one (line 15) 5-bit (line 14) report with no minimums or maximums.

The last report (line 25) specifies X-axis, Y-axis and wheel (lines 18-20). 3 reports (line 24) has been specified, one byte each (line 23).

That’s all we need to know about the device in order to communicate to it. For the curious, detailed explanation of these and all other fields in this report can be found in USB specifications listed on usb.org HID page. Device Class Definition and HID Usage Tables are two most important docs.

USBHID_desc also can parse HID reports on the fly. In order to generate some reports I’m going to move my mouse and observe the results. Here’s what happens when I move it vertically:

Buf: 00000100
 Mouse Pointer Btn1(00) Btn2(00) Btn3(00)
(00)
 X Y Wheel(00)(01)(00)

Line 1 shows the raw report, 4 bytes in length. Line 2 shows state of the buttons, none of them pressed. Line 3 shows state of the “filler” report; since it doesn’t have usage page assosciated with it, it doesn’t have a name. It never changes, either. Line 4 shows state of X,Y and wheel, the Y axis having moved 1 step. We can also find it easily in the raw report in the third byte.

Next output shows how the report looks like when mouse is moved diagonally. We can see that both X and Y are changed and can check that value for X-axis is output in the second byte of the report.

Buf: 00FDAB00
 Mouse Pointer Btn1(00) Btn2(00) Btn3(00)
(00)
 X Y Wheel(FD)(AB)(00)

The next output demonstrates reports for wheel and button presses. It can be seen that buttons are stored in 3 low bits of the first byte of the report.

Buf: 00000002
 Mouse Pointer Btn1(00) Btn2(00) Btn3(00)
(00)
 X Y Wheel(00)(00)(02)
 
Buf: 01000000
 Mouse Pointer Btn1(01) Btn2(00) Btn3(00)
(00)
 X Y Wheel(00)(00)(00)
 
Buf: 00000000
 Mouse Pointer Btn1(00) Btn2(00) Btn3(00)
(00)
 X Y Wheel(00)(00)(00)
 
Buf: 04000000
 Mouse Pointer Btn1(00) Btn2(00) Btn3(01)
(00)
 X Y Wheel(00)(00)(00)
 
Buf: 00000000
 Mouse Pointer Btn1(00) Btn2(00) Btn3(00)
(00)
 X Y Wheel(00)(00)(00)
 
Buf: 02000000
 Mouse Pointer Btn1(00) Btn2(01) Btn3(00)
(00)
 X Y Wheel(00)(00)(00)
 
Buf: 00000000
 Mouse Pointer Btn1(00) Btn2(00) Btn3(00)
(00)
 X Y Wheel(00)(00)(00)

The last output demonstrates the behaviour of USBHID_desc encountering unsupported device (digital scale). It tries to parse the report descriptor but doesn’t have enough information for human-readable representation of the report. As a result, only raw reports are output. The first report shows empty scale, the second – scale loaded with Arduino Mega/USB Host Shield combo on which USBHID_desc is running (~68g or 2.4oz).

Usage Page Scale(8D)
Usage
Collection Application
Usage
Collection Logical
Report Id(01)
Report Size(08)
Report Count(01)
Logical Min(01)
Logical Max(0C)
Usage
Collection Logical
Usage Min(21)
Usage Max(2A)
Feature(00000000)
End Collection
Usage
Collection Logical
Usage Min(51)
Usage Max(5C)
Feature(00000000)
End Collection
End Collection
Usage
Collection Logical
Report Id(02)
Report Size(01)
Report Count(02)
Logical Min(00)
Logical Max(01)
Usage Min(80)
Usage Max(81)
Output(00000010)
Report Size(06)
Report Count(01)
Output(00000011)
End Collection
Usage
Collection Logical
Report Id(03)
Report Size(08)
Logical Min(01)
Usage
Collection Logical
Logical Max(08)
Usage Min(71)
Usage Max(78)
Input(00000000)
End Collection
Usage
Collection Logical
Logical Max(0C)
Usage Min(51)
Usage Max(5C)
Input(00000000)
End Collection
Logical Min(81)
Logical Max(7F)
Usage
Input(00000010)
Report Size(10)
Logical Min(00)
Logical Max(FFFF0000)
Usage
Input(00000010)
End Collection
Buf: 03040BFF0000
 
 
Buf: 03040BFF2100

USBHID_desc is a useful program designed to help with analyzing reports and report descriptors of HID devices using Arduino Mega or Mega 2560 board and USB Host Shield 2.0. By the end of this week I’m hoping to post an article demonstrating how to use the information – stay tuned!

Oleg.

Simulating cable disconnect on USB Host Shield 2.0

oleg — Thu, 29 Mar 2012 13:45:14 +0000

A MOSFET controlling VBUS

Today I want to show a simple USB Host Shield 2.0 modification which allows controlling power to USB peripheral. I learned this technique from Camille’s comment to one of digital camera USB control articles. In short, the idea was to cut VBUS connection between USB host and peripheral, simulating disconnect state. P-channel MOSFET, inserted into VBUS, worked as a switch. I designed this capability into USB Host Shield 2.0 but never needed the functionality therefore this useful feature was left undocumented. Recently I started working with very interesting Nikon P&S camera which can be turned on and off with VBUS power so I finally made this modification. It is very simple.

Take a look at the title picture (click on it to make it larger). The modification uses existing VBUS power select pads of the shield. Out of the box, the one labeled 5V is shorted with solder bridge. First step is to remove this bridge with a solder wick so both pads are clean.

It can be seen that a MOSFET in SOT-23 package fits nicely on those pads (I’m using FDN306P). Drain and source pins are soldered to VBUS and 5V, respectively, and gate, which hangs in the air, is routed to an unused digital pin via an 1M resistor. When digital pin is low the MOSFET conducts. When digital pin goes high the MOSFET switches off disconnecting VBUS from the peripheral.

If you are going to drive high-power peripherals, like digital cameras or phones, it is a good idea to add some capacitance to 5V. I’m using 220uF low-ESR organic polymer tantalum cap in 1210 package which fits nicely on 0.1″ spaced 5V and GND pins of the shield; an ordinary leaded 100-200uF aluminum capacitor will work as well.

Oleg.

Sony PS3 Controller support added to USB Host library

oleg — Sun, 04 Mar 2012 20:02:12 +0000

A fragment of PS3 Bluetooth code

I’m quite pleased to announce that ever-popular Sony PS3 game controllers are now supported by current (rev.2.0) USB Host Library. Kristian Lauszus from TKJ Electronics developed a library to interface with Dualshock 3, as well as Move Navigation and Motion controllers via a Bluetooth dongle (only CSR-based ones are supported at the moment). This library has been merged into the main code and I will start maintaining it as soon as my Dualshock 3 arrives.

Sony PS3 controllers are advanced versions of ordinary HID joysticks. They can be interfaced via USB or Bluetooth, the buttons can be read as analog or digital and controller contains rumble motor which can be activated remotely to indicate a hit, for example. The controller also contains a gyroscope and accelerometers so it is possible to control a robot by simply waving and/or rotating the controller.

Kristian got his inspiration from Richard Ibbotson’s articles, as well as works by Tomoyuki Tanaka and others (full list can be found in PS3README file). His Wiki page gives implementation details, communication protocol, differences between controllers, as well as plenty of links to other sources of PS3 controller interfacing knowledge.

Kristian developed this library as a part of his Balancing robot project. The project is very well documented – if you are interested in robots, PID or remote control, please take a look. I also enjoyed watching this video presentation, give it a shot to see balancing robot in action.

Oleg.

Major ACM/Prolific bug fix posted on gitHub

oleg — Wed, 29 Feb 2012 20:38:55 +0000

While playing with some cheap USB to RS-232 converters which use counterfeit PL2303 chips I found a bug in acm code which was sitting there from initial release. This bug was causing sluggish response from serial devices, as well as random 0x0d and 0x06 error codes. The bug is now fixed and corrected version of the library has been posted on GitHub a moment ago.

As a side effect to aforementioned bug fix some new functionality is now available. First, ACM and PL2303 classes now have isReady() method which can be used to check if certain device has been enumerated, initialized, and ready for service. This method is now used in all sample sketches, see, for example, pl2303_tinygps.pde, line 98.

Another addition is a block of code which performs proper PL2303 initialization. It is a mix of Linux pl2303.c code and Windows Prolific driver USB protocol traces. This block was added during troubleshooting; it turned out that it doesn’t make any difference on PL2303-based devices that I have – either genuine or counterfeit. However, it is tempting to be able to simulate “proper” manufacturer-recommended behaviour in the code so I decided to keep the initialization. It is turned off by default; if desired, it can be added during compilation by defining PL2303_COMPAT (see cdcprolific.h, line 41 and cdcprolific.cpp, lines 159-179 ). The block adds ~500 bytes to the binary so don’t turn it on just in case.

Please check the new code with your devices and let me know if you can see any improvements or new issues.

Oleg.

Low cost step-up-down 120ma DC-DC converter

oleg — Sun, 26 Feb 2012 01:31:18 +0000

120ma Inductorless DC-DC converter

Today’s electronic projects often require more than one supply voltage. 5V is often used to power MCUs, while sensors and peripheral interface controllers usually need 3.3V – if both types are used in your circuit, both voltages must be provided. Typically, one of the voltages is produced from the main supply (battery, wall wart, etc.) and the second voltage is then derived from the first using either linear LDO regulator if the second voltage is lower than the first or a boost converter if the second voltage is higher.

The boost converter I’ve designed uses Microchip MCP1253 charge pump controller. It doesn’t use an inductor and is capable of providing selectable 5V or 3.3V output voltage and up to 120ma of output current. The converter is half-inch long and weighs just 0.5g. All through-hole pads are placed on 0.1″ grid making it breadboard-friendly. Thanks to inductorless desgn, the converter is inexpensive, stable, and easy to use while providing automatic switching between step-down and step-up modes, and offering extra options, such as external shutdown and supply monitoring. The following picture shows board connections (click on it to make it bigger):

ILDC_pinout

Vin, Vout, GND are the only connections necessary out of the box (they are marked on the other side of the PCB). Input voltage can be 2.0-6.0V, output voltage is set to 5V. The converter automatically switches from buck to boost, therefore it is possible, for example, to have regulated 5V output in the whole discharge range of a battery of four alkaline cells (3.6-6V), or 3.3V from a single LiPo (if you switch output voltage to 3.3V, see below). The output current is 120ma, maintained down to 2.8 Vin at 5V Vout
3-pad Vout set jumper is set to 5V by a shorting middle pad to the right one. To switch output voltage to 3.3V remove the short using solder wick and short middle pad to the left one
Shutdown The converter can be stopped by pulling this signal low. By default, it is hardwired to Vin, in order to use it, you need to cut a trace inside Shutdown enable jumper. The jumper can be later closed, if necessary, similarly to output voltage selector
Power Good This signal falls low when output is out of regulation, which can indicate low battery or excessive load. In order to use this signal, a 100K 0603 resistor must be soldered on vacant pads indicated by the arrow Power Good Resistor

Design files are available for download. Fully populated and tested boards are offered for sale at the store. If there is enough interest, I can also offer blank PCBs as well as boards preconfigured for 3.3V output voltage. Please leave a comment if you’d like these options added.

Oleg.

Modified USB Isolator

oleg — Fri, 24 Feb 2012 17:51:27 +0000

Modified USB Isolator

David Peters shared his modifications to my USB Isolator board. The board can be seen on a title picture (click on it to make it bigger), the design files can be downloaded and below is the list of modifications:

Isolated VBUS supply has been added
DC/DC converter can be enabled or disabled by jumper to choose external power supply
7805 linear regulator can be used instead of DC-DC converter
Optional additional capacitors for better filtering
Enumeration reset possible with jumper
LEDs for input and output power visualization
Isolation between areas is 6mm providing ~600V protection

Arduino 1.0-compatible USB Host Library released

oleg — Wed, 11 Jan 2012 02:58:28 +0000

Fresh update of USB Host Library 2.0 has just been posted to GitHub. The primary purpose of this release is to maintain compatibility with Arduino releases – the USB Host Library is now compiles in 1.0 as well as pre-1.0 versions of Arduino IDE. Enjoy!

Several important changes have been made to the code, some related to 1.0 compatibility and some not. The library examples were all tested and corrected, the information below is intended for developers using the library in their own projects:

PL2302 driver. Arduino 1.0 defines PL symbol internally (thank you, Paul for finding this out!), therefore, I needed to change name of Prolific class driver. The new name is PL2302; I updated library examples to compile correctly, if someone uses this class in their own development, the right way to define an instance of Prolific device is now PL2303 Pl(&Usb, &AsyncOper);

NAK handling. A bug preventing long polls of an endpoint has been fixed. Previously, if bmNakPower member of epInfo structure was left unitialized the transfer to this endpoint would stop after receiving a single NAK. With current version, the endpoint would be polled for up to 5 seconds. This is rarely desirable, so please initialize bmNakPower with USB_NAK_DEFAULT or USB_NAK_MAX_POWER. If a single poll is desired, as is often the case with interrupt endpoints, specify USB_NAK_NOWAIT and if more than maximum number of NAKs (up to 5 seconds) is necessary, specify USB_NAK_NONAK.

Code speed. An unnecessary delay of 20ms has been found (thank you, Alex for discovering this!) and removed from USB::setAddress() member function. As a result, every USB transfer is now 20ms faster. While generally a good thing, it could inadvertently affect data exchanges with slow endpoints. If after upgrading to the current version you start seeing more NAKs, that’s probably why.

One nice thing about Arduino 1.0 is built-in PROGMEM support for strings. It is now possible to free about 300-400 bytes of RAM by redefining USBTRACE and USBTRACE2 macros used in debugging output (thank you, John, for the tip!). For example, USBTRACE (Serial.print(F(s))) will move all USBTRACE strings to PROGMEM. The code size will increase so be careful with this feature if your code size is close to the limit for your Arduino board.

This is the end of announcement – download the code, play with it and if you have any issues please share your findings in the comments.

Oleg.