libmraa is the base - for sensors you would use libraries from the UPM repository upm: Main Page.
However, currently supported temperature sensors are only
So you probably would have to write on your own - you may contribute your implementation to the open source UPM repository on github.
The current kernel misses the one wire modules (w1-gpio, w1-therm, wire).
It should not be a big problem to patch these but somebody must do it. In latest kernel versions (not 3.10) i saw them configurable for any gpio port.
It would be nice to see the actual kernel sources for Edison somewhere standalone or is it easy to extract them from the Yocto sources? Until now i didn't find the time to check it out. Generally it's the best way to use these kernel routines - we shouldn't start to invent the wheel again.
it's pretty easy to extract:
- download http://downloadmirror.intel.com/24389/eng/edison-image-rel1-maint-rel1-ww42-14.zip#_ga=1.264048716.175665116.1400568548
- source poky/oe-init-build-env
- bitbake linux-yocto
- pushd tmp/work/edison-poky-linux/linux-yocto/3.10.17+gitAUTOINC+6ad20f049a_c03195ed6e-r0/
Thanks, i appreciate such short kept hints, but your link points simply to ready flashable Yocto images - no sources.
Is it really so simple (crosscompiler, etc. already included) ?
and it's a long running procedure to build all.
I want to configure and build my own kernel only - a task which would be complete in some minutes.
Shouldn't take too long as you don't have to build everything but only the kernel.
The cross binutils would have to be built as well of course.
And well you don't have to build the kernel. I think there is even a "bitbake -c menuconfig yocto-linux" which would run through the config
Thanks, but my target are these steps for kernel building - similar like this:
I don't use the Yocto image, it's not my thing and i switched to ubilinux (although that's everyones personal taste).
I think i understand why Intel decides for Yocto. But there are a lot of developers who want to stay at best practiced distributions, Debian (ubilinux) is one of them.
Are you interested in this feature too? Are you going to be adding it to the kernel or are you merely pursuing your own kernel mods?
1 of 1 people found this helpful
@jolt: i think you mentioned this with regard to your thread title. Sorry for my little aberrancy.
i'm also very interested having the one wire protocol which is supported by standard kernel modules but they must be activated and maybe a little bit patched for the Edison. If that would be done my interest is not using node.js and java programming, i prefer C. But whatever you use for programming at first the kernel has to be configured and build for it.
Because there are a lot of other interesting things i want to do with the Edison i set the use of a DS18B20 not to the highest priority.
Another and probably better solution:
Let the uC do the one wire work and write a sketch. The one wire lib should be already included in the Arduino development package.
What microcontroller? Arduino sketches execute as a Linux process, and you don't have cli() / nointerrupts() and sei() / interrupts(), which means that a lot of timing sensitive code —- such as bit-banged stuff — won't work.
Andrew, you are right.
When i wrote my comments i thought the MCU in the Edison is activated and a sketch can use it. In the meanwhile i made my experience and i have been told it's inactive until now.
I'm also still waiting, hopefully the next release will include mcu support.
I too live in hope that the Arduino environment will be updated so that sketches target the onboard MCU. I think if we had this and a nice, simple interface for passing data between Arduino sketches and Linux apps — e.g. an Arduino library, plus a Linux C/C++ library with Python and node.js bindings — it could be a very much more powerful combination and attractive proposition.
I fully agree, the Edison is a great piece of hardware and i want to use it only with the minibreakout board or standalone. It has an amazing small size for all the builtin features and i hope CPU and MCU will be combined in an awesome way with a common memory region
That's what developers hope for.