Internet of Things

by Aaron K. on Code, Hardware, Internet of Things

Building and Installing Erlang 18 on a Beaglebone Black

This writeup documents the process I used to install Erlang 18.3 on a Beglebone Black, building for ARM (armv71) architecture.

Setup

The Beaglebone has Debian Wheezy installed, 7.9, from the latest Wheezy image available on the beaglebone site at the time I set it up. I had a terrible time getting Jessie to install cleanly, and I recommend you avoid it for now (may write about those woes elsewhere).

Debian 7.9 (BeagleBone, BeagleBone Black, Seeed BeagleBone Green – 4GB SD) 2015-11-12 sha256sum: f6e67ba01ff69d20f2c655f5e429c3e6c2398123bcd3d8d548460c597275d277

First off, I do this via the serial console, so that I can see all the good stuff that may end up there as the system runs. Plenty of ways to connect, like using a standard 3.3V FTDI cable and the screen command. Handy tip – figure out the rows/cols size of your terminal window, and then throw them into this command to get everything sized right:

[code]
root@beaglebone:~# stty cols 150 rows 70
[/code]

The rest of this is written assuming you are logged in as root.

Dependencies

The Debian image provided on the Beagleboard site has most of the deps already in place, but we need to install the ncurses development files. Also, due to use of newer atomic operations constructs, we need gcc 4.7 to avoid performance issues.

[code]
root@beaglebone:~# apt-get install libncurses5-dev
root@beaglebone:~# apt-get install gcc-4.7
root@beaglebone:~# apt-get install g++-4.7
[/code]

After installing gcc 4.7, it will be living along side version 4.6, so we need to switch things around. The update-alternatives command takes care of symlinking and stuff for us:

[code]
root@beaglebone:~# update-alternatives –install /usr/bin/gcc gcc /usr/bin/gcc-4.6 60 –slave /usr/bin/g++ g++ /usr/bin/g++-4.6
root@beaglebone:~# update-alternatives –install /usr/bin/gcc gcc /usr/bin/gcc-4.7 40 –slave /usr/bin/g++ g++ /usr/bin/g++-4.7
root@beaglebone:~# update-alternatives –config gcc
root@beaglebone:~# gcc –version
gcc (Debian 4.7.2-5) 4.7.2
[/code]

Excellent, the gcc link now points at the correct version.

Building Erlang 18.3

Download the source tarball from the Erlang downloads page, unpack it, delete the tarball to save some space, and jump in:

[code]
root@beaglebone:~# wget http://erlang.org/download/otp_src_18.3.tar.gz
root@beaglebone:~# tar -xvf otp_src_18.3.tar
root@beaglebone:~# rm otp_src_18.3.tar
root@beaglebone:~# cd otp_src_18.3/
[/code]

The next steps are from the Erlang build instructions. You should read that page before you proceed, so you can tweak your build to suit your needs.

[code]
root@beaglebone:~/otp_src_18.3# export ERL_TOP=`pwd`
root@beaglebone:~/otp_src_18.3# ./configure
…lots of configure output, make sure it looks good…
root@beaglebone:~/otp_src_18.3# make
…lots of make output, make sure it looks good…
…grab coffee…
…maybe lunch…
root@beaglebone:~/otp_src_18.3# make release_tests
…and more building, not quite as long…
…refill the coffee…
[/code]

Testing Your Erlang Build

Always good to run the tests when available, and especially when building for a less-common platform. Again, these command still come from the Erlang build docs linked above.

[code]
root@beaglebone:~/otp_src_18.3# cd release/tests/test_server
root@beaglebone:~/otp_src_18.3/release/tests/test_server# $ERL_TOP/bin/erl -s ts install -s ts smoke_test batch -s init stop
…runs tests, get more coffee…
[/code]

Finally we need to check the results of the tests. These are delivered up in a nice interactive HTML page, which would be unfortunate to read on a text console. So, let’s toss a link into the www directory and tweak permissions, then we can see it in a graphical browser over the network.

[code]
root@beaglebone:~# ln -s /root/otp_src_18.3/release/tests/test_server /var/www/erlang
root@beaglebone:~# chmod 755 /root
[/code]

You may want to chmod 700 /root when you are done. You can now access the test results at http://YOUR_BBB_IP_HERE:8080/erlang/ – look them over carefully.

A few tests failed for me. Three in the time suite, univ_to_local, local_to_univ, and consistency. Apparently these only work if the system running them is set to CET timezone where the main Erlang build box lives, and where I don’t live, so no worries here. Also, t_gethostnative in inet suite failed, but reading the test case code it seems to check some odd Windows behaviour. When I test the call by hand in an erl shell, it works fine. Meh, good enough!

Installing Erlang

This is as easy as can be:

[code]
root@beaglebone:~/otp_src_18.3# make install
…lots of make install output here, look it over to see if it worked…
[/code]

And test:

[code]
root@beaglebone:~# erl
Erlang/OTP 18 [erts-7.3] [source] [async-threads:10] [hipe] [kernel-poll:false]

Eshell V7.3 (abort with ^G)
1> io:format("It Lives!~n").
It Lives!
ok
[/code]

Enjoy your fresh new version of Erlang on Beaglebone Black!

 
by Aaron K. on Code, General, Hardware, Internet of Things

Buffalo Unconference 2016 Talk

I gave a talk at Buffalo Unconference today (April 16, 2016). It was this:

Internet of Robots
Beyond the Internet of Things is the Internet of Robots. Let’s discuss the state of the art of IoT/M2M, artificial intelligence, and Robotics, where we are heading, and how to get there.

The gist of it was, some of our biggest challenges are not having good tools (for hardware especially), and existing tech not being able to scale to the forecasted number of devices. In discussion, also touched on the information security nightmare we’re about to see.

