Hi Eric, Assuming you've installed the SDK, you need to set ZEPHYR_GCC_VARIANT. You can do this in ~/.zephyrrc, which is sourced by zephyr-env.sh: $ cat .zephyrrc export

I apologize if this forum is the wrong place to post this question, I was not sure where else to post. I am attempting to build the zephyr nanokernel with the Galileo board. I am following the steps

Hi, Preference is to keep the most essential parts for building a basic Zephyr application on a specific board self-contained without external dependencies. Anas

NEW JIRA items within last 24 hours: 3 [ZEP-205] Fail to enable udp loopback for ipv4 https://jira.zephyrproject.org/browse/ZEP-205 [ZEP-207] Fail to have both ipv6 and ipv4 capability in

How about keeping the library/headers external and passing their location in Kconfig? Similar to what buildroot does with external kernel/toolchains. Is that acceptable too? Cheers, -- Maciek

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/1521 : qmsi: use QMSI_LIBRARY instead of QMSI_DRIVERS - https://gerrit.zephyrproject.org/r/1523 : spi: revert changes to API -

Hi, Any files or headers included from an external project that need to be kept in sync with upstream can keep their style and formatting to allow updates in the future. This was the approach taken

Hi Szymon, Actually this is due to printf usage in BT_ERR when smp_timeout is called, something that perhaps we should not account in the system wide timer and perhaps just stick with 128 bytes which

From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> This replaces use of delayed fiber with sys_timer which shares a common fiber and stack with other timers. Change-Id:

From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> This adds a timer fiber which can be used track timeouts removing the need to use one delayed fiber per timeout. Change-Id:

From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> So at this point it works properly, I tested what could be the minimal stack necessary in order to run the timer queue and arrive at 512

Hi there, We are working on a port to a new ARM SoC family (Nordic nRF5X) and are wondering about a couple of things. There has been some discussion lately on whether to use the ARM CMSIS header

Hi Luiz, This is something that will likely be common case (at least in networking) so maybe we could have bt_timer_restart()? We could have helpers like bt_timer_active/running() etc. Especially

Hi Luiz, I think it would be better to have kconfig option for callback needed stack and add overhead internally. This should be easier to estimate for user. -- BR Szymon Janc

Hi Luiz, I don't get this why you need 512bytes if only 128 was needed by SMP. This should mostly depend on how heavy is the callback, right? Is overhead for queue that big? -- BR Szymon Janc

Hi Jukka, <jukka.rissanen(a)linux.intel.com> wrote: Sure, this was just a little bit more convenient to show how it could be implemented, etc. I guess this one will actually end up as

Hi Luiz, Could we make the timer more generic from day one as this can be used quite easily by IP sub-system. So the config could be placed to net/Kconfig already. Why do we need to store the stack

NEW JIRA items within last 24 hours: 0 UPDATED JIRA items within last 24 hours: 0 CLOSED JIRA items within last 24 hours: 0 RESOLVED JIRA items within last 24 hours: 0

From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> This replaces use of delayed fiber with bt_timer which uses a common fiber and stack with other timers used by the stack. Change-Id:

From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> This adds BLUETOOTH_DEBUG_TIMER which can be used to enable debug for the bt_timer related APIs. Change-Id: