I appreciate the detailed response, with many points coinciding with
what I wrote previously. And my hypothesis that many of these points
would apply not just to "hobbyist" usage, but also to "company" or
"commercial" users. Because we truly live in "Arduino" world, and
by now there're enough cross-pollination between different areas,
and that's how "IoT" is different from the ol' good "embedded".
Anyway, I guess the background should be set well enough by now, many
people agree that logging/error reporting in Zephyr can be improved.
I'm now diving into the technical side, with few initial patches having
been already merged, and further ideas how to proceed, to be tested.
On Fri, 15 Sep 2017 11:31:31 -0500
david zuhn <firstname.lastname@example.org> wrote:
This is an incredibly astute comment.
I don't think discussion in this direction would be productive.
Because I too don't like choices made for me, and don't appreciate
someone thinking that code size if more important than error
reporting, and making me spend hours again and again debugging
whole range of issues, from trivial to complex.
I am coming to the RTOS world from years of Unix & Linux development,
with a recent foray into the Arduino world, which has led me to
slightly larger systems which end up in the RTOS space. I do not
consider myself an experienced RTOS developer, but I am an
experienced developer who is now trying to look into other systems.
Issues like code size or power consumption are not my primary concern
right now. I *am* very concerned with getting things running,
achieving basic functionality.
As I get things running, then I might become concerned with trying to
optimize the configuration. As a hobbyist, I'm buying boards that are
way overpowered and overfeatured. But I'm buying 1 or 2, not 10,000
at a time. I don't need to try hard to fit into the 32K RAM
component instead of the 64K piece because the $1.93 price
differential is 20% of my profit margin. I'm just trying to make
As such, I have expectations that capabilities that are touted as
features of a product should be relatively easy to understand out of
the box. Documentation is critical. Examples are great. I don't
believe that providing sparse comments in Kconfig files constitutes
good documentation. Having to fully understand the multitude of
config options and how they interact in order to get basic
functionality (like an IP stack) working seems newcomer-hostile.
Yup, maybe the extra 6K of code size matters to the large-scale
production oriented user. But not out of the box to the hobbyist.
Right now, I've got a part with 512K of flash.
I do understand that the microcontroller universe is a complex space,
and it's not the same as Unix. But if you have to already be an
expert in working in the microcontroller space to work in the
microcontroller space, there's a chicken and egg problem. Right now
it seems like one has to be completely knowledgeable about the
microcontroller itself, all of Zephyr, *and* the Linux kernel config
system in order to work with Zephyr. That's a tall order.
*Afterwards* someone can debug their stuff, and optimize code size
by disabling logging.
Once someone has been able to develop something worthwhile, they will
have also picked up on the skills needed to consider the steps needed
for optimization. But if I can't even get my basic functionality
working, I'll never even consider using Zephyr. Something else out
there will have been able to meet my hobbyist needs.
I'm seeing now the layers of abstraction that the Arduino developers
put into play, keeping me from having to worry about quite a number
of things. Some of those things are now issues that I need to address
because I've hit the limits of the abstraction. But to step into a
project and codebase that is focused on tiniest-device-production and
not user entry is problematic. It doesn't have to be one XOR the
other. And being able to tweak my system to achieve the
tiniest-device capabilities is a good thing. But in my experience, I
found Zephyr to be hard to achieve basic capabilities. I'm finding
it easier to achieve those capabilities in other freely available
zoo @ statebeltrailway.org
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#
!/linaroorg - http://www.linaro.org/linaro-blog