mikroSDK - Learn What it is and How to Use it

2018-02-07 | By MikroElektronika

License: See Original Project

Time is the most precious thing we all have. Everything else can be rebuilt or recovered. Everything but the time. For this reason, anything that saves time is of great value. By using the mikroSDK software development kit, you will be armed with very powerful time-saving software tools. You will always BE ON TIME for your projects.

Standardization is a Must

The main advantage of a standardized development solution is that it is very efficient. Once developed according to a certain standard or protocol, the solution will always have a known and expected form and functionality, regardless of other parts or components of a system.

The mikroBUS™ is a perfect practical example of how using a standardized solution really saves time when it comes to the hardware. One click and your peripheral module are routed with no errors and exactly the way the MCU expects it. The mikroBUS™ also represents a proof of this concept: the mikroBUS™ as a standard, other than on most MikroElektronika development boards, found its way to more than 30 development boards and it brought the support for over 370 different click board™ devices, featuring all kinds of different sensors, controllers, displays and other “intelligent” devices.

Taking into a consideration that the integration of the mikroBUS™ is possible in two ways (the click board and the mikroBUS slot on the developed hardware), it is clear that the software solutions have to be standardized in two levels, too.

From the software point of view, the software can be developed with any of our 7 different compilers, which means that two levels, or two layers of standardization mentioned above, have to be implemented on 7 different compilers/architectures. That can be quite a challenge. Doing so with 3 different languages available for all the 7 different compilers represents an even bigger challenge. And there is more to that. ARM standard itself is implemented by several different companies and we support 5 different ARM vendors for this popular MCU architecture.

Code Portability and Reusability

Every embedded software developer knows that nothing saves time like the simple and easily portable library. A portable library also means that the library can be reused. It doesn’t take a genius to understand how portability and reusability of the code contribute to productivity.

By developing the mikroSDK standard implementation in a form of the mikroBUS API and click libraries, we have managed to achieve a very high level of reusability of the written code. The reusability ratio that is achieved with the mikroSDK standard can be illustrated with these facts: once written, the board def (mikroBUS API) for a specific system can be reused for every other project, developed in compliance with the mikroSDK standard.

The same goes for the Hardware Abstraction Layer, also known as the HAL (Click Library) - once written for a specific architecture, it can be reused with any other project for the same architecture.

mikroSDK as the New Standard

The mikroSDK as the new standard, defines the implementation of the portability problem solution, in a form of the mikroBUS API and the Click Library.

The mikroBUS API represents a separate layer, which consists of a set of board definition files (board defs), as the implementation of the support for our development systems.
The Click Library represents a form of the software support implementation for the click board™ products line.

These two parts of the implementation represent a good and well defined, standardized development kit for writing the reusable application code.

The standardized simple interface in case of both layers is implied because every user-friendly software development kit should have simple and easy to remember functions, which allow fast adjustment and smooth workflow for every user. Also, it should be mentioned that having a standardized interface opens other possibilities, such as the code generators, code automatizations and many more. MikroSDK currently supports more than 25 development systems.

The Final Application

While developing an application by using the mikroSDK, there is no need to worry about if the specific pin on your mikroBUS socket is routed to PA4 or PB6 pin of the used MCU, for example. Also, there is no need to list the documentation and look for an information about which SPI module is routed on the second mikroBUS socket of your development board, either. All of that is already implemented through the mikroBUS API, so you do not have to think about it.

The code used for the peripheral access is implemented through the HAL as a part of the library, so there are no differences between the peripheral access functions among different architectures. These functions will seem identical for the driver layer, which is now used to accesses the peripherals through the HAL layer. The initialization of these peripherals is now done through the mikroBUS API function calls. The configuration of the peripherals is the only difference that appears in the code itself, but that’s not a cause for concern – with every library, the default value is provided and it is really easy to find it and edit since the standard stipulates that it has to be separated from the application code.

Copy Code

void systemInit()
{
mikrobus_gpioInit( _MIKROBUS1, _MIKROBUS_CS_PIN, _GPIO_OUTPUT );
mikrobus_gpioInit( _MIKROBUS1, _MIKROBUS_PWM_PIN, _GPIO_OUTPUT );
mikrobus_spiInit( _MIKROBUS1, &_UTS7SEGR_SPI_CFG[0] );
}
void applicationInit()
{
ts7segr_spiDriverInit((T_UTS7SEGR_P)&_MIKROBUS1_GPIO,
(T_UTS7SEGR_P)&_MIKROBUS1_SPI );
uts7segr_lightCtl( 1 );
}

