Sharpduino Library: Testing

Warning: This post is mostly about Unit testing and less about Sharpduino as a library.

It has been almost two months now that I have been developing the next version of the sharpduino library. I feel that the new implementation is far better in terms of understanding what each part of the code does, with as few byte constants as possible, so anyone who looks at the code can understand what is happening without having the firmata.org page or (shameless plug) my blog open. I tried to make various parts of the library as loosely coupled as possible, so it could be extensible and easier to code against.

In the previous version the library was tested by a console application trying to make sure that everything worked for the end users by telling them what to do (connect LEDS, etc.) and then what to expect as the library was used (Led turns on/off, etc).

For this version much of the functionality was pre-tested with unit tests before even hooking up an arduino. This was done with the help of the NUnit and Moq libraries. I won’t be going into detail about the choice of Unit testing and Mocking frameworks. Let’s just say that the NUnit – Moq combination worked for me without much hustle. If you are interested in finding alternative frameworks, the following is a small list which I made while searching for my library. This is not an exhaustive list, but a few of the most prevalent frameworks that I could find.

Unit Testing Frameworks: NUnit, XUnit.net,MSTest, MbUnit
Moq Frameworks: NMock,RhinoMocks,Moq,NSubstitute

Continue reading

Firmata Messages : Outgoing

Following my previous post about incoming messages of the firmata protocol now it is time to present you with the outgoing messages of the protocol. As you can see in the following picture the number of messages is quite big.

The new 2.2 protocol has a lot of new functionality added. For example we have the new Pin State Query, Analog Mapping Query, Capability Query and Extended Analog messages. These make it very easy to create programs on the host (PC,Phone) side that can talk to arbitrary devices and have a complete overview of the device capabilities and current state.

Firmata Outgoing Messages

All the outgoing messages of Firmata Protocol 2.2

Now that I have finished with the implementation of the message handling I will be posting a few things about the Sharpduino library and its new architecture. Within this month I am expecting to have a new version published on the google code page. It will be fully functional with an ArduinoUno by using the higher level library. You can also use the lower level library to communicate with every Firmata enabled device but you will have to do some more coding.

Firmata Messages : Incoming

As you already know I am rewriting the sharpduino library. The new implementation will handle all known firmata features to date (version 2.2 of the protocol). Trying to decipher the available messages you can get lost, as the text representation offered by the firmata.org page is not really indicative of the message structure. There is also the problem of the fragmentation of the information on the wiki pages.

This is why I made the following image. It is a round-up of all the messages, that can be received on the PC host side as of version 2.2

Firmata Messages

We can separate the messages into 2 categories. Those that are 3 bytes -7-bits, but let’s just say it’s bytes- long and those that are longer and are called Sysex Messages.

The sysex messages always start with 0xF0, they have a second byte that is a sysex command and a final byte 0xF7 which tells us that the message is finished. The second byte tells us what the rest of the message will be. Right now there are 6 kinds of sysex messages, but I expect that they will multiply as more functionality is embedded to the Firmata protocol.

Beware that the messages received are almost always a result of a message sent earlier. This image does not show the proper order of the message exchange, but only analyzes the structure of the incoming messages.

This should be helpful to people implementing their own solution for communication using the Firmata protocol, or people wanting to know the ins and outs of the underlying protocol which they are using, if they use a library such as sharpduino.

Sharpduino Library: Reboot

A little background (Yes you can skip this)

A few years ago I bought an arduino to ease myself into electronic project prototyping. I tried a couple of times with pic microcontrollers, but the promise of using USB to program and debug an electronics board was too good to pass. The arduino, as everyone knows by now, is very easy to use and I had no problem creating from the simplest programs, to more complicated ones.

My goal was to create a program that would communicate with the pc and offer functionality equivalent to USB data acquisition modules from NI that we were using in our laboratory. Although the capabilities of the Arduino weren’t an exact match, the price (about 1/10th) was right. One of the requirements that I had, was that I could use this from the Labview environment. Back then there was no library for arduino for labview so I had to make one. There were actually two ways to accomplish such a task. A full native Labview library or a .net library that could be imported to Labview and used.

Given my background on .net technologies I went for the second solution. This was the birth of the Sharpduino Library. It was based on the Firmata protocol and implemented some basic functionality (Analog Input/Output, Digital Input, Digital Output). It had the functionality that I wanted, so I put it on google code and never really updated it since. I had even forgot that I had written it…

Fast forward to December 2011. I received two emails from people who had seen my library and were interested in the Firmata protocol. One was Noriaki Mitsunaga who not only used the library, but also had made a more complete implementation of the Firmata protocol. You can find his useful applications using this library here. The other was my friend Anton Smirnov who was making an equivalent library in pure Java (find his library here). It rekindled my interest in the library and I decided to do some coding.

