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

Inspired by the printf discussion last week and no one's explicit rejection of a quick code-size-reduction patch I threw out, I spent a little more time in the minimal libc printf implementation,

The way I know looks like this: grep INIT_PRIORITY outdir/.config CONFIG_KERNEL_INIT_PRIORITY_DEFAULT is usually the highest usable priority, CONFIG_KERNEL_INIT_PRIORITY_DEVICE is the priority that

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/4089 : Bluetooth: Controller: A full, hardware-agnostic Link Layer implementation - https://gerrit.zephyrproject.org/r/4090 :

Hi all, We have just posted an initial port of Vinayak Chettimada's BLE Link Layer implementation (internally known as Phoenix) to Gerrit. This is currently functional on nRF5x devices (nRF52 only

Hi all, The corresponding Gerrit link: https://gerrit.zephyrproject.org/r/4081

Hi all, After reviewing all the comments and consulting Ramesh, below is the updated RFC: Current state =========== In the current Zephyr implementation the driver power hooks distinguish only

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: 1 [ZEP-327] (Fixed)

NEW within last 24 hours: UPDATED within last 24 hours: MERGED within last 24 hours:

Hi All, I know that devices' initialization sequence is dertermined by its level and priority, but it's difficult to peek those information in enormous code, especially many devices are

Out of curiosity, why do you want to read the ReST files directly instead of the nicely formatted and indexed documentation posted online at https://www.zephyrproject.org/doc/ ?

Hello All New RC tagged. Thank you for your contributions-we are getting closer to a release, with 48 new fixes Please remember for rc3 to keep it only for fixes; please consider: - If your