eeprom homefeatured iot mercury Mercury System MercurySystem newsline Open Source Projects Projects tech

Mercury System IoT & Connectivity Made Simple: the Framework

Mercury System IoT & Connectivity Made Simple: the Framework

 

Let’s full the outline of the modular improvement system devoted to connectivity and IoT, deepening the discussion of the dedicated framework.
Second Episode.

 

In the article revealed within the earlier concern, we introduced the Mercury System, an progressive improvement system, notably suitable for IoT and connectivity-oriented purposes. At that time we targeted on the hardware of the system, detailing the baseboard that houses the modules and on the modules themselves; we have now additionally introduced the MSF (Mercury System Framework), ie the development framework for the system software, whose architectural scheme is proven in Fig. 1. We’ve additionally described the steps essential for the installation and indicated the third-party tools to put in so as to develop purposes with the MSF, because the latter is predicated on the MPLab X improvement setting and on the Microchip XC compiler line (particularly, it’s used for this first version of the MSF XC8).

Let’s get on to more sensible matters. This can lead us to the event of our first purposes with the Mercury System ranging from the analysis of the set up directory of the Framework, which has already been talked about in the earlier episode.

 

Fig. 1

 

MERCURY SYSTEM FRAMEWORK

Fig. 2 exhibits the contents of the Framework installation folder; under we describe the contents of the person folders created in the course of the set up itself.

  • Documentation: incorporates the documentation of the framework along with the Launch Notes and all of the datasheet datasheets, ie the hardware.
  • MercuryFwk: accommodates the supply code of the framework.
  • MercuryProjetcs: represents the default directory for software improvement. It also accommodates some pattern tasks launched with the framework.
  • Tools: this folder incorporates some improvement tools, and particularly the host aspect software of the USB bootloader.

 

Of specific interest is the Documentation folder, which in addition to containing the varied datasheets of the hardware elements of the Mercury system, incorporates the Getting Started Information (the corresponding file is MS_GettingStartedGuide.pdf) and the framework Consumer Guide, containing the detailed description of all out there APIs (the relative file is MS_FrameworkUserManual.pdf).

Having stated that, we’ll now go on to elucidate tips on how to create an software with our framework.

 

Fig. 2

 

CREATION OF A NEW APPLICATION

The only option to create a new challenge for the Mercury System is to benefit from the era script, to be able to routinely configure all the paths and choices vital for the challenge to compile appropriately. To do that, go to the MSF  MercuryProjects directory and run the “CreateNewProject.bat” script, as proven in Fig. 3.

 

Fig. 3

 

After you have launched it, the script will ask you to enter a name for the undertaking, as shown in Fig. 4 and then create the right MPLab X venture folder construction and information needed, with the right links to the framework ( in Fig. 5 the undertaking creation part is illustrated).

 

   

Fig. 4/5

 

At this point you’ll be able to open MPLab X and load the newly created challenge, utilizing the “Open Venture …” choice from the consumer interface toolbar of the development setting, as shown in Fig. 6.

 

Fig. 6

 

The newly created undertaking has the default identify “AppTemplate” but this identify could be changed at will using the suitable improvement setting choice. To entry this feature, merely right-click on the undertaking icon and select, from the contextual menu that opens, the “Rename” choice: as soon as the option indicated has been selected, the dialogue box will appear proven in Fig. 7, through which you’ll be asked to enter the brand new identify to be given to the venture. Don’t overlook to also verify the “Additionally Rename Venture Folder” choice, in order that the folder containing the MPLab X information can also be renamed appropriately.

 

Fig. 7

 

At this level, it is best to get a display of the Undertaking Supervisor just like the one proven in Fig. 8, by which the information related to the system configuration and the appliance in query are additionally highlighted. We’ll analyze these two information in detail in the following pages; for now, take them for good.

 

Fig. 8

 

By default, a new venture is created with two predefined constructing configurations, as shown in Fig. 9. Building configurations are nothing greater than, as the phrase itself says, totally different configurations with which the challenge may be compiled and linked. One of these configuration has an impression on memory format, code optimization, warning degree, execution velocity and lots of different parameters which have an in depth correlation with the compiler and the target. Particularly, the constructing configurations generated by default for a brand new undertaking with the Mercury Framework are:

  • Standalone: ​​standalone configuration. The hexes generated with this configuration require a Micro-chip programmer to be flashed on the baseboard.
  • Bootloader: configuration suitable with the bootloader. The hex generated with this configuration may be loaded into the memory of the baseboard using the USB bootloader (we’ll see later how to do that).

 

Fig. 9

 

