libftdi1-1.1 released and Windows binaries

libftdi1-1.1 has been released on 06-Feb-2014

Main highlights
------------------
* Fix FT232H eeprom suspend pulldown setting (Davide Michelizza)
* Fix FT232H eeprom user area size (Davide Michelizza)
* Improved mingw build (Paul Fertser and Michel Zou)
* C++ wrapper: Get/set functions for USB timeouts (Jochen Sprickerhof)
* Partial support for FT230X (Nathael Pajani)
* New API function: ftdi_eeprom_set_strings() (Nathael Pajani)
* Prevent possible segfault in ftdi_eeprom_decode() (Nathael Pajani)
* Save device release number in eeprom (Jarkko Sonninen)
* Fix "self powered" eeprom flag (Jarkko Sonninen)
* Improved python wrapper (Michel Zou)
* Many buildsystem improvements (Michel Zou and Mike Frysinger)
* See the git history for more changes and fixes


Download:
http://www.intra2net.com/en/developer/libftdi/download/libftdi1-1.1.tar.bz2

GPG signature:
http://www.intra2net.com/en/developer/libftdi/download/libftdi1-1.1.tar.bz2.sig

Full changelog:
http://developer.intra2net.com/git/?p=libftdi;a=blob;f=ChangeLog;hb=HEAD

I provided the Windows development kit download here. This time I have provided both the MinGW.org based 32bit development kit and MinGW-w64 based 32bit/64bit development kit. libusb-1.0.18 is used as the base for the libftdi1-1.1.

libusb-1.0 and libusbx in OpenBSD ports and NetBSD pkgsrc now

libusb-1.0.9 and libusbx-1.0.11 have OpenBSD/NetBSD support. Now libusb-1.0 and libusb-compat are OpenBSD's ports system. NetBSD's pkgsrc system (okay, pkgsrc is not only for NetBSD) now has both libusb-1.0.9 and libusbx-1.0.11, it also has libusb-compat as well.

On the other hand, at least for the faster moving libusbx, OpenBSD/NetBSD are behind the other supported OS (Linux, Mac OS X and Windows). Hopefully the OpenBSD/NetBSD users can jump in and bridge the gap.

Take note FreeBSD has its own libusb-1.0/libusb-0.1 wrapper on top of its own libusb20 library.

OpenBSD, NetBSD and libusb-1.0

There is OpenBSD support in libusb.git. Since NetBSD and OpenBSD should have quite similar USB codes, I think that it should work under NetBSD as well.
Therefore I tried the following dirty patch to enable libusb-1.0 experimental support for NetBSD using the OpenBSD backend.
Take note FreeBSD has its own libusb-1.0 implementation which should be more mature than the OpenBSD backends of libusb-1.0 which is very recent.

diff --git a/configure.ac b/configure.ac
index ebbc107..71aad37 100644
--- a/configure.ac
+++ b/configure.ac
@@ -83,6 +83,17 @@ case $host in
       AC_CHECK_HEADERS([poll.h])
       AC_DEFINE([POLL_NFDS_TYPE],[nfds_t],[type of second poll() argument])
       ;;
+*-netbsd*)
+       AC_DEFINE(OS_OPENBSD, 1, [OpenBSD backend])
+       AC_SUBST(OS_OPENBSD)
+       AC_MSG_RESULT([OpenBSD])
+       backend="openbsd"
+       threads="posix"
+       THREAD_CFLAGS="-pthread"
+       PC_LIBS_PRIVATE="-pthread"
+       AC_CHECK_HEADERS([poll.h])
+       AC_DEFINE([POLL_NFDS_TYPE],[nfds_t],[type of second poll() argument])
+       ;;
 *-mingw*)
       AC_MSG_RESULT([Windows])
       backend="windows"

And indeed it seems to work under NetBSD (tested with a NetBSD 5.1 VirtualBox VM under Mac OS X Lion)

localhost$ sudo ./listdevs
04d8:fa2e (bus 0, device 2)

I also tested libusb-pbatard's xusb example.

localhost$ sudo ./xusb -d 04d8:fa2e

Opening device...
speed: Unknown

Reading device descriptor:


Reading device descriptor:
           length: 18
     device class: 0
              S/N: 3
          VID:PID: 04D8:FA2E
        bcdDevice: 0001
  iMan:iProd:iSer: 1:2:3
         nb confs: 1

Reading configuration descriptors:
            nb interfaces: 1
             interface[0]: id = 0
