Date   

Re: How to reduce footprint and size of applications in Zephyr

Yie
 

I see. That makes a lot of sense. Thank you Maciek! 

I have another question, if you dont mind. 

I have an app that's taking about ~5MB of RAM and ~5.6MB of ROM judging from the 'ram_report' and 'rom_report'. Is there a way to reduce the size of those? It is much bigger because I've included other functionalities such as multi-threading and networking. Do I remove functionalities I don't need using 'make menuconfig'?

Cheers,
Yie

On 21 September 2017 at 18:28, Maciek Borzecki <maciek.borzecki@...> wrote:
On Thu, Sep 21, 2017 at 7:57 AM, Hui Yie Teh <hteh703@...> wrote:
>
> Hi Thiago,
>
> Thank you so much for the reply. I am running Zephyr on Linux and building the hello_world app on ARM using qemu_cortex_m3.
>
> I've got the numbers from the following:
>
> The 8MB of memory is measured using the system monitor
>
>
> The 3.8MB is seen by clicking properties of the folder created after building the hello_world app. I am assuming that the folder in ../outdir/BOARD will be the folder that is going to be installed on the board itself. Am I understanding this correctly?
>
>
> I'm not sure if those are the right numbers to get, sorry if this is a stupid question.
>
>
> Also, may I know what these numbers from' make ram_report' and 'make rom_report' mean?
>
> ram_report
>
>
> rom_report
>
> Any help would be really appreciated. Thanks!


qemu-system-arm is just a VM that can emulate, among others, Cortex-M
MCUs. `qemu_cortext_m3` board is in fact emulated by qemu. Memory
usage of a running Qemu process does not directly (or otherwise
easily) translate to the memory usage in the target system.

Haven't looked at the reports for some time, but `ram_report` is
likely a listing statically allocated data that would normally be
copied into RAM during system initialization. `rom_report` likely
lists the size of each symbol (i.e. non-inlined function in the code).
So, you're more realistically looking at ~4kB of RAM and ~7kB of
flash.

>
> Cheers,
> Yie
>
>
>
>
> On 21 September 2017 at 06:15, Thiago Silveira <thiago@...> wrote:
>>
>> Hi Yie,
>>
>> That definitely isn't right. In which environment are you running Zephyr, and how are you measuring this?
>>
>> Try 'make rom_report' and 'make ram_report' to get a nice report of how much each function is consuming.
>>
>> Best regards,
>> Thiago
>>
>>
>>
>> 2017-09-20 13:00 GMT-03:00 Hui Yie Teh <hteh703@...>:
>>>
>>> Hi,
>>>
>>> I read that Zephyr allows small footprint of a few KBs. However, the sample hello world application already takes up 8MB of memory and has a size of 3.8MB. I am not sure if I am running this right.
>>>
>>> I would appreciate if I can get any help on this or someone to point me at the right direction.
>>>
>>> Cheers,
>>> Yie
>>>
>>> _______________________________________________
>>> Zephyr-devel mailing list
>>> Zephyr-devel@lists.zephyrproject.org
>>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
>>>
>>
>
>
> _______________________________________________
> Zephyr-devel mailing list
> Zephyr-devel@lists.zephyrproject.org
> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
>



--
Maciek Borzecki


Re: How to reduce footprint and size of applications in Zephyr

Maciek Borzecki <maciek.borzecki@...>
 

On Thu, Sep 21, 2017 at 7:57 AM, Hui Yie Teh <hteh703@aucklanduni.ac.nz> wrote:

Hi Thiago,

Thank you so much for the reply. I am running Zephyr on Linux and building the hello_world app on ARM using qemu_cortex_m3.

I've got the numbers from the following:

The 8MB of memory is measured using the system monitor


The 3.8MB is seen by clicking properties of the folder created after building the hello_world app. I am assuming that the folder in ../outdir/BOARD will be the folder that is going to be installed on the board itself. Am I understanding this correctly?


I'm not sure if those are the right numbers to get, sorry if this is a stupid question.


Also, may I know what these numbers from' make ram_report' and 'make rom_report' mean?