Example of the UT-S 7-SEG R click initialization.

The result is a pretty clear and architecture independent application code, which can be used on any development system, regardless of the used architecture or compiler. Even by quickly glancing through the code, the user is able to understand which mikroBUS socket and which peripheral modules are used by the driver. In our case that is the mikroBUS1 slot with the CS and PWM pins on it. The SPI peripheral module is used, too.

mikroSDK Has its Own Place in our Ecosystem

If you have tried to use some of the demo applications codes released after the December the 1st, you have probably noticed that the used functions are looking somewhat strange and unfamiliar. The things you were looking at were parts of the mikroSDK, or more precisely - the mikroBUS API layer. In order to run such applications, the mikroSDK package should be downloaded and installed to the compiler. It can be found on our Libstock page.

After the installation, a new node will appear inside the Library Manager, labeled as “mikroBUS Board Definition API”. Subnodes of this node depending on the currently selected MCU. For example, you can try and change the MCU to some of the MCUs used on the clicker 2 development boards and you will notice that the content of the Library Manager is updated along with the new Clicker 2 specific node, which will now appear.

The mikroBUS API is currently developed for every clicker, clicker 2 and the main development boards with their default MCUs. Along with the support for these development systems, mikroBUS API contains the generic board def files for the main development boards, which can be used for adding support for any of the currently unsupported MCUs. More information about the generic board defs and how to adopt them to own needs will be explained in the next article.

As already stated, the support for the development systems and the mikroBUS API is just a part of the whole story. The other part of this story is the Click Library, which combined with the mikroBUS API layer, make the complete mikroSDK solution.

The practical usage will be demonstrated through the UT-S 7 SEG R click Library application, because of its simplicity and clearly visible results on the 7 segment display. Note that before using any mikroSDK application code, the mikroSDK should be downloaded from the Libstock page and installed for the used compiler, as discussed above. It is a one-time installation - once installed, it will not require to be reinstalled it every time.

Step by Step Instructions

The first step is to download and install the appropriate library for the UT-S 7 SEG R click from the Libstock page, for the used compiler. After the installation, you will notice that there is a new node in the Library Manager panel (you might need to refresh the Library Manager by clicking the icon) The name of the node is exactly the same as the click board™ itself - that is the actual library node for this click. By unfolding this node, all the available functions will be listed. The help documentation can be opened with the mouse double-click. You can find the descriptions of all the available identifiers inside the help documentation.

Right mouse click on the UT-S 7 SEG R library node in the Library Manager will pop up a menu, with the “Example” item, among others. Clicking on this item will open the folder that contains the demo application example, which can be run by double-clicking on the appropriate project file icon. Another look at the mikroBUS API and you will notice that the default development system is already selected with the clock scheme already loaded. The last remaining step is to rebuild all the project sources (Rebuild All Sources - ALT+ F9). After this step, the UT-S 7 SEG demo application example is ready to be uploaded to the MCU (F11) and used.

If you have some other development system currently supported by the mikroSDK, be it a clicker or a clicker 2, the procedure is almost identical. The only thing that needs to be done additionally is to configure the project for the used MCU:

The appropriate MCU should be selected in the Project Settings panel. As already discussed, the mikroBUS API node will change accordingly and the desired development system can now be selected.
The clock scheme needs to be configured for the used MCU, which can be done through the Edit Project window (CTRL + SHIFT + E).
After these two steps, the rest of the process is the same as when the default system is used: Rebuild All Sources (ALT + F9) and upload it to the MCU (F11) - The application example code is ready to run!

Epilogue

Every embedded developer has his own favorite MCU. Also, there are many embedded developers that have started developing applications a while ago when 8bit MCUs were still a thing. Those developers know their 8bit MCUs by heart.