interface[0].altsetting[0]: num endpoints = 2
  Class.SubClass.Protocol: 00.00.00
      endpoint[0].address: 01
          max packet size: 0020
         polling interval: 00
      endpoint[1].address: 81
          max packet size: 0020
         polling interval: 00
interface[0].altsetting[1]: num endpoints = 2
  Class.SubClass.Protocol: 00.00.00
      endpoint[0].address: 01
          max packet size: 0040
         polling interval: 00
      endpoint[1].address: 81
          max packet size: 0040
         polling interval: 00

Claiming interface 0...

Reading string descriptors:
  String (0x01): "Travis Robinson"
  String (0x02): "Benchmark Device"
  String (0x03): "LUSBW1"

Releasing interface 0...
Closing device...

OpenOCD 0.5.0 release Windows binary download

OpenOCD 0.5.0 has been released. Here is the News.

Source zip archive or tar ball can be downloaded from SourceForge.

Windows binaries (32bit and 64bit, cross build under Linux with MinGW-w64 project's compiler) can be downloaded from Freddie Chopin's website.

You can also use my test build which is native Windows build using 32bit MinGW.org toolchain.

Take note due to GPL licensing reasons, these Windows binaries are linked against libusb-win32 and libftdi and not the proprietary FTDI D2xx library.

libftdi 0.19 and libftdi-1.0 git MinGW binaries download

Here are the unofficial libftdi-0.19 and libftdi-1.0 binaries download.
http://code.google.com/p/picusb/downloads/list

They are cross-built under Linux with MinGW and MinGW-w64. So if you have some difficulties getting them to be built under Windows, you may want to try out the binaries I built.

OpenUSB is alive again

After a long gap, Michael Lewis just announced the release
of OpenUSB 1.1.1.

Website: http://sourceforge.net/projects/openusb.

Highlights of the release:
1) Removed the HAL/DBUS dependency for hotplug events.
2) Improved kernel version checking for the bulk continuation flag.
3) Improved support for zero byte transfers
4) Changed the maximum control transfer size to 4096

According to Michale, these changes are primarily in response to making OpenUSB compatible with the latest distributions.

Compared to libusb-1.0, OpenUSB is not used by many projects. However, it does have two advantages compated to libusb-1.0. It also claims to have better multi-threading support.
1) Hotplug support
2) Solaris support

libusb-1.0 is more widely used and the Windows backend will bring even more users for libusb-1.0. However, it is also good to see that OpenUSB is still alive. If Windows support for OpenUSB is done within a reasonable timeframe, then it would be even better.

Python and USB HID Device

(This is my post to pyusb mailing list on 27-April-2011)

Just a summary for the situation.

Firstly you may want to see if you really want to use
a generic HID device, in most cases, you can use
a custom device and then use libusb0.sys or winusb.sys
as the driver under Windows and then use pyusb with it.

Using a custom device will also make it possible to use
pyusb under Mac OS X. Recent Mac OS X makes it
very difficult (or impossible) to detach the kernel HID driver.
In that case, it is not possible to use libusb (0.1 or 1.0)
and thus pyusb with the device.

So if you really want to use pyusb and care about
cross-platfrom, then you should forget about generic
HID device and use a custom device instead.

If you really need to use HID device, there are a few
options.

1) If you only cares about Linux, then you can use
pyusb with no issues. libusb under Linux can detach
the kernel HID driver.

2) If you only care about Windows, you may want
to look at pywinusb.
http://code.google.com/p/pywinusb/

3) If you really want to use pyusb under Windows with the
HID device, you can use libusb-win32 filter driver for
that particular HID device. Please use the latest
libusb-win32 for this purpose. And take note this is
not a recommended solution.

4) If you want to have cross-platform support for the
HID device, then you need to look at HIDAPI and
use the python binding for it. Take note the python
binding for HIDAPI is not mature yet.
http://libusb.6.n5.nabble.com/Opinion-HID-and-Windows-back-end-td3716872.html
http://comments.gmane.org/gmane.comp.python.pyusb.user/749

5) Another option under Windows is to use the HID branch
of the libusb-pbatard git repo or older version of libusb-pbatard
(up to pbr332). This is not recommended as the official stand
of libusb-1.0 admin is not to support HID native backend under
Windows.

libftdi and OpenOCD binary download

libftdi-0.18 and libftdi-1.0 binaries and OpenOCD git binaries download
http://code.google.com/p/picusb/downloads/list

I have uploaded some Windows (32bit and 64bit) binary of libftdi and OpenOCD to my Google Code picusb page. Most of them are cross-built under Linux with MinGW and MinGW-w64. So if you have some difficulties getting them to be built under Windows, you may want to try out the binaries I built.