As you’ll be able to easily guess, this configuration acts on the memory format, so as to allocate the appliance in a portion of reminiscence subsequent to that occupied by the bootloader by default. Word that flashing a Base Board with the “Standalone” constructing configuration the bootloader (which by default is programmed on the BB) can be deleted. This operation could be reversed just by reprogramming the bootloader on the Base Board (an image of the bootloader is offered as precompiled .hex within the MercuryProjects 00_Precompiled folder). To confirm that the challenge has been appropriately generated, we will attempt to compile it: click on one of the two buttons marked “build” or “clean and build”, as proven in Fig. 10.

 

Fig. 10

 

Once the building part is accomplished, if all the things is profitable you will notice a window just like the one proven in Fig. 11, during which the word “BUILD SUCCESSFUL” will seem in green, to verify that the compilation was carried out with out errors.

Because of this operation you will see, in the path inside your undertaking “.MyNewProject.XdistBootloaderproduction” a file with .hex extension (MyNewProject.X.manufacturing.hex) that you need to use to program your baseboard, as a way to prepare it for the implementation of the appliance in the improvement part.

 

Fig. 11

 

SYSTEM CONFIGURATION FILE

The Mercury framework requires that some primary configurations be made, which have to be offered in the form of consumer information, as they could range from venture to venture.

These configurations point out which sort of modem to use, slightly than the enabling or disabling of certain modules, and lots of other issues, relying, the truth is, on the desired software and the hardware it includes.

When a venture is generated, the responsible script mechanically creates a file referred to as sys_cfg.h in the new undertaking folder; this file incorporates all the static configurations of the precise venture and it is the consumer’s duty to switch it based on his wants.

In TABLE 1 you’ll be able to see an inventory of an important configurations of a venture realized with the Mercury System Framework.

Table1

 

APP

When the era script is launched, in addition to the configuration file, the latter also creates a pair of information referred to as “app.c” and app.h that can be used as a template for the event of the primary software.

The “app.h” file incorporates a single related configuration, ie the macro:

 

#define MY_APP_TASK_PERIOD_MS ((UINT16) (50))

which determines the execution interval of the appliance process.

By default, the latter is 50 milliseconds, however the worth could be modified by the consumer within sure limits.

The app.c file as an alternative incorporates the actual definition of the duty, which is composed of a change..case structure with two houses:

 

  • InitializationState
  • RunningState

 

These two homes symbolize the states by which the appliance process may be found and, as may be easily seen from the identify, the primary represents the initialization status (executed once at startup), while the second represents the operating status ( executed periodically at the periodicity of MY_APP_TASK_PERIOD_MS).

Eager to make a parallel with the Arduino world, these two states of the appliance activity characterize the setup and loop routines that symbolize the bases of a sketch created with the Arduino IDE.

Fig.12 illustrates graphically the above.

 

Fig. 12

 

Subsequently, to understand our software we won’t should do anything but understand our software code and make calls to our initialization features and to the periodic features inside the MyApp_Task process. Being based mostly on a cooperative RTOS (Real-Time Operating System), the Mercury System goes very nicely with Mac-china-style implementations within the Finite States; not by probability, this is the methodology that we’ll use in the practical tasks that we’ll propose to you in future articles.

It is very important contemplate that calls to blocking cycles, reminiscent of whereas or for infinite, cannot be made, as these cycles would block the execution of the “most important features” of the Framework. We’ll cover this facet in more detail once we make the first sensible examples.

 

USE OF THE BOOTLOADER

As we saw earlier, the Mercury System Base Boards could be programmed using a bootloader, and we have now additionally seen which is the constructing configuration that permits producing a hex file suitable with the Mercury bootloader. What we nonetheless need to explain is the actual bootloader programming process.

Earlier than flashing an software on a Base Board using the bootloader, the latter have to be appropriately activated.

The sequence to activate the bootloader could be very easy:

  • it is advisable to join the BB (off, ie with the primary change within the “OFF” place) to the PC utilizing a microUSB cable;
  • then press and hold the SW1 button (boot change);
  • finally, energy may be provided to the Base Board, shifting the primary change to the “ON” place.

 

In essence, the bootloader is activated if, at first of the board, the digital line related to the SW1 button is at a low logic degree.

Activation of the bootloader is confirmed by the LD1 LED, which can flash at high frequency. At this level, it’s attainable to start out the host software of the bootloader (from the shortcut “MercuryBoot”, current on the desktop or in the begin menu). If the Base Board is the host software speaking appropriately, you must see a display like that proven in Fig. 13 seem on the display, indicating that the gadget is within the “Hooked up” state.

 

Fig. 13

 

At this level it’s potential to pick the “Import Firmware Image” choice from the file menu or from the shortcut icon in the form of a folder; the display that lets you select the hex file to load will appear (keep in mind to make use of the file generated with the build configuration “Bootloader”).

Once the hex file is appropriately loaded, it’s attainable to flash the Base Board utilizing the “Erase / Program / Verify system” choice (from the Program menu or by way of the shortcut button with the image of the file and the built-in joined by an arrow).

