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.
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.
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
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.
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:
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:
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.
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:
"C:Program Files (x86)Microsoft SDKsWindows Phonev7.0ToolsCapDetectCapabilityDetection.exe"
"C:Program Files (x86)Microsoft SDKsWindows Phonev7.0ToolsCapDetectRules.xml"
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.
Use this configuration
The two lines that do not show well in the photo should be:
Command: C:Program Files (x86)Microsoft SDKsWindows Phonev7.0ToolsCapDetectCapabilityDetection.exe
Arguments: "C:Program Files (x86)Microsoft SDKsWindows Phonev7.0ToolsCapDetectRules.xml" $(BinDir)
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: