Well, I am the only person working on sensors right now. Writing a device 
driver which works over native is possible if we have hal i2c functions for 
read and write. These functions would return dummy data which won’t really let 
you experiment everything but at the same time let you develop an app which 
returns some dummy data. App in this case can be anything including a test. 
which exercises the sensor api.

Regards,
Vipul Rahane

> On Apr 13, 2017, at 11:10 PM, Jacob Rosenthal <jakerosent...@gmail.com> wrote:
> 
> Yeah, post anything. Sorry I thought sensors and sim was all you.
> 
> Im trying to think about how to work on native instead of device always, how 
> to develop a driver, maybe modify the existing, maybe write tests first....
> 
> Thanks,
> Jacob
> 
> 
> On Thu, Apr 13, 2017 at 10:57 PM, Vipul Rahane <vi...@runtime.io 
> <mailto:vi...@runtime.io>> wrote:
> Hello Jacob,
> 
> Sorry, I had to leave on IRC. Thank you for trying it out. It's great that it 
> worked. I will add the syscfg variable in syscfg defs. Can I pull this 
> conversation on the dev list as I think Sterling might want to add something 
> to this as well since he was the one who initially added sim support for the 
> sensor API.
> 
> In my opinion it is more of an experimental development environment where you 
> get to try out the sensor API using the shell and understand the interaction 
> of the data structures with the code before one jumps to real hardware. 
> Having said that, I feel it is not limited to such a simple use case and can 
> be further modified to add features based on use cases that we might 
> encounter. I used it only for my initial development purposes and later 
> switched to real hardware. That is more fun :-). 
> 
> On the shell, you could try out sensor shell commands, some of them are below:
> - sensor list
> - sensor read <sensor_name> <type> [-n nsamples] [-i poll_itvl(ms)] [-d 
> poll_duration(ms)] (Interval is only supported on real hardware as it uses 
> os_cputime)
> 
> There is “Usage” which can help you with the syntax. 
> 
> Are you planning on using it for something specific or just experimenting ? I 
> would try it with actual sensors which can give you a feel of how useful the 
> API itself is. This is kind of work in progress and any feedback would be 
> welcome.
> 
> Regards,
> Vipul Rahane
> 
>> On Apr 13, 2017, at 7:50 PM, Jacob Rosenthal <jakerosent...@gmail.com 
>> <mailto:jakerosent...@gmail.com>> wrote:
>> 
>> <Jacob______> Jacob Rosenthal Seems like its skipping over that code though, 
>> even though SIM_ACCEL_PRESENT:1
>> 7:40 PM ⇐ vipul quit (~vi...@c-76-103-99-38.hsd1.ca.comcast.net 
>> <mailto:vi...@c-76-103-99-38.hsd1.ca.comcast.net>) Ping timeout: 258 seconds
>> 7:43 PM J<Jacob______> Jacob Rosenthal Its indeed not in 
>> generated/include/syscfg/syscfg.h
>> 7:43 PM 2017/04/13 19:42:50.824 [WARNING] Ignoring override of undefined 
>> settings:
>> 7:43 PM 2017/04/13 19:42:50.824 [WARNING]     SIM_ACCEL_PRESENT: 
>> [targets/sim_sensors:1]
>> 7:45 PM Seems like SIM_ACCEL_PRESENT isnt a syscfg.defs
>> 7:45 PM I added it and it seems to work now
>> 
>> 
>> Can you talk about how to use this?
>> How do you envision sending simulated data to it and in what format?
>> 
> 
> 

Reply via email to