Date   

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@...> 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


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

Paul Sokolovsky
 

On Thu, 14 Sep 2017 17:03:12 +0000
"Nashif, Anas" <anas.nashif@...> wrote:

Should I assume you started replying before you read my final comment
about logging? :-)
Well, just as you tried to present the issues in the net stack from the
different sides, just the same I try to present an extended perspective
of the issue ;-). If we agree that logging can use tweaking, then good,
I already have few simple PRs in the pipeline, which need reviewing,
then hopefully extending, and merging ;-).

Anas

-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@...]
Sent: Thursday, September 14, 2017 12:43 PM
To: Nashif, Anas <anas.nashif@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] RFC: Stopping Zephyr networking from
being painful by enabling error logging by default

Hello Anas,

On Thu, 14 Sep 2017 13:22:11 +0000
"Nashif, Anas" <anas.nashif@...> wrote:

Hi,
I fully agree with your first paragraph but then I got completely
lost how enabling logging is going to solve the issue you have
presented.
We can approach it from another side. Let me present some cases I
faced (some of them based on other users' feedback), and you'll try
to guess what's wrong in each of them. 3 cases are presented, ranging
from warm-up (with answer presented) to "hard cases nobody knows how
to solve".

1. You build an app for a new board and it crashes on startup. The
app works on another board. What's wrong?
https://jira.zephyrproject.org/browse/ZEP-2105 tells what was wrong
for this particular case reported by a user.

Anas' answer: (please time how much time it took to arrive at the
"correct" answer) Paul's answer: The system should log the error
condition

2. You write an app which sends data outside. It doesn't work - just
hangs in there. What's wrong? Umm, yeah. More data: another similar
app works well, so you can exclude firewall and DNS setup. Still not
enough data? You fire up Wireshark and see that Zephyr sends out ARP
requests for 0.0.0.0. So, what's wrong? This is actually quite
solvable by a speculation - except when it's end of day, and you just
try to get the flaming feature tested, not doing guesswork.

Anas' answer: ???
Paul's answer: The system should log the error (or warning) condition
precluding it from working

3. If the above went ok, see what's wrong in
https://jira.zephyrproject.org/browse/ZEP-2593 - so far, nobody was
able to present a truly useful trail to debug it.

Anas' answer: ???
Paul's answer: The system should log the error (or warning) condition
precluding it from working properly

Frankly, the first thing I do when trying out an application is
turn off all the logging, because it gets in the way, it is too
verbose
This only shows how much twisted and confusing is the net logging
situation: I complain there's too little (error) logging, and you
don't believe me it's true. Likewise, you complain about too much of
(useless) logging, and I don't believe you either (really, I don't
know of in-tree samples which have debug-level logging enabled by
default.

So I'd rather believe you then, and that's exactly the nature of my
proposal: let's enable useful logging by default, and make sure that
too-much-details logging, not interesting to a casual user, is
disabled by default.

and it also disturbs the net shell which is enabled in many
applications.
That's also shows how twisted a situation we have: a proposal to
enable little error logging faces opposition that "it'll bloat
binaries", and at the same time "net shell is enabled in many
applications", which is of course much more bloated that just some of
error logging. It's also barely usable due to lack of command history
support and broken paste from host (so you need to type in long
commands manually again and again).

The main problem I see in many of the networking samples is the
fact The main issues as I see them are the following:
- We do need safe defaults that can be lowered or increased,
- We do need to generalize the test setting and just maintain them
in
- It would help if we had all network samples behave the same,
i.e.
There're many issues with network stack/apps, and we can't solve them
all at once. In this thread, I present a proposal for useful error
logging in the net stack.

- Ok, it is not all bad news, Jukka and the network stack
developers introduced this nice netapp interface which makes it
very easy to get started and does eliminate tons of code that used
to be in the application and moved it to the ip stack, so this was
a huge improvement already, we need to continue optimizing into
this direction.
Right, there were bunch of improvements in the stack lately, that's
why I submit this RFC - I think we should be ready now to tackle the
"error logging" issue.

- Finally, logging. It can be really useful and I agree we need to
enable some type of logging by default (which can be turned off
easily). I always get lost in the configuration of logging of
network applications, you would assume that CONFIG_SYS_LOG=n would
turn off everything, but it does not and there are too many
variants and no easy way to understand what enables/disables what.
So we do need to revisit this and think how we can easily
enable/disable logging and keep it on by default without impacting
binary size and performance.
Cool, thanks. My RFC is exactly how to make first few steps in that
direction.


Anas
[]

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


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

On Thu, 14 Sep 2017 13:22:43 +0200
Tomasz Bursztyka <tomasz.bursztyka@...> wrote:

you discover CONFIG_NET_LOG_GLOBAL
[]

I have been using it when porting new devices, it's an easy option to
just see how
the whole behaves at boot/init time.

But indeed, it's not a good option when you need to debug an app.

It's off by default anyway. We can improve the doc there telling this
should not
be used unless the person knows what to do with it
i.e.: getting all errors/warning, but not on debug level!
Right, I had the same idea, mentioned in the other mails.

[]

As the name implies, the CONFIG_NET_LOG_GLOBAL is only for
networking. It might also miss some new net debug options.
Most probably yes
I posted https://github.com/zephyrproject-rtos/zephyr/pull/1507 showing
how this can be tackled in a scalable way (without introducing unneeded
Kconfig interdependencies, etc.).

Besides all that, debugging net stack is complex mostly because it's
a complex stack.
Yes, and we can make it simpler.

We could probably add a documentation about how to relevantly use the
logging options,
that's I guess the best to do right now.
Extending on what was said in the previous mails, people first want to
see stuff working (or telling them what's wrong), and then maybe
they'll dig into documentation. Seeing hangs and crashes in this age
will likely prompt "let's move on to something else" approach rather
than give encouragement to read long docs.

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

Nashif, Anas
 

Should I assume you started replying before you read my final comment about logging? :-)

Anas

-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@...]
Sent: Thursday, September 14, 2017 12:43 PM
To: Nashif, Anas <anas.nashif@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] RFC: Stopping Zephyr networking from being painful by enabling error logging by default

Hello Anas,

On Thu, 14 Sep 2017 13:22:11 +0000
"Nashif, Anas" <anas.nashif@...> wrote:

