The disconnected life
Jul 20, 2016

On those recent travels across Scandinavia, I had a chance to reset my expectations of what life is like when not “attached to internet” all the time. Quite unlike what I’d imagined, I can tell you.

First off, I was in fact online far more often than I originally had planned, despite having only WiFi connectivity at my disposal (only an iPad, no smartphone, no mobile roaming). Whoa… hotels, café’s, even the trains - WiFi everywhere! Most of them with a captive portal, i.e. you have to click-through to enable it, but only very few ask for any info (i.e. an email address).

The end effect:

  • at least once daily checking of my email (outcome: nothing urgent)
  • regular checking of news sites, mostly nu.nl and theguardian.com
  • daily downloading of each edition of our Dutch newspaper (NRC)
  • very frequent checking of the local weather conditions (!)
  • every few days: finding out where to stay, and making reservations online
  • the iPad was in permanent “don’t disturb” mode, no beeps or pings

Apart from that: nothing! - I deliberately made my email checking a bit inconvenient, by forcing myself to use XS4ALL’s webmail gateway. I never checked any of the techie sites which I normally follow.

One thing I did do in preparation of all this, was to fill up the iPad to the brim with ebooks / PDF’s to read, and podcasts (mostly TED talks) to watch and listen to. Likewise, we arranged to put ten ebooks (the limit, alas) from the local library on Liesbeth’s eReader: DRM stuff, controlled by Adobe Reader - yuck, but hey, it works.

And so that’s how we spent our time while travelling: looking at the scenery, reading, watching TED talks. Plus a bit of small talk with our fellow passengers. No “chats”. No calls. No browsing. No music streaming.

Liesbeth took lots of photos, and emailed a selection as daily diary back to our family. My parents told us later that the first thing they did in the morning was to fire up their computer and read it - enjoying the stories and the views every step along the trip.

It might all sound like business as usual, just at a reduced pace, but it really wasn’t. The one aspect standing out in all this was: no interruptions! - internet did not have any effect on how we spent our days. What a refreshing mindset, to be able to say to the internet “don’t call us, we’ll call you!” :)

Now that we’re back, during the months ahead this summer, I intend to stick to that schedule. Life’s too short for interruptions.

What surprised me most: I’m not interested in hearing about the latest techie news right now, echoing around the walls of all those hacker and maker sites. That too can wait!

For comments, visit the forum.

Scandinavia by rail
Jul 13, 2016

It will not have been obvious from this weblog, since new posts are now automatically published each Wednesday at midnight, but these past few weeks I’ve been on vacation, travelling across Germany, Denmark, Sweden, and Norway - by train, via the same Interrail arrangement I used at the age of 16, eons ago…

Some amazing experiences - from a train-on-the-ferry (!) between Hamburg and Copenhagen, to beautiful single-track trips across mountains, forests, rivers, and lakes (no fjords, we weren’t that close to the sea).

And what to think of an entire train carriage dedicated to families with young kids, with a completely padded play area?

Not visible here, is a large area at the other end with lots of baby buggies…

Slightly more on-topic perhaps, was this wall with the Fibonacci series above a café, for no apparent reason - maybe the building constructor was a mathematician?

That last Fibonacci number is also a prime (thanks to Martyn for pointing this out).

Here is Chalmers university in Göteborg, home of embedded software gems such as the uIP TCP/IP stack and the Contiki RTOS:

Midsummer in Sweden on June 24th was very nice, and so were the half dozen train trips, with lots of views like this:

Credit for all these photographs go to my beloved Liesbeth, who has in fact created a wonderful visual diary of our entire voyage.

Apart from that, lots of city strolls, great meals, and my favourite pastime: reading tons of books, including Eating Animals, Digitale Demenz, Countdown to Zero Day.

Meanwhile, seeing the Brexit meltdown unfold from afar felt totally surreal…

For comments, visit the forum.

Mecrisp on other platforms
Jul 6, 2016

We’ve already seen that Mecrisp Forth is also available for the Nandland Go Board FPGA board.

But Mecrisp Forth can in fact be used on several other platforms.

For one, there’s the MSP430 version (which like the Go Board, is a 16-bit version, not 32-bit as on ARM). Here’s a build using the MSP430G2553 chip, with 16K flash and 512 bytes of RAM:

This one communicates at 9600 baud by default, and has about 5 KB flash free for user code. The neat bit is that it all ends up in an easy-to-use DIP chip, which could readily transfer to your own projects once flashed with working code.

