|
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...
toggle quoted messageShow quoted text
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
I don't think discussion in this direction would be productive. Because 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
|
|
|
|
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. 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.
|
|
|
|
Re: RFC: Stopping Zephyr networking from being painful by enabling error logging by default
Paul Sokolovsky
Hello Luiz,
toggle quoted messageShow quoted text
On Fri, 15 Sep 2017 12:26:10 +0300
Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: [] Well, when someone comes by and says "You're doing great, but we won'tWe should think beyond that, we should think why, 8 months after theWhen you use a presentation which says: 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 facingIt'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 complainingYeah, 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,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 ZephyrComparing 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. -- -- Luiz Augusto von Dentz
|
|
|
|
Re: RFC: Stopping Zephyr networking from being painful by enabling error logging by default
Paul Sokolovsky
Hello Piotr,
toggle quoted messageShow quoted text
On Thu, 14 Sep 2017 22:03:19 +0200
Piotr Mienkowski <piotr.mienkowski@gmail.com> wrote: [] I would put it differently: we should make choices for the benefit ofI disagree with enabling logging by default, it bloats the binaryOne more vote to set the default log level to 2 (warning) but not to the users. I preferI 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 smallBut 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 notNo, 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. -- 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,
toggle quoted messageShow quoted text
On Thu, 14 Sep 2017 22:03:19 +0200
Piotr Mienkowski <piotr.mienkowski@gmail.com> wrote: [] I would put it differently: we should make choices for the benefit ofI disagree with enabling logging by default, it bloats the binaryOne more vote to set the default log level to 2 (warning) but not to the users. I preferI 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 smallBut 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 notNo, 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. -- 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
|
|
|
|
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: One more vote to set the default log level to 2 (warning) but not toDebugging the configuration and debug logging itself is quiteWe could set the log level to 2 (warn) as you suggest, there was not 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@intel.com> wrote: Should I assume you started replying before you read my final commentWell, 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 -- 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@linux.intel.com> wrote: []you discover CONFIG_NET_LOG_GLOBAL I have been using it when porting new devices, it's an easy option toRight, I had the same idea, mentioned in the other mails. [] I posted https://github.com/zephyrproject-rtos/zephyr/pull/1507 showingAs the name implies, the CONFIG_NET_LOG_GLOBAL is only forMost probably yes 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'sYes, and we can make it simpler. We could probably add a documentation about how to relevantly use theExtending 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? :-)
toggle quoted messageShow quoted text
Anas
-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@linaro.org] Sent: Thursday, September 14, 2017 12:43 PM To: Nashif, Anas <anas.nashif@intel.com> Cc: devel@lists.zephyrproject.org 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@intel.com> wrote: Hi,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 turnThis 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 manyThat'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 factThere'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 developersRight, 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 toCool, thanks. My RFC is exactly how to make first few steps in that direction. [] -- 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@intel.com> wrote: Hi,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 anThis 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 enabledThat'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 factThere'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 developersRight, 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 toCool, thanks. My RFC is exactly how to make first few steps in that direction. [] -- 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
|
|
|
|
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@ and what about peripherals that zephyr doesn't manage, like FSMC?
|
|
|
|
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?
toggle quoted messageShow quoted text
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,
|
|
|
|
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
|
|
|