Hi,
I fully agree with your first paragraph but then I got completely lost
how enabling logging is going to solve the issue you have presented.
We can approach it from another side. Let me present some cases I faced (some of them based on other users' feedback), and you'll try to guess what's wrong in each of them. 3 cases are presented, ranging from warm-up (with answer presented) to "hard cases nobody knows how to solve".

1. You build an app for a new board and it crashes on startup. The app works on another board. What's wrong?
https://jira.zephyrproject.org/browse/ZEP-2105 tells what was wrong for this particular case reported by a user.

Anas' answer: (please time how much time it took to arrive at the "correct" answer) Paul's answer: The system should log the error condition

2. You write an app which sends data outside. It doesn't work - just hangs in there. What's wrong? Umm, yeah. More data: another similar app works well, so you can exclude firewall and DNS setup. Still not enough data? You fire up Wireshark and see that Zephyr sends out ARP requests for 0.0.0.0. So, what's wrong? This is actually quite solvable by a speculation - except when it's end of day, and you just try to get the flaming feature tested, not doing guesswork.

Anas' answer: ???
Paul's answer: The system should log the error (or warning) condition precluding it from working

3. If the above went ok, see what's wrong in
https://jira.zephyrproject.org/browse/ZEP-2593 - so far, nobody was able to present a truly useful trail to debug it.

Anas' answer: ???
Paul's answer: The system should log the error (or warning) condition precluding it from working properly

Frankly, the first thing I do when trying out an application is turn
off all the logging, because it gets in the way, it is too verbose
This only shows how much twisted and confusing is the net logging
situation: I complain there's too little (error) logging, and you don't believe me it's true. Likewise, you complain about too much of
(useless) logging, and I don't believe you either (really, I don't know of in-tree samples which have debug-level logging enabled by default.

So I'd rather believe you then, and that's exactly the nature of my
proposal: let's enable useful logging by default, and make sure that too-much-details logging, not interesting to a casual user, is disabled by default.

and it also disturbs the net shell which is enabled in many
applications.
That's also shows how twisted a situation we have: a proposal to enable little error logging faces opposition that "it'll bloat binaries", and at the same time "net shell is enabled in many applications", which is of course much more bloated that just some of error logging. It's also barely usable due to lack of command history support and broken paste from host (so you need to type in long commands manually again and again).

The main problem I see in many of the networking samples is the fact
The main issues as I see them are the following:
- We do need safe defaults that can be lowered or increased,
- We do need to generalize the test setting and just maintain them in
- It would help if we had all network samples behave the same, i.e.
There're many issues with network stack/apps, and we can't solve them all at once. In this thread, I present a proposal for useful error logging in the net stack.

- Ok, it is not all bad news, Jukka and the network stack developers
introduced this nice netapp interface which makes it very easy to get
started and does eliminate tons of code that used to be in the
application and moved it to the ip stack, so this was a huge
improvement already, we need to continue optimizing into this
direction.
Right, there were bunch of improvements in the stack lately, that's why I submit this RFC - I think we should be ready now to tackle the "error logging" issue.

- Finally, logging. It can be really useful and I agree we need to
enable some type of logging by default (which can be turned off
easily). I always get lost in the configuration of logging of network
applications, you would assume that CONFIG_SYS_LOG=n would turn off
everything, but it does not and there are too many variants and no
easy way to understand what enables/disables what. So we do need to
revisit this and think how we can easily enable/disable logging and
keep it on by default without impacting binary size and performance.
Cool, thanks. My RFC is exactly how to make first few steps in that direction.


Anas
[]

--
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 Anas,

On Thu, 14 Sep 2017 13:22:11 +0000
"Nashif, Anas" <anas.nashif@...> wrote:

Hi,
I fully agree with your first paragraph but then I got completely
lost how enabling logging is going to solve the issue you have
presented.
We can approach it from another side. Let me present some cases I faced
(some of them based on other users' feedback), and you'll try to guess
what's wrong in each of them. 3 cases are presented, ranging from
warm-up (with answer presented) to "hard cases nobody knows how to
solve".

1. You build an app for a new board and it crashes on startup. The app
works on another board. What's wrong?
https://jira.zephyrproject.org/browse/ZEP-2105 tells what was wrong for
this particular case reported by a user.

Anas' answer: (please time how much time it took to arrive at the
"correct" answer)
Paul's answer: The system should log the error condition

2. You write an app which sends data outside. It doesn't work - just
hangs in there. What's wrong? Umm, yeah. More data: another similar app
works well, so you can exclude firewall and DNS setup. Still not
enough data? You fire up Wireshark and see that Zephyr sends out ARP
requests for 0.0.0.0. So, what's wrong? This is actually quite
solvable by a speculation - except when it's end of day, and you just
try to get the flaming feature tested, not doing guesswork.

Anas' answer: ???
Paul's answer: The system should log the error (or warning) condition
precluding it from working

3. If the above went ok, see what's wrong in
https://jira.zephyrproject.org/browse/ZEP-2593 - so far, nobody was
able to present a truly useful trail to debug it.

Anas' answer: ???
Paul's answer: The system should log the error (or warning) condition
precluding it from working properly

Frankly, the first thing I do when trying out an
application is turn off all the logging, because it gets in the way,
it is too verbose
This only shows how much twisted and confusing is the net logging
situation: I complain there's too little (error) logging, and you don't
believe me it's true. Likewise, you complain about too much of
(useless) logging, and I don't believe you either (really, I don't know
of in-tree samples which have debug-level logging enabled by default.

So I'd rather believe you then, and that's exactly the nature of my
proposal: let's enable useful logging by default, and make sure that
too-much-details logging, not interesting to a casual user, is
disabled by default.

and it also disturbs the net shell which is enabled
in many applications.
That's also shows how twisted a situation we have: a proposal to enable
little error logging faces opposition that "it'll bloat binaries", and
at the same time "net shell is enabled in many applications", which is
of course much more bloated that just some of error logging. It's also
barely usable due to lack of command history support and broken paste
from host (so you need to type in long commands manually again and
again).

The main problem I see in many of the networking samples is the fact
The main issues as I see them are the following:
- We do need safe defaults that can be lowered or increased,
- We do need to generalize the test setting and just maintain them in
- It would help if we had all network samples behave the same, i.e.
There're many issues with network stack/apps, and we can't solve them
all at once. In this thread, I present a proposal for useful error
logging in the net stack.

- Ok, it is not all bad news, Jukka and the network stack developers
introduced this nice netapp interface which makes it very easy to get
started and does eliminate tons of code that used to be in the
application and moved it to the ip stack, so this was a huge
improvement already, we need to continue optimizing into this
direction.
Right, there were bunch of improvements in the stack lately, that's why
I submit this RFC - I think we should be ready now to tackle the
"error logging" issue.

- Finally, logging. It can be really useful and I agree we need to
enable some type of logging by default (which can be turned off
easily). I always get lost in the configuration of logging of network
applications, you would assume that CONFIG_SYS_LOG=n would turn off
everything, but it does not and there are too many variants and no
easy way to understand what enables/disables what. So we do need to
revisit this and think how we can easily enable/disable logging and
keep it on by default without impacting binary size and performance.
Cool, thanks. My RFC is exactly how to make first few steps in that
direction.


Anas
[]

--
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: application specific pin multiplexing (for STM32F412G-Disco)

Erwan Gouriou
 

Quick status about device tree:
  *Pinmux is not yet generated thanks to dts files. Only pinmux.c matters
  *Today, on STM32 dts files, only UART pinctrl is taken into account
So related to FSMC, you just need to consider pinmux.c

FSMC not being ported to zephyr yet, I think it is a bit early to upstream a FSMC pin config,
you need to do it in you application.
One way to do it  would be to code your own fsmc_pinconf array (based on pinmux.c pinconf[]).
Then setup pins with following call, directly in your application.
       stm32_setup_pins(fsmc_pinconf , ARRAY_SIZE(fsmc_pinconf));
This is not identical to integrate directly in "official" pinconf[] since it would be executed
sometime after initialisation of pinmux driver.Though I think it would work.

Erwan

On 14 September 2017 at 16:28, massimiliano cialdi <massimiliano.cialdi@...> wrote:
Please ignore my previous post


I am writing a demo graphic application running on STM32F412G-Discovery. For this purpose, I must set the multiplexing of some pins to use the FSMC device.
I wonder if I need to edit the files zephyr/boards/boards/arm/stm32f412g_disco/pinmux. c and zephyr/dts/arm/st/stm32f412-pinctrl. dtsi or there is a way to do this by editing only files in the application directory, without touching the files inside zephyr.
If I need to edit zephyr files, what are the rules to follow to make my changes live with the system settings?

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


Re: How to use STM32 HAL drives

Erwan Gouriou
 

As said earlier, you can directly access HAL code in your application, no problem with that.
Point is CONFIG_ flags and Kconfig files are designed to enable "typical" use of Zephyr (through
Zephyr APIs and drivers).
If you want to access HW with HAL (to access extended feature or HW not yet available in Zephyr),
this is possible by modifying Makefile and Kbuild to make these accessible directly in your application.

Cheers
Erwan

On 14 September 2017 at 16:19, massimiliano cialdi <massimiliano.cialdi@powersoft.it> wrote:
and what about peripherals that zephyr doesn't manage, like FSMC?

I am writing a demo graphic application running on STM32F412G-Discovery. For this purpose I use the pre-compiled STemWin532_CM4_OS_GCC. a library, and I am trying to integrate some sources from the ST demo application.
I'm not sure that the STemWin532_CM4_OS_GCC. a library doesn't make calls to the functions of the HAL library, but certainly ST application sources make these calls.

best regards
Max

On 14/09/2017 15:53, Erwan Gouriou wrote:
Hi,

This is the correct understanding, you need to modify Makefile/Kbuild to access HAL drivers.
Then, if you need to use some driver in an application, you'd theoretically use zephyr HW API and drivers (based on HAL or directly accessing HW).
Then,CONFIG flags actually control the compilation but through activation of Zephyr drivers.
For instance for GPIO:
CONFIG_GPIO=y
CONFIG_GPIO_STM32=y
CONFIG_GPIO_STM32_PORTA=y

Of course, you can directly access stm32cube HAL in your application if you want to, but this is not the usual use foreseen by Zephyr architecture.

Erwan

On 14 September 2017 at 15:30, massimiliano cialdi <massimiliano.cialdi@powersoft.it <mailto:massimiliano.cialdi@powersoft.it>> wrote:

    In an application I need to use STM32 HAL driver, for example
    GPIO, FSMC and others.

    I wonder how can I have the appropriate files compiled. There are
    some CONFIG_* to set?

    I read zephyr/ext/hal/st/stm32cube/README

    If I understand well it seems that I have to modify Makefile or
    Kbuild in zephyr/ext/hal/st/stm32cube/ but it seems very strange
    and counterintuitive to have to modify a zephyr file for the needs
    of a specific application. I would have expected to be able to
    "control" the compilation using appropriate CONFIG_*.


    best regards

    Max
    _______________________________________________
    Zephyr-devel mailing list
    Zephyr-devel@...ct.org
    <mailto:Zephyr-devel@...hyrproject.org>
    https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
    <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>





application specific pin multiplexing (for STM32F412G-Disco)

Massimiliano Cialdi
 

Please ignore my previous post


I am writing a demo graphic application running on STM32F412G-Discovery. For this purpose, I must set the multiplexing of some pins to use the FSMC device.
I wonder if I need to edit the files zephyr/boards/boards/arm/stm32f412g_disco/pinmux. c and zephyr/dts/arm/st/stm32f412-pinctrl. dtsi or there is a way to do this by editing only files in the application directory, without touching the files inside zephyr.
If I need to edit zephyr files, what are the rules to follow to make my changes live with the system settings?

best regards
Max


Re: How to use STM32 HAL drives

Massimiliano Cialdi
 

and what about peripherals that zephyr doesn't manage, like FSMC?

I am writing a demo graphic application running on STM32F412G-Discovery. For this purpose I use the pre-compiled STemWin532_CM4_OS_GCC. a library, and I am trying to integrate some sources from the ST demo application.
I'm not sure that the STemWin532_CM4_OS_GCC. a library doesn't make calls to the functions of the HAL library, but certainly ST application sources make these calls.

best regards
Max

On 14/09/2017 15:53, Erwan Gouriou wrote:
Hi,

This is the correct understanding, you need to modify Makefile/Kbuild to access HAL drivers.
Then, if you need to use some driver in an application, you'd theoretically use zephyr HW API and drivers (based on HAL or directly accessing HW).
Then,CONFIG flags actually control the compilation but through activation of Zephyr drivers.
For instance for GPIO:
CONFIG_GPIO=y
CONFIG_GPIO_STM32=y
CONFIG_GPIO_STM32_PORTA=y

Of course, you can directly access stm32cube HAL in your application if you want to, but this is not the usual use foreseen by Zephyr architecture.

Erwan

On 14 September 2017 at 15:30, massimiliano cialdi <massimiliano.cialdi@... <mailto:massimiliano.cialdi@...>> wrote:

In an application I need to use STM32 HAL driver, for example
GPIO, FSMC and others.

I wonder how can I have the appropriate files compiled. There are
some CONFIG_* to set?

I read zephyr/ext/hal/st/stm32cube/README

If I understand well it seems that I have to modify Makefile or
Kbuild in zephyr/ext/hal/st/stm32cube/ but it seems very strange
and counterintuitive to have to modify a zephyr file for the needs
of a specific application. I would have expected to be able to
"control" the compilation using appropriate CONFIG_*.


best regards

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


application specific pin multiplexing (for STM32F412G-Disco)

Massimiliano Cialdi
 

Sto sviluppando una pplicazione grafica che gira su STM32F412G-Discovery.
For this purpose, I must set the multiplexing of some pins to use the FSMC device.
I wonder if I need to edit the files zephyr/boards/boards/arm/stm32f412g_disco/pinmux. c and zephyr/dts/arm/st/stm32f412-pinctrl. dtsi or there is a way to do this by editing only files in the application directory, without touching the files inside zephyr.
If I need to edit zephyr files, what are the rules to follow to make my changes live with the system settings?

best regards
Max


Re: Adding Nucleo-F030R8 support to Zephyr - runtime error

Bobby
 

Hello Maciej,

2017-09-14 12:07 GMT+02:00 Maciej Dębski <maciej.debski@...>:
Hello Bobby, hello Neil,

thank you for working on this.
I did not spend much time on this, I just merged the recent zephyr master into my branch and added these changes:

Hello world and blinky are working just fine.

I did not merge the Bobby's pull request to my pull request yet:
If I understand correctly, the above is about the same issue as your recent update? If you think it is the way you want to resolve the issue with vector table - just update the pull request, Bobby.

Pull request now updated. Please pull and test.

Thank you
Bobby
 
If I am wrong, then create the 2nd pull request, I will merge them, when you are ready.

My pull request to zephyr master for stm32f0 is up to date with all the required changes. I fixed all the issues they asked me to, but no new reviews showed up. I am waiting for now. Here it is:

Yours sincerely,
Maciej Dębski

On Thu, Sep 14, 2017 at 10:55 AM, Neil Armstrong <narmstrong@...> wrote:
Hi Bobby,

I was thinking of something similar, good work !

I'll test it,

@Maciej, would you have time to test it and integrate it to your pull request ?

Thanks,
Neil

On 09/13/2017 09:54 PM, b0661 wrote:
> Hi Neil,
>
> I created another vector table relocation function and adjusted the linker control file.
> Please have a look at https://github.com/b0661/zephyr/commit/6be292fab8580b3afa4a50cd59b8c406701d08d3.
>
> I don´t know much about the bootloader mechanisms you mentioned - please review/ comment.
>
> Thanks
> Bobby
>
>
>
> 2017-09-13 14:44 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@...m>>:
>
>     On 09/13/2017 02:30 PM, b0661 wrote:
>     > Hi Neal,
>     >
>     > 2017-09-13 14:10 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@...m> <mailto:narmstrong@...m <mailto:narmstrong@...m>>>:
>     >
>     >     On 09/13/2017 02:09 PM, b0661 wrote:
>     >     > Hi Neal,
>     >     >
>     >     > I had a look at the linker script https://github.com/zephyrproject-rtos/zephyr/blob/master/include/arch/arm/cortex_m/scripts/linker.ld <https://github.com/zephyrproject-rtos/zephyr/blob/master/include/arch/arm/cortex_m/scripts/linker.ld> <https://github.com/zephyrproject-rtos/zephyr/blob/master/include/arch/arm/cortex_m/scripts/linker.ld <https://github.com/zephyrproject-rtos/zephyr/blob/master/include/arch/arm/cortex_m/scripts/linker.ld>> which is also used for STM32F0.
>     >     >
>     >     > Transfer of the vector table to address 0.. of the SRAM will either write to the application .data section or the kernel .bss section. The .bss section will be zeroed just after the relocation of the vector table.
>     >     >
>     >     > I think there must be a memory reservation for the vector table at the start of the RAMABLE_REGION.
>     >
>     >     Exact
>     >
>     >     >
>     >     >
>     >     > I still do not see why execution in place (XIP) mandates the interrupt vector table to be in SRAM. This should be a different configuration option to be set by e.g. bootloaders. Event bootloaders may avoid that by using trampolines. Based on this option the memory at the start of the SRAM can be reseved, the SRAM mapped to address 0 and the vector table transfered from flash to SRAM.
>     >
>     >     Yes it should, then it should disable all the dynamic update and generation of the vector table.
>     >
>     >
>     > There are use cases where you really do not need the dynamic updates (mine for example - updates are done by the supervising system) but as much RAM as possible. So why not make it a config option?
>
>     Yes, I think the SRAM mapped case should be an option, but selected by default. Anyway, something must be pushed along the STM32F0 basic support.
>
>     Neil
>
>     >
>     >
>     >     >
>     >     >
>     >     > Bobby
>     >     >
>     >     > 2017-09-11 17:09 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@...m> <mailto:narmstrong@...m <mailto:narmstrong@...m>> <mailto:narmstrong@...m <mailto:narmstrong@...m> <mailto:narmstrong@...m <mailto:narmstrong@...m>>>>:
>     >     >
>     >     >     Hi,
>     >     >
>     >     >     Since Cortex-M0 cannot relocate the vector base with a processor register, the vector must be moved.
>     >     >
>     >     >     Yes you can map the first kbytes of the flash to the first 32k bytes of 0, but you won't tun change the vector or run other applications if you have a bootloader.
>     >     >
>     >     >     But yes, you may need to add a further Kconfig to completely disable relocation, but also disable vector modification because it can only occur in this SRAM mapped a 0.
>     >     >
>     >     >     Neil
>     >     >
>     >     >     On 09/11/2017 04:02 PM, b0661 wrote:
>     >     >     > Hi Neil,
>     >     >     >
>     >     >     > the patch forces the STM32F0 vector table to be in SRAM as CONFIG_FLASH_BASE_ADDRESS and CONFIG_SRAM_BASE_ADDRESS are not 0.
>     >     >     >
>     >     >     > I would appreciate to save precious SRAM and do the remap only if it is needed.
>     >     >     >
>     >     >     > I could not find out how the vector table space is reserved in SRAM. Is this already done or are there more patches to follow to ensure this?
>     >     >     >
>     >     >     > My patch was agnostic of config options by intention. It copies the vector table if the vector table content is not the expected one. All other measures to ensure correct vector table operations are left to the application/soc/board/....
>     >     >     >
>     >     >     > I will test your patch.
>     >     >     >
>     >     >     > Bobby
>     >     >     >
>     >     >     >
>     >     >     > 2017-09-11 14:54 GMT+02:00 Neil Armstrong <narmstrong@... <mailto:narmstrong@...m> <mailto:narmstrong@...m <mailto:narmstrong@...m>> <mailto:narmstrong@...m <mailto:narmstrong@...m> <mailto:narmstrong@...m <mailto:narmstrong@...m>>> <mailto:narmstrong@...m <mailto:narmstrong@...m> <mailto:narmstrong@...m <mailto:narmstrong@...m>> <mailto:narmstrong@...m <mailto:narmstrong@...m> <mailto:narmstrong@...m <mailto:narmstrong@...m>>>>>:
>     >     >     >
>     >     >     >     Hi Maciej, Bobby,
>     >     >     >
>     >     >     >     Could test the following patch ?
>     >     >     >
>     >     >     >     If it works, it's the correct way to handle this situation, and should be included in the stm32f0 support patchset.
>     >     >     >
>     >     >     >
>     >     >     >     --><---------------------------------------------------------------------------
>     >     >     >
>     >     >     >     diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
>     >     >     >     index 1382379..57e0e92 100644
>     >     >     >     --- a/arch/arm/core/cortex_m/prep_c.c
>     >     >     >     +++ b/arch/arm/core/cortex_m/prep_c.c
>     >     >     >     @@ -26,12 +26,25 @@
>     >     >     >
>     >     >     >      #ifdef CONFIG_ARMV6_M
>     >     >     >
>     >     >     >     +/**
>     >     >     >     + * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
>     >     >     >     + *       This functions is a hook before the vector memory relocation to
>     >     >     >     + *       ensure the mapped memory is correct.
>     >     >     >     + */
>     >     >     >     +void __weak relocate_vector_memory(void)
>     >     >     >     +{
>     >     >     >     +       /* Nothing to do by default */
>     >     >     >     +}
>     >     >     >     +
>     >     >     >      #define VECTOR_ADDRESS 0
>     >     >     >      static inline void relocate_vector_table(void)
>     >     >     >      {
>     >     >     >      #if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
>     >     >     >          !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
>     >     >     >             size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
>     >     >     >     +
>     >     >     >     +       relocate_vector_memory();
>     >     >     >     +
>     >     >     >             memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
>     >     >     >      #endif
>     >     >     >      }
>     >     >     >     diff --git a/arch/arm/soc/st_stm32/stm32f0/soc.c b/arch/arm/soc/st_stm32/stm32f0/soc.c
>     >     >     >     index 727c348..2c056c2 100644
>     >     >     >     --- a/arch/arm/soc/st_stm32/stm32f0/soc.c
>     >     >     >     +++ b/arch/arm/soc/st_stm32/stm32f0/soc.c
>     >     >     >     @@ -17,6 +17,16 @@
>     >     >     >      #include <cortex_m/exc.h>
>     >     >     >
>     >     >     >      /**
>     >     >     >     + * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
>     >     >     >     + *       This functions is a hook before the vector memory relocation to
>     >     >     >     + *       ensure the mapped memory is correct.
>     >     >     >     + */
>     >     >     >     +void relocate_vector_memory(void)
>     >     >     >     +{
>     >     >     >     +       LL_SYSCFG_SetRemapMemory(LL_SYSCFG_REMAP_SRAM);
>     >     >     >     +}
>     >     >     >     +
>     >     >     >     +/**
>     >     >     >       * @brief This function configures the source of stm32cube time base.
>     >     >     >       *        Cube HAL expects a 1ms tick which matches with k_uptime_get_32.
>     >     >     >       *        Tick interrupt priority is not used
>     >     >     >     --
>     >     >     >
>     >     >     >     Thanks,
>     >     >     >     Neil
>     >     >     >
>     >     >     >
>     >     >     >     On 09/11/2017 02:35 PM, Neil Armstrong wrote:
>     >     >     >     > Hi All,
>     >     >     >     >
>     >     >     >     > On STM32F0 SoCs, the forst 32K cam be remapped to an internal SRAM, but this must be done *before* the relocate_vector_table() call.
>     >     >     >     >
>     >     >     >     > I will push a patch to add a relocate hook for Cortex-M0 platforms to use the LL LL_SYSCFG_SetRemapMemory() call before the vector table relocating.
>     >     >     >     >
>     >     >     >     > Neil
>     >     >     >     >
>     >     >     >     > On 09/11/2017 12:06 PM, Neil Armstrong wrote:
>     >     >     >     >> Hi All,
>     >     >     >     >>
>     >     >     >     >> I have some concern about this commit eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 (arm: armv6-m: Support relocating vector table).
>     >     >     >     >>
>     >     >     >     >> On STM32, flash is not at address 0, but can be relocated like sram spi-flash, external nand, ..., but should be when booting from flash, but this code is totally erroneous !
>     >     >     >     >>
>     >     >     >     >> The #if is bogus :
>     >     >     >     >> #if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
>     >     >     >     >>
>     >     >     >     >> And it doesn't take in account what is actually mapped at address 0 !
>     >     >     >     >>
>     >     >     >     >> On STM32, we can consider if we boot on XIP the flash is mapped on 0, so no need to relocate vectors, but indeed it can be remapped later.
>     >     >     >     >>
>     >     >     >     >> @Bobby : I think this relocate should be disabled instead if avoiding copy when the values are the same.
>     >     >     >     >>
>     >     >     >     >> @kumar, erwan : should it be handled with a config disabling the relocation on stm32 ?
>     >     >     >     >>
>     >     >     >     >> Neil
>     >     >     >     >>
>     >     >     >     >> On 09/03/2017 07:22 PM, b0661 wrote:
>     >     >     >     >>> Hello Maciej,
>     >     >     >     >>>
>     >     >     >     >>> I assume the problem is - as Yannis pointed out - the code triggers a write to flash which stops in some way  execution.
>     >     >     >     >>>
>     >     >     >     >>> The commit "arch: arm: core: fix vector table relocate write to flash"
>     >     >     >     >>> https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314
>     <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>>>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>
>     >     <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314> <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>>>>>
>     >     >     >     >>> works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).
>     >     >     >     >>>
>     >     >     >     >>> I do not have a board that needs the relocation. So this is untested for such boards.
>     >     >     >     >>> Nevertheless the commit passes my local sanity check.
>     >     >     >     >>>
>     >     >     >     >>> If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.
>     >     >     >     >>>
>     >     >     >     >>> Bobby
>     >     >     >     >>>
>     >     >     >     >>>
>     >     >     >     >>> 2017-08-25 14:24 GMT+02:00 Maciej Dębski <maciej.debski@... <mailto:maciej.debski@...om> <mailto:maciej.debski@...om <mailto:maciej.debski@...om>> <mailto:maciej.debski@...om <mailto:maciej.debski@...om> <mailto:maciej.debski@...om <mailto:maciej.debski@...om>>> <mailto:maciej.debski@...om <mailto:maciej.debski@...om> <mailto:maciej.debski@...om <mailto:maciej.debski@...om>> <mailto:maciej.debski@...om <mailto:maciej.debski@...om> <mailto:maciej.debski@...om <mailto:maciej.debski@...om>>>> <mailto:maciej.debski@...om <mailto:maciej.debski@...om> <mailto:maciej.debski@...om <mailto:maciej.debski@...om>> <mailto:maciej.debski@...om <mailto:maciej.debski@...om> <mailto:maciej.debski@...om <mailto:maciej.debski@...om>>> <mailto:maciej.debski@...om <mailto:maciej.debski@...om> <mailto:maciej.debski@...om
>     <mailto:maciej.debski@rndity.com>> <mailto:maciej.debski@...om <mailto:maciej.debski@...om> <mailto:maciej.debski@...om <mailto:maciej.debski@...om>>>>>>:
>     >     >     >     >>>
>     >     >     >     >>>     Gentlemen,
>     >     >     >     >>>
>     >     >     >     >>>     thank you for your quick responses!
>     >     >     >     >>>
>     >     >     >     >>>     As I wanted to provide more info and debug output, I accidentally found the issue.
>     >     >     >     >>>     This little change in arch/arm/core/cortex_m/prep_c.c caused sys fatal error on my f0 board, even before the stm32f0_init.
>     >     >     >     >>>
>     >     >     >     >>>     Here is the commit:
>     >     >     >     >>>     https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>
>     <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>>>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>>
>     >     <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>> <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>
>     <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>>>>>
>     >     >     >     >>>
>     >     >     >     >>>     And here are the specific changes causing problem:
>     >     >     >     >>>
>     >     >     >     >>>     diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
>     >     >     >     >>>     index d23dd8b..1382379 100644
>     >     >     >     >>>     --- a/arch/arm/core/cortex_m/prep_c.c
>     >     >     >     >>>     +++ b/arch/arm/core/cortex_m/prep_c.c
>     >     >     >     >>>     @@ -22,9 +22,20 @@
>     >     >     >     >>>      #include <linker/linker-defs.h>
>     >     >     >     >>>      #include <nano_internal.h>
>     >     >     >     >>>      #include <arch/arm/cortex_m/cmsis.h>
>     >     >     >     >>>     +#include <string.h>
>     >     >     >     >>>
>     >     >     >     >>>      #ifdef CONFIG_ARMV6_M
>     >     >     >     >>>     -static inline void relocate_vector_table(void) { /* do nothing */ }
>     >     >     >     >>>     +
>     >     >     >     >>>     +#define VECTOR_ADDRESS 0
>     >     >     >     >>>     +static inline void relocate_vector_table(void)
>     >     >     >     >>>     +{
>     >     >     >     >>>     +#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
>     >     >     >     >>>     +    !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
>     >     >     >     >>>     +       size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
>     >     >     >     >>>     +       memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
>     >     >     >     >>>     +#endif
>     >     >     >     >>>     +}
>     >     >     >     >>>     +
>     >     >     >     >>>      #elif defined(CONFIG_ARMV7_M)
>     >     >     >     >>>      #ifdef CONFIG_XIP
>     >     >     >     >>>      #define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \
>     >     >     >     >>>
>     >     >     >     >>>
>     >     >     >     >>>     When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
>     >     >     >     >>>     What should I do now? How to report it properly?
>     >     >     >     >>>
>     >     >     >     >>>     Thank you!
>     >     >     >     >>>
>     >     >     >     >>>     Yours faithfully,
>     >     >     >     >>>     Maciej Dębski
>     >     >     >     >>>
>     >     >     >     >>>
>     >     >     >     >>>
>     >     >     >     >>>
>     >     >     >     >>>     On Wed, Aug 23, 2017 at 10:47 AM, Maciej Dębski <maciej.debski@... <mailto:maciej.debski@...om> <mailto:maciej.debski@...om <mailto:maciej.debski@...om>> <mailto:maciej.debski@...om <mailto:maciej.debski@...om> <mailto:maciej.debski@...om <mailto:maciej.debski@...om>>> <mailto:maciej.debski@...om <mailto:maciej.debski@...om> <mailto:maciej.debski@...om <mailto:maciej.debski@...om>> <mailto:maciej.debski@...om <mailto:maciej.debski@...om> <mailto:maciej.debski@...om <mailto:maciej.debski@...om>>>> <mailto:maciej.debski@...om <mailto:maciej.debski@...om> <mailto:maciej.debski@...om <mailto:maciej.debski@...om>> <mailto:maciej.debski@...om <mailto:maciej.debski@...om> <mailto:maciej.debski@...om <mailto:maciej.debski@...om>>> <mailto:maciej.debski@...om <mailto:maciej.debski@...om> <mailto:maciej.debski@...om <mailto:maciej.debski@...om>> <mailto:maciej.debski@...om
>     <mailto:maciej.debski@rndity.com> <mailto:maciej.debski@...om <mailto:maciej.debski@...om>>>>>> wrote:
>     >     >     >     >>>
>     >     >     >     >>>         Hello,
>     >     >     >     >>>
>     >     >     >     >>>         I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.
>     >     >     >     >>>
>     >     >     >     >>>         I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.
>     >     >     >     >>>
>     >     >     >     >>>         I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
>     >     >     >     >>>         After checking the code over and over, I think I need help!
>     >     >     >     >>>
>     >     >     >     >>>         I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?
>     >     >     >     >>>
>     >     >     >     >>>         https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>>>>
>     <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103> <https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>>>>>
>     >     >     >     >>>
>     >     >     >     >>>         This is my pull request. I would focus on dts/arm and include/dt-bindings.
>     >     >     >     >>>
>     >     >     >     >>>         Yours faithfully,
>     >     >     >     >>>         Maciej Dębski
>     >     >     >     >>>
>     >     >     >     >>>
>     >     >     >     >>>
>     >     >     >     >>>     _______________________________________________
>     >     >     >     >>>     Zephyr-devel mailing list
>     >     >     >     >>>     Zephyr-devel@...ect.org <mailto:Zephyr-devel@...hyrproject.org> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org>> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org>>> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org>> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org>>>> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org>> <mailto:Zephyr-devel@...hyrproject.org
>     <mailto:Zephyr-devel@...phyrproject.org> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org>>> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org>> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org>>>>>
>     >     >     >     >>>     https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
>     <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>
>     >     <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>>>>
>     >     >     >     >>>
>     >     >     >     >>>
>     >     >     >     >>>
>     >     >     >     >>>
>     >     >     >     >>> _______________________________________________
>     >     >     >     >>> Zephyr-devel mailing list
>     >     >     >     >>> Zephyr-devel@...ct.org <mailto:Zephyr-devel@...hyrproject.org> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org>> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org>>> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org>> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org> <mailto:Zephyr-devel@...hyrproject.org <mailto:Zephyr-devel@...hyrproject.org>>>>
>     >     >     >     >>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel> <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
>     <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>>>>
>     >     >     >     >>>
>     >     >     >     >>
>     >     >     >     >
>     >     >     >
>     >     >     >
>     >     >
>     >     >
>     >
>     >
>
>




