Re: RFC: Stopping Zephyr networking from being painful by enabling error logging by default


david zuhn
 

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.

This is an incredibly astute comment. 

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 something work.   

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 RTOS packages.   

david zuhn

 

 

Join devel@lists.zephyrproject.org to automatically receive all group messages.