It’s all coming together now.
Now, this “screenshot” took some “duct tape” and “grease” to put together. It can be summed up in three categories.
Setting up cron to periodically collet data from a sensor. This (plan9) being a distributed system, has its quirks. One of them was to run cron on a standalone system, since cron is meant to be run on an auth server and log into a designated machine and remotely execute a command there. So, a hacky script was developed to run cron only once from the system owner’s profile file.
Processing and plotting collected data. All glory to the power of the “old school” publishing tools (grap | pic | troff | gs), but it got done in the end. Once an image of a plot was coaxed from the pipeline, it still needed base64 utility, which the internet provided.
And wrapping everything up in a werc app to serve it on a page.
Well, there is an rc script doing the publishing tool chain on the collected data inside the werc app. But the point is, it works!
Another month, another file system.
Something a bit more interesting this time. An environmental sensors, to be connected to the humble “server”: bme680.
Though, it needs to be said, this one brought back memories of disdain of dealing with datasheets. Now, nothing wrong with them, in fact, they are extremely useful. But you can’t help to wonder what the intern was like, who obviously landed the “challenge” of preparing the documentation. We’ve all been there, right? (No? Just me?). But you know it’s true, when you have to go scrounge through their official Arduino library to figure out the type of the data read from the built-in registers.
Oh, and I burned the sensor too. How nice, that the datasheet notices that the provided API runs the sensors at 1Hz at max in continuous mode for testing. Not that this is the maximum you should stress the heating element at. Guess who opened the “file” with the data multiple times a second.
And the application note is even more hilarious. For the sensor self test, just make the measurements and if the calculated temperature is between 0°C and 60°C the sensor probably works. Not, by any chance because that would be useful, what are the possible raw bits from the sensor before the conversions, calibrations correction and calculations, to narrow down where the problem resides.
This one was fun! To be continued when the new sensor arrives.
Deeper and deeper in to the “source” we go.
A quick dip in to the “filesystem way” of things on Plan9, by writing our own Plan9 protocol (p9) file system for a TM1650 7-segment display driver: tm1650fs.
Every long data transfer starts with a single bit.
There is a goal to all this randomness. To “work out my embedded development muscle”.
So, before we start straight up porting plan9 to other devices, let’s try and poke around a working system first and see what is where.
And sorting out and using I2C on a Raspberry Pi 1 seamed like a good start. A lot has been done here already, so it’s a soft start.
Sorting through it and writing it down for anyone interested: notes/plan9/i2c.
With a first success in compiling a custom kernel and poking around a bme680 sensor.
A few changes and we have the basic site up in a pretty decent shape.
Sadly, can’t do anything more for the performance. It is what it is, for a (let’s be generous) “server” running a niche OS on a first generation Raspberry Pi.
To get it this far:
create pub and lib directories in _werc directory of the site
generate all other possible versions of favicon icons (ios, android, …), add them somewhere unobtrusive (eg. _werc/pub/) and create a file headers.inc in ___werc/lib__ and add the definitions:
<link rel="apple-touch-icon" sizes="180x180" href="/_werc/pub/apple-touch-icon.png"> <link rel="icon" type="image/png" sizes="32x32" href="/_werc/pub/favicon-32x32.png"> <link rel="icon" type="image/png" sizes="16x16" href="/_werc/pub/favicon-16x16.png"> <link rel="manifest" href="/_werc/pub/site.webmanifest">while editing headers.inc add the definition for device width:
<meta name="viewport" content="width=device-width, initial-scale=1">This will make the best practices score happy.
copy over headers.tpl from werc/lib to _werc/lib of the site and change
<html>to
<html lang="en">This will make the accessibility score happy.
edit your _werc/config and add meta description:
meta_description='A collection of notes on various topics.'This will make the SEO score happy.
All this could be done in headers.tpl, but the system is configurable, so let’s use the options.
To make the barf blog plugin for werc work as a subfolder, we need to patch it up to correctly parse the slug when it’s not attached to the domain root: diff
Now, add top_bar.inc and footer.inc to your _werc/lib to add page header and footer content.
And for custom styles, create style.css in your _werc/pub folder.
So, the time has come to scrape together a system for publishing, as we set out to do.
For the base, so far, we have a 9front installed on a first generation Raspberry Pi. For hosting, we’ll use rc-httpd web server, distributed with 9front. For content management we’ll use the Werc framework, used by other plan9 / 9front related sites, with barf plugin for blog and other nifty things.
Not to go into too many details here, since this is a learning experience and information will be improved over time (I’m sure), so notes for web are available separately.
In short, how we got this working so far:
- (optionally) a new user was created (gotta figure out administration of this thing)
- werc was installed by cloning it with hg from https://code.9front.org/hg/werc
- werc was configured by creating appropriate folders in werc/sites dir
- barf plugin was installed by cloning it with hg from https://code.9front.org/hg/barf in to werc/apps dir
- barf was configured by creating the appropriate folders and files in _werc subfolder
- rc-https was configured (/bin/service/tcp80) to run werc on request
- example files can be found in werc/bin/contrib (tcp80 & rc-httpd/select-handler) or on the werc docs
- since services in /bin/service are run as an “unprivileged” user none, with no privileges (duh) and werc needs to access to tmp files cor cache or its unhappy, configure the namespace for the service (/bin/service/tcp80.namespace) to include a “world” writable folder binded to /tmp
That got us a working set up, that we can now play around with, and do the “timey wimey” magic and “back port” some notes and posts.