Re: How to use STM32 HAL drives

Erwan Gouriou
 

Hi,

This is the correct understanding, you need to modify Makefile/Kbuild to access HAL drivers.
Then, if you need to use some driver in an application, you'd theoretically use zephyr HW API and drivers (based on HAL or directly accessing HW).
Then,CONFIG flags actually control the compilation but through activation of Zephyr drivers.
For instance for GPIO:
CONFIG_GPIO=y
CONFIG_GPIO_STM32=y
CONFIG_GPIO_STM32_PORTA=y

Of course, you can directly access stm32cube HAL in your application if you want to, but this is not the usual use foreseen by Zephyr architecture.

Erwan

On 14 September 2017 at 15:30, massimiliano cialdi <massimiliano.cialdi@...> wrote:
In an application I need to use STM32 HAL driver, for example GPIO, FSMC and others.

I wonder how can I have the appropriate files compiled. There are some CONFIG_* to set?

I read zephyr/ext/hal/st/stm32cube/README

If I understand well it seems that I have to modify Makefile or Kbuild in zephyr/ext/hal/st/stm32cube/ but it seems very strange and counterintuitive to have to modify a zephyr file for the needs of a specific application. I would have expected to be able to "control" the compilation using appropriate CONFIG_*.


best regards

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


Re: Using Flash partitions

