Beaglebone Mikrobus cape, oled C, oled B support
Posted: 09 Jan 2018 08:53
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?
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?