Ken Boak has blogged about a build using the MSP430FR2433 chip with 15.5K FRAM (that’s “Ferro RAM”, which retains its contents on power-down) and 4K RAM.

But the Mecrisp options don’t stop there. There is also a build for 32-bit ARM which runs on Linux. Here’s a demo, running on my home automation server:

$ ssh mohse
jcw@mohse:~$ uname -a
Linux mohse 3.8.13.30 #1 SMP PREEMPT [...] armv7l armv7l armv7l GNU/Linux
jcw@mohse:~$ mecrisp
Mecrisp-Stellaris RA 2.2.7 for Linux by Matthias Koch
ok.

As of Mecrisp 2.2.7, this version runs really well (an important cache bug was fixed by Matthias recently). In fact, it fully supports the way flash and RAM memory areas are implemented on embedded µC’s, including “flash erasure” and the cornerstone word. The one major difference of course, is that we’re now running under the Linux OS, and have no direct access to hardware. Instead, there’s a syscall word, which can be used to implement system calls to Linux.

One use which I intend to explore, is as test environment with a TDD approach. The speed of this setup should be a huge time-saver - both for uploading new code and for running it.

The Folie terminal front-end utility now also supports remote execution using SSH:

$ folie -x ssh mohse bin/mecrisp
Connected to: (ssh mohse bin/mecrisp)
Mecrisp-Stellaris RA 2.2.7 for Linux by Matthias Koch
ok.
: a 0 do loop ;  ok.
1000000000 a  ok.
^D
$

This is a quad-core Odroid C1 running at 2 GHz. That 1,000,000,000x loop takes under 1 second, so the loop cycle time in Forth is under 1 ns.

Now watch this:

$ ssh debbix uname -a
Linux debbix 3.16.0-4-amd64 #1 SMP Debian [...] GNU/Linux
$ folie -x ssh debbix bin/mecrisp
Connected to: (ssh debbix bin/mecrisp)
Mecrisp-Stellaris RA 2.2.7 for Linux by Matthias Koch
ok.
: a 0 do loop ;  ok.
1000000000 a  ok.
^D
$

Marginally slower, roughly 1.5 sec for the same loop. But there is something very unusual going on here: this is a virtual machine running on my MacBook Pro laptop. How can an Intel 64-bit x86 chip run ARM binaries?

$ ssh debbix
jcw@debbix:~$ file bin/mecrisp
bin/mecrisp: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), \
                                        statically linked, not stripped
jcw@debbix:~$ ls /usr/bin/qemu-
qemu-aarch64-static       qemu-mips64-static        qemu-s390x-static
qemu-alpha-static         qemu-mipsel-static        qemu-sh4eb-static
qemu-armeb-static         qemu-mipsn32el-static     qemu-sh4-static
qemu-arm-static           qemu-mipsn32-static       qemu-sparc32plus-static
qemu-cris-static          qemu-mips-static          qemu-sparc64-static
qemu-i386-static          qemu-or32-static          qemu-sparc-static
qemu-m68k-static          qemu-ppc64abi32-static    qemu-unicore32-static
qemu-microblazeel-static  qemu-ppc64le-static       qemu-x86_64-static
qemu-microblaze-static    qemu-ppc64-static         
qemu-mips64el-static      qemu-ppc-static           
jcw@debbix:~$ mecrisp
Mecrisp-Stellaris RA 2.2.7 for Linux by Matthias Koch
ok.

It’s all done by Qemu, an open source emulator for dozens of different CPU architectures (see the list above). And by installing qemu-user-static, something very clever happens: when a binary executable is launched which does not match the host architure, Qemu is transparantly started to take over. It emulates the processor, and passes all the Linux system calls through to the host. The effect is truly magical: if you have all the necessary shared libraries installed (using the “multiarch” mechanism), any binary will work just as if it was running on that specific CPU!

So there you have it: Mecrisp Forth runs in lots of places, which is perfect to try it out and play with it - whether embedded, with serial uploads (and freezes), or under Linux, with instant uploads (and harmless premature quits).

And if you want to look into a (large!) implementation of Forth, check out gforth - it’s available as standard package for just about every Linux distribution, as well as Windows and Mac OSX.

The development “feeling” you get from running code interactively, the ability to peek and poke at actual hardware, and the concise way in which an application can be implemented are unique to Forth, and yet it fits on some of the smallest µC’s:

(from Leo Brodie’s “Thinking Forth” book)

Some more resources for getting into Forth:

Forth is not mainstream / hype of the day, but oodles of fun - and amazingly effective!

For comments, visit the forum.

Weblog © Jean-Claude Wippler. Generated by Hugo.