Puzdrowski, Andrzej
 

Hi.

You need to provide description of how to use the description you introduced. Look at https://github.com/zephyrproject-rtos/zephyr/blob/master/dts/common/yaml/partition.yaml
For details how BOT partitions were described.

But these defines are not available, do I need to enable specific configuration options to get these defines ?
No, just jour device tree description didn't fit to any *.yaml script.

Andrzej

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Laczen JMS
Sent: Thursday, September 14, 2017 3:25 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] Using Flash partitions

Hi,

I would like to setup zephyr so that it can use a flash area to store data. I have added a partition description in my dts file describing the flash partitioning (for testing I used the partitioning for MCUBOOT).

I was expecting that after this partitioning I would be able to get the offset and size as e.g.:

FLASH_AREA_MCUBOOT_OFFSET and FLASH_AREA_MCUBOOT_SIZE FLASH_AREA_IMAGE_0_OFFSET and FLASH_AREA_IMAGE_0_SIZE ...

But these defines are not available, do I need to enable specific configuration options to get these defines ?

Kind regards,

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


How to use STM32 HAL drives

Massimiliano Cialdi
 

In an application I need to use STM32 HAL driver, for example GPIO, FSMC and others.

I wonder how can I have the appropriate files compiled. There are some CONFIG_* to set?

