Hi all, I am working on a project where we will need to use CANopen on top of the SocketCAN driver layer in Zephyr. I have found two references to CANopen on Zephyr so far: -

Hi Ivan, I have successfully tried Zephyr with C++ library (eRPC) some time ago. The version of Zephyr was based on master branch as of March 19th. However: I haven't used zephyr-sdk, I used

Ivan, I would suggest you to not use C++. I am facing a lot of compatibility issues and some drivers (like Bluetooth) will not work in C++. C is the only truly viable option. Go for it. Zephyr in C

Hello. I was wondering how to investigate the state of things around incompatibility of the level of C++ support, required to compile these bindings for ZeroMQ: http://zeromq.org/docs:core-api . But

Reminder: Zephyr Project: Dev Meeting When: Thursday, 23 May 2019, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles Where:https://zoom.us/j/993312203 An RSVP is requested. Click here to

Hi, The first HAL (QMSI) was removed from the tree and the west manifest has been updated. Please make sure you run `west update` to update your trees. Anas

Hi, Most of you already use the west tool for various things already, including building, flashing, signing and other common operations. One of the main reasons west was introduced was to support

That's coming! But that's the easy part. Making core Zephyr 64-bit clean is the bulk of the work. That's wonderful! Go figure why I didn't find it when looking exactly for such a thing.

Hi Nicholas! I for one am definitely excited about a 64-bit RISC-V port of Zephyr! You might be interested in this tool from GitHub called ‘hub’: https://hub.github.com/ It provides a command-line

Hello, This is my first post here, however it probably won't be the last. For a while I've been working on making Zephyr to compile for and run on 64-bit targets. That currently works with the

Qipeng, You should be posting to the devel@ mailing list instead. To answer your question, this is not supported in zephyr. Anas From:<builds@...> on behalf of "Zha, Qipeng"

Reminder: Zephyr Project: APIs When: Tuesday, 21 May 2019, 9:00am to 10:00am, (GMT-07:00) America/Los Angeles Where:https://zoom.us/j/177647878 An RSVP is requested. Click here to

Why must we support high-speed deferred logging of C strings? Really what is this use-case so compelling that we have to leave sharp edges to developers like this? Is there precedent for this in other

Hi, Logger was redesigned to work in deferred mode (string processing and transport deferred to idle stage) to be capable of handling multiple backends and to be less intrusive than standard in-place

There's a violation of the "Least Astonishment" principle but it's not with the '%s'. The '%s' traditionally refers to the type of the argument only, it says nothing about memory management. I don't

On Fri, May 17, 2019 at 04:24 PM, Boie, Andrew P wrote: For an operating system that aims to support various functional safety certifications, asynchronous rendering of %s is a terrible idea. It

Hello, "lairdjm" <jamie.mccrae@...> wrote: Opinions vary on that matter, some people think that the logging was actually "regressed" and not "improved". Literally, it became

Hello, "Boie, Andrew P" <andrew.p.boie@...> wrote: Some people think that asynchronous logging, forced on unsuspecting users, is pretty bad idea and make bets when CONFIG_LOG_IMMEDIATE

Such a "sharp tool" should at least not look exactly like the slow but safe version used absolutely everywhere else. http://www.catb.org/~esr/writings/taouu/html/ch01s03.html#rule-surprise On the

Hi, I think what confused me is that I was reading about the ‘improved logging’ from this guide:https://foundries.io/insights/2018/08/14/zephyr-logging-part-2/ which doesn’t mention anything