Too Much Abstraction?? Can we deploy libraries anymore?

[cubelogic_io]

I have bought and used mikroE products since the inception of your company. I use them in real product design because, like most of your customers, I am not a professional embedded software developer, though I am a company owner and a successful product designer. I only break out the mikroE board when I am ready to develop the code for my products. In the past I would use and deploy your libraries, after testing them, as they and the supplied example code got me to my solution quickly while keeping me at flying low at the hardware level while I developed my deployable code using a Click or a peripheral breadboard with the and EasyPIC devboard.

I have bought Necto Studio and spent the last few days trying to see if I could use the examples, as I did in the past, to help develop my next product. It appears that the mikroSDK and its examples really only benefits hobbiest who will never move off of the development board in their basement or back bedroom and mikroE (initially anyway) to quickly deploy code and examples across your complete ecoSystem of dev board architectures. I develop mainly in PIC and any one product that most develop will only operate on one architecture, i.e. we are not developing apps that have to run on IOS and Andriod. So why would I want you to abstract me from the hardware? We are embedded developers and people learning should stay learning at the lowest level the hardware level, as mikroE use to provide us.

I have read the entire mikoSDK document and found no answers there that debunk my concerns.

I could be misinformed and if I am could we be shown an example like Click Pressure 7 board example by using mikroSDK without using the mikroBus (which abstract us from the hardware).
I really hope I am misinformed as I have just invested heavily in new mikroE hardware which is making its way to me as we speak.

BTW - mikroE knocked it out of the park with the hardware in these V8 developer boards. What a piece of hardware, very nice!!!

[filip]

Hi,

First of all thank you for your opinion and kind words about the 8th generation of development boards.

The whole idea behind the mikroSDK is to make application code portable and reusable on many different platforms and architectures.

Since we have a lot of add-on/extra boards, MCUs and compilers supported, we needed some kind of abstraction layer(s) in order to handle every possible combination of beforementioned pieces.
The intention is that the user can easily switch from one HW/SW setup to another, without needing to know the internal mechanism in which it operates.

On the other hand, if a more advanced level of approach is needed (i.e. accessing registers manually, taking care of every aspect of the HW/SW), this is also supported as the drivers for our add -on boards
(in your case a click board) are open source, so you can see how they are configured and use them in legacy mode (i.e. without the usage of mikroSDK).

Regards,
Filip.

[vidsranja]

Hi,

SDK is not that much different as you think from former libraries. It is just somewhat different organized software architecture and layered so that it is more portable and reusable. You have driver for click board (click library) as you had before. You have driver for MCU periphery (Eg. SPI) as you had before, right? It is now only separated in two layers (driver and HAL), and it is all part of one software package (mikroSDK). You had abstraction in former libraries too, when you use

Code: Select all

UART_WriteText("Abstraction!")

, isn't that abstraction? If you put your shoes in mikroe perspective, they need to develop libraries, that you use, for a lot of different hardware, without portability it starts to get very hard to develop new and maintain existing libraries.

The key differences are:
* One unified interface across families (I think its more accurate than architectures). Pros: Gives you portability and code reuse. Cons: Less access to some hardware specific functionalities.
* Removed sbits. Middleware libraries are not coupled with hardware registers. Portability and reusability!
* Drivers have context, so you can control more than one device (Eg. click board)
* The MCU periphery drivers and other libraries are not part of the compiler, instead its part of MikroSDK package, so they have its own lifecycle.
* Extended with board definitions, so it is easy to map driver pins, without looking at scheme.
* It is now open source!!!
* It has really nice documentation, and I believe it would get even better.

When you develop library you want to abstract hardware in that way so the code is not tightly coupled with hardware registers, so your upper layers are more portable. It is common sense in programing, even (especially) in embedded world.

The new SDK is more powerful then former libraries, mikroe just don't put enough effort to explain that to users. I guess you just need time to learn and accept the new way of thinking.

As for your question, you can configure click driver on pins you wish

Code: Select all

pressure7_cfg_t cfg;
cfg.scl = PA11; // or whatever pin is connected on your board
cfg.sda = PB12; // or whatever pin is connected on your board

pressure7_init(&pressure7, &cfg);

And never say never -- you don't know when you might switch to another hardware, eg. some cheaper MCU appears on the market, would you like to have hard time porting all your nice applications and libraries to that new hardware? I don't think so.

Best regards,