ram_report


rom_report

Any help would be really appreciated. Thanks!

qemu-system-arm is just a VM that can emulate, among others, Cortex-M
MCUs. `qemu_cortext_m3` board is in fact emulated by qemu. Memory
usage of a running Qemu process does not directly (or otherwise
easily) translate to the memory usage in the target system.

Haven't looked at the reports for some time, but `ram_report` is
likely a listing statically allocated data that would normally be
copied into RAM during system initialization. `rom_report` likely
lists the size of each symbol (i.e. non-inlined function in the code).
So, you're more realistically looking at ~4kB of RAM and ~7kB of
flash.


Cheers,
Yie




On 21 September 2017 at 06:15, Thiago Silveira <thiago@exati.com.br> wrote:

Hi Yie,

That definitely isn't right. In which environment are you running Zephyr, and how are you measuring this?

Try 'make rom_report' and 'make ram_report' to get a nice report of how much each function is consuming.

Best regards,
Thiago



2017-09-20 13:00 GMT-03:00 Hui Yie Teh <hteh703@aucklanduni.ac.nz>:

Hi,

I read that Zephyr allows small footprint of a few KBs. However, the sample hello world application already takes up 8MB of memory and has a size of 3.8MB. I am not sure if I am running this right.

I would appreciate if I can get any help on this or someone to point me at the right direction.

Cheers,
Yie

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


--
Maciek Borzecki


Re: How to reduce footprint and size of applications in Zephyr

Yie
 

Hi Thiago,

Thank you so much for the reply. I am running Zephyr on Linux and building the hello_world app on ARM using qemu_cortex_m3. 

I've got the numbers from the following:
  • The 8MB of memory is measured using the system monitor

    Inline images 2
  • The 3.8MB is seen by clicking properties of the folder created after building the hello_world app. I am assuming that the folder in ../outdir/BOARD will be the folder that is going to be installed on the board itself. Am I understanding this correctly? 

    Inline images 3
I'm not sure if those are the right numbers to get, sorry if this is a stupid question. 


Also, may I know what these numbers from' make ram_report' and 'make rom_report' mean? 
  • ram_report

    Inline images 8
  • rom_report
    Inline images 9
Any help would be really appreciated. Thanks!

Cheers,
Yie




On 21 September 2017 at 06:15, Thiago Silveira <thiago@...> wrote:
Hi Yie,

That definitely isn't right. In which environment are you running Zephyr, and how are you measuring this?

Try 'make rom_report' and 'make ram_report' to get a nice report of how much each function is consuming.

Best regards,
Thiago



2017-09-20 13:00 GMT-03:00 Hui Yie Teh <hteh703@...>:
Hi,

I read that Zephyr allows small footprint of a few KBs. However, the sample hello world application already takes up 8MB of memory and has a size of 3.8MB. I am not sure if I am running this right.

I would appreciate if I can get any help on this or someone to point me at the right direction.

Cheers,
Yie

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel




Re: How to reduce footprint and size of applications in Zephyr

Thiago Silveira
 

Hi Yie,

That definitely isn't right. In which environment are you running Zephyr, and how are you measuring this?

Try 'make rom_report' and 'make ram_report' to get a nice report of how much each function is consuming.

Best regards,
Thiago



2017-09-20 13:00 GMT-03:00 Hui Yie Teh <hteh703@...>:

Hi,

I read that Zephyr allows small footprint of a few KBs. However, the sample hello world application already takes up 8MB of memory and has a size of 3.8MB. I am not sure if I am running this right.

I would appreciate if I can get any help on this or someone to point me at the right direction.

Cheers,
Yie

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



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

Paul Sokolovsky
 

Hello David,

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.

Thanks,
Paul


On Fri, 15 Sep 2017 11:31:31 -0500
david zuhn <zoo@statebeltrailway.org> wrote:


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
zoo @ statebeltrailway.org


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


How to reduce footprint and size of applications in Zephyr

Yie
 

Hi,

I read that Zephyr allows small footprint of a few KBs. However, the sample hello world application already takes up 8MB of memory and has a size of 3.8MB. I am not sure if I am running this right.