I read zephyr/ext/hal/st/stm32cube/README

If I understand well it seems that I have to modify Makefile or Kbuild in zephyr/ext/hal/st/stm32cube/ but it seems very strange and counterintuitive to have to modify a zephyr file for the needs of a specific application. I would have expected to be able to "control" the compilation using appropriate CONFIG_*.


best regards

Max


Using Flash partitions

laczenJMS
 

Hi,

I would like to setup zephyr so that it can use a flash area to store
data. I have added a partition description in my dts file describing
the flash partitioning (for testing I used the partitioning for
MCUBOOT).

I was expecting that after this partitioning I would be able to get
the offset and size as e.g.:

FLASH_AREA_MCUBOOT_OFFSET and FLASH_AREA_MCUBOOT_SIZE
FLASH_AREA_IMAGE_0_OFFSET and FLASH_AREA_IMAGE_0_SIZE
...

But these defines are not available, do I need to enable specific
configuration options to get these defines ?

Kind regards,

Jehudi


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

Nashif, Anas
 

Hi,
I fully agree with your first paragraph but then I got completely lost how enabling logging is going to solve the issue you have presented. Frankly, the first thing I do when trying out an application is turn off all the logging, because it gets in the way, it is too verbose and it also disturbs the net shell which is enabled in many applications.