If all the things is profitable you will notice a display like the one proven in Fig. 14, which indicates that the bootloading process has been successfully accomplished. At this level you’ll be able to reset the board (from the primary change or utilizing the “Reset System” choice of the MercuryBoot software), to permit the newly loaded software to start out operating.

In fact it’s also attainable to program the BB utilizing a traditional programmer for Microchip units, and in this case, it’s also attainable to use advanced debugging features (relying on the system used). Within the latter case, nevertheless, care have to be taken to use the standalone configuration, or alternatively load the hex image of the bootloader as “Loadable” of the MPLab X undertaking. The BB exposes the programming pins (MCLR, PGD and PGC) and a connector suitable with the Microchip normal is all the time proven on the enlargement boards (it’s recommended to discuss with the Base Board and Enlargement Board datasheets for more particulars).

 

Fig. 14

 

FIRST PRACTICAL EXAMPLE: HELLO WORLD

Now that we have now completed a first overview of the development framework (there can be far more to say, however here we restrict ourselves to a purely “consumer” description), let’s move on to the primary, simple practical examples. As a first instance, we understand the basic Whats up World program, which makes an LED flash at a predetermined frequency. The Base Board 110 will be the hardware help for this first instance

So let’s create a new challenge referred to as “HelloWorld” following the instructions within the earlier part and open it with MPLab X.

In Fig. 15 we present the display of the venture supervisor of our first example.

 

Fig. 15

 

What we suggest to do is to make the LD1 LED flash at a frequency of 1Hz (so 1 second on and a second off).

To implement this easy software, the framework comes to our assist, and particularly the “SSL LED module, which already has pre-packaged LED administration features, and particularly the 2 features “Led_SetLedBlinkTime” and “Led_SetLedStatus”, of which we report the descriptive charts (Fig. 16 and Fig. 17), extracted from the Consumer Guide.

 

Fig. 16

 

As can easily be guessed from the descriptive tables, by way of the primary perform we set the flashing occasions, whereas with the second we put the LED we want to flash in blinking standing (LED_STS_BLINK). Then the framework will deal with making the LED blink for us. We’ll then need to name the perform “Led_SetLedBlinkTime” with arguments LED_1 (Macro referencing the LED LD1), and 1,00zero for the 2 flash occasions (because the occasions in this API are expressed in ms):

Led_SetLedBlinkTime (LED_1,1000,1000);