I would appreciate if I can get any help on this or someone to point me at the right direction.

Cheers,
Yie


HTTP Request Timeout Not Working

Yie
 

Hi,

I am currently running a HTTP client in QEMU_cortex_m3 and I was trying to set the timeout for the http_client_send_req(..) function and it doesn't seem to work.

It still does not return immediately even after I've set the timeout to 0.

Can I get any help on this?

Cheers.


Zephyr SDK issue tracking moved to github

Nashif, Anas
 

Hi,

As part of the migration to Github Issues, we moved the SDK Jira project and made the Jira project  read-only. All new SDK issues should be reported to

 

https://github.com/zephyrproject-rtos/meta-zephyr-sdk/issues

 

During the week we will migrate the ZEP project and will make JIRA read-only and keep it running for some time. Please take a look at the above and lets us know if you have any comments on how the JIRA tickets were migrated.

 

Thanks,

Anas

 


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

Boie, Andrew P
 

Re (1): in this spirit, I would also enable CONFIG_ASSERT by default...
I definitely think it makes sense to do this by default for our QEMU based targets, since they have lots of ram and we don't gather performance metrics for emulated targets.

Andrew


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

Nashif, Anas
 

Re (1): in this spirit, I would also enable CONFIG_ASSERT by default...
Re (4): SYS_LOG itself is not the issue, it is the layers added on top of it to enable logging in subsystems such as the IP stack which is confusing to say the least and has been discussed in this thread. We will have situations where we do want to using printk and family to print out kernel level exceptions and oopses, even if the logging was disabled for whatever reason, although the SYS_LOG could be optimized to handle such cases as well, we do have logger hooks that can for example write to a file system instead of the console in production systems, so depending on printk for all messages (and assuming console is always connected) is already not ideal.

This goes beyond the original thread topic and is probably worth a bug/enhancement request to be tracked.

Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Boie, Andrew P
Sent: Friday, September 15, 2017 1:52 PM
To: Paul Sokolovsky <paul.sokolovsky@linaro.org>; Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] RFC: Stopping Zephyr networking from being painful by enabling error logging by default

My views on this topic:

1) Right now we have very inconsistent error/debug logging. In lots of places in the kernel, when a bad situation is encountered the problem is simply reported with a printk(). In other places we are using SYS_LOG_*. The default experience for the user is that all the SYS_LOG messages are suppressed, but the printks are emitted. This is not an ideal default configuration, in fact words like "horrible" and "baffling" come to mind when considering it.

2) I still think that SYS_LOG should be turned on by default for error and warning situations, just like printk() is on by default.

3) If people are concerned about code size, there should be some kind of global flag which suppresses all debug output, including printk(). In the future, for very RAM constrained devices we could implement a backend to SYS_LOG which uses tricks like storing format strings completely outside the binary, in an external file used to decode raw log data, stuff like that.

4) The way SYS_LOG_* is configured in Kconfig is currently a confusing disaster and I look forward to seeing what Paul comes up with to clean it up. I think the difficulty in using this mechanism is at least partly why large parts of the kernel do not use it and just do printks instead.

5) We may consider making printk() a thin wrapper for a particular level of SYS_LOG().

Andrew
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


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

Boie, Andrew P
 

My views on this topic:

1) Right now we have very inconsistent error/debug logging. In lots of places in the kernel, when a bad situation is encountered the problem is simply reported with a printk(). In other places we are using SYS_LOG_*. The default experience for the user is that all the SYS_LOG messages are suppressed, but the printks are emitted. This is not an ideal default configuration, in fact words like "horrible" and "baffling" come to mind when considering it.

2) I still think that SYS_LOG should be turned on by default for error and warning situations, just like printk() is on by default.

3) If people are concerned about code size, there should be some kind of global flag which suppresses all debug output, including printk(). In the future, for very RAM constrained devices we could implement a backend to SYS_LOG which uses tricks like storing format strings completely outside the binary, in an external file used to decode raw log data, stuff like that.

