Things I Find Interesting
Posts tagged Samsung
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
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
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!
Recent Blog Comments