devel@lists.zephyrproject.org

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

I definitely think it makes sense to do this by default for our QEMU based targets, since they have lots of ram and we don't gather performance metrics for emulated targets. Andrew

By Boie, Andrew P · #1024 ·

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

Re (1): in this spirit, I would also enable CONFIG_ASSERT by default... Re (4): SYS_LOG itself is not the issue, it is the layers added on top of it to enable logging in subsystems such as the IP

By Nashif, Anas · #1023 ·

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

By Boie, Andrew P · #1022 ·

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

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

By david zuhn · #1021 ·

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

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

By Bobby · #1020 ·

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

Hello Luiz,

By Paul Sokolovsky · #1019 ·

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

Hi Paul, <paul.sokolovsky@...> wrote: 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

By Luiz Augusto von Dentz · #1018 ·

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

Hello Piotr,

By Paul Sokolovsky · #1017 ·

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

Hello Piotr,

By Paul Sokolovsky · #1016 ·

Re: Counter API ambiguity.

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

By Chettimada, Vinayak Kariappa · #1015 ·

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

By 曹子龙 · #1014 ·

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

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

By Piotr Mienkowski · #1013 ·

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

"Nashif, Anas" <anas.nashif@...> wrote: 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

By Paul Sokolovsky · #1012 ·

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

Tomasz Bursztyka <tomasz.bursztyka@...> wrote: [] Right, I had the same idea, mentioned in the other mails. [] I posted https://github.com/zephyrproject-rtos/zephyr/pull/1507

By Paul Sokolovsky · #1011 ·

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

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

By Nashif, Anas · #1010 ·

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

Hello Anas, "Nashif, Anas" <anas.nashif@...> wrote: 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

By Paul Sokolovsky · #1009 ·

Re: application specific pin multiplexing (for STM32F412G-Disco)

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

By Erwan Gouriou · #1008 ·

Re: How to use STM32 HAL drives

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

By Erwan Gouriou · #1007 ·

application specific pin multiplexing (for STM32F412G-Disco)

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

By Massimiliano Cialdi · #1006 ·

Re: How to use STM32 HAL drives

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

By Massimiliano Cialdi · #1005 ·

Messages