Hi, Szymon Janc <szymon.janc@...> writes: Adding the warnings, I think, is the best way forward. Keeping the checks after the NULL pointer is accessed gains us little, we are already in undefi

Hi Wojtek, "Bober, Wojciech" <Wojciech.Bober(a)nordicsemi.no> writes: There are still some bugs in the implementation, I am working on solving them, I just noticed it when I was running a CoAP test su

Hi, Marcus Shawcroft <marcus.shawcroft(a)gmail.com> writes: I agree that this has a cost in repeated code. Just a little background: when I wrote sol-coap, for the Soletta project, I took the opposite

Hi, Marcus Shawcroft <marcus.shawcroft(a)gmail.com> writes: The plan is that the error handling would live in the layer above. So yeah, the zoap-server sample right now is lacking in the invalid messa

Hi, Euan Mutch <euan.mutch(a)gmail.com> writes: Licensing issues perhaps[1]? "Disclaimer and Credits ... 4. This software may only be redistributed and used in connection with an Atmel microcontroller

Hi Johan, Johan Hedberg <johan.hedberg(a)intel.com> writes: I had some plans that this could be used in other places, but I am not opposed to make this Zephyr specific, and use net_buf (for example) i

Hi, Vinicius Costa Gomes <vinicius.gomes(a)intel.com> writes: The public accessible address is: http://git.infradead.org/users/vcgomes/quapi.git Cheers, -- Vinicius

Hi, Extracted from: https://gerrit.zephyrproject.org/r/#/c/2487/ --8<---------------cut here---------------start------------->8--- Quapi[1] - Basic CoAP for Zephyr ################################ CoA

Hi Anas, "Nashif, Anas" <anas.nashif(a)intel.com> writes: +1 Just for reference the Rust[1] project has a similar concept, and it's been working for some time, it may give a few ideas: https://github.

Hi Jukka, Jukka Rissanen <jukka.rissanen(a)linux.intel.com> writes: At least from Soletta side, what I feel is lacking from the Zephyr network stack API-wise is this: - net_writeto(struct net_context

Hi, "Thomas, Ramesh" <ramesh.thomas(a)intel.com> writes: Ah, I see. Thanks. Cheers, -- Vinicius

Hi, "Thomas, Ramesh" <ramesh.thomas(a)intel.com> writes: I am thinking about the case when DEV_BUSY is returned, I am considering this would happen, for example, in the SPI case when there's a transfe

Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> writes: I am just wondering that in the "old" API '_port_enable_callback()' was a way to have the callback called with the pins expressed in a bit

Hi, Sorry if I am a little too late. Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> writes: Another issue of the current API is the confusion caused by 'gpio_port_enable_callback()' and 'gpio_p

Hi, Dmitriy Korovkin <dmitriy.korovkin(a)windriver.com> writes: Exactly, from what I can see, it will be only one common function. I see. I wouldn't like that these _priv.{c,h} idiom would become the

Hi Dmitriy, Dmitriy Korovkin <dmitriy.korovkin(a)windriver.com> writes: Good idea, this is going to be useful to see if what I have in mind is aligned with what other's have. This is a rough sketch of

Dirk Brandewie <dirk.j.brandewie(a)intel.com> writes: [...] I already started this. Hoping to have something to show later today or tomorrow. Cheers, -- Vinicius

Hi Dirk, Dirk Brandewie <dirk.j.brandewie(a)intel.com> writes: [...] I like it. The only thing I am thinking about is polluting the drivers/pinmux/ directory when there are more than a couple of board

Hi, "Kalowsky, Daniel" <daniel.kalowsky(a)intel.com> writes: Thanks for the well thought answer.

Hi, (Sorry for the click bait-ish subject) As per Dirk's suggestion moving the discussion on the pinmux model[1][2] to the mailing list. Quoting Dirk: Makes sense. The only thing that may complicate m