Firmware question ...
Hi all,
I hope that this is right place to ask. Sorry if not.
Suppose you are going to make a SideShow compatible device. Further, your device should use 2.4GHz Radio to connect to Vista. I am working on a hardware/firmware project to support that.
The idea is to create a USB dongle that has built in RF module. Firmware on that dongle should be able to receive (using USB) SideShow data from the Vista side and transfer it to the device by the radio.
On another side, for SideShow devices, we are going to provide our customers a RF module (hardware, with SPI connection) and an API to use it.
So, my project is not SideShow device but hardware/firmware to provide SideShow compatible wireless link to the device.
There is a lot of examples how to write gadgets, how to use SideShow simulator etc. However, I haven't found good source of information about underlying SideShow protocol i.e. how is the data supposed to go from Vista to the device and vice verse?
I understood that SCF is used to describe text data etc. But how about binary data?
Is there a low level SideShow protocol? How it works in first few levels of OSI Model (Physical and Data Link)?
Maybe I do not understand some of base concepts here?
Thank you.
Mileta.
[1274 byte] By [
MiletaR] at [2008-3-7]
Hi,
That sounds like a really interesting project!
First of all there isn't a "SideShow Protocol" as such. The beauty of SideShow is once the data leaves the gadget it is entirely upto the driver as to how it is handled.
Everything that is passed to and from the SideShow framework is sent via the ISideShowDriver interface (http://msdn2.microsoft.com/en-us/library/aa508359.aspx) which is implemented by a SideShow driver. For example, content pages (via the OnAddContent method) driver receive 2 Guids (Gadget ID and Endpoint ID), a content ID (DWORD) and a byte buffer containing the data. The driver then either processes the data and performs the calculations on the pc or sends the byte buffer to the device for it to do the calculations.
An example of a SideShow Endpoint is SCF. SCF describes content pages in an XML format that is easy for both gadget and device to understand. SideShow can support any number of endpoints and therefore the driver needs to allow for any type of data. Devices don't have to support SCF to be SideShow compatible devices but for them to be compatible with the current set of gadgets then it makes sense to include support. Due to the vast range of data types I am presuming that is why a byte buffer is being received by the driver from the framework. It is upto the driver to supply the Endpoints that it supports so that the SideShow framework can pair up compatible devices for the specific Endpoints. Other examples of endpoints could include support for audio/video or even more complex structures to be sent from the device to the gadget (ie textual data instead of navigation commands).
As the device manufacturer you will need to implement a user-mode driver that acts as the proxy between your RF module and the SideShow framework. A fantastic sample is included in the WDK which demonstrates how to implement a skeleton driver for Windows SideShow.
Once you have established the communication between the framework and your device you will need to write code to parse the data (ie. SCF). Depending on the level of complexity of your device depends on the amount of SCF you choose to support. Although, if your project is only involved with the communication then this phase can be left out
. Despite this, your driver will need to provide points for the device to send back application events (see the WDK for information on the structures for these).
Information on these topics is available in the WDK (http://msdn2.microsoft.com/en-us/library/aa508239.aspx).