Updated Microchip USB Links and Microchip Stack Anomaly list

PIC USB related web sites
http://www.microchip.com/forums/m123533.aspx

PIC USB Firmware Framework Confirmed and Potential Anomalies
http://www.microchip.com/forums/m275422.aspx

The above links should help the users of Microchip USB PICs.

MinGW Win32 installation to build libusb-1.0 Windows Backend

libusb-1.0 Windows backend currently supports Cygwin, MinGW and MinGW-w64, MSVC and WDK as the building tool. Cygwin, MSVC and WDK are more straightforward to install under Windows. But MinGW and MinGW-w64 are less straightforward.

One way to solve this issue is to use cross-compile under Linux. Leading Linux distros have MinGW and even MinGW-w64 packages. And the auto-tools (automake, autoconf, libtool) are normally installed under Linux. For MinGW-w64 build, one think to take note is that you probably need to update the libtool to 2.2.8 and later. Ubuntu 10.04 still ships an older version of libtool which does not recognize 64bit library properly.

Native build with MinGW/MSys from MinGW.org is really not that difficult once you have the base system and auto-tools installed. Pete Batard has a blog entry talking about the setup.
http://pete-tech.blogspot.com/2010/07/installing-mingw-w32-on-windows-system.html

I just checked again and now it seems MinGW people has recognized the problem and come up with a new automatic installer for the MinGW/Msys base system installation. The name is mingw-get. It is currently in alpha but rather usable. I just used it to set up a new MinGW/MSys base system under Windows 7 32bit.

mingw-get can be downloaded from MinGW Sourceforge site.
http://sourceforge.net/projects/mingw/files/

Once you have the base system, you need to install auto-tools for MinGW (not the MSys version). The auto-tools may need some MSys dependency packages as well (eg: perl, crypt, etc). After that, it is quite simple to build libusb-1.0 Windows backend.

As for MinGW-w64 64bit build, it is similar. You can download the 32bit MSys base system and MinGW-w64 64bit Windows binary snapshots from its Sourceforge website.
http://sourceforge.net/projects/mingw-w64/files/

Alternatively, you can get 64bit binary from the following website (only for 64bit Windows).
http://www.drangon.org/mingw/

After that, you still need to get 32bit auto-tools installed. I recommend you to use the ones from MinGW.org and not the ones from MinGW-w64 sites as I have encountered problems with them.

If you are more adventurous, you can try the multilib option to build 32bit and 64bit using the same toolchain. Pete has a blog entry for this. I have not tried this and will probably not try this myself.
http://pete-tech.blogspot.com/2010/07/compiling-mingw-w64-with-multilib-on.html

There is an existing package WPG System64 which include multilib based MinGW-w64 and all the tools (and more) to build libusb-1.0 Windows backend. However, we found out that the MinGW-w64 compiler included is a bit outdated that the output is not compatible with the current MinGW-w64 compile. So it is not recommended any more.

libftdi-0.18 and libftdi-1.0 Win32 and Win64 binaries download

http://code.google.com/p/picusb/downloads/list

I have uploaded some Windows (32bit and 64bit) binary of libftdi and libftdi-1.0 to my Google Code picusb page. Most of them are cross-built under Linux with MinGW and MinGW-w64. So if you have some difficulties getting libftdi or libftdi-1.0 to be built under Windows, you may want to try out the binaries I built.

Windows 7 32bit installed

Last week I installed Windows 7 32bit Ultimate on my two-year old Acer M1641 desktop, it was a smooth process. The only unrecognized device of the original PC after the Win7 installation was a mysterious "co-processor" device. After installation of the Nvidia NForce chipset driver everything on the original PC was recognized. The added old Compro X50 PCI TV/FM card was also not recognized. Luckily Compro provides the driver and necessary applications for this 5-year old product.

There was a glitch, after the installation, the grub bootloader is gone, only Vista and Win7 are shown in the Windows bootloader. So I have to recover the grub bootloader so that I can boot into various Linux versions (Ubuntu 9.10 32bit, Ubuntu 10.04 64bit and Arch Linux).

I am now using Windows 7 Home Premium 64bit for my Asus laptop. Same as the experiences there, I do not see too much differences between Vista and Win 7. Being a new installation with less "junks", it seems to be a bit faster.

Other than that, one of the major difference is the XP mode. The nice thing about XP mode is that now it supports USB. This is not a fast PC to run the virtual XP mode since it lacks the Hardware Assisted Virtualization Technology feature and the amount of RAM is not that big. Still allocating 512MB to the XP mode seems to let the virtual XP run relatively smooth. But this is just a test and I do not really need XP or miss XP.

