Things I Find Interesting
Posts tagged ARTIK
Programming the ARTIK-0 IoT Devices
Jul 1st
If you’ve read this blog much at all you’ll have noticed that I’ve been a fairly big fan of the ARTIK line of IoT boards (see here, here, here, here, here, here , here and here) but I really need to clarify that a bit now. I love my ARTIK-520 board. It runs the entire InfluxData stack nicely and is a solid, reliable place to deploy IoT-Edge software. I really like it.
That being said, I am still really unhappy with the ARTIK-0x line of “products”. It started when I purchased the ARTIK-020 developer board. Lots of claims about being able to program it from Mac OS, etc. The reality was that — 13 pages into the developer guide — one comes to the realization that a) you need a Windows machine and b) after 30 days you needed to purchase a $3,000 license to IAR Workbench. So much for being Maker-friendly. I put that board in a drawer and gave up on it. Expensive lesson learned.
I complained to my friends at Samsung — yes, I have friends at Samsung — and a while later they gave me a free ARTIK-053 module. This one didn’t need the IAR Workbench to program it (yay for gcc!!) and I thought things looked better. I wish I had been right. I played with it for a bit after getting it but ran out of time so, as with the other Samsung board, it went in the box.
I decided to revisit it this week. I had built a CO2 sensor using a Nordic Semi nRF52DK and a Senseair K30 but the nRF52DK was really sort of big and I was looking for a smaller form-factor (that I had “in stock”) and didn’t require Arduino. I won’t start in on Arduino here, but I could.
So out came the ARTIK-053 Dev Board, and … oh shit, here we go again. First, I started with the ARTIK-IDE for development. It’s based on Eclipse (of course) but seriously, it was unbelievably slow, cumbersome and didn’t do any code-completion or hints. It took about 4 minutes to deploy a binary to the board. I iterate a lot so 4 minutes per load was seriously slowing me down. -1 for ARTIK-IDE.
I discovered serendipitously that Microsoft VS Code supports the ARTIK development environment and was a ton faster. 10-second compiles (vs. 1-minute compiles on Eclipse/ARTIK-IDE) and 30-second deploys (vs. the 4 minutes on ARTIK-IDE). Life got a lot better after that. (I may come back and do another post about VS Code just because I’m singing it to be super versatile and a really good tool — which is saying something for someone with as virulent anti-microsoft antibodies as I have.)
So I moved all my development to VS Code and began what I thought would be a fairly straightforward port of my mBed OS I2C CO2 sensor code to ARTIK’s TizenOS. There I go thinking again. I2C is pretty straightforward. You need to know the address of the device, the registers you want to write to, the registers you want to read from, and that pretty much covers it. Really simple stuff.
/* 7-bit address of the K30 CO2 Sensor */
const int addr = 0xD0;
char cmd[4] = {0x22, 0x00, 0x08, 0x2A};
int ack = i2c.write(addr, cmd, 4);
i2c.read(addr, readBuff, 4, false);
That’s a 7-bit address. Write a 4-byte command to the address, then read a 4-byte buffer back and I’ve got my reading. That’s the mBED OS code above, by the way. It works perfectly, so porting it to Tizen should be easy-peasy.
Wrong
It turns out there is less than zero documentation for the ARTIK-0x line of devices. There are a couple of sample programs, but if you want to move beyond just compiling and running those samples, you’re on your own. Samsung seems to think that the source code for i2c.h should be enough to make everything happen. They couldn’t be more wrong. If you post to the user forums, you get told to “just read the source code.” That’s hardly a response if you want developers to use your platform.
I’m fairly adept at reading source code. IF it’s written clearly and well documented. And that’s the problem with the ARTIK source code. The authors seemed to think that just writing the code would be enough. Especially when it came to the ‘example’ programs. As an example, the websocket example code consists of a single source file that is 1158 lines long. Here are all the comments in the source to help you along with understanding it:
/// @file app/netutils/websocket/websocket.c
/// @brief websocket file to support client and server.
/****************************************************************************
* Included Files
****************************************************************************/
/****************************************************************************
* Definitions
****************************************************************************/
/****************************************************************************
* Private Types
****************************************************************************/
/****************************************************************************
* Private Data
****************************************************************************/
/****************************************************************************
* Private Functions
****************************************************************************/
/***** websocket client oriented sources *****/
/***** websocket server oriented sources *****/
/****************************************************************************
* Global Functions
****************************************************************************/
/* If tls is enabled, socket fd would be released */
/*
* if websocket server is initiated from http(s), you just can call this function.
* see the comment of websocket_server_open to know what is different.
*/
/*
* websocket_server_open function includes:
* 1. allocating socket fd
* 2. accepting client
* 3. authenticating with client
* those 3 are not needed when websocket is initiated from http(s).
*/That’s right, that’s all the comments from 1158 lines of complicated websocket code. Most of the Demo code is similarly ‘documented.’ This is either pure laziness on the part of the developers of the demo code, or else Samsung just doesn’t care whenever their end users are successful at developing applications on their platform. I’m going to give them the benefit of the doubt and go with laziness. As a developer myself, I try to do as much in-line code documentation as I can reasonably do as it’s just a common courtesy for the developer that comes along behind you. I don’t always do it with code I write purely for myself, but if I’m publishing it, or making it available, I really try to make it easy to follow. Samsung apparently doesn’t care about that.
Conclusions
I’m 9 days in and I’ve now finally gotten the I2C device to be readable on a fairly consistent and reliable basis. It wasn’t easy, or even remotely pleasurable, but it’s working well enough for me. The next bit is to be able to post the sensor results via http — ideally https — to my InfluxDB server. That’s why I went through 1158 lines of websocket code on a Sunday afternoon. Your Sunday was probably better, I’m assuming.
I’m pretty sure that getting the https POST to go through is going to take about 8 days as well, which should make Samsung ask themselves the question: When someone can implement this in a day or 2 using mBED, FreeRTOS, or Arduino and it takes 2 weeks on ARTIK, why would anyone choose ARTIK?” It’s a valid question that I don’t think they have an adequate answer for.
Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1057
InfluxDB on ARTIK-520 Redux
Jul 20th
Last week I wrote a piece on installing and running the InfluxDB time series database, ingestion, dashboard and action packages on your ARTIK-520, but I need to update that post, and it’s a bit more than just a few edits. Influx Data supplies the Linux binaries as packages for most of the major distributions, but the ARM distribution is just as a binary, with no package installation scripts, etc. I thought I’d show you how (and why) I fixed that for my ARTIK-520.
I’m sure you could incorporate the whole thing into a Resin.io build for your ARTIK-520 — and maybe that will be another project for me shortly — but for now, I just wanted to make sure that all the processes were properly launched, and stayed up.
This became important to me when I wanted to show someone my nifty dashboards live, but the ARTIK-520 had rebooted, and nothing was running anymore. I wanted to make sure that didn’t happen again.
The ARTIK-520 (at least mine) runs Fedora Linux. Now technically you should be able to use the package manager to install InfluxDB, but in this case, there isn’t a package for ARM, so you have to do it yourself. All the downloads for InfluxDB, Chronograf, Telegraf and Kapacitor contain a directory structure with /usr, /var and /etc directories, so here’s what I did after I untar’ed all the downloads:
[root@localhost ~]# cd influxdb-1.2.4-1 ; cp -rp usr/* /usr ; cp -rp etc/* /etc ; cp -rp var/* /var
That gets everything in the right places for influxes. Now just to the same thing for the kapacitor, telegraf, and chronograf directories. Everything may be in the right place, but they won’t automatically start at boot time because Fedora is a systemd based OS, so it’s important to get each one of those set up as a systemd service. Luckily, this isn’t hard. You just need to create the files in the /etc/systemd/system directory, and I’m going to make it even easier for you by giving you those files.
[root@localhost system]# cat influxdb.service
[Unit]
Description=InlfuxDB service
[Service]
ExecStart=/usr/bin/influxd
NotifyAccess=main
#WatchdogSec=10
Restart=on-failure
LimitNPROC=1
ProtectHome=true
ProtectSystem=full
I then created one for each of the other services as well:
[root@localhost system]# cat telegraf.service
[Unit]
Description=Telegraf service
[Service]
ExecStart=/usr/bin/telegraf -config /etc/telegraf/telegraf.conf
NotifyAccess=main
#WatchdogSec=10
Restart=on-failure
ProtectHome=true
ProtectSystem=full
[root@localhost system]# cat chronograf.service
[Unit]
Description=Chronograf service
[Service]
ExecStart=/usr/bin/chronograf -b /var/lib/chronograf/chronograf-v1.db >/dev/null 2>&1
NotifyAccess=main
#WatchdogSec=10
Restart=on-failure
ProtectHome=true
ProtectSystem=full
Finally, I just had to make sure that systemd knew about these new services, and start them:
[root@localhost system]# systemctl enable influxes.service; systemctl start influxes.service
[root@localhost system]# systemctl enable telegraf.service ; systemctl start telegraf.service
[root@localhost system]# systemctl enable chronograf.service ; systemctl start chronograf.service
Then a quick check with:
[root@localhost system]# systemctl
...
influxdb.service loaded active running InlfuxDB service
...
telegraf.service loaded active running Telegraf service
...
chronograf.service loaded active running Chronograf service
And I can see that they are all up and running, and that systemd will make sure that they stay that way, even across reboots.
I hope this helps you if you’re also deploying your Influx DB on an ARTIK-520, or even another ARM-based embedded system that is systemd-dependent.
Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1057
OpenHAB Server on ARTIK-520
Mar 28th
As I said earlier, when you have a hammer … So I decided to set up Yet Another IoT Gateway. This time I took a look at OpenHAB the “vendor and technology agnostic open source automation software for your home.” Why not, right? I’ve already set up a Droplit.io edge server, and an Eclipse Kura server, so why not give one more a try right? Right. So let’s dive in.
Setup
Setup was incredibly easy. Almost scary easy. Seriously. As always, I started with the basic ARTIK Fedora image, and of course updated it with all the latest:
[root@localhost ~]# dnf update
That takes a while.
Note: I start with a fresh OS for each of these projects. Thanks to being able to dump a running system back out to mini-SD Card, I just dump what I was working on to a card, burn a fresh card, and start over.
You’re going to need that Zulu JVM I talked about earlier. Installation is quick and easy, but don’t skip it! Apparently the open-jdk version of the JVM won’t really give you much joy with OpenHAB. I didn’t try it, I just installed the Zulu JVM and went on. In case you forgot, once you’ve downloaded the Zulu JVM:
[root@localhost ~]# tar xvf ezdk-1.8.0_112-8.19.0.31-eval-linux_aarch32hf.tar [root@localhost ~]# update-alternatives --install /usr/bin/java java ~/ezdk-1.8.0_112-8.19.0.31-eval-linux_aarch32hf/jre/bin/java 100 [root@localhost ~]# update-alternatives --config java
The only additional package you are going to need is unzip because someone thought it was a good idea to not include unzip (or zip for that matter) in the base image. Whatever.
[root@localhost ~]# dnf install unzip
Easy. Done. Then get the openHAB server. The instructions for this install are here, but really I’ll tell you everything you need to know.
[root@localhost ~]# cd /tmp
[root@localhost /tmp]# wget -O openhab-download.zip https://bintray.com/openhab/mvn/download_file?file_path=org%2Fopenhab%2Fdistro%2Fopenhab%2F2.0.0%2Fopenhab-2.0.0.zip
[root@localhost /tmp]# unzip openhab-download.zip -d /opt/openhab2
[root@localhost /tmp]# rm openhab-download.zip
The instructions say to create an openhab user, and then run the openhab server as that user. Don’t do that. I guess you can figure out how, but when I did, I kept getting:
/opt/openhab2/runtime/bin/karaf: line 28: cd: /root: Permission denied : JAVA_HOME is not valid: /root/ezdk-1.8.0_112-8.19.0.31-eval-linux_aarch32hf/jre/
So finally I just ran it as root. It works just fine as root.
That’s really all there was too it! Told you it was easy!
Using OpenHAB
This is where things got fun! Once the OpenHAB server was started, I connected to the ARTIK-520 using my browser (port 8080, just FYI) and Voilà! I had a dashboard of sorts. But nothing was there. Hmmm … okay, so I had to go install some “bindings”.
There are a lot of them. I chose the ones for the stuff I have. A Samsung TV, some Nest Stuff and those Wemo switches. As soon as I installed those bindings, stuff started showing up in my “Inbox”. Like, instantly! What showed up right away were the Wemo switches. As soon as I fixed the network connection on my Samsung TV, it also showed up right away. The Nest stuff is going to take a bit more work since I had to register as a Nest Developer, and I haven’t finished jumping through all their hoops just yet. But the bindings are installed:
I installed the Z-Wave binging for reasons that now escape me. Deal with it.
And those are all the devices that appeared. And now I can control them!
Conclusions
The Kura Server took me a week or two to get working, with a fair amount of support from the Eclipse engineers responsible. It really wasn’t designed to run on an embedded platform like the ARTIK-520, and had never been tested there, so it’s not really surprising.
The Droplit.io Edge Server took me about a week. Actually, the install was pretty easy once I gave up on trying to build the system on the ARTIK-520. Remember my rule: Don’t build/compile on ARTIK-520 unless absolutely necessary. Then it took a few days to get a bug worked out so it could find my Wemo switches, but that’s about all it was going to find.
The openHAB server was by far the easiest. Took about 2 hours, start to finish, including building/flashing/updating the OS. And it found a lot more devices almost instantly (once I figured out to install the bindings. I don’t always read all the directions.). It’s very responsive and easy to deal with.
I’ve got a bunch more stuff to investigate here, like the ‘experimental’ rules engine, and I may try out the Text-to-Speech integration if I have time.
In all honesty, this may be my last ARTIK-520 integration test for a while. They aren’t actually paying me to do them. In fact, no one is paying me to do anything right now, so until I get that fixed, I’ll probably spend most of my time job-hunting. And maybe some more time on the resistbot project. This is all easily fixable if someone would decide to hire me. 🙂
Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1057
Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1057
Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1057
ARTIK-520 as a Droplit.io Edge Device
Mar 28th
Doing some further work with my trusty ARTIK-520 (hey, when you have a hammer, everything looks like a nail! Back up off me! ) I decided to try installing another IoT Gateway framework on it. (I’ve done that before.) Equal opportunity and all that. And I’ll be doing more of them as soon as I get more mini-SD Cards in-house. But I digress.
I originally just followed the basic install instructions for deploying a Droplit.io Edge server. But that didn’t work. No fault of Droplit.io, to be sure. And really no fault of the ARTIK-520. But here’s my new rule:
Do Not Compile/build On ARTIK-520
It just doesn’t ever end well. It may be a pain to set up a cross-compiler on your architecture, but you only have to do that once (and lucky me I already had the ARM compiler toolchain installed and working from working on MyNewt. But you won’t even need a compiler for Droplit.io edge. It’s all JavaScript, so it’s pretty easy.
Setup
Once you’ve got the Droplit.io-edge wad on your laptop (or whatever) and all the prerequisites, just build it according to the instructions. Don’t actually run it from your laptop though. Once I had it built, I just ran:
DSimmons-Pro:~ dsimmons$ tar czf droplit.tgz droplit.io-edge
And then used sftp to copy the compressed tar file over to the ARTIK-520, un-compress/tar it and then:
[root@localhost ~]# export DEBUG=droplit:* [root@localhost ~]# cd droplit.io-edge/ [root@localhost droplit.io-edge]# node droplit-edge droplit:router using setting host: wss://edge-ws.droplit.io/edge +0ms droplit:router using setting ecosystem: C58c71404f57350103c9a8dda +19ms droplit:router using setting edge id: 36:e8:d4:9e:f4:a6 +7ms droplit:router load plugins +7ms droplit:router droplit-plugin-philips-hue loaded +2s droplit:router droplit-plugin-lifx loaded +85ms droplit:router droplit-plugin-sonos loaded +2s droplit:router droplit-plugin-wemo loaded +2s droplit:transport-edge reconnecting... +4ms droplit:transport-edge connected +805ms droplit:router info < droplit-plugin-wemo:uuid:Socket-1_0-221631K0100D8A +6s droplit:router info < droplit-plugin-wemo:uuid:Socket-1_0-221643K0101D76 +200ms droplit:router id > uuid:Socket-1_0-221631K0100D8A -> 58da675822fea674dc071474 +62ms droplit:router pc < uuid:Socket-1_0-221631K0100D8A\BinarySwitch.switch off +59ms droplit:router info < droplit-plugin-wemo:uuid:Lightswitch-1_0-221614K1300BE2 +181ms droplit:router id > uuid:Socket-1_0-221643K0101D76 -> 58da675922fea674dc071475 +26ms droplit:router pc < uuid:Socket-1_0-221643K0101D76\BinarySwitch.switch off +24ms droplit:router pc < uuid:Lightswitch-1_0-221614K1300BE2\BinarySwitch.switch off +30ms droplit:router id > uuid:Lightswitch-1_0-221614K1300BE2 -> 58da675922fea674dc071476 +130ms
I set the DEBUG property because I wanted to see what was actually going on behind the scenes (plus I was actually debugging a problem with the Droplit folks, who are awesome about helping out and super responsive!).
You’ll see that very quickly the Droplit-io edge server found the Wemo switches I have deployed in my house. Sweet! I then went to my Droplit.io developer portal and:
And there they are! And I have verified that I can indeed turn them on and off from here.
Now, if anyone wants to send me some Sonos gear, or some Philips HUE gear, that I can install here at home to test with this, I’d be happy to test that out.
I may see about creating some connectors to connect things like my MyNewt-based devices to the edge server, but that’s not going to happen today.
Conslusions
As usual, I have found the ARTIK-520 to be a fairly easy, and very versatile, IoT hub. This is my second gateway project with ARTIK-520 and, though I have run into some quirks each time, it’s basically pretty straight-forward to set up. Again, don’t try to build/compile on the ARTIK-520 unless you absolutely have to, and it’s a relatively small build. I’ve actually built Node.js from source on the ARTIK-520 a couple of times and it was slow, but relatively painless.
Droplit.io is a fairly straightforward deployment target for ARTIK-520. As small as the actual ARTIK module is (aside from all the development board stuff) it would be a pretty attractive target for a Droplit.io ‘appliance’, though I’m not sure the price-point would hit a reasonable target for them.
As I said, I’d like to try my hand at building some connectors for other IoT devices for Droplit, and I’m certainly looking at some other gateways to build/deploy on this ARTIK-520 board. Stay tuned!
Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1057
Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1057
How To Save (Backup or clone) Your ARTIK-520
Mar 11th
Let’s say, for argument’s sake, that you have a Samsung ARTIK-520 (I assume this will work on other ARTIK modules aside from the ARTIK-0 ones) and you have it all configured the way you want, and don’t want to lose anything. Or maybe you just want to replicate it a dozen times onto a dozen different ARTIK-520s. As it stands right now, apparently, the answer is “good luck with that” as there is no mechanism to actually dump a running ARTIK-520 to a Mini-SD Card that can then be used to install it again.
Until now. I have such an ARTIK-520, and I don’t want to destroy it, but I want to be able to boot it to a different version of the OS to play around with some things, then be able to easily restore it back to this system later. After extensive searching and poking about, I could find no way to do that. So I invented one. Here’s how to do it:
First, you will need the original ARTIK-520 image that you started with. Mine was still on the Mini-SD Card I installed from, so it was easy. If you don’t have that, just re-download it to your card following the excellent instructions here.
Now, if you just put that card in the reader and look at what you’ve got:
[root@localhost mnt]# fdisk -l Disk /dev/mmcblk0: 3.7 GiB, 3909091328 bytes, 7634944 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 00042021-0408-4601-9DCC-A8C51255994F Device Start End Sectors Size Type /dev/mmcblk0p1 2048 67583 65536 32M Microsoft basic data /dev/mmcblk0p2 67584 133119 65536 32M Microsoft basic data /dev/mmcblk0p3 133120 7634910 7501791 3.6G Microsoft basic data Disk /dev/mmcblk0boot1: 4 MiB, 4194304 bytes, 8192 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mmcblk0boot0: 4 MiB, 4194304 bytes, 8192 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mmcblk1: 7.4 GiB, 7892631552 bytes, 15415296 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xfd34147e Device Boot Start End Sectors Size Id Type /dev/mmcblk1p1 2048 67583 65536 32M 83 Linux /dev/mmcblk1p2 67584 133119 65536 32M 83 Linux /dev/mmcblk1p3 133120 1140735 1007616 492M 83 Linux
You’ll see that last disk entry for
/dev/mmcblk1
that is partitioned into 3 parts. The last partition is the one you’re interested in. Now, the SDCard I am using is an 8 GB card, but you’ll notice that if you add up all those partitions, they don’t add up to anywhere close to 8GB. That’s because they didn’t need to. They only needed to be big enough to hold the original OS, and in case you were only using a 1GB card it would still fit. But you’re not using a 1GB card, are you? Of course not. So you need to grow the filesystem to hold the new OS you’re actually running.
Here’s how you grow that partition:
[root@localhost mnt]# fdisk /dev/mmcblk1
Welcome to fdisk (util-linux 2.26.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/mmcblk1: 7.4 GiB, 7892631552 bytes, 15415296 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xfd34147e
Device Boot Start End Sectors Size Id Type
/dev/mmcblk1p1 2048 67583 65536 32M 83 Linux
/dev/mmcblk1p2 67584 133119 65536 32M 83 Linux
/dev/mmcblk1p3 133120 1140735 1007616 492M 83 Linux
Command (m for help): dPartition number (1-3, default 3): 3
Partition 3 has been deleted.
Command (m for help): n
Partition type p primary (2 primary, 0 extended, 2 free) e extended (container for logical partitions)
Select (default p):
Using default response p.
Partition number (3,4, default 3):
First sector (133120-15415295, default 133120):
Last sector, +sectors or +size{K,M,G,T,P} (133120-15415295, default 15415295):
Created a new partition 3 of type 'Linux' and of size 7.3 GiB.
Command (m for help): p
Disk /dev/mmcblk1: 7.4 GiB, 7892631552 bytes, 15415296 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dosDisk identifier: 0xfd34147e
Device Boot Start End Sectors Size Id Type
/dev/mmcblk1p1 2048 67583 65536 32M 83 Linux
/dev/mmcblk1p2 67584 133119 65536 32M 83 Linux
/dev/mmcblk1p3 133120 15415295 15282176 7.3G 83 Linux
Command (m for help): w
The partition table has been altered.Calling ioctl() to re-read partition table.
And you’ve just grown the partition table for that last section to fill the available space. But you’re not done, because you also have to grow the file system to match!
Next you need to check the filesystem, then mount it, and then ‘grow’ it:
[root@localhost mnt]# e2fsck -f /dev/mmcblk1p3 e2fsck 1.42.12 (29-Aug-2014) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information rootfs: 20/125952 files (10.0% non-contiguous), 119676/125952 blocks [root@localhost mnt]# mkdir /mnt/SD3 [root@localhost mnt]# mount /dev/mmcblk1p3 /mnt/SD3 [root@localhost mnt]# resize2fs /dev/mmcblk1p3
Great! You passed! Now you should have a very large 3rd partition on your SSD Card and we can start the process of dumping your running system as a backup.
Next, and I did this so you don’t have to, I went through the filesystem and found all the directories you don’t want to descend into while backing up, and then wrote a long but very dumb script to dump everything into a tar archive, and then gzip compress it (since you can’t append to an already compressed archive). And here’s an odd thing. GNU Tar says that to not add a directory recursively, you should run `tar cf foo.tar foo –no-recursion` but at least on the version of Fedora I’m running, which claims to have GNU tar installed, that failed to have any effect. In fact, what I ended up with, as you’ll see in the script, is `tar cf foo.tar –no-recursion foo`. Apparently the –no-recursion has to come before the directory you don’t want recursion on. Who knew. Run that script, and you’ll end up with a new rootfs.tar.gz on your SD Card. This is what will be installed on a new system, thus making your new system a carbon-copy of the old one.
Note: as a precaution, you should rename the existing rootfs.tar.gz file to preserve it. If something goes wrong, you can then move it back into place and recover — though not recover the system you’re trying to clone.
The script is available from my GitHub
UPDATE: Since this is now available via GitHub, I added some fancy to the script. It will safely calculate the size of the 3rd partition, and get it right. It will backup the existing rootfs.tar.gz file for you, it will ask you if there are any additional files or directories to include (first ones to include non-recursively, then the recursive includes), etc. It’s a lot nicer now. Enjoy!
Here’s how big the original was:
-rw-r--r-- 1 root root 410873697 Apr 15 2016 rootfs.tar.gz
my uncompressed tar file was YUGE by comparison:
-rw-r--r-- 1 root root 2893404160 Mar 11 14:06 rootfs.tar
And then, even compressed, it was a monster:
-rw-r--r-- 1 root root 1521728492 Mar 11 14:06 rootfs.tar.gz
So make sure that the SD Card you’re using is large enough to hold the uncompressed tar file, since you’ll need to store it as uncompressed until it’s done, then compress it. I likely could have made mine considerably smaller had I removed a bunch of stuff I wasn’t actually using, but given that I wanted to test this all out, I decided to make it a rigorous test.
Once you’ve got your full roots.tar.gz file, you can simply unmount the SD Card, put it in a new ARTIK-520, flip the boot switches, and boot your device. It will then install the cloned system, you shut it off, un-flip the boot switches, pull out the card and reboot and Voilà! You have a cloned system!
Don’t be fooled though, this whole process will take you the better part of a day to complete. At least, that’s how long it took me. But then again, I had to come up with it, and test it, as well.
Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1057
Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1057
Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1057
Just How Fast Is Faster?
Mar 6th
After I installed and tried the Zulu Embedded JVM on my ARTIK-520 this morning I noticed that it felt faster. It seemed faster. But was it really faster? And if so, how much faster? So I went looking for some Java Benchmark tests to run.
I chose the DaCapo Benchmark for this. Why? Because google, that’s why. Here’s what the DaCapo Benchmark says about itself*:
This benchmark suite is intended as a tool for Java benchmarking by the programming language, memory management and computer architecture communities. It consists of a set of open source, real world applications with non-trivial memory loads. The initial release of the suite was the culmination of over five years work at eight institutions, as part of the DaCapo research project, which was funded by a National Science Foundation ITR Grant, CCR-0085792. Three years of development have gone into the 2009 release. This work has been funded by the ANU, the Australian Research Council and a generous donation from Intel.
Works for me. My mom was a world-famous Benchmark expert for decades. I’m not. So this is what I chose. Are there better benchmark suites out there? Probably. Do I care? Not so much.
Here are the specific benchmark tests included in this suite. You’ll notice that not all of them are represented below. While they all completed successfully on the Mac, I have only included the ones that succeeded successfully on at least one of the embedded JVMs.
The DaCapo-9.12-bach benchmark suite, released in 2009, consists of the following benchmarks:
avrora batik eclipse fop h2 jython luindex lusearch pmd sunflow tomcat tradebeans tradesoap xalan
|
avrora |
simulates a number of programs run on a grid of AVR microcontrollers |
|
batik |
produces a number of Scalable Vector Graphics (SVG) images based on the unit tests in Apache Batik |
|
eclipse |
executes some of the (non-gui) jdt performance tests for the Eclipse IDE |
|
fop |
takes an XSL-FO file, parses it and formats it, generating a PDF file. |
|
h2 |
executes a JDBCbench-like in-memory benchmark, executing a number of transactions against a model of a banking application, replacing the hsqldb benchmark |
|
jython |
inteprets a the pybench Python benchmark |
|
luindex |
Uses lucene to indexes a set of documents; the works of Shakespeare and the King James Bible |
|
lusearch |
Uses lucene to do a text search of keywords over a corpus of data comprising the works of Shakespeare and the King James Bible |
|
pmd |
analyzes a set of Java classes for a range of source code problems |
|
sunflow |
renders a set of images using ray tracing |
|
tomcat |
runs a set of queries against a Tomcat server retrieving and verifying the resulting webpages |
|
tradebeans |
runs the daytrader benchmark via a Jave Beans to a GERONIMO backend with an in memory h2 as the underlying database |
|
tradesoap |
runs the daytrader benchmark via a SOAP to a GERONIMO backend with in memory h2 as the underlying database |
|
xalan |
transforms XML documents into HTML |
So here’s what I found.
Yeah, the Zulu JVM is faster. And it’s not just a little bit faster. It’s a LOT faster. I mean a whole lot. So much so that I decided to run the same Benchmark suite on my MacBook Pro just for grins. Guess what? In one of the tests, Zulu beat the JVM on my Mac. Whiskey. Tango. Foxtrot. But yes, the numbers don’t lie.
|
Test |
OpenJDK |
Zulu |
Mac OS X |
|
avrora |
588264 |
44963 |
6137 |
|
xalan |
438577 |
41963 |
50066 |
|
tradesoap |
FAIL |
247835 |
51650 |
|
tradebeans |
FAIL |
85343 |
13105 |
|
sunflow |
218045 |
69992 |
5405 |
|
pmd |
135382 |
24268 |
4333 |
|
lusearch |
459989 |
39134 |
5035 |
|
luindex |
230904 |
11399 |
2305 |
|
fop |
103144 |
15233 |
3852 |
|
jython |
1204207 |
59300 |
4150 |
So Zulu beats Mac on the xalan benchmark. Astonishing. And the OpenJDK for ARMv7 is really sort of crap. On the tests it was able to complete it lagged far, far behind the Zulu JVM. The failures in the tradesoap and tradebeans tests were outOfMemeoryException failures, so the Zulu JVM is not just faster, but it’s a lot more memory efficient. And on an embedded system, a memory-efficient JVM is what you really want, right?
Here’s what those results look like in pretty chart form:
Ridiculous, right? Yes, the Mac numbers are so small they barely register almost everywhere at this scale, but the Zulu numbers are quite impressive when compared to the OpenJDK numbers.
So not only does the Zulu JVM feel faster, it actually is faster. And by a LOT. I’d say if you’re planning to deploy something on the ARTIK-520, and it’s written in Java, and you want it to perform well, you’d be well-served to shell out the money for the Zulu JVM. You’ll be a lot happier.
* Blackburn, S. M., Garner, R., Hoffman, C., Khan, A. M., McKinley, K. S., Bentzur, R., Diwan, A., Feinberg, D., Frampton, D., Guyer, S. Z., Hirzel, M., Hosking, A., Jump, M., Lee, H., Moss, J. E. B., Phansalkar, A., Stefanovic, D., VanDrunen, T., von Dincklage, D., and Wiedermann, B. The DaCapo Benchmarks: Java Benchmarking Development and Analysis, OOPSLA ’06: Proceedings of the 21st annual ACM SIGPLAN conference on Object-Oriented Programing, Systems, Languages, and Applications, (Portland, OR, USA, October 22-26, 2006) (pdf, BibTeX).
Make your ARTIK-520 Scream
Mar 6th
If you read last week’s post about making an ARTIK-520 an IoT gateway device using the Eclipse Kura project, then this will be a noticeable improvement for you if you’re going to try it yourself (and why wouldn’t you? It was an excellent little How To on getting started with ARTIK-520 and IoT!)
It was suggested to me (these little birdies keep feeding me interesting nuggets to try) that I try the Azul Zulu Embedded JVM as an alternative to the OpenJDK JVM that is installed by default. Ok, sure, why not. What’s the worst that could happen. Don’t answer that.
Anyway, this is going to be a short post. I tried it. I downloaded the Zulu JVM and installed it like so:
[root@localhost ~]# tar xvf ezdk-1.8.0_112-8.19.0.31-eval-linux_aarch32hf.tar
[root@localhost ~]# update-alternatives --install /usr/bin/java java ~/ezdk-1.8.0_112-8.19.0.31-eval-linux_aarch32hf/jre/bin/java 100
[root@localhost ~]# update-alternatives --config java
[root@localhost ~]# systemctl restart kura.service
Now reload the Kura Web Console in your browser.
At least for me, there was a quite noticeable and marked improvement in the performance of the web service. As in I really noticed it. But then again, although I was too polite to comment on it in my previous post, I had noticed that the performance of Kura had been bit sluggish. I just attributed that to the fact that we’re running on some embedded hardware and that’s almost always slower than more robust platforms. But get yourself a high-performance JVM and get a few seconds of your life back every time you take an action in Kura. Those are seconds that, once lost, you’d never have gotten back. Seconds that you can now use to fully spell out ‘your’ in text messages instead of just typing ‘ur’. This will make the world a better place for everyone.
Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1057
Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1057
Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1057
Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1057
Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1057
Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1057
Making an ARTIK-520 IoT Gateway with Kura
Mar 2nd
There are about a million ways to build or buy an IoT Gateway Device. (Actually, more like 586,000, but let’s not quibble). Each has it’s own merits, or pitfalls. You could buy one, and risk being locked into a single-vendor solution. You could build one from scratch and then be saddled with having to source the hardware, build the software, and then maintain it all and hope that you made the right choices and that it will scale. Or, you could use an existing Open Source solution, like Kura from the Eclipse Foundation.
I’ve been playing around with the Samsung ARTIK line of IoT hardware recently, as you may remember, so I decided to see if I could turn my ARTIK-520 into an IoT Gateway in an easy, scalable manner. It was suggested to me that I try the Eclipse Kura project, even though it was not actually supported on ARTIK. I’m not one to be deterred by “It doesn’t work on that hardware” so I decided to give it a go. It took me a few days, and a few meetings with some of the engineers from various parts of the Kura project, but it turned out to be relatively simple and straightforward. So, here are my experiences, and a sort of ‘How To’ to get it working for you, if you’re interested. I’m also going to talk a little bit about some of the strengths, and weaknesses, I see in this approach along the way.
The Hardware
First, about the hardware. I have an ARTIK-520 developer kit. Here’s the rundown on that if you don’t want to go look it up yourself:
- Power efficient dual Cortex®-A7 with Wi-Fi, Bluetooth, ZigBee, Thread
- Leverages Samsung ePoP technology to offer small footprint modules: 30 mm X 25 mm
- 512MB RAM, 4GB flash (eMMC)
- Enterprise class security with hardware secure element and Secure OS
- Fedora Linux® package with connectivity, graphics, power management and security libraries
The actual dev kit has a wired ethernet port (this will be important, so remember this), micro-usb ports, and other stuff too, but I won’t be using most of that in this example. Just follow the excellent “Getting Started” Guide to get your ARTIK-520 board up and running. I used the generic Fedora 25 image from that guide to set up my board. I came at this from several different directions, and had a few false starts along the way as I did so. Here’s how I got the Kura software installed.
The Software
First of all, don’t follow the Kura ‘Getting Started’ guide. It won’t get you started here, which is why I’m not even linking to it. I never did manage to get through that document and end up with anything resembling a working development system for Kura. We’re trying to get Kura running on an ARTIK-520, not build a development system. The docs just didn’t match reality for me on a MacBook Pro. Next, don’t follow the Getting Started Guide here either. Seriously. Or if you do, just do this little piece of it:
DSimmons-Pro:~ $ git clone -b develop https://github.com/eclipse/kura.git kura DSimmons-Pro:~ $ cd kura DSimmons-Pro:kura $ ./build-all.sh
And you’re doing this on your Laptop, not the ARTIK-520 board! Remember that. You don’t want to build all of this on the ARTIK-520 itself. You can if you want, I think, but it will take a very long time, and at least when I was trying it, I had to disable parallel building because there just aren’t the resources to do it. Which is why I advise not doing it.
You’ll need to have Java, and Maven, etc. installed already on your laptop, but those setup instructions are just too convoluted and confusing. At least on my Mac, ‘brew install maven’ was all it took. That build-all script will take a while. And not just a “cup of coffee” while. More like a “go to the gym” while. When it’s finally done, go look in kura.git/kura/distrib/target directory and marvel at all the stuff it created for you.
DSimmons-Pro:kura $ cd kura/distrib/target DSimmons-Pro:target $ ls -l total 4001616
Don’t say I didn’t warn you! It’s a lot. What you’re looking for in this haystack is the file ‘kura_3.0.0-SNAPSHOT_fedora25_installer.sh’ That’s the file you want to move over to the ARTIK-520. Just ftp/sftp/scp it over there, but don’t actually go run it yet! That’s the next section, and you’ll want to read that section before you do the install or you’ll waste a day or so.
The Gateway
As I said, don’t just ssh into the ARTIK-520 board and run that installer. I was connected via the USB Debug port, so I never lost connectivity, but if you’ve set up the WiFi connection on the ARTIK-520, and are ssh-ed in to that when you run the installer, you’ll get a fairly unwelcome surprise. And here’s where that wired ethernet port I mentioned earlier comes back into play — remember, I told you I’d come back to it. You absolutely must have that wired ethernet port connected to your network. And here is where I have to register my only really serious disappointment with, and quarrel with, the Kura software package. So here it is.
When I installed it, I had already set up the ARTIK-520 board, gotten the wireless network set up so I could access it, etc. It’s fairly straightforward to do, and saved me having to find a CAT-5 cable and get that set up. But when I ran the Kura installer, suddenly everything went haywire with my networking. It installed fine, and started up the Kura service fine, but I could no longer get to the box via WiFi. Whiskey, Tango, Foxtrot!? When I began to dig, I noticed that suddenly my WiFi (wlan0) interface had a static IP of some 172,x.x.x range assigned to it, not my WiFi LAN range that it had before. Changed it back, but sooner or later it would revert to this address again. Couldn’t contact the web-UI to configure the box. The dogs learned a whole new set of expletives and swear words that day.
It turns out that the Kura service, upon install, decided that thew WiFi interface was to be used as a new Access Point, so it was given a new IP Address, set up as an Access Point, and started advertising a new SSID all by itself. Without notifying me. Without asking me. I see this as some fairly anti-social behavior and am trying to figure out the exact wording for a bug-report. So far the bug report is NSFW. Adding a new SSID and, essentially a new router, to my network is not playing nice. I decide when a new access point is allowed on my network. I decide when a new router is installed. As I said, pretty anti-social behavior. And just to make sure I wasn’t making an issue out of something that wasn’t a big deal, I ran this scenario past a bunch of other networking and security people I know. To a person, they were all horrified by this behavior. It’s not ok.
Ok, rant over. I’ll climb down off my soapbox.
So, back to the task at hand. You absolutely must have that wired ethernet port setup. Then do the install, then you can connect to the web-UI over the wired ethernet address. And then, and only then, can you actually see the power and versatility of using Kura as your gateway management software. Don’t get the impression from my above displeasure with the hijacking of my network that I dislike Kura. Quite the contrary. I actually like it quite a bit. It’s just that little bit of shenanigans that I’m not fond of.
But if you’ve run the installer, and rebooted your ARTIK-520 and tried to connect you will probably quickly realize that you can’t. Hmmm … You’ll need to make one alteration to the startup script first. so on the ARTIK-520:
[root@localhost ~]# systemctl stop kura.service [root@localhost ~]# cd /opt/eclipse/kura/bin/ [root@localhost bin]# ls start_kura_background.sh start_kura_debug.sh start_kura.sh
Now, edit the start_kura_* scripts and change all the lines that say ‘java -Xms512m -Xmx512m’ to 256m instead. The ARTIK-520 only has 512m of memory (see above) so trying to give every last bit of it to Java results in an outOfMemoryException and a crash. Of course.
Now restart Kura:
[root@localhost bin]# systemctl start kura.service
So now that I’ve got Kura running successfully I can login to the web-UI (username admin, password admin so you’ll want to change that) I actually have a pretty nice management UI that I can use to configure he box itself.
Don’t worry, you won’t have the “Demo” stuff on yours. That’s something else I’m working on for another blog post. I can configure the firewall, I can wrestle control of my WiFi interface back, and a whole host of other things.
Now, if what you’re looking for is a very simple, fast, and effective way of building an Access Point that will set up its own SSID, etc. then, out of the box, Kura is certainly the way to go as it certainly does that.
I’m still working on figuring out how to connect it to a cloud service, and to begin logging sensor data to it, so that will have to wait for another post. I’d also like to try to get this all built as part of a Resin.io deployment model, but I’m not quite there yet either.
Stay tuned!
Hardware Extravaganza
Nov 18th
It’s been a minute since I’ve posted anything new, and I apologize to anyone that follows along here and has missed my posting. I’ve been a bit busy lately with the MyNewt Operating System for IoT. It’s new, it’s cool, and it’s a lot of work right now.
That being said, I thought I’d take a minute to show off some of the new hardware I have to add to the Big Board of IoT on my desk. I’ll start with some stuff I’ve been pounding away at lately with MyNewt OS. No cool unboxing porn for you, as it’s all in heavy use right now.
First we have the trusty STMicro STM32F3DISCOVERY board. Cortex M3 MCU with a bunch of LEDs on the board but no built-in networking. No BLE, no WiFi, nothing.
Next, the one I’ve been working on the most lately, is the Nordic Semi NRF52DK Development Board. This one has BLE built in, and I’ve been doing Bluetooth testing etc. with it. Very capable little board and the Nordic NRF52 is a near-ubiquitous IoT workhorse.
You can see that the LED is lit on that one, and it’s wired up since it’s the one I’m currently using.
Next up is this Arduino M0 Pro. Another Cortex M0-based board, but again, without a radio.
And the one I haven’t gotten running yet, the Olimex STM32-e407. As I said, I haven’t even powered this one on as I seem to have misplaced my JTAG programmer, and the new one just arrived about an hour ago.
But now for the real excitement!! <drum roll please> I splurged a little and got myself a couple of Samsung ARTIK development kits. Now for these, I actually do have some unboxing porn, since they just arrived, and they came in these schwanky boxes.
First the ARTIK 5:
What did I say about the packaging? Sweet!
It’s a box in a box! And there’s a bag in the box!
That’s a big board! With lots of possibilities! Underneath there’s all sorts of cables and external antennas, etc. but I won’t bore you with pictures of that. Mostly because I want to get on to the next one.
The ARTIK 0.
Again with the fancy box!
But no anti-static bag? Huh? Tsk tsk Samsung! It really should be in a bag. Both pieces. This one is really quite exciting, so I put the module on the board and just HAD to power it up.
The little display comes on and everything. That’s about as far as I’ve gotten with it. Hopefully I’ll have some free time soon to play with these new Samsung boards, but I have to get some Mynewt stuff finished first!
Recent Blog Comments