|
ODP: [Zephyr-devel] logging MACRO LOG_ERR/LOG_INF/LOG_DBG expansion issue
Chruściński, Krzysztof
Hi,
compiler is able to figure out things and remove code that is known not to be executed.
Code like this will disapear from the binary:
if ( 2 > 3) {
foo();
}
It can even be more complex like here were constant comes from inline function:
static inline int f3(void)
{
return 3;
}
if (2 > f3()) {
foo();
}
regards,
Krzysztof
Od: devel@... <devel@...> w imieniu użytkownika qzhang via lists.zephyrproject.org <qzhang=ambiq.com@...>
Wysłane: piątek, 14 maja 2021 09:03 Do: devel@... <devel@...> Temat: [Zephyr-devel] logging MACRO LOG_ERR/LOG_INF/LOG_DBG expansion issue Hi,
I am new to zephyr, I am reading the logging subsystem code and find that 'LOG_ERR/LOG_INF/LOG_DBG ..., etc.' will be expanded finally by below MACRO looks like even I disable the logging (not set CONFIG_LOG), below code is still remained in the code after the preprocessing, Is my understanding correct or not? does it cause the code bloat? /*****************************************************************************/
/****************** Macros for standard logging ******************************/
/*****************************************************************************/
#define Z_LOG2(_level, _source, _dsource, ...) do { \
if (!Z_LOG_CONST_LEVEL_CHECK(_level)) { \
break; \
} \
if (IS_ENABLED(CONFIG_LOG_MINIMAL)) { \
Z_LOG_TO_PRINTK(_level, __VA_ARGS__); \
break; \
} \
\
bool is_user_context = k_is_user_context(); \
uint32_t filters = IS_ENABLED(CONFIG_LOG_RUNTIME_FILTERING) ? \
(_dsource)->filters : 0;\
if (!LOG_CHECK_CTX_LVL_FILTER(is_user_context, _level, filters)) { \
break; \
} \
if (IS_ENABLED(CONFIG_LOG2)) { \
int _mode; \
void *_src = IS_ENABLED(CONFIG_LOG_RUNTIME_FILTERING) ? \
(void *)_dsource : (void *)_source; \
Z_LOG_MSG2_CREATE(UTIL_NOT(IS_ENABLED(CONFIG_USERSPACE)), _mode, \
CONFIG_LOG_DOMAIN_ID, _src, _level, NULL,\
0, __VA_ARGS__); \
} else { \
Z_LOG_INTERNAL(is_user_context,
_level, \
_source, _dsource, __VA_ARGS__);\
} \
if (false) { \
/* Arguments checker present but never evaluated.*/ \
/* Placed here to ensure that __VA_ARGS__ are*/ \
/* evaluated once when log is enabled.*/ \
z_log_printf_arg_checker(__VA_ARGS__); \
} \
} while (false) Br Quan
|
|
|
|
bluetooth init error -90
Smitha Ratnam <s.ratnam@...>
Hi,
We are trying to use the silicon labs thunderboard sense2 SLTB004A device with bluetooth.
When we program the device the zephyr beacon sample, we get the following error:
* Booting Zephyr OS build zephyr-v2.5.0-3011-gb61c23943c6f * Starting Beacon Demo Bluetooth init failed (err -19) [00:00:00.007,000]
<err> bt_hci_core: No HCI driver registered
What are we supposed to do to get the bluetooth on the device initialised?
Does Zephyr support the device for bluetooth?
Thanks and regards,
Smitha.
|
|
|
|
Re: Review of concept of changing UART flow control from Kconfig to DTS config
Bolivar, Marti
Hi Jaime,
Jamie Mccrae <Jamie.Mccrae@...> writes: Hi Marti,I think we might be talking past each other but I think I'm finally getting what you mean. It does sound like we agree that: - dts/arm/nordic/*.dtsi sets hw-flow-control to 'false' by default, meaning flow control is opt-in at the SoC level - boards/arm/.../BOARD.dts files can still set per-board defaults for hw-flow-control for each uart node, so it's up to the board maintainer to decide if they want to change that default - each 'project' (Zephyr application) can still change that using a DTS overlay (yet strangely parity is still a Kconfig option, theI agree that seems like some future work to move to DT but it was probably out of scope for PR #25999. I'll leave it to Krzysztof to comment on whether he'll be moving parity to DT also. The issue is not that it is opt-in or opt-out, the issue is that it isThe Kconfig options that are gone now were per-instance (UART_0_NRF_FLOW_CONTROL, UART_1_NRF_FLOW_CONTROL, etc.), so I'm still confused about what you were doing that used to work on a "project" wide basis that no longer does. If you were doing something like this in <app>/Kconfig: config UART_1_NRF_FLOW_CONTROL default y if BOARD_MY_BOARD source "Kconfig.zephyr" Then you can just move that same setting to <app>/boards/my_board.overlay. If you were doing something like this: config UART_1_NRF_FLOW_CONTROL default y if SOC_FAMILY_NRF source "Kconfig.zephyr" Then unless *all* of your boards use UART 1 in the same way for that purpose, this seems like an unsafe thing to do. So I still don't get what you are trying to say; can you please provide a sample of what you were doing before to make this concrete? Thanks, Martí Thanks,
|
|
|
|
Re: [REMINDER] Changing default branch name on GitHub - action required
Bolivar, Marti
The main west repository [1] has also renamed its default branch to
toggle quoted messageShow quoted text
'main'. Similar guidance applies if you've got a local clone or GitHub fork. Martí https://github.com/zephyrproject-rtos/west "Kumar Gala via lists.zephyrproject.org" <kumar.gala=linaro.org@...> writes:
Reminder to all that this change has gone into effect.
|
|
|
|
logging MACRO LOG_ERR/LOG_INF/LOG_DBG expansion issue
qzhang@...
Hi,
I am new to zephyr, I am reading the logging subsystem code and find that 'LOG_ERR/LOG_INF/LOG_DBG ..., etc.' will be expanded finally by below MACRO looks like even I disable the logging (not set CONFIG_LOG), below code is still remained in the code after the preprocessing, Is my understanding correct or not? does it cause the code bloat? /*****************************************************************************/
/****************** Macros for standard logging ******************************/
/*****************************************************************************/
#define Z_LOG2(_level, _source, _dsource, ...) do { \
if (!Z_LOG_CONST_LEVEL_CHECK(_level)) { \
break; \
} \
if (IS_ENABLED(CONFIG_LOG_MINIMAL)) { \
Z_LOG_TO_PRINTK(_level, __VA_ARGS__); \
break; \
} \
\
bool is_user_context = k_is_user_context(); \
uint32_t filters = IS_ENABLED(CONFIG_LOG_RUNTIME_FILTERING) ? \
(_dsource)->filters : 0;\
if (!LOG_CHECK_CTX_LVL_FILTER(is_user_context, _level, filters)) { \
break; \
} \
if (IS_ENABLED(CONFIG_LOG2)) { \
int _mode; \
void *_src = IS_ENABLED(CONFIG_LOG_RUNTIME_FILTERING) ? \
(void *)_dsource : (void *)_source; \
Z_LOG_MSG2_CREATE(UTIL_NOT(IS_ENABLED(CONFIG_USERSPACE)), _mode, \
CONFIG_LOG_DOMAIN_ID, _src, _level, NULL,\
0, __VA_ARGS__); \
} else { \
Z_LOG_INTERNAL(is_user_context, _level, \
_source, _dsource, __VA_ARGS__);\
} \
if (false) { \
/* Arguments checker present but never evaluated.*/ \
/* Placed here to ensure that __VA_ARGS__ are*/ \
/* evaluated once when log is enabled.*/ \
z_log_printf_arg_checker(__VA_ARGS__); \
} \
} while (false) Br Quan
|
|
|
|
problem porting Zephyr to new architecture (Renesas RX65N): architecture-specific GCC is adding leading underscores
Jan Peters
Hello all,
I'm part of a team that is porting Zephyr to Renesas RX65N processors, and we have encountered a bit of a problem. The GCC toolchain for the processor (available at https://llvm-gcc-renesas.com/) by default adds leading underscores to C-Symbols. These lead to problems with Zephyr Linker scripts and at least one build-script (gen_handles.py), which do expect symbols from C-code without these underscores. We have contacted the developers of the Renesas GCC and they told us that this a a common behaviour ("for 20 out of the 50 targets of the GCC"). Has this problem been encountered before with other toolchains used to build Zephyr ? Does anyone have an idea how it can be solved (using the GCC option -fno-leading-underscore leads to problems with gcclib, which does assume the leading undescores) ? Thanks, Jan
|
|
|
|
Re: Review of concept of changing UART flow control from Kconfig to DTS config
lairdjm
Hi Marti,
toggle quoted messageShow quoted text
Let's say there is a board (all our boards are Nordic-based so this applies to all of them) which has a UART brought out to a header, the UART might be used for a multitude of things, it could be a debug port which is mostly unused, or it could be connected to a PC for exchanging a lot of data, or it could be connected to a shield, perhaps a modem, which does not have flow control pins - this is one board (and one .dts file) but with different requirements for flow control, in the old system this worked fine and flow control could be enabled or disabled on a per-project configuration or even by board/shield overlays (one board but many different projects). With the new system, that isn't possible, this requires unique board .dts files because you can no longer disable or enable flow control via a Kconfig option (yet strangely parity is still a Kconfig option, the change itself doesn't really make sense to me). The issue is not that it is opt-in or opt-out, the issue is that it is opt-in at a DTS level (and thus a board level) and not opt-in at a project level. If we enable flow control for our board, we need to add overlays to every sample project for all of our boards whereby flow control isn't needed which becomes a mess. Thanks, Jamie
-----Original Message-----
From: Bolivar, Marti <Marti.Bolivar@...> Sent: 13 May 2021 17:11 To: Jamie Mccrae <Jamie.Mccrae@...>; devel@... Cc: Chruściński, Krzysztof <Krzysztof.Chruscinski@...> Subject: Re: [Zephyr-devel] Review of concept of changing UART flow control from Kconfig to DTS config EXTERNAL EMAIL: Be careful with attachments and links. Hi (and +Krzysztof in Cc), "lairdjm via lists.zephyrproject.org" <jamie.mccrae=lairdconnect.com@...> writes: Hi,To be clear, this PR is limited to nRF SoCs only, it is not a project-wide change. I find this to be a bit of a step backwards for applicationI'm having a bit of trouble understanding what you mean here. The boolean hw-flow-control property is still available for enabling hardware flow control for both UART and UARTE: https://docs.zephyrproject.org/latest/reference/devicetree/bindings/serial/nordic%2Cnrf-uarte.html#dtbinding-nordic-nrf-uarte https://docs.zephyrproject.org/latest/reference/devicetree/bindings/serial/nordic%2Cnrf-uart.html#dtbinding-nordic-nrf-uart Looking at the code, if hw-flow-control is disabled in DTS (the default), then in both drivers cfg->flow_ctrl is false. The HAL configuration structure ends up with flow control disabled in that case: https://github.com/zephyrproject-rtos/zephyr/blob/5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1/drivers/serial/uart_nrfx_uart.c#L346 https://github.com/zephyrproject-rtos/zephyr/blob/5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1/drivers/serial/uart_nrfx_uarte.c#L397 So flow control at a SoC level seems to be turned off by default. It's true that many boards in PR #25999 do enable it by default, e.g. nRF52840-DK: https://github.com/zephyrproject-rtos/zephyr/pull/25999/files#diff-f496b12068cf78fdbb22c1b8a4eaeb66010db95b4e80db7377a340ae30a83519R7 But it seems like at a board maintainer level, you can leave the SoC default as-is to make flow control "opt in" as requested. It looks like flow control is off by default and it's opt-in; what did I miss? Thanks! Martí Thanks,
|
|
|
|
Re: [REMINDER] Changing default branch name on GitHub - action required
Kumar Gala
toggle quoted messageShow quoted text
On May 14, 2021, at 3:36 AM, Kumar Gala <kumar.gala@...> wrote:
|
|
|
|
[REMINDER] Changing default branch name on GitHub - action required
Kumar Gala
Reminder to all that this change has gone into effect.
toggle quoted messageShow quoted text
You may additionally want to make this change in your own GitHub fork of Zephyr. - k
On May 12, 2021, at 10:35 AM, Kumar Gala <kumar.gala@...> wrote:
|
|
|
|
Re: Review of concept of changing UART flow control from Kconfig to DTS config
Bolivar, Marti
Hi (and +Krzysztof in Cc),
"lairdjm via lists.zephyrproject.org" <jamie.mccrae=lairdconnect.com@...> writes: Hi,To be clear, this PR is limited to nRF SoCs only, it is not a project-wide change. I find this to be a bit of a step backwards for applicationI'm having a bit of trouble understanding what you mean here. The boolean hw-flow-control property is still available for enabling hardware flow control for both UART and UARTE: https://docs.zephyrproject.org/latest/reference/devicetree/bindings/serial/nordic%2Cnrf-uarte.html#dtbinding-nordic-nrf-uarte https://docs.zephyrproject.org/latest/reference/devicetree/bindings/serial/nordic%2Cnrf-uart.html#dtbinding-nordic-nrf-uart Looking at the code, if hw-flow-control is disabled in DTS (the default), then in both drivers cfg->flow_ctrl is false. The HAL configuration structure ends up with flow control disabled in that case: https://github.com/zephyrproject-rtos/zephyr/blob/5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1/drivers/serial/uart_nrfx_uart.c#L346 https://github.com/zephyrproject-rtos/zephyr/blob/5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1/drivers/serial/uart_nrfx_uarte.c#L397 So flow control at a SoC level seems to be turned off by default. It's true that many boards in PR #25999 do enable it by default, e.g. nRF52840-DK: https://github.com/zephyrproject-rtos/zephyr/pull/25999/files#diff-f496b12068cf78fdbb22c1b8a4eaeb66010db95b4e80db7377a340ae30a83519R7 But it seems like at a board maintainer level, you can leave the SoC default as-is to make flow control "opt in" as requested. It looks like flow control is off by default and it's opt-in; what did I miss? Thanks! Martí Thanks,
|
|
|
|
Re: SAMC21 support and subscribe to zephyr development lists.
Michael Hope
Hi Romin. There's more information about the devel@ list at https://lists.zephyrproject.org/g/devel including instructions on how to subscribe.
toggle quoted messageShow quoted text
re: the SAMC21, I haven't been involved with the SAM0 work in a while but I also haven't heard of anyone working on that particular family. The SAM0 series is interesting as the families are all similar but slightly incompatible - it should be straight forward for you to add support and adapt the drivers but it's hard to say without diving in! -- Michael ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, May 6th, 2021 at 7:01 PM, Romin Gajjar <rominzephyr@...> wrote:
Hello Zephyr Development Team,
|
|
|
|
Re: Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 13 May 2021
#cal-cancelled
Kumar Gala
Canceling this week due to several things:
toggle quoted messageShow quoted text
* I had some last minute meetings that I need to join this week and can’t attend/run the meeting * Various people have holidays this week, so wasn’t able to coordinate a replacement * I know we had a topic around the Flash APIs we planned to discuss. I’ll move this to next week * Let people focus a bit more on bugs to help reduce our bug count this week thanks - k
On May 12, 2021, at 5:51 PM, devel@... Calendar <noreply@...> wrote:
|
|
|
|
Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 13 May 2021
#cal-cancelled
devel@lists.zephyrproject.org Calendar <noreply@...>
Cancelled: Zephyr Project: Dev Meeting This event has been cancelled. When: Where: Organizer: devel@... Description: ________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
________________________________________________________________________________
|
|
|
|
Changing default branch name on GitHub - action required
Kumar Gala
We will be changing the default branch on github from 'master' to 'main' on Friday (May 14, 2021).
There is no action required for any open PRs, however you'll need to update your local git clone as follows: git branch -m master main git fetch origin git branch -u origin/main main You'll need to be utilizing at least west 0.10.1 or later. Will announce here when this change is made on Friday. I’ve also opened this GitHub discussion on this topic as well: https://github.com/zephyrproject-rtos/zephyr/discussions/35230 thanks - k
|
|
|
|
Re: SAMC21 support and subscribe to zephyr development lists.
rominzephyr@...
Hi a quick reminder is there any support or development happening? Please, I am need of some direction or help from anyone who has done something similar in zephyr. Yours sincerely, Romin
|
|
|
|
Re: using low level sensor drivers directly, without sensor API
Martin Schröder
Hi Rudolph, If you want to configure FIFO it would make the most sense to do so in the adxl driver. So just modify the driver, perhaps add a boolean dts option for the functionality and then create a pull request to get that functionality accepted into and managed by the main project.
On Mon, 10 May 2021 at 15:12, Rudolph Aschmoneit <rudolph.aschmoneit@...> wrote:
--
Best regards, Martin Schröder Consultant
|
|
|
|
Review of concept of changing UART flow control from Kconfig to DTS config
lairdjm
Hi, I only noticed today that the Kconfig option for enabling hardware flow control on UARTs, which used to be an optional Kconfig option, was removed and replaced with a DTS boards file configuration option instead, as per https://github.com/zephyrproject-rtos/zephyr/pull/25999 I find this to be a bit of a step backwards for application development, we have many boards in zephyr that we and customers use, these boards might be used for something simple like a sensor or might be used alongside a PC for doing some heavy processing and message passing over Bluetooth, so with a sensor, the log system might be active but it won’t have anything connected to it most of the time unless there’s an issue, so flow control is not required here, if it’s enabled then it’s going to cause an issue once the UART buffer gets full. However, on a PC communications module, that would be using the UART constantly, and need data integrity so needs flow control – in the old system, the boards file would have the flow control pins and it would be disabled by default, a project could enable it with a Kconfig option, this was great. However with the new system, it seems that we need to force flow control on all our boards, and then in instances where it’s not needed, have an overlay for that specific board (and we have many boards) to delete the hardware flow control part. This means that to enable hardware flow control, we need to update our boards file then add an overlay to almost every sample application in zephyr for most of our boards to disable flow control. This seems a bit chaotic to me so I would like to revisit this concept of having flow control configurable as a Kconfig option, the pins should be defined in the DTS file which hasn’t changed but if flow control is needed or not should be controlled on a project basis, opt in not opt out.
Are there any thoughts on this subject and how to get this working, focused on ease of being able to set this for ours and customer’s reuse? Thanks, Jamie
|
|
|
|
Re: using low level sensor drivers directly, without sensor API
Rudolph,
With the Zephyr project being open source, if you would find it useful for someone in the future to access this functionality you should raise either a RFC or PR in the GitHub. You should find the community fairly helpful in appraising and assisting with making changes. Billy..
|
|
|
|
Zephyr Project: APIs - Tue, 05/11/2021 4:00pm-5:00pm, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: APIs When: Tuesday, 11 May 2021, 4:00pm to 5:00pm, (GMT+00:00) UTC Where:Microsoft Teams Meeting An RSVP is requested. Click here to RSVP Organizer: devel@... Description: Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18 ________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
________________________________________________________________________________
|
|
|
|
API meeting: agenda
Carles Cufi
Hi all,
Items for today: - hwinfo: Add a reset cause - https://github.com/zephyrproject-rtos/zephyr/pull/24884 - Pinctrl - Issue: https://github.com/zephyrproject-rtos/zephyr/issues/22748 - Discussion: https://github.com/zephyrproject-rtos/zephyr/discussions/35077 - Issue triaging, time permitting. If you have additional items please let me know. Teams link: https://teams.microsoft.com/l/meetup-join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d https://lists.zephyrproject.org/g/devel/calendar https://github.com/zephyrproject-rtos/zephyr/projects/18 Minutes: https://github.com/zephyrproject-rtos/zephyr/issues/33641 Regards, Carles
|
|
|