Hi, Following Ramesh and Ku-Lang's feedbacks we have split the changes to multiple small patches(instead of the original delivery). Note: Due to the fact that the drivers changes depends on the

See https://gerrit.zephyrproject.org/r/4160 for the maintainers. Anas

Which reminds me to ask... who _are_ the ARM maintainers and how do we find out such things given that the MAINTAINERS file in the source tree is somewhat deficient in coverage? -- Tixy

Hello See also https://jira.zephyrproject.org/browse/ZEP-188 Agree There is support for real hardware,

No objection from me. Sounds reasonable to me as well. I'd like to hear from the ARM maintainers to get their opinion too. Cheers, Ben

NEW JIRA items within last 24 hours: 2 [ZEP-713] Implement preemptible regular IRQs on ARC https://jira.zephyrproject.org/browse/ZEP-713 [ZEP-711] I2c: fails to write with mode fast plus

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/4127 : WDT: remote duplicated wdt clock enable code - https://gerrit.zephyrproject.org/r/4136 : Bluetooth: Fix race condition between

Hello, Taking a chance, I'd like to start with drawing attention to https://jira.zephyrproject.org/browse/ZEP-687 "docs: Subsystems/Networking section is almost empty". Zephyr networking information

Hello Rohit, Rohit Grover <Rohit.Grover(a)arm.com> wrote: There's already TCP support in samples/net/echo_server , you just need to build it with CONFIG_NETWORKING_WITH_TCP=y . While waiting

Sounds reasonable to me. (I'm new around here though, so don't count that as anything other than a random opinion ;-) My main thought was that boards/SoCs select a CPU type which then selects the

It's definitely not an option to always build choices in at compile time for each board, as there could be thousands or even millions of instances of a particular target board in the IoT space. Being

Did not expect this to generate such a big discussion. Here is a use case in addition to what was mentioned in the thread below. Think of this API as a helper API for higher lever features and not a

TIxy, I am thinking either, CPU_HAS_BASEPRI or ARCH_HAS_BASEPRI. I also want to add an ARCH_ARMV6, V7 etc to handle architecture specific code. We still need the more specific CPU_CORTEX_M0PLUS, 3,

Yes, calling the test case repeatedly isn't important, and may even complicate things. Given than threads can yield/block, this should be easy to abstract into the framework. I would also like to

Hello, Thanks for the feedback and suggestions! I believe the framework can be extended to provide support for asynchronous testing. An assertion function which either blocks until a

Hello Community, Thanks for introducing a test framework. It seems that this proposed test framework only deals with synchronous test execution. It is fine for a start, but this may prove to be a

Hello, I now implemented an initial version of a framework, and I submitted it at https://gerrit.zephyrproject.org/r/#/c/4118/ While developing, it became apparent that the current testing stack

Hi Euan, I was looking at what would take to get Zephyr to support Cortex-M0 today (wanted to port Zephyr to nRF51), and found your thread :-) Are you expecting to open source/upstream your Cortex

NEW JIRA items within last 24 hours: 6 [ZEP-702] Integrate Nordic's Phoenix Link Layer into Zephyr https://jira.zephyrproject.org/browse/ZEP-702 [ZEP-706] cannot set debug breakpoints on ARC

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/4111 : usb: Add USB sample build test to sanity check - https://gerrit.zephyrproject.org/r/4106 : ipm_console: rate-limit to avoid