Video recording next week if my kids don't bring home a plague. I'm very excited!

How hard(ware) could it be?

I have never done a bunch of C, C++ or otherwise close to the metal programming. In spite of listening to metal for years! I swear every time I need to change something in a Makefile to make some compiler happy. I'm not comfortable with any of it.

My first code contribution to the Elixir community was a way to drive an eInk screen.

This was not a genius move. I think I can explain the path and in that way enable others to do the exact same thing and suddenly feel like a new world of possibilities has opened.

I had an eInk display (the Inky) and I wanted to use it with Nerves. The official libraries are in Python. That would mean I'd have to include Python in Nerves and make some kind of Port thing to talk across. It wouldn't be very nice. So I looked at the code. Python was what I did before Elixir. And then I started to port the code. There was nothing uniquely low-level about the Inky Python library. It does do a bunch of binary commands and stuff but it was all GPIO, SPI and I2C which were things that Elixir Circuits provides for you. So the things I saw in Python had direct matches in Elixir.

Right now I'm experimenting with repeating that for a different class of device. The process is the same. I'm poking the Elgato Streamdeck Plus. Programmable buttons, knobs and a touchscreen. Someone has already implemented it fully in Python, Node.js and probably others. The only low-level concern is that I need the libusb hidapi bindings. Thankfully someone built a HID library, as a NIF in C using the libusb hidapi stuff, for Elixir which works fine on my Linux box so far. Not so fine on my Mac. Later problem.

This means I can mostly port code from Python to Elixir. This means reading a fair bit of code and writing a decent bunch of it. But it doesn't mean a whole lot of invention. It is fairly straightforward. It has a bounded scope already as the library I'm porting usually matches the capabilities of the device.

Essentially it is similar to talking to a really bad JSON API but replace JSON with arbitrary binary commands and that's basically it. Inky was more complex than a raw USB HID device in terms of how I had to treat the device it seems.

What I'm saying is, if you know a language well enough to write code in it and you know another language well enough to read it, you can port between them. And if you can port code and have enough budget to get the hardware you can probably do this first step into hardware programming.

I've gotten a lot less nervous about working with binary from this type of work. Further reinforced from building the ID3 library for the Changelog. Lots of binary construction and matching there.

I think hardware is uniquely juicy in that it seems dangerous or hard. This is a good place to start I feel. The same applies to implementing libraries for new and old protocols (I may be trying to convince a fledgling alchemist to improve the IMAP offerings in Elixir land right now). Implementing a library for hardware or a protocol expands the capabilities of the community permanently.

Why not give it a shot? Do you think you can do it?

If you need to argue with me or need ideas for what library to do, reach out at lars@underjord.io or as @lawik@fosstodon.org.

Thank you for reading. I appreciate you spending your attention here.