after which name the perform “Led_SetLedStatus” with arguments LED_1 and LED_STS_BLINK (enumerative which indicates that the referenced LED have to be set in blink status:

Led_SetLedStatus (LED_1, LED_STS_BLINK);

 

Fig. 17

 

So the code of our software is lowered to the one proven in Itemizing 1.

Listing1

 

To test the newly written software we will compile and program by way of the bootloader, as described in the earlier section.

SECOND PRACTICAL EXAMPLE: BT RELAY

After this primary simple instance let’s transfer on to something barely more complicated and extra oriented to connectivity: a BT remote management that permits us to activate and deactivate a relay. For this second example, we’ll want a more full set of boards, as we may even want a board with a relay and a BT modem. The required boards are, subsequently:

  • A BB110,
  • An SB110 (relay board),
  • One MB310 (BT modem).

 

For the interconnection, it’s potential to attach the three bunk boards, but in the realization of this instance, we used an EB110 (dual enlargement board), as it appears within the hardware illustrated in Fig. 18. What we propose to do in this case it’s to activate a relay on receipt of the string “R1: 1” and deactivate it when “R1: 0” is acquired, on the BT channel. The selection of strings is completely arbitrary and could be modified at will by the consumer. We proceed by producing a brand new challenge, as seen above and opening it with MPLab X. Also, on this case, the functionalities of the framework could be very useful, as there are already APIs for the administration of BT and I²C communication.

 

Fig. 18

 

The APIs we’ll use on this case is the next:

  • I2cSlv_SendI2cMsg (sending a knowledge buffer on the I²C bus);
  • MdmBt_ReceiveBtMsg (a receipt of a string from the BT channel).

The relative descriptive tables are shown for convenience in (Fig. 19 and Fig. 20):

 

Fig. 19 and Fig. 20

 

To know, as an alternative, what knowledge to send on the I²C bus to activate the SB110 relays, we need to consult the datasheet of the latter board, which exhibits the command set supported by this slave board, which for convenience is reported in Fig. 21:

 

Fig. 21

 

The command that pursuits us is the 0x50, that’s Set Relay Standing. For example, if you want to activate or deactivate relay 1, you will have to send the next instructions to the I²C bus:

  • relay activation: 0x50 0x01
  • relay deactivation: 0x50 0x00

This strategy is valid basically; whenever you need to use a certain one

Slave Board for the development of an software, it’s value checking instantly its datasheet and particularly the record of supported instructions. This set of commands can also be periodically up to date by the Mercury system developers.

As an alternative, as regards addressing on the bus, since we now have just one slave we will use the printed tackle 0x00 without having to fret about setting the handle on the SB110 as all the slaves respond to this specific tackle. Alternatively, we will use a special handle, however we should deal with setting it utilizing the appropriate dip-board of the slave board. Utilizing the APIs and knowledge obtained from the datasheet we’ve got created the quite simple perform shown in Itemizing 2, which have to be invoked in the operating status of the appliance activity.

Listing2

 

As you’ll be able to see from the itemizing, the MdmBt_ReceiveBtMsg perform is used in an if… else if … else selection structure to know if a message has been acquired from the BT channel (and ultimately copy the bytes acquired into the BtRxBuffer obtain buffer, along with their number within the variable RxDataLen). In the event that a message has truly been acquired, it’s searched, by the use of the strstr perform, of the strings library of C, if the string “R1: 1” or “R1: 0” is present inside the reception buffer BT. If the string “R1: 1” is found the relay is activated by sending on the bus 0x50 0x01, while if the string “R1: 0” is discovered, the relay is deactivated sending 0x50 0x00.

As you possibly can see no cycles of any type have been used, but the property of the appliance process to be periodic is exploited, and subsequently to offer a cyclic execution itself (within the particular periodic, with a periodicity equal to MY_APP_TASK_PERIOD_MS).

Having to use the Bluetooth modem in this instance we should care for appropriately configuring the framework, setting the macro “MODEM_USED” of the file sys_cfg.h to the value “BT_MDM”, to allow the relative stack. Also keep in mind, as indicated above, to invoke the “ManageBtCmd” perform within the “RunningState” state of the appliance process, as shown in Fig. 22.

 

Fig. 22

 

To test our new software we will use any Bluetooth terminal (PC or smartphone or tablet), or the particular Android software provided with this instance, a display of which is proven in Fig. 23.

 

Fig. 23

 

Utilizing the Android software could be very easy: first we pair the composed system with our Mercury boards to our cell phone, utilizing the BT pairing utility (the default pin of the BT modem is “1234”), then we launch the appliance and, utilizing the “Select System & Join” button, hook up with the board. If the operation succeeds, we will examine the standing of the relay utilizing the 2 “Relay ON” and “Relay OFF” buttons that we find on the app display.

 

CONCLUSIONS

In this second and ultimate instalment, we accomplished our overview of the Mercury System Framework, illustrating tips on how to create new purposes with this improvement software and in addition providing the primary simple sensible examples. Within the subsequent few articles, we’ll present new and extra complicated purposes, which exploit the potential of the system to implement connectivity, residence automation, IoT and rather more.

 

From openstore

Mercury System 

jlcpcb.comjlcpcb.com

!perform(f,b,e,v,n,t,s)if(f.fbq)return;n=f.fbq=perform()n.callMethod?
n.callMethod.apply(n,arguments):n.queue.push(arguments);if(!f._fbq)f._fbq=n;
n.push=n;n.loaded=!0;n.version=’2.0′;n.queue=[];t=b.createElement(e);t.async=!0;
t.src=v;s=b.getElementsByTagName(e)[0];s.parentNode.insertBefore(t,s)(window,
doc,’script’,’https://connect.facebook.net/en_US/fbevents.js’);

fbq(‘init’, ‘1435112296761783’);
fbq(‘monitor’, “PageView”);(perform()
var _fbq = window._fbq || (window._fbq = []);
if (!_fbq.loaded)
var fbds = doc.createElement(‘script’);
fbds.async = true;
fbds.src = ‘//join.fb.internet/en_US/fbds.js’;
var s = document.getElementsByTagName(‘script’)[0];
s.parentNode.insertBefore(fbds, s);
_fbq.loaded = true;

)();
window._fbq = window._fbq || [];
window._fbq.push([‘track’, ‘6021809506052’, ‘value’:’0.00′,’currency’:’EUR’]);

window.fbAsyncInit = perform()
FB.init(“appId”:”139297462792714″,”channelUrl”:”https://www.open-electronics.org/?sfc-channel-file=1″,”status”:true,”cookie”:true,”xfbml”:true,”oauth”:true);
sfc_update_user_details();
;
(perform(d)
var js, id = ‘facebook-jssdk’; if (d.getElementById(id)) return;
js = d.createElement(‘script’); js.id = id; js.async = true;
js.src = “//connect.fb.internet/en_US/all.js”;
d.getElementsByTagName(‘head’)[0].appendChild(js);
(document));
(perform(d, s, id)
var js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) return;
js = d.createElement(s); js.id = id;
js.src = “//connect.fb.internet/en_US/all.js#xfbml=1”;
fjs.parentNode.insertBefore(js, fjs);
(doc, ‘script’, ‘facebook-jssdk’));