Hi, Enforcing "zephyr," suffix is a great idea given that software config is allowed in the dts - the one grievance I have is that using dts overlays for configuration purposes isn't great UX. It's no

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 be

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 s

Thanks for the info Mike. Queueing mode seems like it would resolve some worries, but would you mind clarifying one thing? From the issue: Wake up before lifetime or observation (if any) expires Seems

To be honest, it sort of seems as if the implementation assumes it has a perpetually open socket connection to cloud at all times. Perhaps this is an exaggeration, but I'd kind of like to know how (if

Hi, We have a use-case which I deem to be pretty normal: uplinks are really expensive and should be kept to a minimum (in fact, we want the radio completely powered off 99.99% of the time). But we hav

Hey, I seem to recall this mentioned in the documentation, but now I can't find it anywhere. What are the ramifications/constraints of relying upon a 64 bit k_uptime_get if one wants to avoid the 55 d

Hey Pawel, I noticed `int usb_dc_ep_set_callback(const u8_t ep, const usb_dc_ep_callback cb);` in `usb_dc.h`, but using them doesn't sound so stable to me. Since `usb_dc_ep_set_callback` actually *ove

Hi, Going through the APIs today looking for a public function for discerning if we are connected to something (i.e. we are supplied by VBUS) but I couldn't find anything. There is some internal API a

Hi Arun, The NCP should probably not be high in the list of priorities - I doubt it makes a huge difference for the infrastructure that the NCP was compiled from some Nordic SDK or whatever. This is j

Thanks, I really appreciate the response and especially the PR reference. Will check it out.

Hi, I've verified basic OT functionality using the echo_client/server samples with the openthread overlays. That's nice, but it's not obvious to me how I proceed after this. A few things that had me c

It's not easy to comment on what caused the usage fault without knowing what code is actually running on the device.

You need to add the bme280 to your device tree file. Something like: &i2c0 { bme280@76 { compatible = "bosch,bme280"; label = "BME280"; reg = <0x76>; }; };

If the feature isn't horribly misimplemented, does what is expected of it and is expected to have very little maintenance costs, why drop it? I haven't used the feature, but I can definitely picture a

Hey, I've been trying to build the mcumgr/smp_svr sample on a nRF52840 DK (pca10056) by following https://docs.zephyrproject.org/latest/samples/subsys/mgmt/mcumgr/smp_svr/README.html, using Zephyr v1.

Hi Robert, Thanks for a quick response :) I don't have a strong preference regarding lazy handshaking, it's probably better the way you implemented it - I'd recommend elaborating the source code comme

First, regarding delayed handshakes. In sockets_tls.c: if (net_context_get_type(ctx) == SOCK_STREAM) { /* Do the handshake for TLS, not DTLS. */ This had our scratching our heads for a while today bec

Lol. Mistyped again -- to clarify, I definitely mean checkstack.pl and not checkpatch.pl, if anyone did not extrapolate successfully Den ons 28 nov. 2018 kl 13:10 skrev Benjamin Lindqvist <benjamin.li

Hi, I wanted to try out scripts/checkstack.pl and verified that it actually works on a vmlinux image by arm-none-eabi-objdump -d vmlinux | zephyr/scripts/checkpatch.pl arm but when I do it on build/ze