Booger
Monday, June 13, 2016
Thursday, June 2, 2016
Zephyrizing the Curie
Disorganize Notes on Getting started with Zephyr on the Arduino 101
Ubuntu Linux:
* forget the JTAG stuff
* install the latest dfu-util (and libusb)
Ubuntu Linux:
* forget the JTAG stuff
* install the latest dfu-util (and libusb)
$ gpg --verify dfu-util-0.9.tar.gz.md5.asc
$ tar -zxvf dfu-util-0.9.tar.gz
$ cd dfu-util-0.9
$ ./configure
...
configure: error: *** Required libusb-1.0 >= 1.0.0 not installed ***
$ sudo apt-get install libusb-1.0-0-dev
$ ./configure
$ make
$ sudo make install
$ dfu-util -V
dfu-util 0.9
* install the Arduino IDE (>= 1.6.7)
* install the Curie board in the IDE (Tools->Board -> Boards Manager)
(Note: Tools->Board will show a selected board so it doesn't look like a list of boards. Click on it anyway to see the list and the Boards Manager option)
The list of boards will then include "Arduino/Genuino 101".
As a side effect a hidden directory ~/.arduino15/ will be created. For dfu-util to work a udev rule must be set up. A shell script is included to do this, in
~/.arduino15/packages/Intel/tools/arduino101load/1.6.4+1.18/scripts/create_dfu_udev_rule
Execute that script (using sudo) and you'll be ready to flash. To do that, you have to reset the board and then run your dfu-util command within 5 seconds.
"The MASTER RESET is intended to reset both the cores of Curie chip, while RESET will only reset the sketch (though the software doesn't support that yet, so they both reset the whole board).
When pressing MASTER RESET the board will enter DFU and you should see an entry in your device manager similar to this one" (http://forum.arduino.cc/index.php?topic=369653.5;wap2)
When pressing MASTER RESET the board will enter DFU and you should see an entry in your device manager similar to this one" (http://forum.arduino.cc/index.php?topic=369653.5;wap2)
- minimum version of dfu-util required, and instructions for obtaining and installing
- the required udev rule
- required group memberships - my UID was a member of plugdev (from the old instructions) and dialout (required by Arduino IDE). But when I removed myself from those groups I was still able to flash so I guess they're not required
- "flash mode"
- if you press the master reset button, then wait > 5 sec, the flash will fail with message "No DFU capable USB device available"
- if you press the master reset and flash within 5 sec, it will work
- thereafter, you can flash at will, until you hit the master reset again
- so I would say there is a "flash" mode, or something like that, which you enter if you flash within 5 secs of a master reset
- in flash mode, if you press the plain reset, you do not have to flash within 5 seconds
- exit flash mode by pressing master reset (and not flashing)
- once in no-flash mode, the only way to flash is via the master reset button, the plain reset won't work that way
It should be possible to get started without installing the Arduino IDE, by using the script create_dfu_udev_rule:
#!/bin/bash
#
if [ "$(id -u)" != "0" ]; then
echo "This script must be run as root"
exit
fi
NAME=99-arduino-101.rules
echo >/etc/udev/rules.d/$NAME
echo \# Arduino 101 in DFU Mode >>/etc/udev/rules.d/$NAME
echo SUBSYSTEM==\"tty\", ENV{ID_REVISION}==\"8087\", ENV{ID_MODEL_ID}==\"0ab6\", MODE=\"0666\", ENV{ID_MM_DEVICE_IGNORE}=\"1\", ENV{ID_MM_CANDIDATE}=\"0\" >>/etc/udev/rules.d/$NAME
echo SUBSYSTEM==\"usb\", ATTR{idVendor}==\"8087\", ATTR{idProduct}==\"0aba\", MODE=\"0666\", ENV{ID_MM_DEVICE_IGNORE}=\"1\" >>/etc/udev/rules.d/$NAME
udevadm control --reload-rules
udevadm trigger
Intel firmware page: https://downloadcenter.intel.com/download/25832 (source available)
Intel firmware page: https://downloadcenter.intel.com/download/25832 (source available)
Wednesday, June 1, 2016
Iotivity on the Intel IoT Gateway
Iotivity is "an open source software framework enabling seamless device-to-device connectivity to address the emerging needs of the Internet of Things." It has the backing (as in paid programmers) of some of the major players, including Intel and Samsung, to name just two.
You probably wouldn't want to build Iotivity on an IoT gateway machine; it is designed as embedded software, after all, so you'd cross-compile it on a more powerful machine and then install it. Or rather, you'd build a platform image in the proper way, but that is beyond the scope of this article (I'll blog about it later). But if you're working on Iotivity itself, and if you're pulling changes on the bleeding edge, you need to build it by hand. Here's how.
The instructions for Linux on the Iotivity website are for Ubuntu LTS 12.04. They assume that apt-get is installed, which is not the case with WindRiver Linux on a gateway. WRLinux does have rpm, but I'm not yet familiar that so let's do it by hand.You probably wouldn't want to build Iotivity on an IoT gateway machine; it is designed as embedded software, after all, so you'd cross-compile it on a more powerful machine and then install it. Or rather, you'd build a platform image in the proper way, but that is beyond the scope of this article (I'll blog about it later). But if you're working on Iotivity itself, and if you're pulling changes on the bleeding edge, you need to build it by hand. Here's how.
WARNING: this is a little bit messy at the moment, as I'm composing it as my build proceeds, but it should be of some use. I'll clean it up a bit later.
Note that the build scripts are supposed to do some of this stuff automatically (e.g. download and compile some of the deps). Which they do, on Ubuntu. I had some trouble getting them to work on WRLinux (also OS X), plus the build scripts make some assumptions that only work on Ubuntu. So I decided to pull out most (all?) of the dependency stuff and handle it separately, manually. Once you have that stuff installed the build seems to proceed smoothly.
Dependencies:
- tinycbor - see below
- gtest-1.7.0
- the build scripts use https://googletest.googlecode.com/files/gtest-1.7.0.zip, but google has switched to github: https://github.com/google/googletest
- bzip2 - only need for downloading other deps?
- uuid
- libicu
- gio - BLE uses gdbus. deps:
- glib - low-level C routines etc. from the Gnome project http://ftp.gnome.org/pub/gnome/sources/glib/2.48/glib-2.48.1.tar.xz
- libffi - Foreign Function Interface
- https://github.com/libffi/libffi - download zipfile, ./autogen.sh, .configure...
- libpcre - Perl Compatible Regular Expressions
- ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/
- python 2.7.*
- scons
- Python 2.7.* - should be already installed. Needed for scons
- Install bzip2
- $ wget http://www.bzip.org/1.0.6/bzip2-1.0.6.tar.gz
- verify md5 checksum: $ md5sum ...
- $ tar -zxvf bzip2-1.0.6.tar.gz
- $ cd bzip2-1.0.6
- $ sudo make install
- Install libuuid
- $ wget http://downloads.sourceforge.net/project/libuuid/libuuid-1.0.3.tar.gz
- Do NOT use OSSP uuid, it seems to be missing some fns
- verify integrity - on Sourceforge you can find the checksums in the file browser; see Verifying Downloaded Files.
- $ tar -zxvf libuuid-1.0.3.tar.gz
- $ cd libuuid-1.0.3
- $ ./configure
- $ make
- $ sudo make install
- Install libicu
- e.g. $ wget http://download.icu-project.org/files/icu4c/57.1/icu4c-57_1-src.tgz
- build it
- Install libpcre (ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/)
- $ wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.38.tar.bz2
- $ wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.38.tar.bz2.sig
- $ gpg --verify pcre-8.38.tar.bz2.sig
- $ gpg --recv-keys FB0F43D8 (or whatever key is shown by the --verify op)
- $ tar -jxvf pcre-8.38.tar.bz2
- $ ./configure --enable-utf --enable-unicode-properties
- $make && sudo make install - puts libs in /usr/local/lib
- Install libffi
- Install glib - this may be a pain, see Notes on glib below.
- blah....
- $ ./configure
- Unfortunately the system pcre lib in /usr/lib64 is apparently not compiled with unicode support so ./configure will not finish. I linked /usr/lib65/libprc.so.1 to /usr/local/lib. I dunno if that's a good idea, but it got me thru ./configure
- Install boost
- $ wget https://sourceforge.net/projects/boost/files/boost/1.61.0/boost_1_61_0.tar.bz2
- verify sha256 hash: $ sha256sum ...
- $ tar -jzvf boost_1_61_0.tar.bz2
- $ cd boost_1_61_0
- $ ./bootstrap.sh --with-libraries=system,filesystem,date_time,thread,regex,log,iostreams,program_options --prefix=/usr/local
- $ ./b2
- go make a cup of coffee, the build takes a long time
- $ sudo ./b2 install
- Install scons
- $ wget http://downloads.sourceforge.net/project/scons/scons/2.5.0/scons-2.5.0.tar.gz
- see Building and Installing SCons on Any System
- Build Iotivity
- Download: $ http://mirrors.kernel.org/iotivity/1.1.0/iotivity-1.1.0.zip
- NOTE: download the zip file and check the sha256 sum. As of the time of writing, the tar.gz file does NOT match its checksum!
- $ unzip iotivity-1.1.0.zip
- $ cd iotivity-1.1.0
- $ scons
The build takes quite a while.
tinycbor
At the very beginning you will see a message like this:
*********************************** Error: *************************************
* Please download cbor using the following command: *
* $ git clone https://github.com/01org/tinycbor.git extlibs/tinycbor/tinycbor *
******************************************************************************
But when you try to do this you will get an error:
fatal: unable to access 'https://github.com/01org/tinycbor.git/': Problem with the SSL CA cert (path? access rights?)
Gateways running WRLinux come with lots of certificates (see /etc/ssl/certs) but apparently not the one we need for git cloning. The workaround is to use wget. Go to the tinycbor git repo in your browser, click on the "Clone or download" button, then right click on the "Download zip" link to copy the link address. On the gateway, cd to iotivity-1.1.0/extlibs/tinycbor, wget the zip file, and unzip it. You'll get a directory called tinycbor-master. Rename this to tinycbor, and then return to the iotivity-1.1.0 dir and rerun scons.
Other notes:
$ scons -c seems to hang when it gets to "scons: Cleaning targets ..." ???
Notes on glib:
The bluetooth le stuff for linux depends on the Bluez stack, which
depends on gdbus, which depends on gio, then glib, etc.
So we install glib-2.0, and then the trouble starts. The pkg-config
files go in /usr/local/lib/pkgconfig, but when scons runs pkg-config
it only uses the default dir, namely /usr/lib64/pkgconfig. I don't
know how to get it to also look in /usr/local, you can't pass stuff
via env vars. So the quick-n-dirty is to copy the relevant *.pc
files. Ditto for the headers; copy /usr/local/include/gio-unix-2.0 to
/usr/include.
Subscribe to:
Posts (Atom)