On quarta-feira, 3 de agosto de 2016 11:22:44 PDT Hudo Assen?o wrote: > Hi Thiago, > > First of all, this looks very promising. Good to see that we have options > for constrained devices.
Hello Hudo Happy to be of help. > > Q: what OSes does it support? > > > > Currently, it supports Zephyr (https://zephyrproject.org) primarily. It > > can > > also be compiled on Linux, but that should be seen as a tool to ease > > development, rather than a real target. > > > > Porting it to different OSes should be possible. We're considering whether > > to port to Contiki and/or RIoT, but we have no plans at this moment to do > > so. We welcome contributions in that area. > > How easy is it to port to a bare metal device? or something like FreeRTOS? I > think the majority of constrained devices, runs on bare metal. Porting to FreeRTOS should be reasonably acceptable task. I won't say it's easy, especially the first port after Zephyr, but it's definitely not immense. The code was designed so that it needed little from the OS. The biggest thing is the connectivity itself, for which there's a simple abstraction layer. You just have to write the code that sends a packet to a given destination and, when packets arrive, calls back into the processing. (ok, slightly more complex than that) I don't consider "bare metal" a valid distinction from Zephyr and FreeRTOS at this level. You need something that handles interrupts, scheduling of tasks (timers) and some kind of storage for the configuration parameters. Most importantly, you need an IPv6 stack and a radio stack. If you put all of that together, you've got an OS. That's what Zephyr is at this level. If you want to strike out on your own and just use the board's library of I/O functions, you're welcome to. I don't advise doing that: integrating an IPv6 stack is not easy. You'll be better off choosing Zephyr, Contiki, RIoT, mBed, or FreeRTOS as your starting point. > Other thing that I was thinking about was the Thread network protocol. This > might be a stupid question as the thread is a network protocol and iotivity > is an application protocol but how easy would it be to use the this network > protocol in your implementation? In theory, like you said, they should complement each other and not step on each other's toes. The protocols operate on different UDP port numbers, on different multicast addresses. The commonality is restricted to both using CoAP as their transport protocol, and that only applies to part of Thread's management and control messages (they have one other for the other part). In practice, we have yet to try to see if there's anything we may have missed. But it's definitely in our radar: Thread is very important to us. See this week's announcement: https://openconnectivity.org/press-releases/thread-group-open-connectivity-foundation-create-liaison-agreement-increase-application-connectivity-choice-connected-home http://threadgroup.org/news-events/press-releases/ID/113/The-Thread-Group-and-Open-Connectivity-Foundation-Create-Liaison-Agreement-to-Increase-Application-Connectivity-and-Choice-in-Connected-Home -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