4) The way SYS_LOG_* is configured in Kconfig is currently a confusing disaster and I look forward to seeing what Paul comes up with to clean it up. I think the difficulty in using this mechanism is at least partly why large parts of the kernel do not use it and just do printks instead.

5) We may consider making printk() a thin wrapper for a particular level of SYS_LOG().

Andrew


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

 

 


Adding Nucleo-F030R8 support to Zephyr - CI fails due to low SOC RAM (8k)

Bobby
 

Hello Macjie,

the pull request #1103 seems to fail some CI tests due to not enough RAM space (8k only).
The missing amount of RAM is above 1.5k so disabling the RAM vector table (~400 bytes) will not help either.   

It seems the stack sizes are too big.

E.g. in benchmark/latency_measure:
  "region `SRAM' overflowed by 1704 bytes"

The stack sizes are:

_k_thread_stack_tt_id 0x400
y_stack_area  0x200
_k_thread_stack_int_thread_id 0x200
_main_stack  0x400
_idle_stack  0x100
_interrupt_stack 0x800
sys_work_q_stack  0x400

in total 6.4k


Maybe you can reduce the stack size.


Regards
Bobby


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

Paul Sokolovsky
 

Hello Luiz,

On Fri, 15 Sep 2017 12:26:10 +0300
Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:

[]

We should think beyond that, we should think why, 8 months after the
project being on github, it has barely over 300 stars (which is good
for a personal spare-time project and zilch for something targetting
to influence the landscape). We should think why Zephyr TSC
receives a feedback
(https://docs.google.com/presentation/d/1L3t6V9dr2IhUlz6f4Tc_gz1-zmt00O2aspO3IfyEtBs/edit#slide=id.g1f87755cc1_0_39)
from perspective users which says "Zephyr project would get even
more credibility if there would be device manufacturers &
hobbyist".
When you use a presentation which says:

Main benefits taking zephyr in use would come from good ble and
tcp/ip stacks ...
Well, when someone comes by and says "You're doing great, but we won't
use your stuff and can't even tell where we will be able to" (and
that's arguably summarizes that presentation), I'd spend less time on
being flattered by a polite conversation starter, and would spend more
time on 2nd part of the message ;-).

I understand it can be frustrating to not have proper logs when facing
issues, but things like this happen when we are trying to move as fast
as we can, perhaps too fast?
It's true that Zephyr development moves fast overall, and yet some
things are vice-versa pretty slow, for example here we, at version 1.9,
discuss whether it makes sense to report error messages or not.

[]