The main problem I see in many of the networking samples is the fact that we have developers designing the applications for their needs and for their own testing environment, i.e. we do have most configurations with whatever is needed to run in Qemu and in many cases with logging enabled and with kernel and networking options that worked for "someone" at "some point".

The main issues as I see them are the following:
- We do need safe defaults that can be lowered or increased, depending on usage and memory constraints. We basically want to have configuration options that enable a feature safely without having to worry about details, this might increase the binary size and memory usage, but should be possible to be customized down if needed.

Just picking a random example:

CONFIG_NET_PKT_RX_COUNT=16
CONFIG_NET_PKT_TX_COUNT=16
CONFIG_NET_BUF_RX_COUNT=16
CONFIG_NET_BUF_TX_COUNT=16

CONFIG_NET_IF_UNICAST_IPV6_ADDR_COUNT=2
CONFIG_NET_IF_MCAST_IPV6_ADDR_COUNT=4

CONFIG_NET_MAX_CONTEXTS=16

Why do I need to deal with all of that as a "random novice user". In most cases people will just copy paste those without knowing what is going on. We should either set those to safe default values or adjust them automatically based on configured features using Kconfig.

- We do need to generalize the test setting and just maintain them in one place and keep the configurations of samples generic and hw oriented as much as possible. In a test environment we then could merge the test setting and do the qemu magic without clobbering sample configurations with local test settings like


