First off: this is not going to be an introduction to VHDL or Verilog, the two languages normally used to define the configuration of an FPGA. There are books for that, it’s a huge field, and yours truly isn’t really versed enough in either of them… not yet, anyway.
Let’s simply explore this whole domain a bit. Enough to get a feel for what’s involved.
At the most basic level, you might expect a structural definition of the entire circuit, i.
↧
The language(s) of FPGAs
↧
TFoC - A wide performance range
(This article is part of the The Fabric of Computing series - “in search of simplicity”)
It’s a tricky business to try and define what constitutes the fabric & essence of computing. But it’s probably reasonable to say that computing is where physics and information meet:
a transistor is not a computing device (but it can be used to create one) likewise, a logic gate is not a computer, but it sure forms part of it a software package (of any kind) is not a computer, but it does run on it So where does the FPGA fit in?
↧
↧
VMs are OUT, Odroid is IN
There are three main internet-facing web servers for JeeLabs - the weblog (jeelabs.org), the community site (jeelabs.net), and the shop (jeelabs.com). The shop is hosted elsewhere and managed by Digital Smarties, the other two have been running each in a separate VM.
This has been the setup until now:
one VM running Nginx for serving some static data and as reverse proxy for the rest one VM running WordPress, Apache, PHP, and MySQL - for the weblog one VM running Redmine, Apache, Ruby On Rails, and MySQL - for forums & wikis Note that three VMs help to cleanly compartmentalise these different systems.
↧
Effortless fallback server
All hardware breaks, occasionally. In the case of a server - it’s usually the storage which fails eventually, be it SD cards, eMMC, an SSD, or a rotating disk (remember those?).
The new server setup at JeeLabs relies completely on a single Odroid XU4 in a CloudShell.
What if it breaks, gets hacked, stolen, or otherwise ceases to work?
Here’s the backup plan: we set up a second server, with fairly modest hardware, and we keep it around for when things turn sour.
↧
Why doesn't this dream setup exist?
The beauty of an all-static website, is that it’s all data, and that it is fully defined by a set of files on the disk. By copying it, or restoring it to some previous state, we can instantly adjust the appearance of the website. No databases to launch, and no application servers.
You would think that static websites are limited-purpose. But what is a weblog, or even a discussion forum, other than a set of pages which occasionally changes during the day?
↧
↧
Getting the most out of rsync
The rsync utility is an amazing workhorse tool: it synchronises file system trees in a very efficient manner, only sending changes in data. Which is particularly useful across a network connection, as it can save dramatically on I/O bandwidth and speed up the whole process, often by several orders of magnitude when compared to a full copy.
Perhaps even more impressive, is that rsync knows how to send changes between binary files when some parts of the data have moved up or down in the file.
↧
Temporary post-HouseMon script
With the original Mac Mini server now decommissioned, this also marks the end of the HouseMon installation here at JeeLabs. In this case, it was the older 0.7.0 release - based on Node.js and written in CoffeeScript - HM 0.7 has served us well, and now it’s gone…
Unfortunately, there is no practical replacement for HouseMon at the moment - yet it sure would be a shame to lose all new readings still coming in from over a dozen wireless sensor nodes.
↧
Great visibility, no cloud in sight
Here is some wonderful art called “Nimbus-Probe” by Berndnaut Smilde, a Dutch artist:
A cloud, captured inside a house - how very appropriate for this article!
With the completion of the recent server migration, and some related changes, JeeLabs is now officially no longer “in” the cloud, i.e. there is no internet server “out there”, involved in serving the JeeLabs.org and JeeLabs.net websites.
Well, up to a point, of course: there is still an ISP in the equation, providing connectivity, the routing of all traffic, and the DNS service.
↧
Preparing for a new weblog
Now that the WordPress-powered JeeLabs weblog has been replaced by a static set of pages, we need a way to continue adding new weblog posts and articles. The current approach is clearly an unsustainable “hack”: there’s still a copy of WP running the original weblog on a local VM, from which a new snapshot is tediously being created once a week.
Luckily, there are many dozens of static website generators to choose from these days.
↧
↧
My New Year's resolutions
It’s that time of year again - the last day of 2015. Another year gone by. A new one waiting in the wings. In an increasingly connected and technocratic world. Time for making plans.
Energy For 2016, my resolution is to reduce our dependence on energy and natural resources further still. The “JeeLabs household” has been a net producer of electricity for the past two years, but there’s still progress to be made:
↧
Sh(r)edding those CDs & DVDs
If you’ve been around for a while, taking in the wonders of “personal computing” as it happened, then you’ll probably also have collected lots of disks with bits on them over the years. It started with floppies, from 8” to 3.5”, and then moved quickly to CD-ROMs and data DVD’s.
Piles of them. Boxes and boxes. As part of some magazine, or even being a magazine.
Here at JeeLabs there were over 500 of them, and that was after a large cleaning session about a decade ago!
↧
Squashing tons of source code
And then came internet, open source software, and public code repositories…
Never before has it been possible to access so much software, of all kinds, in any programming language, for any application, and of all qualities & complexities. Even if not of immediate use “as is”, source code is a phenomenal resource - for knowledge, development ideas, engineering tricks, clever hacks - or simply to learn what others have done and how they have done it.
↧
Keeping track of lab supplies
There’s this nasty thing with electronics: There Are So Many Kinds Of Tiny Little Components!
If you’re into hardware and building circuits, you’ll quickly find out that not only are there so many different resistors, capacitors, semiconductors, chips, sensors, LEDs, actuators, fasteners, wires, and so on… some of those SMD parts are also minuscule! - way too easy to lose track of.
At JeeLabs, there are now about a hundred cardboard boxes filled with little plastic envelopes, mostly from DigiKey, but more and more also ordered directly from China:
↧
↧
A base board for the Hy-Tiny
There are many Arduino “shields” out there, i.e. boards which fit on top of the Arduino Uno and compatibles. Even for one-off prototypes, it may make sense to use this form-factor, as it allows you to re-use a setup with a different µC board underneath (but watch out for 3.3V/5V issues!).
This could be convenient with STM’s low-cost “Nucleo” boards - letting you switch to a different µC if the current one runs out of steam, or doesn’t have all the needed peripherals after all.
↧
Side-stepping the 0.06" mistake
As mentioned before, the one thing standing between an Arduino and convenient protoyping, is that horrid 0.06” mis-alignment of one of its headers.
No longer - meet this almost-too-trivial-for-an-article “Bridge Fifity-Fifty” (BFF) adapter:
Bridge, because that’s all it does - and Fifty Fifty, because that is its size in millimeters.
This is a simple pass-through board to convert in either direction between the Arduino shield header layout, and a layout suitable for numerous prototyping boards with a “sea of holes” on a 0.
↧
JET, as seen from 9,144 meters
The JET project name is an acronyn for “JeeLabs Embello Toolkit”. And with that out of the way, please forget it again and never look back. A few more acronyms will be explained when the subsystems are introduced - none of them particularly fancy or catchy - it’s just because we can’t move forward without naming stuff. Names and terms will be introduced in bold.
As will become clear, this is a long-term project, but not necessarily a big one: this is not about creating a huge system.
↧
Ongoing software development
Ok, with those (somewhat vaguely-defined) requirements down, how do we even start to move in this direction?
Well, we’re going to have to make a number of decisions. We will need to build at least one program / app, of course, and we’re going to need to run it on some hardware. In a product setting (which this is not!), the steps would involve one or more people planning, designing, implementing, and testing the product-to-be.
↧
↧
Architecture: it's all about data!
Code vs. data… there are many ways to go into this oh so important dichotomy.
Here is a famous quote from a famous book, now over four decades old (as you can tell from its somewhat different terminology, i.e. flowcharts <=> code, tables <=> data):
Show me your flowcharts, and conceal your tables, and I shall continue to be mystified; show me your tables and I won’t usually need your flowcharts: they’ll be obvious.
↧
An introduction to JET/Hub
This is the start of a series describing “JET v4”, and in particular the “hub” subsystem. JET is a system which is intended to bring together all the home monitoring and automation tasks here at JeeLabs, for the next 10 years…
As mentioned before - and as its name indicates - “JET/Hub” is the centrepiece of this architecture. It’s the switchboard which sits between the various (and changing) components of the system, including: from serial ports, bridges to Wireless Sensor Networks, and directly-attached I/O hardware, to software-based functionality, e.
↧
Connecting to serial ports
The main mechanisms for communicating between devices around the house in JET are via serial communication and via Ethernet (LAN or WLAN) - often in the form of USB devices acting as virtual serial interfaces. For simple radio modules used for a Wireless Sensor Network, we can then use a USB or WiFi “bridge”.
Other (less common) options are: I2C and SPI hardware interfaces, and direct I/O via either digital or analog “pins”.
↧