Note, this can all be achieved without a wall of text complaining
about things that doesn't work for you, from the responses here
everyone seems quite positive with the idea of having better logging
so there is no point in keep coming with more more rants about it.
Yeah, sorry about that. I mentioned that I "sent probes" on this
before, and quite anticipated the possible response ("let's not change
things, everything works well as it is"). So, I appreciate that
everyone agrees we can change in logging *something*, I'm just trying
to convey that we should change a bunch of stuff consistently to make a
real difference.

Anyway, I'm off to patches on this stuff.

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


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

Luiz Augusto von Dentz
 

Hi Paul,

On Fri, Sep 15, 2017 at 10:55 AM, Paul Sokolovsky
<paul.sokolovsky@linaro.org> wrote:
Hello Piotr,

On Thu, 14 Sep 2017 22:03:19 +0200
Piotr Mienkowski <piotr.mienkowski@gmail.com> wrote:

[]

I disagree with enabling logging by default, it bloats the binary
and also increases ram / stack usage. Normally you do not need to
have debugging enabled anyway, and if you need it, then it is easy
to set CONFIG_NET_LOG=y, enable individual component logging or
global logging, and then increase the log level.
One more vote to set the default log level to 2 (warning) but not to
enable logging by default for the reasons Jukka has mentioned. It
certainly makes sense to provide sane defaults (level 2 is a good
idea, maybe even level 3 if we clean up _INF messages, seeing
assigned MAC address, IP number in the log wouldn't be all that bad)
but we should avoid making choices on behalf of the users.
I would put it differently: we should make choices for the benefit of
the users.

I prefer
to enable options that I need when I need them rather than disable
all those I don't only because someone believed they are good for me.
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.

Instead, we should think what would be in the interest of users, how to
let them engage with Zephyr easily, and keep them afterwards.

We should think beyond that, we should think why, 8 months after the
project being on github, it has barely over 300 stars (which is good
for a personal spare-time project and zilch for something targetting
to influence the landscape). We should think why Zephyr TSC receives a
feedback
(https://docs.google.com/presentation/d/1L3t6V9dr2IhUlz6f4Tc_gz1-zmt00O2aspO3IfyEtBs/edit#slide=id.g1f87755cc1_0_39)
from perspective users which says "Zephyr project would get even more
credibility if there would be device manufacturers & hobbyist".
When you use a presentation which says:

Main benefits taking zephyr in use would come from good ble and tcp/ip stacks
...

I understand it can be frustrating to not have proper logs when facing
issues, but things like this happen when we are trying to move as fast
as we can, perhaps too fast? Though I agree that hobbyists would
probably help fill these gaps.

Indeed, why would somebody make commercial projects based on Zephyr
with all the investment required, if nobody invests their spare fun
time into it? Then you might think if there's a correlation between
that and it being agonizing hard to configure Zephyr and debug
misconfigurations.

Zephyr documentation specifically mentions that it's targeting small
memory footprint devices.
But above that, it targets users, so any premature optimizations of
code size at the expense of user experience are, well, strange.

Few things eat up memory quite so reliably as a couple of printfs.
The network stack has eaten up memory much reliably than printfs, so
adding few won't change picture much, but may improve user
experience considerably.

That said, we could enable logging for all sample applications but not
for the main project. Maybe that was the intention all way long and I
misunderstood it.
No, this issue being talked up for a while now, so it's worth a
solution, not half-measures. I really mean that if you take a new
Linux distro, then it ships with printk's in kernel enabled, so if
something goes wrong during the installation or afterwards, you see it
right away, not receive kind suggestions to dig into documentation
looking for god-knows-what and build your kernel differently just to
approach answering question "what may be wrong". I mean that, just
applied to Zephyr. *Afterwards* someone can debug their stuff, and
optimize code size by disabling logging.
Comparing Zephyr with Linux is not fair really, they target completely
different environments, especially when it is concerned to runtime so
we have to keep things at certain perspective. We could perhaps have
debug builds using KConfig that selects whatever makes sense to help
with initial development/prototyping phase, things like _assert
support, warnings logging, etc.

Note, this can all be achieved without a wall of text complaining
about things that doesn't work for you, from the responses here
everyone seems quite positive with the idea of having better logging
so there is no point in keep coming with more more rants about it.


Cheers,
Piotr
--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


--
Luiz Augusto von Dentz


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

Paul Sokolovsky
 

Hello Piotr,

On Thu, 14 Sep 2017 22:03:19 +0200
Piotr Mienkowski <piotr.mienkowski@gmail.com> wrote:

[]

I disagree with enabling logging by default, it bloats the binary
and also increases ram / stack usage. Normally you do not need to
have debugging enabled anyway, and if you need it, then it is easy
to set CONFIG_NET_LOG=y, enable individual component logging or
global logging, and then increase the log level.
One more vote to set the default log level to 2 (warning) but not to
enable logging by default for the reasons Jukka has mentioned. It
certainly makes sense to provide sane defaults (level 2 is a good
idea, maybe even level 3 if we clean up _INF messages, seeing
assigned MAC address, IP number in the log wouldn't be all that bad)
but we should avoid making choices on behalf of the users.
I would put it differently: we should make choices for the benefit of
the users.

I prefer
to enable options that I need when I need them rather than disable
all those I don't only because someone believed they are good for me.
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.

Instead, we should think what would be in the interest of users, how to
let them engage with Zephyr easily, and keep them afterwards.

We should think beyond that, we should think why, 8 months after the
project being on github, it has barely over 300 stars (which is good
for a personal spare-time project and zilch for something targetting
to influence the landscape). We should think why Zephyr TSC receives a
feedback
(https://docs.google.com/presentation/d/1L3t6V9dr2IhUlz6f4Tc_gz1-zmt00O2aspO3IfyEtBs/edit#slide=id.g1f87755cc1_0_39)
from perspective users which says "Zephyr project would get even more
credibility if there would be device manufacturers & hobbyist".

Indeed, why would somebody make commercial projects based on Zephyr
with all the investment required, if nobody invests their spare fun
time into it? Then you might think if there's a correlation between
that and it being agonizing hard to configure Zephyr and debug
misconfigurations.

Zephyr documentation specifically mentions that it's targeting small
memory footprint devices.
But above that, it targets users, so any premature optimizations of
code size at the expense of user experience are, well, strange.

Few things eat up memory quite so reliably as a couple of printfs.
The network stack has eaten up memory much reliably than printfs, so
adding few won't change picture much, but may improve user
experience considerably.

That said, we could enable logging for all sample applications but not
for the main project. Maybe that was the intention all way long and I
misunderstood it.
No, this issue being talked up for a while now, so it's worth a
solution, not half-measures. I really mean that if you take a new
Linux distro, then it ships with printk's in kernel enabled, so if
something goes wrong during the installation or afterwards, you see it
right away, not receive kind suggestions to dig into documentation
looking for god-knows-what and build your kernel differently just to
approach answering question "what may be wrong". I mean that, just
applied to Zephyr. *Afterwards* someone can debug their stuff, and
optimize code size by disabling logging.


Cheers,
Piotr
--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


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

Paul Sokolovsky
 

Hello Piotr,

On Thu, 14 Sep 2017 22:03:19 +0200
Piotr Mienkowski <piotr.mienkowski@gmail.com> wrote:

[]

I disagree with enabling logging by default, it bloats the binary
and also increases ram / stack usage. Normally you do not need to
have debugging enabled anyway, and if you need it, then it is easy
to set CONFIG_NET_LOG=y, enable individual component logging or
global logging, and then increase the log level.
One more vote to set the default log level to 2 (warning) but not to
enable logging by default for the reasons Jukka has mentioned. It
certainly makes sense to provide sane defaults (level 2 is a good
idea, maybe even level 3 if we clean up _INF messages, seeing
assigned MAC address, IP number in the log wouldn't be all that bad)
but we should avoid making choices on behalf of the users.
I would put it differently: we should make choices for the benefit of
the users.

I prefer
to enable options that I need when I need them rather than disable
all those I don't only because someone believed they are good for me.
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.

Instead, we should think what would be in the interest of users, how to
let them engage with Zephyr easily, and keep them afterwards.

We should think beyond that, we should think why, 8 months after the
project being on github, it has barely over 300 stars (which is good
for a personal spare-time project and zilch for something targetting
to influence the landscape). We should think why Zephyr TSC receives a
feedback
(https://docs.google.com/presentation/d/1L3t6V9dr2IhUlz6f4Tc_gz1-zmt00O2aspO3IfyEtBs/edit#slide=id.g1f87755cc1_0_39)
from perspective users which says "Zephyr project would get even more
credibility if there would be device manufacturers & hobbyist".

Indeed, why would somebody make commercial projects based on Zephyr
with all the investment required, if nobody invests their spare fun
time into it? Then you might think if there's a correlation between
that and it being agonizing hard to configure Zephyr and debug
misconfigurations.

Zephyr documentation specifically mentions that it's targeting small
memory footprint devices.
But above that, it targets users, so any premature optimizations of
code size at the expense of user experience are, well, strange.

Few things eat up memory quite so reliably as a couple of printfs.
The network stack has eaten up memory much reliably than printfs, so
adding few won't change picture much, but may improve user
experience considerably.

That said, we could enable logging for all sample applications but not
for the main project. Maybe that was the intention all way long and I
misunderstood it.
No, this issue being talked up for a while now, so it's worth a
solution, not half-measures. I really mean that if you take a new
Linux distro, then it ships with printk's in kernel enabled, so if
something goes wrong during the installation or afterwards, you see it
right away, not receive kind suggestions to dig into documentation
looking for god-knows-what and build your kernel differently just to
approach answering question "what may be wrong". I mean that, just
applied to Zephyr. *Afterwards* someone can debug their stuff, and
optimize code size by disabling logging.


Cheers,
Piotr
--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Counter API ambiguity.

Chettimada, Vinayak Kariappa
 

Hi,

Analysing the problem here, with a 32-bit integers, only 31-bit value range can be used to set alarms that expire after a rollover of 32-bit clock counts.
This is considering that we want to detect if an alarm expired in the past or will expire in the future.

Use of s32_t seems a way of restricting the application from supplying something greater than 0x7fffffff.
Hence, we should retain the use of s32_t for duration/offset/period etc. and make other APIs consistent.

Regards,
Vinayak


On 13 Sep 2017, at 17:40, Boie, Andrew P <andrew.p.boie@...> wrote:

Ø  Shouldn't we stay consistent with the type for delay/timeout/alarm values among Zephyr modules?
 
I had noticed this recently as well, I couldn't figure out why APIs like k_timer_start() took signed values for the timeout, especially since the code has assertions in it to ensure the value is positive.
 
As far as I can tell from asking around, this is a historical artifact. I think we could change these parameter to unsigned types.
 
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


the zephyr device-tree mechanism seems not identical with the linux dirver, right?

曹子龙
 

Hi all:
     from  the dtc compiler command in Makefile.lib  document, the device tree of zepher project are  compiler to  "DTS" file, not the blob file "DTB" type, so, and then convert to header filles by python and yamal script,

so, seems the device tree is a just method to control in compiler time, not runtime with"of_xxx“ funtions like Linux kernel, right?



cmd_dtc = echo '\#include "$(notdir $<)"' > dts/$(ARCH)/$(notdir $<)_pre_compiled ; \                                                                                                                           
294         if test -e $(DTC_OVERLAY_FILE); then \
295                 echo '\#include "$(DTC_OVERLAY_FILE)"' >> dts/$(ARCH)/$(notdir $<)_pre_compiled ; \
296         fi ; \                    
297         $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) dts/$(ARCH)/$(notdir $<)_pre_compiled ; \
298         $(DTC) -O dts -o $@ -b 0 \
299                 -i $(dir $<) $(DTC_FLAGS) \
300                 -d $(depfile).dtc.tmp $(dtc-tmp) ; \
301         cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)




 


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

Piotr Mienkowski
 

Hi,

On 14.09.2017 08:33, Jukka Rissanen wrote:

Debugging the configuration and debug logging itself is quite
painful,
after a year on Zephyr, I still didn't master it, what to say about
newcomers?

So, I'd like to propose to make following changes:

1. Enable CONFIG_NET_LOG=y, CONFIG_NET_LOG_GLOBAL=y,
CONFIG_SYS_LOG_NET_LEVEL=2 (WARN) by default.
We could set the log level to 2 (warn) as you suggest, there was not
many warns in the net stack anyway.

I disagree with enabling logging by default, it bloats the binary and
also increases ram / stack usage. Normally you do not need to have
debugging enabled anyway, and if you need it, then it is easy to set
CONFIG_NET_LOG=y, enable individual component logging or global
logging, and then increase the log level.
One more vote to set the default log level to 2 (warning) but not to
enable logging by default for the reasons Jukka has mentioned. It
certainly makes sense to provide sane defaults (level 2 is a good idea,
maybe even level 3 if we clean up _INF messages, seeing assigned MAC
address, IP number in the log wouldn't be all that bad) but we should
avoid making choices on behalf of the users. I prefer to enable options
that I need when I need them rather than disable all those I don't only
because someone believed they are good for me. Zephyr documentation
specifically mentions that it's targeting small memory footprint
devices. Few things eat up memory quite so reliably as a couple of printfs.

That said, we could enable logging for all sample applications but not
for the main project. Maybe that was the intention all way long and I
misunderstood it.

Cheers,
Piotr

4641 - 4660 of 8046