Hi, I had set up all the dev libaries, SDK and downloaded required files ( https://www.zephyrproject.org/doc/board/galileo.html ). but under $ZEPHYR_BASE directory when I did make BOARD=galileo it

Hi, I had set up all the dev libaries, SDK and downloaded required files ( https://www.zephyrproject.org/doc/board/galileo.html ). but under $ZEPHYR_BASE directory when I did make BOARD=galileo it

Hi, I had set up all the dev libaries, SDK and downloaded required files ( https://www.zephyrproject.org/doc/board/galileo.html ). but under $ZEPHYR_BASE directory when I did make BOARD=galileo it

This should work. We need to rework some of the drivers as they make the driver_api assignment unconditionally. ---------- Daniel Leung

Sure.

You are right, this will not break existing code. Nevertheless, we should track such API changes and document them in release notes. Anas >

We're just returning a thread ID when we start a fiber now, you can ignore it. I don't see an issue here...

Ugh, you're right, it's a nano_thread_id_t.

Hi Anas, Quoting Nashif, Anas (2016-02-19 14:07:36) Yes, I agree. I'm not a gerrit expert but from I could understand, this is related to the 'forge author' settings from submitter rights. I'm CCing

How about something like this: diff --git a/kernel/nanokernel/device.c b/kernel/nanokernel/device.c index f86f95f..82774c4 100644 --- a/kernel/nanokernel/device.c +++ b/kernel/nanokernel/device.c @@

Makes sense but why not tell the compiler the truth about the type?

Thanks for documenting this but I don't think forcing people to use git-review is the right approach. It worked for us before in many other projects, why is this different and why can't I use vanilla

Sounds good, but we need to do it in away that keeps APIs compatible I guess. Anas

Looks like it. You want to do the implementation yourself Jukka ?

What I was proposing in my last reply, too keep things simple, is one Kconfig option to enable/disable handling of error codes by init functions. If it's disabled, nothing is handled automatically and

Hi Joakim, I have not measured this. At the moment the IP stack is configured to have separate TX and RX buffers. So in minimal configuration there would be one TX and one RX buffer vs. in Contiki

Hi Jukka! Ok, yes - I expected that there would be quite som changes. But I guess that they will be the same changes at each sync! I will take a look at the codebase and see how much differences you

Hi, No comments -> no objects -> perhaps we can continue with this route then? Cheers, Jukka

Hi Joakim, The plan is to sync it from Contiki when applicable. If you look the code, we needed to make lot of changes to uIP stack in order to make it work in Zephyr. The biggest change is that the

that worked - thanks Ben! Ravi