Hi,

me and Paul brought in constrained iotivity stack few months back
to Mynewt, and I probably should send an update what’s going on.

I’ve been working on getting it more fully integrated. My first
goal is to get the code size/RAM usage down.

To cut down code size I’m converting it to use MyNewt’s memory pools,
timers, and event queues. By default we also left quite a bit logging
turned on, so I’ll make that optional (inclusion controlled by syscfg
settings).
To cut down RAM use I’m going to convert it to use os_mbuf for
data packets. This will probably make code size slightly larger,
but allows me to share the memory pool with bluetooth stack.

My end goal is to have OIC running over bluetooth in a way which
allows us to connect to apps written using iotivity’s framework
https://github.com/iotivity/iotivity <https://github.com/iotivity/iotivity>.
I'm quite interested in this from a sensor driver point of view. I have no experience with iotivity, but if it will be a core part of Mynewt moving forward, it would be good to get a sense of what kinds of requirements the stack would place on sensors and sensor configuration, since that's the area I'm most likely to get involved with on my end.

- Are there specific config mechanisms that should be kept in mind?
- Are there any definitions about power mode and device/driver 'state'?
- What are the practical payload limitations given BLE as a transport?

It's too early to probably answer a lot of those things definitively, but it would be good to get the ball rolling as we start throwing some ideas around publicly about a sensor API as well.

Kevin

Reply via email to