The first step was to integrate Noriaki’s work (with his permission) and make it available. This begun with the switch of the repository from svn to mercurial. I have become a huge fan of DVCS and have found that it suits my any style of development if you spend a little time to make the switch from server-based systems. You can find the current code from the source tab of the sharpduino page.

Then I started refactoring a lot of the code, so it would make more sense. At some point I decided that the library needed a more thorough refresh,hence the reboot of the project.

Reboot

For this new implementation I have decided to make a library that will be useful to two kinds of consumers. There will be a higher level API that will be useful to people in need of the previously available functionality. For example, using the ArduinoUno will be as easy as:

Of course the actual names might change, but the general direction will be this.

What is more interesting (for me) is the lower level API. It will be mostly Message Handlers, Message Senders, Messages and a few base classes to coordinate all these. The previously mentioned implementation will be based on this and will serve as an example on how to put things together to make other Firmata Implementations.

Keep an eye on this blog and/or the sharpduino page for more updates as the new implementation matures and I will have a few things to share.

PS. I would also like to mention that my goal is to create a nuget-distributable library.

Links

Changing the Default Sound Device

About a year ago I bought for myself a new 24-inch monitor. It is great for games work as you can work with a lot of documents/source code files together without having to scroll around and/or toggle between many windows. What was great about this monitor, was that it had an HDMI port. “So what?” you will say and you will be right, but for me it was a revelation, especially when I upgraded my graphics card and bought one which had an HDMI output.

Although regarding graphics there was no difference transitioning from DVI to HDMI the sound was a whole new experience. As with anything in this life, when you get something you have to give something in return. What happened was that there was a new sound device in my setup, so my headphones could not function in parallel to the monitor speakers.

Changing from one to the other is not very difficult, but you have to access the playback devices tab in the sound configuration and set the device you want to use as the default. Searching the net you can find many guides and solutions to this problem. Some with screenshots showing the windows way:

And some more suited to power users/programmers:

Running a command line or having a shortcut (that I usually don’t remember) is not my thing, so building upon the work of the aforementioned people I decided to create an application that lives on the tray, is easy to access and helps me change easily between my monitor speakers and headphones. Let me present you with the aptly named ChangeSoundDevice program.

Usage

Before you use the application make sure that you have downloaded and installed the Microsoft Visual C++ 2010 Redistributable Package (x86). The first time that you will launch the program, it will automatically pop up a window listing the devices it has found in your system.

image

You can edit the names (to make them shorter and friendlier) and hit the OK Button. By default the first time the program is launched the first device will be chosen, but you can now change it easily with two clicks. One to the tray icon and one to the device of your choice. The following screenshot shows the user interface for this window.

image

You can also use the find devices button to get the first window again. This can be useful if you have a new sound device or are not satisfied with the previous naming.

Warning: Geeky Stuff

After having used code that was freely given by the aforementioned sites, it would be only fair to publish the source code of my application too. Inside the source code bundle you will find a solution with 2 projects. The first is a native dll library that is mostly a copy of Dave Amenta’s code with a few changes to make it play nice with P/Invoke. The second is the main program that uses the native library and runs in the tray.

Note that there is an error with the P/Invoke signatures, that I couldn’t resolve. Even though it works, there is some problem that gets caught in the debugger.

You can get the source code here.

Download

Get the applicationhere

Sportnews GR is now live!

Today my application went live. After a failed submission and 7 more days of waiting for certification, my application is live on the WP7 marketplace.

This application is an RSS reader for the major Greek sport sites. It was a really nice experience seeing this application start from file -> new project and now seeing it on the marketplace.

Here are some screenshots of the application.

If you are interested in sport-related news and/or you can read Greek and have a WP7 give it a try and let me know what you think.

WP7 WebBrowser Control Woes

Something small, but inherently useful to know. When you use the WebBrowser control in WP7 you don’t get the same behavior when browsing. An example that came up during the development of my application is shown below:

explorerwebbrowser component

The left screenshot is from the native internet explorer while the one on the right is from a sample application I made to test the control. I could not understand what was happening and ended up spending a whole afternoon debugging the network traffic with Fiddler (very useful tool btw). *

The problem was that by default the WebBrowser Control had Scripting disabled. Easy enough you will say; just use the easy to find webBrowser.IsScriptEnabled property. There is a catch here though. Let me quote MSDN:

WebBrowser.IsScriptEnabled Property

Enables or disables scripting. This applies to the next document that is navigated to, not the current document. This property is false by default. Set this property to true to enable scripting, or false to disable scripting.

So beware to set WebBrowser.IsScriptEnabled to true before navigating to the page. Any subsequent navigation retains this value, so you have to manually set it to false if you don’t want scripting in other pages.

