Alljoyn: embedded view of the developer. Part 2: Linux to help us

The previous part of the Alljoyn cycle : embedded view of the developer. Part 1: Introduction

We continue the story of how to get a "real piece of iron", working on the protocol AllJoyn. The ultimate goal of the cycle is to get a prototype of the “smart Wi-Fi light bulb”. And it is precisely the “prototype”, because we will not touch upon the implementation of the power section of our light bulb, since this is a separate major topic that has nothing to do with frameworks and control methods. Therefore, we restrict ourselves to the LED on the SAMD21-XPRO debug board.
')
Before we start porting the framework to the microcontroller, we will deal with tools that will provide us with invaluable assistance in the development process. In principle, AllJoyn is a cross-platform framework and you are free to use the operating system option that is convenient for you. I used Linux (Ubuntu) - simply because it is more familiar to me.

We download source codes, we compile, we try

To do this, follow the instructions in paragraph 4.1 of the instructions from the official site. True, this instruction suggests using Git to download source files, but with this method the framework refused to compile (the situation could have changed since then), so I downloaded the source files one folder from the official site and laid them out in accordance with the required structure. I put the sources in my home folder in the alljoyn / lsf directory.
You need to get the following file structure:
~/alljoyn/lsf
|------ core
| |------ service_framework ( Lighting Service Framework Source)
| |------ ajtcl ( Thin Core Source)
| |------ alljoyn ( Standard Core Source)
|------ base_tcl
|------ base ( Base Services Source)

To compile, we will need additional programs. We put them:

 sudo apt-get install build-essential libgtk2.0-dev libssl-dev xsltproc ia32-libs libxml2-dev sudo apt-get install python sudo apt-get install scons sudo apt-get install libssl-dev 

Go to the service_framework folder and build the project:

 cd ~/alljoyn/lsf/core/service_framework scons WS=off 

I am not a great Linux expert, but in the process of working with him I had the persistent feeling that there are no two identical solutions of the same task on different computers and there are always some nuances in each specific case. Personally, I had a long trip to the torment before everything was successfully gathered, but I don’t see much point in describing my adventures in this article. So go ahead and in the end you will see the following:

 scons: Reading SConscript files ... BULLSEYE_BIN not specified Using OpenSSL crypto GTEST_DIR not specified skipping common unit test build BULLSEYE_BIN not specified GTEST_DIR not specified skipping About Service unit test build GTEST_DIR not specified skipping alljoyn_core unit test build GTEST_DIR not specified skipping LSF unit test build scons: done reading SConscript files. scons: Building targets ... ... scons: done building targets. 

As a result, there will be compiled a lot of things. We will need 3 programs:

1. lamp_service is an imitator of a “smart bulb” (hereinafter, I will often call this program a “bulb”). Use Thin (lightweight) version of the framework. It is this program that we will port to the Atmel SAMD21 microcontroller in the third part of the cycle. Also, this program is the basis of the Android application Luminaire. Located in the ~ / alljoyn / lsf / core / service_framework / build / linux / thin_core_library / lamp_service / bin folder
2. lighting_controller_service is the Router for our Thin device (read the theoretical part in the first part). Lies in the folder ~ / alljoyn / lsf / core / service_framework / build / linux / standard_core_library / lighting_controller_service / bin
3. lighting_controller_client_sample is the “control panel” with which we will control our light bulb. This program is the basis of the Android application LSF, which was mentioned in the last article. Located in the ~ / alljoyn / lsf / core / service_framework / build / linux / standard_core_library / lighting_controller_client / samples folder

Thus, we can now present the “abstruse” pictures from the previous article in a more substantive form:


Now turn on WireShark, run lamp_service and see what happens:

 cd ~/alljoyn/lsf/core/service_framework/build/linux/thin_core_library/lamp_service/bin ./lamp_service 

In order not to drown in the stream of network traffic, we add a filter to WireShark udp.port == 5353 || udp.port == 9956

We see that the bulb sends its presentation data to the network in search of the Router, using all three methods available to it (multicast 224.0.0.113:9956, multicast 224.0.0.251.153535, broadcast: 9956). In this case, these attempts are futile, as there is no Router on the network. The light bulb periodically sends these packets to the network, after which it “pauses” for a while (up to 40 seconds).

