Hi, The discussion in this issue https://jira.zephyrproject.org/browse/ZEP-1618 has prompted me to raise this topic in the wider forum. Zephyr has a philosophy of "minimal runtime error checking", it

Hi, The discussion in this issue https://jira.zephyrproject.org/browse/ZEP-1618 has prompted me to raise this topic in the wider forum. Zephyr has a philosophy of "minimal runtime error checking", it

<nicolas.perrenoud(a)geo-satis.com> wrote: Hi, Short term, just remove the two lines in question. I'll talk to Carlesc and the Nordic guys to figure out what the proper solution should be. Cheers /Mar

<marcus.shawcroft(a)gmail.com> wrote: Incidentally, there is work going on in newlib upstream at the moment to provide more flexible support for re-targeting such locking mechanisms in pre-built binar

Newlib has a re-entrancy support/infranstructure that needs porting to the platform in order to get thread safety, I know that such porting work for zephyr is not in upstream newlib, have we done that

Hi! The sensor.h API provides various SENSOR_CHAN_*_ANY channels. The intent of these, and so far as I can see all current use of these ANY channels is to represent a the tuple of all of a group of re

How easily can we feed different -W options to the /ext part of the tree, or is that painful ? Cheers /Marcus

This is not a choice between alternatives. There are two separate decisions here: 1) Do we align minimal C with newlib in order to have consistent breakage in /ext irrespective of the users choice bet

We will likely find either immediately, or with future additions to /ext that each blob of third party code does something different: - Some will use %u for uint32_t - Some will use %lu for uint32_t -

That would be my fault, my example above is missing: #include <inttypes.h> Cheers /Marcus

Since the type is 'uint32_t' rather than 'unsigned' the correct specifier is: PRIu32 e.g. #include <stdint.h> printf("blah %" PRIu32 " more blah", v); Cheers /Marcus

Hi, [Second attempt at responding, my arm email address seems to have triggered a moderator approval, sorry about the duplication for those of you that got a direct reply.] This is because the code is

Hi! I noticed this review fly by: https://gerrit.zephyrproject.org/r/#/c/9982/ Which essentially adjusts a Kconfig to have an SPI driver Kconfig explicitly select a GPIO driver when it needs the GPIO

Hi Bodan, I was just checking that the plan had not changed. Thanks for the update. Cheers /Marcus

Re-send with updated email address for Bogdan...

On 29 November 2016 at 21:54, Davidoaia, Bogdan M <bogdan.m.davidoaia(a)intel.com> wrote: Hi Bodan, > If we want to define specific value types for each channel type, then we might as well have the sa

<tomasz.bursztyka(a)linux.intel.com> wrote: Hi Tomasz, do you want to take ethernet driver changes on the net branch aswell, or should those go to master ? Cheers /Marcus

<tomasz.bursztyka(a)linux.intel.com> wrote: Understood. _low_ _high_ does make sense. Cheers /Marcus

Hi Tomasz, <tomasz.bursztyka(a)linux.intel.com> wrote: The three modes standard, high, disconnected are mutually exclusive hence the proposal to represent them as three values encoded in a two bit fie

An example of the scenario above would be an nrf5 i2c driver that needs to use the nrf5 gpio driver to put the two pins used for clock and data into an open collector mode. Cheers /Marcus