CONFIG_NET_APP_SETTINGS=y
CONFIG_NET_APP_MY_IPV6_ADDR="2001:db8::1"
CONFIG_NET_APP_PEER_IPV6_ADDR="2001:db8::2"
CONFIG_NET_APP_MY_IPV4_ADDR="192.0.2.1"
CONFIG_NET_APP_PEER_IPV4_ADDR="192.0.2.2"


- It would help if we had all network samples behave the same, i.e. all samples should target similar use cases, of course depending on the features being demonstrated that might not be possible, but take protocols for example and anything that would require a full network setup, we could define a setup that is easily done by the novice user and build on top of that, most basic setup I could think of, and this is just an example, more options should be possible:

- DHCPv4
- IPv4

I can here connect my board with Ethernet to a local network with DHCP and be able to send and receive data immediately. Of course this is very simplified, but if we can generalize similar functionality with similar and unified configuration options, then we will make it easy.

- Ok, it is not all bad news, Jukka and the network stack developers introduced this nice netapp interface which makes it very easy to get started and does eliminate tons of code that used to be in the application and moved it to the ip stack, so this was a huge improvement already, we need to continue optimizing into this direction.

- Finally, logging. It can be really useful and I agree we need to enable some type of logging by default (which can be turned off easily). I always get lost in the configuration of logging of network applications, you would assume that CONFIG_SYS_LOG=n would turn off everything, but it does not and there are too many variants and no easy way to understand what enables/disables what. So we do need to revisit this and think how we can easily enable/disable logging and keep it on by default without impacting binary size and performance.