Consider for interest the contents of one of the packages. We will look at the broadcast AllJoyn package. Although it is an outdated format (as discussed in the first article), it looks less cumbersome compared to MDNS and therefore easier to understand. MDNS uses a similar principle.

The bus identifier may or may not be used by the Router to decide whether the Router will be “friends” with our device. Who is he to be friends with when the developer writes the Router code. The IP address and port are used to indicate the TCP connection data to Router. In our case, we see that the light bulb lifted a TCP server on port 9955.

Add Router

In principle, it does not matter whether Router is physically on the same device as lamp_service or on different ones. But if you run lighting_controller_service (this is a specialized Router for our case) on the same computer, they will connect inside the machine, so the exchange will not work through a network card and WireShark will not fix it. To visualize the exchange, run lighting_controller_service on another computer.


As we see this time, the “cries of the light bulb” did not go unheard, and Router, after having previously “heard” the light bulb via UDP, connected to it via TCP and produced a rather lengthy process of exchanging more detailed information. In principle, to successfully use the framework, it is not at all necessary to understand the intricacies of this exchange, since it lies on the shoulders of the alliance developers and is delivered in finished form. But if you look closely, you can see the use of DBus of a similar protocol with all sorts of BusHello, Introspect, etc. Looking ahead, I’ll note that later in the exchange process, if you wish, you can use all sorts of authentication methods, encryption, etc. As a result, AllJoyn resembles a sort of Frankenstein, consisting of parts of different protocols and technologies. But this is the lyrics, I repeat, in theory, diving too deeply is not required (although this fate did not pass us, as in the process of work we had to pretty much walk around the rake).

After the light bulb has “made friends” with Router via TCP, it (the light bulb) stops “making noise” via UDP. Now Router does it for it, offering its services to control panels. The process occurs in general similarly - Router multicast and / or brodkastovo notifies the local network of the existence of a light bulb (or light bulbs). If the control panel is interested, it connects via TCP. And here is an important difference: Router does not cease to “make noise” via UDP so that other panels can join in if necessary.
Actually, now it becomes clear such an intricate organization of exchange. Router is a program on “serious” hardware, with a normal implementation of the TCP / IP stack and supporting a large number of simultaneous connections. While the requirements for the light bulb are reduced - all that is required from the microcontroller and the stack is the ability to support one UDP socket and one TCP connection.

We present the above in the form of a comic book:

Connect the "control panel"

The last exercise for today is to see the 4th stage in the picture above in action. To do this, run our control panel. We use for this a separate instance of the terminal. Again, it does not matter on which physical device our panel will be launched:

 $ cd ~/alljoyn/lsf/core/service_framework/build/linux/standard_core_library/lighting_controller_client/samples $ ./lighting_controller_client_sample 

As a result, if done correctly, the panel should detect our light bulb:

Immediately we see the 32-bit unique identifier of the light bulb, which was broadcast over UDP. Unfortunately, when preparing this article, different instances of lamp_service were launched, so the values ​​of this identifier on the screenshots do not match - just take a word for it that this is it.
In addition to detection, lighting_controller_client_sample allows you to perform a lot of manipulation with a light bulb (request parameters, set values, etc.). If you wish, you can play around with it, but I will omit this part so as not to inflate the article to indecent scales. I will only warn you that the program's interface is far from being friendly ... but this is one of the most insignificant obstacles on the thorny path of the AllJoyn pioneer.

On this theoretical, technical and moral training will be considered complete and in the third (probably final) part of the cycle we will begin to implement the “smart light bulb” in the gland and shooting the result for youtube.

Appendix A. Compliance with linux programs and mobile applications

The programs collected and used today clearly echo the mobile Android applications, which were discussed in the first article . Fix this moment:
The Luminaire application corresponds to the lamp_service program. We will port it to the microcontroller in the third part.
The LSF Sample App is compliant with the lighting_controller_client_sample program. It is used to control our light bulb.

Appendix B. Statement of the problem for the third part of the cycle

As a result of our research, we want to get a physical device (debugging with a microcontroller and a Wi-Fi module) that will be detected and controlled from our control panels (a mobile phone with the LSF Sample App installed and a program in lighting_controller_client_sample ). As the Router, we will use the lighting_controller_service program running on a computer with Linux.

Today this is all, I hope it was interesting. Until new meetings.