Beaglebone Mikrobus cape, oled C, oled B support

[dkay]

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?

[lana.arsic]

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.

For example:
-- The beaglebone cape has a firmware.

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

-- Oled B click. There is an undocumented 5V pin.

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.

-- 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?

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

PS: Is Hexiwear better documented?

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

[parkersscott]

Good day!
I have to fully agree and scream in reiteration with use 'dkay', the message posted was spot on. You guys provide a well made product, it is packaged and cared for with great professionalism, and then you drop the ball completely!
If you are going to make a cape for BBB or any other product, at least have the professionalism to document the product and the usage. Pick one click board, any of them, and document the usage of BBB with the Cape and with the Click board. Otherwise, you are just producing paper weights that look great on a breadboard for a photo opportunity. This has nothing to do with your compiler and that you can only support your compiler, and has everything to do with unsupported documented products. I have addressed this on the BBB forum, and even at element forums, and no one has a clue as to how to use the cape and the clicks with the BBB, because it is undocumented!
I began searching on google as far back as October 2017, I had just received my Clicks and they as 'dkay' stated looked amazing, only to spend the next several days without finding ANY worthy documentation on how to get the cape and the clicks to work with the BBB.
Now over a year later, there is still almost ZERO information, what have you guys done in the last 12 months except continue to misrepresent and all but steal money from good paying customers. The only saving grace is a small piece of information on GitHUB.
If you guys would spend 5 days of quality time of documenting the BBB Cape the use of the overlay, and again pick a click board to use, and document how communicate and use it, you would sell clicks so fast that you couldn't produce enough!
Now myself and many users have just moved onto Adafruit and the use the (pHat, Hat, Cape, Feather) you name it, because they are well documented. I have several friends that are Electrical Engineers, and they won't use your product because it takes days sometimes weeks to make them work correctly, because you have no documentation on how to get a user to use your click's.
Now, to be fair, I know your click boards work, and they work well, you can put them on an Easypic V7, put some C code on it and it works great! So they are great boards if you just want to see them work, but are horrible for usage outside of MikroBUS.
I just wanted to echo what dkay said and the community at large, we don't need an apology, or acknowledgement that it is our opinion, we need these devices to work as advertised, or take them off the market!! They have such amazing potential, and I'd just like to see them work as advertised.

Have a Happy New Year, and an amazing 2019!!!!!

[petar.suknjaja]

Hi,
We wish you Happy New Year!

I'll make sure to forward your suggestion about adding more support and documentation
for the non MikroE platforms.

Bests wishes,

Petar

[Cool Games]

Yesterday I plugged in the MP3 click to the new Game Pup cape for pocket beagle.
Now what do I do ?
The Pocket Beagle and Game Pup https://github.com/beagleboard/capes/tr ... le/GamePup are so new that all of them plus the MP3 Click
are in uncharted territory !
I already can use aplaymidi on a USB connected general Midi device and want the
MP3 click to behave the same.

There is no audio devices showing up so the MP3 Click can own that space as well.

I have bookmarked this thread and will watch for feedback and assistance.
I am NOT a programmer so I know this is beyond my skills and there seems to
be no books on Click board for Beaglebone especially Pocket Beagle https://github.com/beagleboard/pocketbeagle.

Lee (retired owner)
Cool Games Network
and
Event Video Multimedia