PS. If you want to make Fiddler work with the WP7 Emulator see this post.

The difference between a prototype and a product

One of the common themes that keeps popping up lately in my line of work is the difference between a product and a prototype. A prototype is something that you make for yourself. Something that only you will use (or select few with specific instructions), something that does a very specific job and will probably crash your hard drive and burn your dvd player if you try to make any changes.

A few simple examples of this are renaming of files/folders, some csv file data “massage” or anything that is repeatable. The development time is usually short enough to warrant that you won’t spend more time doing the development than the time you gain from doing this work manually. This can scale up to include machines that cost a few thousands of Euros, like the ones which we make at my workplace for in-house use. The pattern is the same no matter what the complexity is. Let me share some of my experience as it relates to software development.

There are some times when the result is so good, that you want to share this thing with the community or sell it. That is when you hit a brick wall. Your prototype program that renames all files and replaces an underscore with a space did a great job for you, but what about those that have files with dots? What happens when you have two underscores? Not to mention the more complex scenarios.

This is what I call the gray zone. It is a place of pain, where you don’t have significant gains as far as important features are concerned, but you keep pouring effort into. It is a disproportionately long and demanding effort, before you are able to transition to the product area, where you can give the thing you are developing to someone else. See the following graph (made by matplotlib and edited by paint.net) for an visual depiction of this.

Prototype-Product Graph

This is a clear example of the Pareto Principle or the 80-20 rule.

The Pareto principle (also known as the 80–20 rule, the law of the vital few, and the principle of factor sparsity) states that, for many events, roughly 80% of the effects come from 20% of the causes.

Wikipedia

Although this principle has its roots in economics, you can find applications of this in many real life scenarios like businesses, demographics and software engineering to name a few. In our case, you can spend 20 percent of the total development time to achieve 80 percent functionality, but the rest 20 percent of functionality is what makes a product shine. It can make all the difference in terms of having happy “clients” (either paying ones, or not –friends,family,community).

For example you can have software which when crashes, shows the following screens:

image

image

Guess which is a product. One gives you some cryptic information that probably even the author of the application wouldn’t use. The other apologizes for the crash, promises to get some of your work back and asks if you want to contribute towards the fix of the problem that created your crash by sending data that is useful to the ones who wrote the application.

When you are in the prototype phase you don’t care about such things. If there is a crash, then you probably already have attached a debugger, or you make a mental note to do so next time. Also, you know and expect what you will be doing with your program. If you write a division program you won’t be putting any zeroes to the divisor textbox, will you? When you give your software to others though, nobody can assure you that they won’t. In fact, you can be assured that they will.

If you like your product to have an impact you have to trudge through the Gray zone, now matter how difficult –or boring- it may seem. It really makes a world of difference. When you manage to break through the Gray zone, then –oh joy- you are ready to reap the rewards of your hard work, be it a friendly pat in the back (even a good comment on twitter qualifies as one), a big pile of money or anything between those.

As far as I am concerned, there are at least 4-5 projects/relevant posts that are somewhere in the middle of the gray zone. Hopefully you will hear of them soon.

Capability Detection Inside Visual Studio 2010

For the last month or so I have been developing an application for my windows phone, that I am going to publish to the marketplace in the coming week(s). As I am getting ready to make the final build I have started searching the certification requirements and good practices. One that I had missed was the advice to use as few capabilities as needed in the WMApplicationManifest.xml

Fortunately Microsoft is distributing a nice tool with the Windows Phone SDK that performs the task of finding the capabilities that your application is using. The problem is that this is a console application that lives inside the C:Program Files (x86)Microsoft SDKsWindows Phonev7.0ToolsCapDetect folder (for those having x64 machines). It also requires 2 arguments to invoke, one of which is an xml located at the same directory.

Tired of having to execute the following command each time:

I decided to make a shortcut for myself from inside visual studio 2010. The process of doing this is extremely easy and I wonder why Microsoft did not put it there in the first place.

Tool configuration

Use this configuration

The two lines that do not show well in the photo should be:

When this is done, you can now invoke the tool from tools->Capability Detection or whatever name you gave it. The result is much better and easier to get to:

Capability Detection Result

Enjoy

Hello Blog

This is my opening blog post. Hopefully it is not going to be the last one. Through this blog I will try to give some insights to people about software, software engineering, hardware and pretty much everything that comes up in my work/life.

A few things about me first. I am an Electrical Engineer with an Msc in Nanosciences & Nanotechnologies who is currently working towards his PhD in Chemical Engineering. My interests revolve around software development, web development and electronics engineering. I am also a tech enthusiast and a new father. It is quite a mix, but it keeps me occupied and hopefully will give me something to write about.

I will try to put out things that baffled me, and their solution, so others (and probably me in the future) do not have to go through this again.