<jukka.rissanen@...> wrote: We should understand the code size implication of that decision before changing the out of box behaviour. Another option might be to have a test compile run aga

Casting pointers to and from integers is legal, but implementation defined (c99 6.3.2.3 p5 p6). We should avoid implementation defined behaviour in the language where possible, especially in public AP

Hi, Can anyone add some insight on this issue? The code looks to me as if net_if_up/down() were originally added to provide an enable/disable semantic, but we have BT using them in what appears to be

Hi, The network interface patches proposed as a result of this thread have generated a fair amount of discussion both in patch reviews and in IRC. Now would seem like a good time to summarize where we

Hi, I raised https://jira.zephyrproject.org/browse/INF-119 which is currently assigned to Inaky. Cheers /Marcus

Hi Luiz My last set of comments in gerrit and this RFC crossed, I'll repost my comments here in the thread: This seems reasonable. It would be good to choose names that more clearly articulate the TRN

Folks, We don't appear to have had any daily gerrit digests since 7/3/2017. Does anyone know what this issue is? Cheers /Marcus

Ok, I have it running now, I swapped microbits. It appears I have 3 microbits on which it works and 1 microbit on which it doesn't work. Thank you both for your help. Cheers /Marcus

Interesting. I can still build various other samples and flash them to the microbit and they run just fine. I used a microbit fairly extensively a while back when putting together drivers for its I2C,

Hi, I've just tried samples/bluetooth/eddystone on nrf51 (bbc_microbit) and so far as I can tell it doesn't boot as far as main(). Same experiment on nrf52 (pca10040) runs just fine. Is edddystone exp

The toplevel Makefile hardwires: -D__ZEPHYR__=1 I don't know if that symbol is documented somewhere, but it would be nice if it was. Cheers /Marcus

An interface always gets an address, hence I think that for both static and DHCP cases the following would work: <wait on semaphore signaled by a NET_EVENT_IPV4_ADDR_ADD callback > Cheers /Marcus

Hi Is it important to distinguish how the address was acquired? /Marcus

Hi, I've just hit an issue with gerrit, can anyone help... I pushed a series of 5 related patches into gerrit for review on the net branch. The top two of those patches subsequently needed some minor

PRI is *the* solution, stop trying to paddle against the current ;-) Cheers /Marcus

<jukka.rissanen@...> wrote: We do however still need to figure out, for udp, how to prevent: - rx path starving tx path to dead lock - multiple tx paths deadlocking (by attempting to acqui

Can you raise a JIRA issue and add some details of the failure you are seeing ? Thanks /Marcus

<luiz.dentz@...> wrote: Indeed the echo server could perhaps be optimized not to deep copy thus removing the issue. The wider question here is whether or not we want a design rule that effective

Hi, This evening I took a look at how we might better integrate dhcpv4 into the platform. In the current tree, in order to use dhcp the application is expected to start the dhcp client explicitly. The

<jukka.rissanen@...> wrote: Running out of resources is bad, dead lock, especially undetected deadlock, is worse. Avoiding the dead lock where the RX path starves the rest of the system of