Let’s take an 8bit PIC as an example: you have developed your own application, using one of our development boards for 8bit PIC, and a click board. Your code works fine, everything’s perfect. But now, trends are changing and it is not enough to just have a working application, you need to add a Text-To-Speech (TTS) to it, for example. For an older 8bit PIC, this is can be too demanding. So, the most likely course of action would be to go PIC32. By using a click board, the functional continuity of the application on a hardware level is ensured: the click board will fit in the new mikroBUS™ with no issues at all. But what happens with the code?

Until now, you would have to redevelop the whole code, not only the TTS module part - because the PIC32, although still PIC family, is fundamentally different. The code written for the peripherals or pins would have to be redeveloped from the scratch, along with the new code for the TTS module. This leads to wasting time on writing a code for something that has already been working, in the first place.

By using the mikroSDK, this situation becomes a thing of the past. Since all the peripheral functions look the same for the driver code of the used click board™, the developer is free to focus on the development of the application code itself. The mikroSDK compliant click board application that has been working before, will continue working, even with the new PIC32 MCU and almost no changes to the code at all. Even with the STM32, if it comes to that! The developer now can start adding the TTS related code on a top of something that already works, not having to start from the scratch every time.

Again, as a demonstration, we will take the two completely different platforms, made by two completely different MCU manufacturers: PIC by Microchip and STM32 by ST Microelectronics. Also, we will use the UT-S 7SEG R click with the library, developed according to the mikroSDK standard.

Copy Code

#include "Click_UT_S_7SEG_R_types.h"
#include "Click_UT_S_7SEG_R_config.h"
uint8_t counter;
void systemInit()
{
mikrobus_gpioInit( _MIKROBUS1, _MIKROBUS_CS_PIN, _GPIO_OUTPUT );
mikrobus_gpioInit( _MIKROBUS1, _MIKROBUS_PWM_PIN, _GPIO_OUTPUT );
mikrobus_spiInit( _MIKROBUS1, &_UTS7SEGR_SPI_CFG[0] );
Delay_ms( 100 );
}
void applicationInit()
{
uts7segr_spiDriverInit( (T_UTS7SEGR_P)&_MIKROBUS1_GPIO, (T_UTS7SEGR_P)&_MIKROBUS1_SPI
);
uts7segr_lightCtl( 1 );
}
void applicationTask()
{
counter = 0;
while (counter < 100)
{
uts7segr_writeNumDec( counter );
Delay_ms(100);
counter++;
}
}
void main()
{
systemInit();
applicationInit();
while (1)
{
applicationTask();
}
}

Example of the UT-S 7-SEG R click initialization.

The Application Code is Identical for Both mikroC PRO for PIC and mikroC PRO for ARM Compiler

The UT-S 7SEG R click demo application example demonstrates the mikroSDK concept very clearly. There will be certain differences between different architectures, but now it all happens beneath the user-written code layer, transparently. This layered structure of the mikroSDK allows for easy tracking of the written code, so it is easy to understand where to make the necessary changes required to configure the application to work on a new platform. In the case of the UT-S 7SEG R click, it was just a single line in a config file.

As demonstrated, using the new mikroSDK standard certainly leads to tremendous time-saving. This practically means that the application code itself is reusable and switchable between different architectures and platforms - just like the click boards™.

The default systems for which the support is provided:

STM32 - EasyMX PRO v7 for STM32 with STM32F107VC
TIVA - EasyMX PRO v7 for TIVA with TM4C129XNCZAD
CEC - Clicker 2 for CEC1702
MSP432 - Clicker 2 for MSP432
KINETIS - Hexiwear with the Hexiwear Docking Station

EasyPIC PRO v7 with P18F87K22

PIC32

EasyPIC Fusion v7 with P32MX795F512L

dsPIC

EasyPIC Fusion v7 with P33FJ256GP710A

EasyAVR v7 with ATMEGA32

FT90x

EasyFT90x with FT900

Conclusion

The whole process of the specific library usage on a set of different development systems becomes very simple and quick by using the mikroSDK. A tremendous amount of time is saved, which would be spent on the redevelopment for each system, otherwise. Even if one of our development boards is used with another, nondefault MCU that is not yet covered by the mikroBUS API, the “generic” board will appear as the possible choice. Once this generic board is modified (instructions will be given in one of the next articles), it will stay usable for every other mikroSDK compliant Click Library, which is exactly what we started this story with: reusability and portability save time. So - BE ON TIME