Hey there,

I am new to the mikroe world, and I initially got into it because I thought the Mikrobus concept combined with a cape is a really nice way to plug in lots of different sensors for various prototyping projects. I also like the Hexiwear idea a lot.

However, I have trouble finding any useful documentation and software support in common programming languages, especially Python. It's confusing to me -- first introducing a hardware standard to speed up development, but then each board has so little documentation on the software / usability side of things that it negates the great idea of an "plug and play" style click board standard.

For example:
-- The beaglebone cape has a firmware, but on the mikroe website there is no documentation what this firmware really does, and if it works with current versions of bb.overlay. I found one overlay but that was totally deprecated and did not work. It takes a lot of time to look around at dozens of old blog posts in order to get a clue what's going on. There is a pin list published by another distributor, but none of that is discussed on the Mikroe website.

-- Oled B click. There is an undocumented 5V pin. The print on the board says 3.3V. So which is it? I saw someone asked that question in one of the subforums here but the answer is still unclear to me. No matter what I try, I can not get the B to show anything on the screen, not even a flicker. Other boards with the SSD1306 for SPI or I2C, even the cheapest B-ware from Amazon for 6$ a piece are much easier to operate with one of the many libraries out there (Adafruit, u8g2, etc.) What is the advantage of the click board approach here?

Together with the unknowns about the cape, the lack of documentation makes debugging very arcane. I end up putting each click board on a breadboard because I do not trust that the cape is working.

-- Oled C click: Same here, I have other displays working with the SSD1351. It is a well supported controller. Could you at least add the untypical display size to the constructor lists of the most common libraries on Github? This is what takes a lot of time, when other displays are ready to go right away. The oled c is recognized by the Linux kernel driver using SPI, and the graphics driver and framebuffer /dev/fb* is loaded, but the screen just does not show a single flicker.

-- Weather click: Advertised as temperature monitoring solution. Bosch marketing themselves are far more careful in their datasheet for the BMW280. Turns out the unit heats itself up and returns temperature readings 3-4 degrees C too high, and then the humidity also is not accurate at all. Bosch seems to limit the marketing communication now to very accurate pressure readings, but that does not really help. The Adafruit temperature board for 5.95$ with an SI chip is way more accurate and as easy to get it running. Online forums are full of complaints on the BME280, but no hint from mikroe on their website that there might be issues. (I understand the poor measurements are not your fault and Bosch should not market this IC as weather station kind of thing. But please let me know that in advance before buying one.)

-- Speaking of Github: It's great that you upload some of your products there. How about being a bit more active in the community aspect? I bet very few of the library maintainers would mind accepting pull requests from your engineering team.

-- Why not supporting something like platformio.org, and promote the mikrobus standard there by offering really nice library support?

To sum up: When the click boards arrived, I was really impressed by the packaging, the good hardware design, and the concept. It was clear to me that you're following a premium approach. And I would be very willing to pay more for good electronics. But actually using these boards is in some ways harder than getting random stuff from Amazon to work.

My question: What is the reasoning behind this? Why making so nice hardware, and then ignore the actual user experience? I'd love to build a collection of click boards and related hardware, but I have put that idea on hold until I better understand your goals with all this. I hope it is more than selling your compilers. You could earn so much money with a truly usability-focused click board product line!

PS: Is Hexiwear better documented?

Hi,

Welcome to the MikroE forum.

Thank you for your time for sharing your opinion,
and I sincerely apologize for all unpleasantness.

I understand you, but unfortunately, at this moment, we can only provide hardware
and software support for development boards which are MikroElektronika's products
and which MCUs are supported in MikroElektronika's compilers.

For shields which are made for non MikroElektronika's boards,
we can only provide hardware support.


I'm sorry for misunderstanding, Beaglebone cape doesn't come with firmware, it is only a shield,
i.e. pinout for connecting on an easy way click boards. It only has in addition chip for EEPROM.

All our products are tested before sending, but if you doubt if mikroBus Cape is working,
you can open a ticket and we will investigate it:

https://helpdesk.mikroe.com/index.php?/Tickets/Submit


5V pin is used along with AP7331 linear regulator
which is used for VDDB (Supply voltage for internal DC/DC on display).

For the click boards there are examples written in our compilers,
which can be used as reference. Also, all click boards are tested before sending.

And with introduction to mikroSDK
examples can be easy written for MikroElektronika development boards.


Thnak you for the suggestions, I have forwarded them to our developers.

You can check Hexiwear documentation here:

https://github.com/MikroElektronika/HEXIWEAR

If you have any doubt regarding some feature, feel free to contact us.

Kind regards,
Lana