Cancelled: Zephyr Project: APIs This event has been cancelled. When: Tuesday, December 28, 2021 9:00am to 10:00am (UTC-08:00) America/Los Angeles Where: Microsoft Teams Meeting Organizer:

Cancelled: Zephyr Project: APIs This event has been cancelled. When: Tuesday, December 21, 2021 9:00am to 10:00am (UTC-08:00) America/Los Angeles Where: Microsoft Teams Meeting Organizer:

Cancelled: Zephyr Project: APIs This event has been cancelled. When: Tuesday, December 14, 2021 9:00am to 10:00am (UTC-08:00) America/Los Angeles Where: Microsoft Teams Meeting Organizer:

Hi Nazar, Correct me, the requirement is to be able to use Vendor HCI command/Response on `bt_enable()` after a HCI device is open but before the `bt_init()`. to be able to handle asynchronous

Well if code quality is truly the only goal of the steering committee and there's no politics involved then I retract everything I said. Misra offers less than nothing for this project. But I don't

I'd like make clear once and for all that the happiness of scanning tool is *never* a valuable purpose under a MISRA perspective. What matter is *only* the quality of code and MISRA is a tool to

Daimler and Volvo are relying on Linux already in many unsuspected ways. Yet, the Linux community has vehemently rejected many of the "best practice" mantras taught by academia and sought by the

HiJohan, Thank you for your quick response. I will open a new enhancement request for this. Regards, Nazar

Hopefully most people in the community agree that many, if not most, Misra rules are outdated or even slightly harmful. But you optimize with the constraint being the way the world works, not how it

I find this discussion extremely interesting. I don't come from a linux background. I historically have worked with MCU's in a bare metal or conventional rtos context. While I'm not one to be a MISRA

Significant community backing won't come about if the project blindly adopts obnoxious rules, especially with some of them having little intrinsic value, just to let a few brag certification

"I figure that that the MISRA-C changes are an attempt to step in the direction to having a version of Zephyr that is or can be certified." And that is what is being watched by those with

Hi Nazar, Adding such a feature to the Bluetooth stack sounds like a good idea, but I suspect we need to discuss a bit whether it should be a host extension using a __weak function, an extension

Hi Nicolas, Just a note that the project is not seeking MISRA compliance, we only looking at complying with our own published coding guidelines (which is a subset of MISRA). When we adopted the

I figure that that the MISRA-C changes are an attempt to step in the direction to having a version of Zephyr that is or can be certified. I've been involved in the certification process (DO-178C,

Zephyr: Toolchain Working Group When: 12/13/2021 8:00am to 9:00am (UTC-08:00) America/Los Angeles Where: Microsoft Teams Meeting Organizer: Torsten Rasmussen Description: Live meeting

Reminder: Zephyr: Toolchain Working Group When: 12/13/2021 8:00am to 9:00am (UTC-08:00) America/Los Angeles Where: Microsoft Teams Meeting Organizer: Torsten Rasmussen An RSVP is requested.

Hello Devel team, My name is Nazar. I am working for Infineon in the SW integration team. Currently, I am working on the integration of our CYW43xxx connectivity device into Zephyr (PSoC 6

That's certainly better. And this provides you with the opportunity to document the reason for such a macro alongside its definition. Well, you aren't preventing any wrapping by adding a bunch of

I started to question a bunch of the choices in the early PRs, but it was moot. I also got the impression that the mess they are creating now with the enormous amount of obfuscating casting