Overall, the first impression of Win 7 is positive. But heh my first impression with Vista was also not bad even though many people have negative views on Vista.

WinUSB related resources

WinUSB related resources:

Microsoft resource:
http://www.microsoft.com/whdc/connect/usb/winusb_howto.mspx
http://msdn2.microsoft.com/en-us/library/aa476426.aspx

Jan Axelson's website
http://www.lvr.com/winusb.htm

libusb-1.0 Windows backend
http://www.libusb.org/wiki/windows_backend

libusbdotnet supports WinUSB, libusb-1.0 and libusb-win32 0.1
http://libusbdotnet.sourceforge.net/

WinUSB component
http://asyncop.com/MTnPDirEnum.aspx?treeviewPath=[o]+Open-Source\WinUSB+Component

WinUSBDotNet
http://code.google.com/p/winusbnet/

pywinusb: python wrapper
http://code.google.com/p/pywinusb/

Microchip Forum thread:
http://www.microchip.com/forums/tm.aspx?m=264046

picusb Google code page updated

http://code.google.com/p/picusb/

I have created this page quite some time ago. But I did not put anything inside. Now I will start to put some contents inside, mainly related to some open source codes related to USB PIC MCUs.

Some files for download:
http://code.google.com/p/picusb/downloads/list

libusb 1.0 Windows backend reaches pre-release mode

http://old.nabble.com/Announcing-code-freeze---pre-release-mode-for-the-Windows-backend-td27657981.html

Pete Batard announced the news and Pete Stuge has come out a good integration plan. Hopefully the Windows backend will sooon be integrated into the main tree.

At the same time, I think if you are interested in the Windows backend, you can already try it. It mostly works for me. The only issue I have right now is the HID backend where feature reports do not seem to work.

FreeBSD 8.0 First Impression

Now I used FreeBSD 8.0-Release (updated to 8.0-RELEASE-p2) and it seems to be much better than last time, especially in the USB front. I also like the freebsd-update capability. It seems to be faster than last time.

What I like compare to Linux: maybe the BSD license itself. But now I feel GPL/LGPL are not bad either.

What is not working: my SATA DVD-RW is not recognized at all. This is an Acer M1641 desktop with NVidia 620i/Geforce 7050 based chipset and FreeBSD seems to have big problems with NForce 620i and 630i.

What I do not like: the port system. I have since removed most of the packages initially installed (LXDE, KDE3, KDE 4, QT33, QT4, etc) due to the mass upgrade of libjpeg. It caused big problems to many packages. So now I have a bare-minimum Gnome 2.26 based desktop (dare not update to 2.28). Mass upgrade takes a long time and often the ports are broken. ARCH seems to do a much better job since binary updates are provided. I still like Ubuntu's package system (deb/apt, Synaptic) the best.

My libusb testing on FreeBSD: pk2cmd seems to behave like last time, but now I do not need to recompile the kernel. libusb based programs work better but there are still problems.
http://old.nabble.com/LibUSB-on-FreeBSD--current-%288.x%29-td21642051.html

My OpenOCD test on FreeBSD: FT2232D seems to work, J-Link V3 does not work. J-Link V7 seems to work. All of them works under Linux.
https://lists.berlios.de/pipermail/openocd-development/2010-February/014864.html

My main interests with FreeBSD will be more libusb/MCU related -- to get OpenOCD (J-Link and FTDI, for ARM MCU development) and PICkit 2 (and other PIC related things, for PIC development) to work well under FreeBSD. Now it seems that FreeBSD is an possible platform for MCU development.

FreeBSD 8.0 Installed

After about 1.5 years gap with FreeBSDs, yesterday I finally got FreeBSD 8.0 Release version installed. My main interests are to get some libusb based programs to work under FreeBSD, including the USB demos from Microchip, pk2cmd for PICkit 2.

The installation itself is not flawless. Initially I tried with ACPI disabled (last time it helped) but this resulted in General Protection Fault on this Acer M1641 PC (Nvidia 620i/Geforce 7050 integrated chipset). With ACPI enabled, the install CD can boot up. But the installed could not find the SATA DVD-RW. Luckily the network card was recognized. So I used network install and it was not too bad, faster than I expected. I then spent some time to get Nvidia driver port to work. I have to disable the Linux emulation support in nvidia-driver since I could not download the large Linux emulation base packages (linux_base-f10) due to dead mirrors.

There are some other minor things to fix up, like I need to mount procfs to /proc (edit /etc/fstab) to get the gdm login screen to be able to properly shutdown/reboot the PC.

