And if connected to HW, should it be enabled and clocked? Linux uses mix of Kconfig/dt. Kconfig for compilation/dt for activation. Do we want the same in Zephyr and keep these 2 levels of

Some changes are coming in to convert host build tools like gen_idt and gen_offset_header to Python, as well as some new tools to support memory protection which involve parsing DWARF information in

OK, so it sounds like these DT changes aren't expressing expectations about the state of the peripheral. But based on David's response, it does seem like it matters to Zephyr what state the

The enabled property doesn't describe whether the peripheral is active or not at bootloader handover. It is more like whether that peripheral is connected to something useful. DT describes the

I don't think so. Part of the definition of the bootloader needs to be to describe what state it leaves things in. For most compatibility, it would seem best to leave things in as close to

Hi, David's threads didn't get much response, but while looking at some STM32 rework in Zephyr, I thought it was worth another try. I especially want to highlight this part: ^^ Erwan, I noticed while

Hi All, I'll be happy to follow your work on F0, I'll like to target the F051 from the F0x1 family. Thanks, Neil

Dear All, I am currently working on a 4G(LTE) Networking task, Then I turned to zephyr to try to set it as a beginning. The Internet articles told me it supports 3GPP protocols but I didn't find

Dear All, I am currently working on a 4G(LTE) Networking task, Then I turned to zephyr to try to set it as a beginning. The Internet articles told me it supports 3GPP protocols but I didn't find

Dear all, I installed the SDK on Ubuntu 16.04 64bit system today, it's OK. So, I guess there is something wrong in the installing script of "zephyr-sdk-0.9.1-setup.run" Or the tools(x86, arm, arc....)

Hi all, I'm currently working on a pull request to introduce a Lightweight Machine-to-Machine (LwM2M) library to Zephyr. If you are interested, please

Hello, David Brown <david.brown@...> wrote: I recently hit a case when I needed to run Zephyr SDK on 32-bit system and of course, it was a rather unpleasant surprise to remember that I can't.

The SDK is indeed built for 64 bit systems. It could be built for a 32-bit host, although I don't think there has been that much demand for it. David

Dear All I got a trouble when installing zephyr SDK on Ubuntu 16.04.2 desktop i386 (32 bit) I followed the instructions exactly on page

OK I'll look into that to see how it fits my needs (and if it isn't to much more work how it would fit other ppl's needs). I am not sure if that is the right way to go for resource constraint systems

Hi Erwin, We could follow the same idea as IEEE 802.15.4 radio API is doing. So each CAN hw driver would need to provide a set of function pointers to do various CAN operations. See

Hallo all, I am working on a CAN driver for STM32F4 and am having a few conceptual problems. How to generalize the interface to hardware that can be very different. For example the

The Zephyr Technical Steering Committee (TSC) has not yet made a decision on whether GitHub Issues will be eventually used for issue tracking instead of Jira. Because of that the Issues feature of

Hello Andrew, "Boie, Andrew P" <andrew.p.boie@...> wrote: It would be interesting to ask someone who posted a first bug on Github why they did that. But I'd imagine the answer would be "The

Why were bugs being filed on Github instead of JIRA? Having two simultaneous bug tracking systems in use seems insane to me. Andrew