mirror of
https://github.com/wezm/wezm.net.git
synced 2024-11-10 01:42:32 +00:00
Finish lca2019 post
This commit is contained in:
parent
20c7413375
commit
a12f0395d0
12 changed files with 229 additions and 153 deletions
80
Gemfile.lock
80
Gemfile.lock
|
|
@ -1,31 +1,31 @@
|
|||
GEM
|
||||
remote: https://rubygems.org/
|
||||
specs:
|
||||
addressable (2.5.2)
|
||||
addressable (2.6.0)
|
||||
public_suffix (>= 2.0.2, < 4.0)
|
||||
adsf (1.4.0)
|
||||
adsf (1.4.1)
|
||||
rack (>= 1.0.0, < 3.0.0)
|
||||
bitly (1.1.0)
|
||||
bitly (1.1.2)
|
||||
httparty (>= 0.7.6)
|
||||
multi_json (~> 1.3)
|
||||
oauth2 (>= 0.5.0, < 2.0)
|
||||
builder (3.2.3)
|
||||
coderay (1.1.2)
|
||||
colored (1.2)
|
||||
concurrent-ruby (1.0.5)
|
||||
cri (2.13.0)
|
||||
concurrent-ruby (1.1.4)
|
||||
cri (2.15.3)
|
||||
colored (~> 1.2)
|
||||
ddmemoize (1.0.0)
|
||||
ddmetrics (~> 1.0)
|
||||
ref (~> 2.0)
|
||||
ddmetrics (1.0.1)
|
||||
ddplugin (1.0.2)
|
||||
faraday (0.12.2)
|
||||
faraday (0.15.4)
|
||||
multipart-post (>= 1.2, < 3)
|
||||
ffi (1.9.25)
|
||||
ffi (1.10.0)
|
||||
formatador (0.2.5)
|
||||
fssm (0.2.10)
|
||||
guard (2.14.2)
|
||||
guard (2.15.0)
|
||||
formatador (>= 0.2.4)
|
||||
listen (>= 2.7, < 4.0)
|
||||
lumberjack (>= 1.0.12, < 2.0)
|
||||
|
|
@ -35,72 +35,73 @@ GEM
|
|||
shellany (~> 0.0)
|
||||
thor (>= 0.18.1)
|
||||
guard-compat (1.2.1)
|
||||
guard-nanoc (2.1.3)
|
||||
guard-nanoc (2.1.4)
|
||||
guard (~> 2.8)
|
||||
guard-compat (~> 1.0)
|
||||
nanoc (>= 4.3.8, < 5.0)
|
||||
haml (5.0.3)
|
||||
haml (5.0.4)
|
||||
temple (>= 0.8.0)
|
||||
tilt
|
||||
hamster (3.0.0)
|
||||
concurrent-ruby (~> 1.0)
|
||||
httparty (0.15.6)
|
||||
httparty (0.16.3)
|
||||
mime-types (~> 3.0)
|
||||
multi_xml (>= 0.5.2)
|
||||
jwt (1.5.6)
|
||||
json_schema (0.20.1)
|
||||
jwt (2.1.0)
|
||||
listen (3.1.5)
|
||||
rb-fsevent (~> 0.9, >= 0.9.4)
|
||||
rb-inotify (~> 0.9, >= 0.9.7)
|
||||
ruby_dep (~> 1.2)
|
||||
lumberjack (1.0.13)
|
||||
method_source (0.9.0)
|
||||
mime-types (3.1)
|
||||
method_source (0.9.2)
|
||||
mime-types (3.2.2)
|
||||
mime-types-data (~> 3.2015)
|
||||
mime-types-data (3.2016.0521)
|
||||
mini_portile2 (2.3.0)
|
||||
multi_json (1.12.2)
|
||||
mime-types-data (3.2018.0812)
|
||||
mini_portile2 (2.4.0)
|
||||
multi_json (1.13.1)
|
||||
multi_xml (0.6.0)
|
||||
multipart-post (2.0.0)
|
||||
nanoc (4.9.3)
|
||||
nanoc (4.11.0)
|
||||
addressable (~> 2.5)
|
||||
cri (~> 2.8)
|
||||
cri (~> 2.15)
|
||||
ddmemoize (~> 1.0)
|
||||
ddmetrics (~> 1.0)
|
||||
ddplugin (~> 1.0)
|
||||
hamster (~> 3.0)
|
||||
json_schema (~> 0.19)
|
||||
parallel (~> 1.12)
|
||||
ref (~> 2.0)
|
||||
slow_enumerator_tools (~> 1.0)
|
||||
tomlrb (~> 1.2)
|
||||
nenv (0.3.0)
|
||||
nokogiri (1.8.1)
|
||||
mini_portile2 (~> 2.3.0)
|
||||
nokogiri (1.10.1)
|
||||
mini_portile2 (~> 2.4.0)
|
||||
notiffany (0.1.1)
|
||||
nenv (~> 0.1)
|
||||
shellany (~> 0.0)
|
||||
oauth2 (1.4.0)
|
||||
faraday (>= 0.8, < 0.13)
|
||||
jwt (~> 1.0)
|
||||
oauth2 (1.4.1)
|
||||
faraday (>= 0.8, < 0.16.0)
|
||||
jwt (>= 1.0, < 3.0)
|
||||
multi_json (~> 1.3)
|
||||
multi_xml (~> 0.5)
|
||||
rack (>= 1.2, < 3)
|
||||
parallel (1.12.1)
|
||||
pry (0.11.3)
|
||||
parallel (1.13.0)
|
||||
pry (0.12.2)
|
||||
coderay (~> 1.1.0)
|
||||
method_source (~> 0.9.0)
|
||||
public_suffix (3.0.3)
|
||||
rack (2.0.3)
|
||||
rake (12.1.0)
|
||||
rack (2.0.6)
|
||||
rake (12.3.2)
|
||||
rb-fsevent (0.10.3)
|
||||
rb-inotify (0.9.10)
|
||||
ffi (>= 0.5.0, < 2)
|
||||
rb-kqueue (0.2.5)
|
||||
ffi (>= 0.5.0)
|
||||
rb-inotify (0.10.0)
|
||||
ffi (~> 1.0)
|
||||
rdiscount (2.2.0.1)
|
||||
ref (2.0.0)
|
||||
rouge (3.2.1)
|
||||
rouge (3.3.0)
|
||||
ruby_dep (1.5.0)
|
||||
rubypants (0.6.0)
|
||||
sass (3.5.1)
|
||||
rubypants (0.7.0)
|
||||
sass (3.7.3)
|
||||
sass-listen (~> 4.0.0)
|
||||
sass-listen (4.0.0)
|
||||
rb-fsevent (~> 0.9, >= 0.9.4)
|
||||
|
|
@ -109,9 +110,9 @@ GEM
|
|||
slow_enumerator_tools (1.1.0)
|
||||
systemu (2.6.5)
|
||||
temple (0.8.0)
|
||||
thor (0.20.0)
|
||||
tilt (2.0.8)
|
||||
tomlrb (1.2.7)
|
||||
thor (0.20.3)
|
||||
tilt (2.0.9)
|
||||
tomlrb (1.2.8)
|
||||
|
||||
PLATFORMS
|
||||
ruby
|
||||
|
|
@ -128,7 +129,6 @@ DEPENDENCIES
|
|||
nanoc (~> 4.0)
|
||||
nokogiri
|
||||
rake
|
||||
rb-kqueue (>= 0.2)
|
||||
rdiscount
|
||||
rouge
|
||||
rubypants
|
||||
|
|
@ -136,4 +136,4 @@ DEPENDENCIES
|
|||
systemu
|
||||
|
||||
BUNDLED WITH
|
||||
1.16.3
|
||||
1.17.2
|
||||
|
|
|
|||
|
|
@ -1,23 +1,31 @@
|
|||
This week I attended linux.conf.au (for the first time) in Christchurch, New
|
||||
This week I attended [linux.conf.au] (for the first time) in Christchurch, New
|
||||
Zealand. It's a week long conference covering Linux, open open source software
|
||||
and hardware, privacy, security and much more. The theme this year was [IoT].
|
||||
In line with the theme I built a digital conference badge to take to the
|
||||
conference. It used a tri-colour e-Paper display and was powered by a Rust
|
||||
program I built running on Raspbian Linux. This post describes how it was
|
||||
built, how it works, and how it fared at the conference.
|
||||
program I built running on [Raspbian Linux][Raspbian]. This post describes how
|
||||
it was built, how it works, and how it fared at the conference. The [source
|
||||
code is on GitHub][source].
|
||||
|
||||
### Building
|
||||
<figure>
|
||||
<a href="/images/2019/badge-at-end-of-conference.jpg"><img src="/images/2019/badge-at-end-of-conference_thumb.jpg" width="600" alt="The badge in its final state after the conference." /></a>
|
||||
<figcaption>The badge in its final state after the conference</figcaption>
|
||||
</figure>
|
||||
|
||||
## Building
|
||||
|
||||
After booking my tickets in October I decided I wanted to build a digital
|
||||
conference badge. I'm not entirely sure what prompted me to do this but it was
|
||||
a combination of seeing projects like the [BADGEr] in past, the theme of
|
||||
a combination of seeing projects like the [BADGEr] in the past, the theme of
|
||||
linux.conf.au 2019 being IoT, and an excuse to write more Rust. Since it was
|
||||
ostensibly a Linux conference it also seemed appropriate for it to run Linux.
|
||||
|
||||
Over the next few weeks I collected the parts and adaptors to build the badge. The main components were:
|
||||
Over the next few weeks I collected the parts and adaptors to build the badge.
|
||||
The main components were:
|
||||
|
||||
* [Raspberry Pi Zero W] - AU$15.00
|
||||
* [Pimoroni Inky pHAT] e-Paper display - AU$38.00
|
||||
* [Raspberry Pi Zero W] — AU$15.00
|
||||
* [Pimoroni Inky pHAT] e-Paper display — AU$38.00
|
||||
* 4800mAh/3.7V USB battery pack that I already owned
|
||||
|
||||
The Raspberry Pi Zero W is a single core 1Ghz ARM SoC with 512Mb RAM, Wi-FI,
|
||||
Bluetooth, microSD card slot, and mini HDMI. The Inky pHAT is a 212x104 pixel
|
||||
|
|
@ -25,40 +33,35 @@ tri-colour (red, black, white) e-Paper display. It takes about 15 seconds to
|
|||
refresh the display but it draws very little power in between updates and the
|
||||
image persists even when power is removed.
|
||||
|
||||
I powered the badge with a several year old 4800mAh USB battery pack that I
|
||||
already owned. Some rough calculations suggested that it should run for many
|
||||
hours on this battery but I didn't actually test this until day 1 of the
|
||||
conference.
|
||||
|
||||
### Support Crates
|
||||
|
||||
The first part of the project involved building a Rust driver for the
|
||||
controller in the e-Paper display. That involved determining what controller
|
||||
the display used, as Pimoroni did not document the display they used for the
|
||||
Inky pHAT. Searching online for some of the comments in the Python driver
|
||||
suggested the display was possibly a HINK-E0213A07 - Electronic Paper display
|
||||
from Holitech Co. Further searching based on [the datasheet for that
|
||||
display][HINK-E0213A07] suggested that the controller was a [Solomon Systech
|
||||
SSD1675][SSD1675]. Cross referencing the display datasheet, [SSD1675
|
||||
datasheet], and the [Python source of Pimoroni's Inky pHAT
|
||||
driver][https://github.com/pimoroni/inky] suggested I was on the right track.
|
||||
the display used, as Pimoroni did not document it. Searching online for some of
|
||||
the comments in [the Python driver][inky] suggested the display was possibly a
|
||||
HINK-E0213A07 from Holitech Co. Further searching based on [the datasheet for
|
||||
that display][HINK-E0213A07] suggested that the controller was a [Solomon
|
||||
Systech SSD1675][SSD1675]. Cross referencing the display datasheet, [SSD1675
|
||||
datasheet], and the [Python source of Pimoroni's Inky pHAT driver][inky]
|
||||
suggested I was on the right track.
|
||||
|
||||
I set about building the Rust driver for the SSD1675 using the [embedded HAL
|
||||
traits]. These traits allow embedded Rust drivers to be built against a
|
||||
defacto-standard set of traits that allow the driver to be used in any
|
||||
environment that implements the traits. For example I make use of traits for
|
||||
[SPI] devices, and [GPIO] pins, which are implemented for
|
||||
[Linux][embedded-linx], as well as say, [STM32 dev boards]. This allows the
|
||||
driver to be written once and be potentially usable on may different devices.
|
||||
traits][embedded-hal]. These traits allow embedded Rust drivers to be built
|
||||
against a de facto standard set of traits that allow the driver to be used in
|
||||
any environment that implements the traits. For example I make use of traits
|
||||
for [SPI] devices, and [GPIO] pins, which are implemented for
|
||||
[Linux][linux-embedded-hal], as well as say, [the STM32F30x family of
|
||||
microcontrollers][stm32f30x-hal]. This allows the driver to be written once and
|
||||
used on many devices.
|
||||
|
||||
The result was the [ssd1675 crate]. It's a so called no-std crate. That means
|
||||
it does not use the Rust standard library, instead sticking only to the core
|
||||
library. This allows the crate to be used in devices and microcontrollers
|
||||
library. This allows the crate to be used on devices and microcontrollers
|
||||
without features like file systems, or heap allocators. The crate also makes
|
||||
use of the [embedded-graphics crate][embedded-graphics], which makes it easy to
|
||||
draw text and basic shapes on the display in a memory efficient manner.
|
||||
|
||||
Whilst testing the ssd1675 crate I also built another crate, [profont], which
|
||||
While testing the ssd1675 crate I also built another crate, [profont], which
|
||||
provides 7 sizes of the [ProFont font] for embedded graphics. The profont crate
|
||||
was published 24 Nov 2018, and ssd1675 was published a month later on 26 Dec
|
||||
2018.
|
||||
|
|
@ -68,62 +71,116 @@ was published 24 Nov 2018, and ssd1675 was published a month later on 26 Dec
|
|||
Now that I had all the prerequisites in place I could start working on the
|
||||
badge proper. I had a few goals for the badge and its implementation:
|
||||
|
||||
* I wanted the badge to have some interactive component.
|
||||
* I wanted it to have some interactive component.
|
||||
* I wanted there to be some sort of Internet aspect to tie in with the IoT
|
||||
theme of the conference.
|
||||
* I wanted the badge to be entirely powered by a single, efficient Rust binary,
|
||||
that did not shell out to other commands, or anything like that.
|
||||
that did not shell out to other commands or anything like that.
|
||||
* Ideally it would be relatively power efficient.
|
||||
|
||||
<figure>
|
||||
<img src="/images/2019/badge-early-revision_thumb.jpg" width="600" alt="Photo of e-Paper display showing my name, websize, IP address and uname information." />
|
||||
<a href="/images/2019/badge-early-revision.jpg"><img src="/images/2019/badge-early-revision_thumb.jpg" width="600" alt="An early revision of the badge from 6 Jan 2019 showing my name, website, badge IP, and kernel info." /></a>
|
||||
<figcaption>An early revision of the badge from 6 Jan 2019</figcaption>
|
||||
</figure>
|
||||
|
||||
I settled on having the badge program serve up a web page with some information
|
||||
about the project, myself, and some live stats of the Raspberry Pi (uptime,
|
||||
free RAM, etc.). The plain text version of the page looked like this:
|
||||
about the project, myself, and some live stats of the Raspberry Pi (OS, kernel,
|
||||
uptime, free RAM). The plain text version of the page looked like this:
|
||||
|
||||
[Insert sample response hre]
|
||||
Hi I'm Wes!
|
||||
|
||||
The interactive part came in the form of a virtual 'hi' counter. Each HTTP POST
|
||||
to the `/hi` endpoint incremented the count, which was shown on the badge. The
|
||||
badge showed a URL to access in order to view the page, the URL was just the
|
||||
badge's IP address on the conference Wi-Fi. To provide a little protection
|
||||
against abuse I added code that only allowed a give IP to increment the count
|
||||
once per hour.
|
||||
Welcome to my conference badge. It's powered by Linux and
|
||||
Rust running on a Raspberry Pi Zero W with a tri-colour Inky
|
||||
pHAT ePaper dispay. The source code is on GitHub:
|
||||
|
||||
When building the badge software these are some of the details and goals I implemented:
|
||||
https://github.com/wezm/linux-conf-au-2019-epaper-badge
|
||||
|
||||
* Wi-Fi going away
|
||||
* IP address changing
|
||||
* Memory use of large POSTs (don
|
||||
|
||||
Say Hello
|
||||
---------
|
||||
|
||||
12 people have said hi.
|
||||
|
||||
Say hello in person and on the badge. To increment the hello
|
||||
counter on the badge:
|
||||
|
||||
curl -X POST http://10.0.0.18/hi
|
||||
|
||||
|
||||
About Me
|
||||
--------
|
||||
|
||||
I'm a software developer from Melbourne, Australia. I
|
||||
currently work at GreenSync building systems to help make
|
||||
better use of renewable energy.
|
||||
|
||||
Find me on the Internet at:
|
||||
|
||||
Email: wes@wezm.net
|
||||
GitHub: https://github.com/wezm
|
||||
Mastodon: https://mastodon.social/@wezm
|
||||
Twitter: https://twitter.com/wezm
|
||||
Website: http://www.wezm.net/
|
||||
|
||||
|
||||
Host Information
|
||||
----------------
|
||||
|
||||
(_\)(/_) OS: Raspbian GNU/Linux
|
||||
(_(__)_) KERNEL: Linux 4.14.79+
|
||||
(_(_)(_)_) UPTIME: 3m
|
||||
(_(__)_) MEMORY: 430.3 MB free of 454.5 MB
|
||||
(__)
|
||||
|
||||
|
||||
.------------------------.
|
||||
| Powered by Rust! |
|
||||
'------------------------'
|
||||
/
|
||||
/
|
||||
_~^~^~_
|
||||
\) / o o \ (/
|
||||
'_ - _'
|
||||
/ '-----' \
|
||||
|
||||
The interactive part came in the form of a virtual "hello" counter. Each HTTP
|
||||
POST to the `/hi` endpoint incremented the count, which was shown on the badge.
|
||||
The badge displayed the URL of the page. The URL was just the badge's IP
|
||||
address on the conference Wi-Fi. To provide a little protection against abuse I
|
||||
added code that only allowed a given IP to increment the count once per hour.
|
||||
|
||||
When building the badge software these are some of the details and things I
|
||||
strived for:
|
||||
|
||||
* Handle Wi-Fi going away
|
||||
* Handle IP address changing
|
||||
* Prevent duplicate submissions
|
||||
* Pluralisation of text on the badge and on the web page
|
||||
* Automatically shift the text as the count requires more digits
|
||||
* If the web page is requested with an `Accept` header that doesn't include
|
||||
`text/html` (E.g. `curl`) then the response is plain text and the method to
|
||||
"say hello" is a curl command. If the user agent indicates they accept HTML
|
||||
then the page is HTML and conttains a form with a button to, "say hello".
|
||||
* Serve plain text and HTML pages:
|
||||
* If the web page is requested with an `Accept` header that doesn't include
|
||||
`text/html` (E.g. `curl`) then the response is plain text and the method to,
|
||||
"say hello", is a `curl` command.
|
||||
* If the user agent indicates they accept HTML then the page is HTML and
|
||||
contains a form with a button to, "say hello".
|
||||
* Avoid aborting on errors:
|
||||
* I kind of ran out of time to handle all errors well, but most are handled
|
||||
gracefully and won't abort the program. In some cases a default is used in
|
||||
the face of an eror. In other cases I just resorted to logging a mesasge and
|
||||
the face of an error. In other cases I just resorted to logging a message and
|
||||
carrying on.
|
||||
* Keep memory usage low:
|
||||
* The web server efficiently discards any large POST requests sent to it, to
|
||||
avoid exhausing RAM. Typical RAM stats showed around 420Mb free of the
|
||||
512Mb most of the time, of which some is taken for the GPU. The Rust
|
||||
program itself using about 4Mb.
|
||||
* Be relatively power efficient
|
||||
avoid exhausting RAM.
|
||||
* Typical RAM stats showed the Rust program using about 3Mb of RAM.
|
||||
* Be relatively power efficient:
|
||||
* Use Rust instead of a scripting language
|
||||
* Only update the display when something it's showing changes
|
||||
* Only check for changes every 15 seconds (the rest of the time that tread just slept)
|
||||
* Only check for changes every 15 seconds (the rest of the time that thread just sleeps)
|
||||
* Put the display into deep sleep after updating
|
||||
|
||||
I used [hyper] for the HTTP server. To get a feel for the limits of the device
|
||||
I did some rudimentary HTTP benchmarking with [wrk] and concluded that 300 requests
|
||||
per second was was probably going to be fine. ;)
|
||||
I used [hyper] for the HTTP server built into the binary. To get a feel for the
|
||||
limits of the device I did some rudimentary HTTP benchmarking with [wrk] and
|
||||
concluded that 300 requests per second was was probably going to be fine. `;-)`
|
||||
|
||||
Running 10s test @ http://10.0.0.18:8080/
|
||||
4 threads and 100 connections
|
||||
|
|
@ -136,41 +193,38 @@ per second was was probably going to be fine. ;)
|
|||
|
||||
### Mounting
|
||||
|
||||
When I started the project I imagined it would hang it around my neck like
|
||||
conference lanyard. When departure day arrived I still hadn't worked out how
|
||||
this would work in practice (power delivery being a major concern). In the end
|
||||
I settled on attaching it to the strap on my backpack. My bag has lots of
|
||||
When I started the project I imagined it would hang it around my neck like a
|
||||
conference lanyard. By the time departure day arrived I still hadn't worked out
|
||||
how this would work in practice (power delivery being a major concern). In the
|
||||
end I settled on attaching it to the strap on my backpack. My bag has lots of
|
||||
webbing so there were plenty of loops to hold it in place. I was also able to
|
||||
use the velcro covered holes intended for water tubes to get the cable neatly
|
||||
use the Velcro covered holes intended for water tubes to get the cable neatly
|
||||
into the bag.
|
||||
|
||||
## At the Conference
|
||||
|
||||
I had everything pretty much working for the start of the conference, although
|
||||
I did make some final improvements and add a systemd unit to automatically start
|
||||
and restart the Rust binary once I arrived in my accommodation on the Sunday
|
||||
before the conference. At this point there were still two unknowns: battery
|
||||
life and how the Raspberry Pi would handle coming in and out of Wi-Fi range.
|
||||
The Wi-Fi turned out fine: automatically reconnecting whenever it came into
|
||||
range of the Wi-Fi.
|
||||
I had everything pretty much working for the start of the conference. Although
|
||||
I did make some improvements and add a [systemd unit] to automatically start
|
||||
and restart the Rust binary. At this point there were still two unknowns:
|
||||
battery life and how the Raspberry Pi would handle coming in and out of Wi-Fi
|
||||
range. The Wi-Fi turned out fine: It automatically reconnected whenever it
|
||||
came into range of the Wi-Fi.
|
||||
|
||||
<figure>
|
||||
<img src="/images/2019/badge-sunday-night_thumb.jpg" width="600" alt="Badge display a count of zero." />
|
||||
<a href="/images/2019/badge-sunday-night.jpg"><img src="/images/2019/badge-sunday-night_thumb.jpg" width="600" alt="Badge displaying a count of zero." /></a>
|
||||
<figcaption>Ready for day 1</figcaption>
|
||||
</figure>
|
||||
|
||||
### Reception
|
||||
|
||||
At this point I had not had time to test battery life, so day one I hooked it
|
||||
up and hoped for the best. Day 1 was a success! I had my first few people talk
|
||||
to me about the badge and increment the counter. Battery life was good too.
|
||||
After 12 hours of uptime the battery was still showing it was half full. Later
|
||||
in the week I left the badge running overnight to hit 24 hours uptime. The
|
||||
battery level indicator was on the last light so I suspect there wasn't much
|
||||
juice left.
|
||||
Day 1 was a success! I had several people talk to me about the badge and
|
||||
increment the counter. Battery life was good too. After 12 hours of uptime the
|
||||
battery was still showing it was half full. Later in the week I left the badge
|
||||
running overnight and hit 24 hours uptime. The battery level indicator was on
|
||||
the last light so I suspect there wasn't much juice left.
|
||||
|
||||
<figure>
|
||||
<img src="/images/2019/badge-first-hello_thumb.jpg" width="600" alt="Badge display showing a hello count of 1." />
|
||||
<a href="/images/2019/badge-first-hello.jpg"><img src="/images/2019/badge-first-hello_thumb.jpg" height="600" alt="Me with badge display showing a hello count of 1." /></a>
|
||||
<figcaption>Me after receiving my first hello on the badge</figcaption>
|
||||
</figure>
|
||||
|
||||
|
|
@ -184,28 +238,31 @@ pixels. The change was a success, most people scanned the QR code from this
|
|||
point on.
|
||||
|
||||
<figure>
|
||||
<img src="/images/2019/badge-with-qr-code_thumb.jpg" width="600" alt="Badge display now including QR code." />
|
||||
<a href="/images/2019/badge-with-qr-code.jpg"><img src="/images/2019/badge-with-qr-code_thumb.jpg" width="600" alt="Badge display now including QR code." /></a>
|
||||
<figcaption>Badge display showing the newly added QR code</figcaption>
|
||||
</figure>
|
||||
|
||||
On day 2 I also ran into [E. Dunham][edunham], and rambled briefly about my
|
||||
badge project and that it was built with Rust. To my absolute delight [the
|
||||
project was featured in their talk the next day][edunham-talk]. The project was
|
||||
mentioned and linked on slide and I was asked to raise my hand in case anyone
|
||||
mentioned and linked on a slide and I was asked to raise my hand in case anyone
|
||||
wanted to chat afterwards.
|
||||
|
||||
<figure>
|
||||
<img src="/images/2019/badge-edunham-talk_thumb.jpg" width="600" alt="Photo of E. Dunham's slide with a link to my git repo." />
|
||||
<a href="/images/2019/badge-edunham-talk.jpg"><img src="/images/2019/badge-edunham-talk_thumb.jpg" width="600" alt="Photo of E. Dunham's slide with a link to my git repo." /></a>
|
||||
<figcaption>Photo of E. Dunham's slide with a link to my git repo</figcaption>
|
||||
</figure>
|
||||
|
||||
At the end of the talk the audience was asked to talk about a Rust project they
|
||||
were working on. Each person to do so got a little plush Ferris. I spoke about
|
||||
[Read Rust] and am now the proud owner of a litle Ferris.
|
||||
At the end of the talk the audience was encouraged to tell the rest of the room
|
||||
about a Rust project they were working on. Each person that did so got a little
|
||||
plush [Ferris]. I spoke about [Read Rust].
|
||||
|
||||
[Insert Ferris here]
|
||||
<figure>
|
||||
<a href="/images/2019/badge-plush-ferris.jpg"><img src="/images/2019/badge-plush-ferris_thumb.jpg" width="600" alt="Photo of a small orange plush crab." /></a>
|
||||
<figcaption>Plush Ferris</figcaption>
|
||||
</figure>
|
||||
|
||||
### CHANGEME What did I learn?
|
||||
## Conclusion
|
||||
|
||||
By the end of the conference the badge showed a count of 12. It had worked
|
||||
flawlessly over the five days.
|
||||
|
|
@ -214,35 +271,54 @@ Small projects with a fairly hard deadline are a good way to ensure it's seen
|
|||
through to completion. Also a great motivator to publish some open source code.
|
||||
|
||||
I think I greatly overestimated the number of people that would interact with
|
||||
the badge. Of those that did I think most tapped the button to increase the
|
||||
the badge. Of those that did, I think most tapped the button to increase the
|
||||
counter and didn't read much else on the page. For example no one commented on
|
||||
the system stats at the bottom of the page. I had imagined the badge as a sort
|
||||
of digital business card but this did not really eventuate in practice.
|
||||
the system stats at the bottom. I had imagined the badge as a sort of digital
|
||||
business card but this did not really eventuate in practice.
|
||||
|
||||
Attaching the Pi and display to my bag worked out pretty well although I did
|
||||
have to be careful when putting my bag on and it was easy to catch on my
|
||||
clothes. Also one day it started raining on the way back to the accommodation.
|
||||
I had not factored that in at all and given it wasn't super easy to take on and
|
||||
off I ended up shielding it with my hand all the way back.
|
||||
Attaching the Pi and display to my bag worked out pretty well. I did have to be
|
||||
careful when putting my bag on as it was easy to catch on my clothes. Also one
|
||||
day it started raining on the walk back to the accommodation. I had not
|
||||
factored that in at all and given it wasn't super easy to take on and off I
|
||||
ended up shielding it with my hand all the way back.
|
||||
|
||||
TODO: Link to code
|
||||
TODO: Add images
|
||||
### Would I Do It Again?
|
||||
|
||||
### Would I do it again?
|
||||
Maybe. If I were to do it again I might do something less interactive and
|
||||
perhaps more informational but updated more regularly. I might try to tie the
|
||||
project into a talk submission too. For example, I could have submitted a talk
|
||||
about using the embedded Rust ecosystem on a Raspberry Pi and made reference to
|
||||
the badge in the talk or used it for examples. I think this would give more
|
||||
info about the project to a bunch of people at once and also potentially teach
|
||||
them something at the same time.
|
||||
|
||||
If I were to do it again I might do something less interactive and perhaps more
|
||||
informational but updated more regularly. For example showing the previous and
|
||||
next talks to attend. Perhaps even allowing free text.
|
||||
|
||||
|
||||
Maybe. I think if I were to do something along these lines again I might try to tie into a talk submission.
|
||||
For example I could have submitted a talk about using the embedded Rust ecosystem on a Rasperry Pi and made
|
||||
reference to the badge in the talk or used it for examples. I think this would give more info about the project
|
||||
to a bunch of people at once and also potentially teach them something at the same time.
|
||||
All in all it was a fun project and excellent conference. If you're interested,
|
||||
[the Rust source for the badge is on GitHub][source].
|
||||
|
||||
[BADGEr]: https://wyolum.com/projects/badger/
|
||||
[HINK-E0213A07]: https://www.unisystem-displays.com/en/fileuploader/download/download/?d=0&file=custom%2Fupload%2Ffile%2F6f3084488018ca68c5bf0a26460e7c57%2FHINK-E0213A07-V1.1-Spec.pdf
|
||||
[SSD1675]: http://www.solomon-systech.com/en/product/advanced-display/bistable-display-driver-ic/SSD1675/
|
||||
[SSD1675 datasheet]: https://www.buydisplay.com/download/ic/SSD1675A.pdf
|
||||
[edunham-talk]: https://youtu.be/uCnnhMleoKA?t=530
|
||||
[edunham]: http://edunham.net/
|
||||
[embedded-graphics]: https://crates.io/crates/embedded-graphics
|
||||
[embedded-hal]: https://crates.io/crates/embedded-hal
|
||||
[Ferris]: http://rustacean.net/
|
||||
[GPIO]: https://en.wikipedia.org/wiki/General-purpose_input/output
|
||||
[HINK-E0213A07]: https://www.unisystem-displays.com/en/fileuploader/download/download/?d=0&file=custom%2Fupload%2Ffile%2F6f3084488018ca68c5bf0a26460e7c57%2FHINK-E0213A07-V1.1-Spec.pdf
|
||||
[hyper]: https://hyper.rs/
|
||||
[inky]: https://github.com/pimoroni/inky
|
||||
[IoT]: https://en.m.wikipedia.org/wiki/Internet_of_things
|
||||
[linux-embedded-hal]: https://crates.io/crates/linux-embedded-hal
|
||||
[linux.conf.au]: https://2019.linux.conf.au/
|
||||
[Pimoroni Inky pHAT]: https://shop.pimoroni.com/products/inky-phat
|
||||
[ProFont font]: https://web.archive.org/web/20180412214402/http://tobiasjung.name/profont/
|
||||
[profont]: https://crates.io/crates/profont
|
||||
[Raspberry Pi Zero W]: https://www.raspberrypi.org/products/raspberry-pi-zero-w/
|
||||
[Raspbian]: https://raspbian.org/
|
||||
[Read Rust]: https://readrust.net/
|
||||
[source]: https://github.com/wezm/linux-conf-au-2019-epaper-badge
|
||||
[SPI]: https://en.wikipedia.org/wiki/Serial_Peripheral_Interface
|
||||
[ssd1675 crate]: https://crates.io/crates/ssd1675
|
||||
[SSD1675 datasheet]: https://www.buydisplay.com/download/ic/SSD1675A.pdf
|
||||
[SSD1675]: http://www.solomon-systech.com/en/product/advanced-display/bistable-display-driver-ic/SSD1675/
|
||||
[stm32f30x-hal]: https://crates.io/crates/stm32f30x-hal
|
||||
[systemd unit]: https://www.freedesktop.org/software/systemd/man/systemd.unit.html
|
||||
[wrk]: https://github.com/wg/wrk
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
title: Rust powered linux.conf.au e-Paper badge
|
||||
extra: TODO
|
||||
title: My Rust Powered linux.conf.au E-Paper Badge
|
||||
extra: For linux.conf.au 2019 I built a digital conference badge using a Raspberry Pi Zero, tri color e-Paper display and a custom Rust program.
|
||||
kind: article
|
||||
section: technical
|
||||
created_at: 2019-01-26 16:17:00.000000000 +10:00
|
||||
created_at: 2019-01-27 11:00:00.000000000 +11:00
|
||||
keywords:
|
||||
- rust
|
||||
- linux
|
||||
|
|
|
|||
BIN
output/images/2019/badge-at-end-of-conference.jpg
Normal file
BIN
output/images/2019/badge-at-end-of-conference.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.3 MiB |
BIN
output/images/2019/badge-at-end-of-conference_thumb.jpg
Normal file
BIN
output/images/2019/badge-at-end-of-conference_thumb.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 73 KiB |
BIN
output/images/2019/badge-early-revision_thumb.jpg
Normal file
BIN
output/images/2019/badge-early-revision_thumb.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 55 KiB |
BIN
output/images/2019/badge-edunham-talk_thumb.jpg
Normal file
BIN
output/images/2019/badge-edunham-talk_thumb.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 60 KiB |
BIN
output/images/2019/badge-first-hello_thumb.jpg
Normal file
BIN
output/images/2019/badge-first-hello_thumb.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 132 KiB |
BIN
output/images/2019/badge-plush-ferris.jpg
Normal file
BIN
output/images/2019/badge-plush-ferris.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
BIN
output/images/2019/badge-plush-ferris_thumb.jpg
Normal file
BIN
output/images/2019/badge-plush-ferris_thumb.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 88 KiB |
BIN
output/images/2019/badge-sunday-night_thumb.jpg
Normal file
BIN
output/images/2019/badge-sunday-night_thumb.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 159 KiB |
BIN
output/images/2019/badge-with-qr-code_thumb.jpg
Normal file
BIN
output/images/2019/badge-with-qr-code_thumb.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 119 KiB |
Loading…
Reference in a new issue