You can see the slides on GitHub, if you like:

https://github.com/aaronkondziela/buffalo-unconference-2016

 
by Aaron K. on Hardware, Internet of Things

SPRINGnet

Many moons ago, in the early 1990’s during high school, my friends and I somehow came across three ancient laptops. Back then, we acquired all kinds of weird and wacky stuff, and being poor students, would press anything into service we could manage. I don’t recall the model exactly, but they were something much like a Toshiba T1100, if not one of these exactly, pictured here:

Toshiba T1100

By Johann H. Addicks – own photo, deriving from Gallery, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=1254296

Of course, the first thing to do was get DOS running. Having abandoned DR-DOS a few years prior, we whipped out our ever-handy MS-DOS 6.22 disks and set to work. No problem! Worked first go. Remember when it was that easy? Not so much any more… Of course, the next thing on our agenda was to connect them all together.

What? Network these ancient beasts? And who did that for funsies at home in 1992?? You see, we got into this whole network thing early, being nerds and all. Dialup, Gopher protocol, all that fun stuff. I fondly recall the days spent with Dave trying to make a pair of ISA Ethernet cards work. Thinnet 10Base-2 stuff, RG-58 coax, T-connectors, and terminators… We even had to compile IPX/SPX drivers using some Novell Netware floppies. Massive pain in the ass. Why did we go to all this trouble? Well, it was the classic motivator for any youngins to learn them some high-tech toys – To play Hexen on a LAN in co-op mode, of course. It was worth every second of effort. =) We ended up re-playing Heretic as well, and moved on to Descent. Oh my, I still get vertigo thinking of that game, and I’m not one to suffer from vertigo! So good…

ISA Ethernet

It looked something like this. But crustier. Image by Klaus Eifert – Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=11045803

And before that Ethernetty goodness that we lucked into, we all had our machines wired up with serial cables, between rooms, and between floors of the house. It was tiring having to sneakernet files between machines all the time, and (at the time) damn near impossible when one was a DOS-based 8086 (actually an NEC V30 or V40, the cloned and souped-up version) and the other a Macintosh SE running System 6.0.8. Of course, we would shuffle connections when it was time to fire up the modem (which was ALL the time, duh! MOM! Hang up the phone!!). And that sucked.

So when it came time to network our new-found “laptops”, I got crafty. I figured, well hey we have three of these things, and some desktops we may want to get in the mix, so why not connect them all together at once? Mind you, at the time, Ethernet was still exotic, expensive, and well out of our reach with that one notable exception for Hexen. (Heck this may predate that event; it’s all a bit fuzzy) But, I was pretty handy with RS-232 and RS-422, thanks to a PC, a Mac, and a modem.

So I created SPRINGNet! This stood for Serial Packet Ring Network. Machine A would send to B, which would send to C, which would send back to A. Or however many we had in the ring. Mind you, this was before I had ever even heard of Tokenring, and just seemed the thing to do. Well, it worked! For what applications, you ask? Well, for the roleplaying game engine that we wrote in QuickBasic 4.5. It wasn’t a game by itself, but it facilitated AD&D sessions like a champ (2nd edition FTW). Started out by extending the codebase with the SPRINGNet protocol, which was little more than a message format and an source/destination address, but hey what more do you need?

SPRINGNet diagram

SPRINGNet diagram

After that I extended it to a separate TSR driver that would do the same thing, so that any application could use it. Worked well, but we never made much use of it, primarily because those ancient laptops really sucked. I had big plans to build some hardware accelerator modules for the protocol, since it wasn’t nearly as fast as I’d like for transferring files, implementing all the address detection and packet decoding in software. It was going to be simple, and would simply be a chip that would watch for the address byte, and if it matched the address of the machine/adapter, it would switch the data stream into the serial port instead of pass it on. (We’re talking basic logic chips here, not microcontrollers.) We didn’t have any kind of TTL counter to prevent loops, but would just have the originating machine look for it’s own address as the sender, and drop the packet if it saw it.

Never got around to building the hardware, and moved on to other things. But SPRINGNet lives on fondly in my memories! Even had some door sensors, buttons, and other fun stuff hooked into the ports, what with all those DSR CD CTS etc wires hanging out unused. (RI? Who ever used RI anyhow??) Yes kids, back in the day, our things were all on the Internet (or some kind of net). Take THAT, IoT!

 
by Aaron K. on Code, Hardware, Internet of Things

Delicious IoT Coffee, Part 2 of 3

My second guest article on the Texas Instruments’ e2e site Launch Your Design blog has gone live!

Coffee Temperature Probe

Coffee Temperature Probe

This second of three articles covers component testing, challenging assumptions, and building a temperature probe. You can read it here: https://e2e.ti.com/group/launchyourdesign/b/blog/archive/2016/01/11/an-iot-solution-for-perfect-coffee-part-2

See also Part 1, and the original writeup.

 
by Aaron K. on Code, Hardware, Internet of Things

Delicious IoT Coffee, Part 1 of 3

My first guest article on the Texas Instruments’ e2e site Launch Your Design blog has gone live!

LM35 IoT Coffee

LM35 IoT Coffee

You can read it here: https://e2e.ti.com/group/launchyourdesign/b/blog/archive/2016/01/11/an-iot-solution-for-perfect-coffee-part-1

This is a three-part series, that will discuss the engineering process behind the project I wrote about previously. It goes into developing design constraints, component selection, empirical testing, hardware design and assembly, embedded software design, messaging architecture, and cloud data services. Lots of stuff for tasty coffee, but more hardware-focused detail than the previous writeup at wot.io. I hope you enjoy!

See also Part 2