Here’s what searching for 150 ohm resistor gets you. Awesome!
Other interesting queries: op amp, circuits, transformer.
What’s your favorite query?
Portability is a much sought after objective of high-level (as opposed to machine-level) languages. Portability reached a water-shed moment with Java, which defined an intermediate language (IL) that programs can be compiled to (called byte code) and a Virtual Machine that executes the IL. By abstracting the machine-level aspects like memory, processor and operating system, Java brought portability to the mainstream.
Earlier attempts at portability in languages like C and C++ were based on being able to compile the same high-level code to different machine-level code, using different compiler implementations for each machine architecture, and portable run-time libraries.
IL code is translated to machine code at run-time. That requires a capable machine. IL code allows access to machine-specific features (like graphics processors) using non-portable extension mechanisms. Java has been relegated to the background in mobile devices due to these factors. Microsoft.NET has however managed to remain relevant by embracing machine-specific extensions.
Microsoft.NET began as a Windows only run-time. Microsoft had the foresight to release its specifications as open standards. Now, due to Mono, .NET is available on a number of different machine architectures including ARM (most mobile devices) and x86 (most PC devices). It has clearly overtaken Java in that sense. Java is still relevant in the mobile devices space due to Android and that too only as a high-level language. Java is compiled to run on Android’s own VM called Dalvik.
Java is however the quintessential portable language on desktop PCs and servers. It will remain relevant there for a long time due to strong backing from the likes of Apache, Google, IBM, Oracle, SAP, and due to the large number of applications and frameworks written in it. Developer usage trends show Java as stagnant (surprising considering Android) but C# and Visual Basic .NET on a steady rise.
Writing USB drivers used to be a tough proposition before WinUSB. There are other frameworks like the WinDriver toolkit from Jungo that have existed before WinUSB, but they can easily cost several thousand dollars in developer licenses. You can target Windows XP SP3 and beyond with WinUSB. If you are new to USB I suggest reading Jack Ganssle’s USB Overview.
Creating a Custom Driver
WinUSB has a kernel mode driver (winusb.sys) that talks with the device and a user mode DLL (winusb.dll) that communicates with the driver. To communication with the USB device Windows needs to know about your device. This configuration is provided in an INF file. I refer you to the INF template as a starting point. I am reproducing a modified version of the template that works with 32-bit and 64-bit Windows. Remember to change strings that have MY in them, and the class and device interface GUIDs. You’ll also need to edit the USB vendor and product IDs to match your device.
Your objective then is to have a folder with the following elements.
<root folder> <device>.inf x86 WdfCoInstaller01009.dll winusbcoinstaller2.dll amd64 WdfCoInstaller01009.dll winusbcoinstaller2.dll
You can now use the Windows Device Manager to update the driver for your, as yet, unknown device. Point Windows to the INF file you have created. If all goes well you’ll see a MY DEVICE NAME device category with a device called MY DEVICE NAME, or something else appropriate if you’ve changed that in the INF file. Windows 8 refuses to install unsigned drivers, you’ll either need to enable installation of unsigned drivers, or test-sign the driver.
Using WinUSB without a driver package
Your USB device may work with WinUSB without requiring a custom INF. Details are available under section “Installing WinUSB by specifying the system-provided device class” at WinUSB Installation. You’ll need to edit Windows registry to set the device interface GUID each time the device is plugged to a different physical port. If your device provides the right descriptors it should work with Windows 8 without requiring any extra effort.
Communicate with the device in C# using WinUSBNet
We’ll use the excellent WinUSBNet component to communicate with the device. Download and reference it in your C# project. Here’s a short snippet of code that demonstrates how you can use WinUSBNet to access your USB device.
Here’s some sample output produced by running the console app above. The information regarding the USB Device is printed using the printInfo method.
Interface - id:0, protocol:1, class:2, subclass:2 Pipe - address:129 Interface - id:1, protocol:0, class:10, subclass:0 Pipe - address:3 Pipe - address:130 00 02 00 00 00 00 00 06 00 00 00 07 00 00 00 02 01 01 01
The most significant bit of the pipe’s address indicates direction, it is IN (data arriving at the host) when set. Thus address 129 (0x81) is actually a bulk data IN endpoint with ID 1. WinUSBNet only supports control and bulk transfer endpoints.
I was looking for a browser for Android that had support for websockets. I opened an online demo such as the one at websocket.org in the default Web Browser on the Android device emulator, and was greeted with a message saying websockets are not supported.
Getting Firefox is the easiest since its apk can be downloaded from mozilla.org. Firefox will not run on older Android emulator devices which use the ARM v6 architecture, it currently supports the ARM v7a architecture. As luck would have it that is the architecture used by the Android 4.0 emulator device.
Let’s get to installing Firefox. Download the apk for the latest version for Android from mozilla.org. At the time of writing this that happens to be
Start the Android Emulator for ICS (Android 4.0) using AVD Manager.
Use adb to install the apk
Run adb with the install option, e.g.
\platform-tools\adb.exe install fennec-10.0.3esr.multi.android-arm.apk
Use DDMS to install the apk
Note – If ddms fails to connect to the Emulator try resetting adb from the Actions menu.
Run File Explorer from the Device menu. Push the apk to the emulator into the folder
/mnt/sdcard. Run the Web Browser in the Emulator. Open url
file:///mnt/sdcard/fennec-10.0.3esr.multi.android-arm.apk. That should get the installer going.
Unfortunately for me, online websocket demos such as the one at jimbergman.net, show that Firefox for Android does not yet support websockets.
I got this tip from a colleague, and on further investigation discovered that Firefox version 6.0 does not have the
WebSocket class, it has been prefixed and is instead called
MozWebSocket. Instantiating that class should get you going.
Today I coded and tested code snippets on my iPhone using ideone.com from the browser. I am wondering if I should buy the CodeToGo app. I found typing certain keys like the curly brackets a royal pain. That app puts them prominently on the onscreen keyboard.
Getting a clean iTunes URL to link to is impossible with Google on mobile Safari. Doesn’t Google provide clean (as in not redirecting from google.com) URLs any more? I had to use Bing.
I had a hard time building a Mono for Android project a while back. I thought I should share this.
On building a Mono for Android project using MonoDevelop I got this cryptic error message:
C:\Program Files\MSBuild\Novell\Novell.MonoDroid.Common.targets(2,2): Error: Could not find android.jar for API Level 10. This means the Android SDK platform for API Level 10 is not installed. Either install it in the Android SDK Manager, or change your Mono for Android project to target an API version that is installed. (Hello)
Sure, I thought. I’ll just fire up the Android SDK Manager and install the Android SDK for version 2.3 (API Level 10). Easier thought than done, it was already installed. The SDK path reported by the SDK Manager was:
It seems the installer for Mono for Android had messed up the Android SDK path, but where? I looked at the build log and that showed me where MonoDevelop was getting its SDK path:
Target _ResolveMonoAndroidSdks: Looking for Android SDK.. Key HKCU\SOFTWARE\Xamarin\MonoAndroid\PrivateAndroidSdkPath not found. Key HKCU\SOFTWARE\Android SDK Tools\Path not found. Key HKLM\SOFTWARE\Android SDK Tools\Path found: Path contains adb.exe in \platform-tools (C:\Program Files\Android\android-sdk).
All right, so now I knew that the Android SDK was installed in two different folders. The build problem was easily solved after I changed the registry key at
HKLM\SOFTWARE\Android SDK Tools\Path to point to the path that the Andoid SDK Manager was reporting.
Now, where was the Android SDK Manager getting its path from? I still don’t know. If any one does happen to know please comment below.
[Thanks to Paul who left a comment below, I discovered that Mono for Android setup added a shortcut to its copy of the Android SDK Manager. One less mystery…]