I tried a few simple programs based on libusb 0.1 and they seem to work fine under FreeBSD 8.0 release. Last time I had to patch the kernel and use the then alternative USB stack from Hans Petter Selasky (FreeBSD USB developer).

Then I tried to build pk2cmd and it seemed to work. The "-s" option does not see to work just as the release note of pk2cmd 1.20 says. I have not tried updating the firmware which was not working last time I tried it.

libusb 1.0 API has not fully been synced by the FreeBSD /usr/include/libusb.h. Luckily Hans says that he will make the libusb 1.0 compatible layer available to FreeBSD.

USB permision setup is now much easier than last time. By default, it seems USB device will have a ugen driver associated. The /dev/ugen* device belong to the operator group. So it is quite easy to add the user to the operator group and then the user can run libusb based program without root privilege.

I had problems to build OpenOCD git code, luckily Tomek Cedro provided a port so that I could build OpenOCD 0.4.0-rc2. I had to update the port system to build libftdi 0.17. This seems to be a prerequisite for OpenOCD.

Overall this time I have more positive views about FreeBSD. It is not as smooth as Ubuntu, but at least it is quite usable.

$ uname -a
FreeBSD MyFreeBSD.WORKGROUP 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan 5 16:02:27 UTC 2010 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386

[mcuee@MyFreeBSD /usr/home/mcuee/Desktop/build/pk2cmd/pk2cmdv1.20LinuxMacSource]$ ./pk2cmd -?V

Executable Version: 1.20.00
Device File Version: 1.55.00
OS Firmware Version: 2.32.00

Operation Succeeded

OpenOCD -- a promissing project

Project website:
http://openocd.berlios.de/web/
http://developer.berlios.de/projects/openocd

Mailing list archive
https://lists.berlios.de/pipermail/openocd-development/

Forum
http://forum.sparkfun.com/viewforum.php?f=18

I started to really trying it out (with J-Link) this May. It has really progressed very fast. Before that, it did not work at all with J-Link V3. Now I can use J-Link (V3, V6 and V7) with several targets I have (STM3210E-Eval, TMS470R1A256, ADuC7060 and LPC-2148) under Linux (and Windows). I am still in the process of learning to use OpenOCD but I can see it as a very promissing project.

V0.2 is slated to be released any time now.

In the future, I would like to see a more stable J-Link driver.

On the other front, right now it used libusb 0.1 and libusb-win32 0.1 and synchronous USB I/O. In the future, maybe it can be switched to libusb 1.0 under Linux and Mac OS X and use asynchronous USB I/O to boost the performance.

For FTDI2232x based JTAG debuggers, right now it uses either FTD2XX (proprietory) or libftdi+libusb 0.1. Hopefully the features of libftdi can be improved to match the performance of FTD2xx, especailly under Windows. The situation is rather complicated under Windows due to the fact that libftdi uses libusb-win32 and libusb-win32 does not work under Vista 64 right now. Maybe WinUSB is a better solution (for XP/Vista and later).

LPC-2148 USB Isochronous Examples based on lpcusb

Today I read an interesting article from Linux Journal.
http://www.linuxjournal.com/article/10421

In the article, there is an interesting example of Isochrouns USB Transfer example based on lpcusb. So I use lpc21isp and download the code to my Olimex LPC-P2148 board which the developers are also using. They have also the Linux host example based on usbfs which seems to work right out of the box. Now I need to read the firmware in more detail.

There are also quite some examples from the psas site.
http://psas.pdx.edu/

lpcusb (get the svn version)
http://sourceforge.net/projects/lpcusb

lpc21isp
http://sourceforge.net/projects/lpc21isp

PCI card based serial and parallel port

Yesterday I went to Sim Lim square for the monthly (or bi-monthly) IT refreshment trip. My intention was mainly to check out network based media player. But interestingly I found out that there are shops selling PCI based serial/parallel port card. You get real serial port and real parallel port from the card. Typically USB to serial port cable can do most of the job. But typical USB to parallel cable is totally useless for interfacing to anything other than your old parallel port based printer. Therefore if you have parallel port based cheap JTAG debugger (say ARM or MSP430), then you are out of luck if you do not have parallel port with your new PC (laptop or desktop).

One of the vendor is ST-LAB (http://www.st-lab.com/). It is using MOSChip (http://www.moschip.com/pepc.php) as its brain. The single serial or parallel port version is selling at about S$23.

Another company providing chips is Oxford Semiconductor (http://www.softconnex.com/products/serial/serial.html)