Anas

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Paul Sokolovsky
Sent: Wednesday, September 13, 2017 4:02 PM
To: devel@...
Subject: [Zephyr-devel] RFC: Stopping Zephyr networking from being painful by enabling error logging by default

Hello,

I more the once mentioned the issue that Zephyr IP networking is very hard to configure. It almost impossible to configure a slightly-above-trivial app from scratch: something won't work with it, usually silently.

A usual response would be "enable debug logging", but here it goes in the vicious cycle, because it's hard to enable network debug logging in Zephyr. It requires setting CONFIG_NET_LOG, then if you're lucky, you discover CONFIG_NET_LOG_GLOBAL, then you also need to figure out that you need to set CONFIG_SYS_LOG_NET_LEVEL to a cryptic numeric value.

If you think that's enough, then nah, because CONFIG_NET_LOG_GLOBAL doesn't really enable logging globally. Then maybe you trace another config option, after which you will likely either get a flood of DEBUG level logging, or find out that an important condition is not logged at all.

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.

2. Describe (in the docs, or otherwise) that CONFIG_NET_LOG=n is the master switch to disable all logging at once.

3. Make sure that CONFIG_NET_LOG_GLOBAL=y actually enables logging for anything network related.

4. Make sure that any important (to user) conditions actually reported with NET_WARN() or NET_ERR(), so will be visible to a user by default.


--
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@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


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

Paul Sokolovsky
 

On Thu, 14 Sep 2017 09:33:22 +0300
Jukka Rissanen <jukka.rissanen@...> wrote:

Hi Paul,

On Wed, 2017-09-13 at 23:02 +0300, Paul Sokolovsky wrote:
Hello,

I more the once mentioned the issue that Zephyr IP networking is
very hard to configure. It almost impossible to configure
a slightly-above-trivial app from scratch: something won't work with
it,
usually silently.
I am probably biased here and looking the code too close but what
exactly is hard when configuring the IP stack? Is it difficult to
figure out the suitable config options, are the help texts in Kconfig
options too short or what? Please elaborate this more.
It's that there're too many options, and need for a particular option
or an effect of some option is hard to anticipate, and if one didn't,
an application usually silently doesn't do anything/something useful or
just crashes.

A usual response would be "enable debug logging", but here it goes
in the vicious cycle, because it's hard to enable network debug
logging in
Zephyr. It requires setting CONFIG_NET_LOG, then if you're lucky,
you discover CONFIG_NET_LOG_GLOBAL, then you also need to figure
out that you need to set CONFIG_SYS_LOG_NET_LEVEL to a cryptic
numeric value.
I never use the CONFIG_NET_LOG_GLOBAL because it just prints out too
much data which slows down everything in the device and makes
debugging even harder. I would actually propose that we remove that
option but if someone sees it useful to have, then we can keep it.
That's why I propose to enable it only with "warning" logging level.
That will be useful for users to spot misconfigurations/understand
misbehavior. But as I mentioned in the previous reply on the thread
(to Andrew), this leads to a problem that if a user adjusts just
the logging level to "debug", they get flooded with spam-logging.

We should anticipate this problem and give instructions for users how to
deal with it (as in: Kconfig help for CONFIG_NET_LOG_GLOBAL should warn
against it's usage with DEBUG, and instead suggest to disable itself
and enabled individual module logging).



If you think that's enough, then nah, because CONFIG_NET_LOG_GLOBAL
doesn't really enable logging globally. Then maybe you trace another
config option, after which you will likely either get a flood of
DEBUG
level logging, or find out that an important condition is not logged
at
all.
As the name implies, the CONFIG_NET_LOG_GLOBAL is only for networking.
It might also miss some new net debug options.
ARP is also networking, BSD Sockets is also networking, SLIP is also
networking. I'm, a Random J User, expect to see errors/warnings in all
of them by default (and ready to be taught how to deal with debug-level
logging enabled).



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.
Above you write that there're not so many warnings in the stack. So,
bloating a binary shouldn't be that big a problem. If it is, we need to
optimize the logging and its ram/stack usage. (But we definitely need
to add more warns/errors, that's the whole point.)

Normally you do not need to have
debugging enabled anyway,
My experience with Zephyr shows the contrary.

and if you need it, then it is easy to set
CONFIG_NET_LOG=y,
So, the talk is about making it uber-easy: users get the errors by
default, and making it easy to *disable* it (by setting
CONFIG_NET_LOG=n).

enable individual component logging
Enable individual component logging is easy? But you need to know that
you need to enable it individually, know how to do that, know which
individual components exist. That's already *very* hard for a novice.

or global
logging, and then increase the log level.
You lost me (a random novice user) here.

Perhaps we could have better documentation about this, could you
perhaps send a patch describing how to do it?
So, the talk is about making it work with least user surprise
for novice and casual users - by enabling the err/warn logging by
default. Then, for users who go as far as using Zephyr in production
(where logging should be disabled), there should be an easy way to
disable it (1 config option). Yes, it should be well documented, and
I'll be happy to contribute to such documentation. (Sorry, expecting
that people start on a new project with thoroughly reading docs is,
well, ungrounded.)


Cheers,
Jukka
Thanks,

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

5181 - 5200 of 8570