Search
23 results for “ayke”
-
And now a followup on how to actually update a row of LEDs efficiently, using bitplanes:
https://aykevl.nl/2026/01/bitplanes/ -
Charlieplexing LEDs is actually really neat, if you understand how it works. It's basically just a LED matrix where you use the same pins on both sides of the matrix. I've written about it in my latest blog post:
https://aykevl.nl/2026/01/charlieplexing/Charlieplexing is what allows my 36-LED earrings to have so many LEDs - I would have needed a bigger microcontroller without Charlieplexing.
-
Did my #GopherConEU talk on threading/multicore support in #TinyGo yesterday!
The video should be available in a month or so, but if you want to take a sneak peek at the slides you can do so here:
https://aykevl.nl/talks/2025-06-17-gopherconeu/ -
I wrote a blog post about how to efficiently render polygons on slow microcontrollers while still looking reasonably nice!
It contains an intuitive explanation (with lots of images!) how it works, and an explanation of the algorithm itself in pseudocode.
https://aykevl.nl/2024/02/tinygl-polygon/
You can see the result below, which is an analog clock that's part of my smartwatch project.
-
And now my wonderful collaborator @ayke with "Implementing Parallelism: How We Added Threading and Multicore Support in TinyGo" here at @gopherconeu
#gopherconeu -
was ein toller song zum tee trinken an diesem sonntag morgen.
https://ethiopiquesseries.bandcamp.com/track/aykedashem-lebe
-
was ein toller song zum tee trinken an diesem sonntag morgen.
https://ethiopiquesseries.bandcamp.com/track/aykedashem-lebe
-
For the next batch of earrings, I plan on adding a bunch more pride flags to the earrings. Any suggestions? I already have the rainbow flag and the trans flag.
Note that because these are LEDs, the colors black and gray are difficult to represent so for example the ace flag sadly won't work well.
-
LED earrings are back in stock! It took a bit longer than expected due to Lunar New Year, but I finally received the PCBs today.
https://lectronz.com/products/erring-ring-rgb36
Because I'm doing this as a company now, there are a few changes:
* VAT is charged in the EU.
* Shipping costs are much lower.
* More payment methods are accepted, including a few local ones.
* Shipping to the US got re-enabled, with added tariff and handling fees paid during checkout. -
My earrings are back in stock! Just need to put them together. You may have seen them at #39C3, but I quickly ran out there.
You can buy a pair in person at #FOSDEM (no shipping!), or order them online:
https://lectronz.com/products/erring-ring-rgb36 -
Working on something 👀
(Yes this is still all written in #TinyGo, with some assembly for the bitbanging).
-
...and now finally on sale! I'm low on stock (I ran out of some components) but more is on the way!
-
PSA: don't require people to distinguish between red/yellow/green in status LEDs etc. Especially if there is no other way to distinguish status (position of LED, flashing pattern, etc). Red-green color blindness is incredibly common (~5% or so of people), much more common than other kinds of color blindness.
I'm not colorblind so can't give specific recommendations, but it seems that green/blue or red/blue are better options if you have to differentiate by color. While there are people who have trouble differentiating between those colors, it's much rarer than red-green color blindness.
-
PSA: don't require people to distinguish between red/yellow/green in status LEDs etc. Especially if there is no other way to distinguish status (position of LED, flashing pattern, etc). Red-green color blindness is incredibly common (~5% or so of people), much more common than other kinds of color blindness.
I'm not colorblind so can't give specific recommendations, but it seems that green/blue or red/blue are better options if you have to differentiate by color. While there are people who have trouble differentiating between those colors, it's much rarer than red-green color blindness.
-
PSA: don't require people to distinguish between red/yellow/green in status LEDs etc. Especially if there is no other way to distinguish status (position of LED, flashing pattern, etc). Red-green color blindness is incredibly common (~5% or so of people), much more common than other kinds of color blindness.
I'm not colorblind so can't give specific recommendations, but it seems that green/blue or red/blue are better options if you have to differentiate by color. While there are people who have trouble differentiating between those colors, it's much rarer than red-green color blindness.
-
PSA: don't require people to distinguish between red/yellow/green in status LEDs etc. Especially if there is no other way to distinguish status (position of LED, flashing pattern, etc). Red-green color blindness is incredibly common (~5% or so of people), much more common than other kinds of color blindness.
I'm not colorblind so can't give specific recommendations, but it seems that green/blue or red/blue are better options if you have to differentiate by color. While there are people who have trouble differentiating between those colors, it's much rarer than red-green color blindness.
-
PSA: don't require people to distinguish between red/yellow/green in status LEDs etc. Especially if there is no other way to distinguish status (position of LED, flashing pattern, etc). Red-green color blindness is incredibly common (~5% or so of people), much more common than other kinds of color blindness.
I'm not colorblind so can't give specific recommendations, but it seems that green/blue or red/blue are better options if you have to differentiate by color. While there are people who have trouble differentiating between those colors, it's much rarer than red-green color blindness.
-
Trying a new way of dealing with GitHub notifications and TinyGo maintenance in general. I've been using Octobox for a while and it's nice, but it's a technological solution and cannot in itself fix the stream of notifications for a project like TinyGo.
Instead, my new approach is:
* Limit what repositories I'm actively going to, to what is realistic. For now, that's tinygo and drivers mostly, and mostly maintenance work.
* Work in two passes. The first pass is going through the notifications, replying where needed, maybe writing a bugfix if it's fast, but ideally not spending more than 15 minutes or so on a single issue/PR. If it's not something I can fix quickly, I'll star and archive it to put on the backlog. I can work on the backlog later. If I keep doing that frequently, I can keep the inbox (close to) zero.
* Decide for myself what I'm going to work on, instead of reacting to issue reports. Working reactively burns me out and leads to tons of unfinished PRs, which doesn't help anybody. Instead, I can pick what I am going to work on, such as: updating dependencies, documentation, refactoring, new features, etc. (Roughly in that order).I'm only starting, but I'm now down from 900+ notifications to just 8. So I should be finished very soon. Then I hope to keep this "inbox zero" approach working. I suspect that's going to be the hard part - sticking with this approach.
-
Ever heard of the device motion API in web browsers? No? It lets websites access the position and movements of your phone or tablet.
Here is a demo:
https://www.audero.it/demo/device-orientation-api-demo.html
Very useful for some specific applications, like augmented reality. But other than that, not particularly useful for websites.Well, except advertisers of course. I couldn't find any up-to-date research, but this one from 2018 shows there's a minority of trackers that do access this information and send it to a server, for who knows what purposes exactly:
https://sensor-js.xyz/I think this should have been an opt-in feature. While device orientation and motion is not nearly as sensitive as a camera or microphone, very few websites actually need this information and just providing it to every website seems like a totally unnecessary privacy violation to me.
-
It's really hard to make photos of these earrings! I've taken out my old (t)rusty photo camera (over 10 years old) to make this photo, because it allows me to manually control focus, ISO value, shutter speed, and aperture. And even then I think I could do better - this was the first photo I was happy with. Phone cameras don't give you this much control normally.
Also, yes, new earrings coming soon :D
-
I've figured it out! The new algorithm I wrote is partially based on the classic A-buffer algorithm from 1984 and partly on the "Scanline Edge-flag Algorithm for Antialiasing" paper from 2007. It looks pretty nice, even though it's not perfect (and slower than my previous attempt). Now I just need to clean up the code, write tests, and optimize the code some more.
I plan on writing a blog post describing the algorithm in more detail.
