We need more general purpose embedded modules to act as an abstraction/ middleware / API interface to diversity implemented but frequently utilised low-level hardware. (and since this is a real world, with grades of environmental reliability like automotive, or specs like -45 C to 85 C.

edit * models-> modules (autoincorrect)

I start pretty much every new electronics project with the question "Which M5Stack product handles 99% of the use cases?" and I start iterating from there

https://shop.m5stack.com/collections/m5-controllers

Love it and was hitherto unfamiliar - thanks for clueing me in =)

That’s an amazing resource. Thank you for sharing.

Same here. A ridiculous amount of busywork just disappears when I go with M5Stack.

I do a lot of custom builds of arduino-class hardware and it gets easier and easier every year. Cheap hardware coming out of China is plenty good enough and means that I rarely need to design anything electronic. Just write code.

We also need more manuals with dinosaurs.

I'm game to build anything. What specifically did you have in mind that doesn't already exist?

Motor control. All the motor control. I want literal lego blocks that convert me from position control to speed control to torque control, sensorless to position/velocity feedback, squirrelcage motor to induction motor to BLDC to brushed dc and any phylogeny in-between.

Getting the mechanical engineers to produce a modular shaft, motor mounts, and modular payload mounting interface will come later. (Yes I'm aware of brackets, shaft couplings, pillow-blocks)

Things that help me make things are one of my favorite kind of things

I just today was interfacing to one of these 4x4 keypad arrays for a small in-house test box we're making at work. I was handed the keypad and told to make it go. No problem, they're pretty straightforward to work with. But my immediate question was, "can't we get one with a calculator style number layout rather than a phone style layout?" and it seems to be the answer is basically no, unless you want to have one custom made. Pretty much all the stuff out there floating around is all phone layout. Why?? The pattern on the one in your project write up (which is a fun project, btw) seems the most common, and the same pattern as the one I've got. Along with the reverse number pattern, the '#' and '*' keys seems much less useful than a '.' and an 'enter' key would be in a lot of applications.

Phone layout plus * and # is extremely common on combination locks, even ones with electronic displays for keypads like this https://www.levellock.com/home-and-office-electronic-lock-wi... so maybe it's just more widely recognized by users for non-computer, non-calculator devices.

When I opened a bank account, I had to choose a PIN on the keypad in the office (probably a computer numpad with the same layout as a keyboard) and the clerk warned me that the numbers are upside down compared to an actual POS machine or ATM (which are phone layout).

The 3270 terminal family had a numberpad-like matrix on the right side of the keyboard which was PF1–PF12 with the PF1–3 on the top row. It was a bit confusing for people who used ASCII terminals with a numeric keypad muxed in to access IBM mainframes as occasionally software would assume the 3270 arrangement of keys but the mapping for ASCII terminals used the keypad with the keypad’s 1–0 corresponding to PF1–PF10 and . and + (if I remember right) corresponding to PF11 and PF12 and there would be seemingly irrational arrangements of commands with up and down reversed.

Slightly off-topic, but ‘choosing a PIN’ is an interesting rabbit hole.

Some banks send you a random PIN in a sealed letter.

Other banks have you key in your choice of PIN in various manners (at a branch, online or by phone).

Some banks support changing PIN at an ATM. Others don’t.

I guess it's up to their evaluation of the risk since they're the ones who'll pay for fraud if someone finds your lost card and guesses the PIN. Though if you're not going into a branch, there's no opportunity for you to choose a PIN so they have to do it for you.

Sadly not here, they put all the responsibility on you as a customer. You loose your card and don't immediately notice it, you are responsible for all lost funds until you block the card.

Here in Sweden the banks have been hard at work removing all physical contact for 20 years or so. Started with lowering opening times, closing down the smallest, closing down the next smallest, only accepting booked appointments and so on. Now they are opening tiny holes in the walls of shopping malls where you can get the simplest things taken care of like a new ID card or maybe even setting up a new account if you are not customer already.

If you don't have a Bank-ID on your phone you can hardly do anything any more.

Inexpensive 10 key hid usb keyboards are common. Either interface directly or dismantle.

Huh, weirdly I was just searching for solutions for this just few days ago - I've got some ESP32 projects with keypads and LCDs, which usually are wired little further away from the ESP and other attachments, so the wiring is somewhat PITA. This thing could help it go from 12 wires total for both LCD+keys to only 4 using shared I2C wiring, quite nice!

> This thing could help it go from 12 wires total for both LCD+keys to only 4 using shared I2C wiring, quite nice!

Or you could use shift registers which cost a few USD cents.

On a personal project a long long time ago, I recall using daisy-chained shift registers to control a stupidly high number of relays (think 100+), at an extra BOM cost of around $1.

The relay switching time was still much, much larger than the time it took to bit-bang the daisy-chained shift registers for all relays.

I think this is great, but it strikes me as the DIY embedded hardware equivalent of what coders often do.

“I could manually enter 100 lines of text or…I could spend all afternoon writing Perl to clean and correct my noisy OCR data…and end up with the same 100 lines of text.

But also I’ll have built a tool! A tool nobody asked for. I really hope I can get someone else to use it so I can feel better about my lost afternoon.”

The programmers’ creed: We do these things not because they are easy, but because we thought they would be easy. ;)

The one I follow is slightly different:

We do these things not because they are easy, but because we want to

And later we can find 100 good excuses explaining why it was worth it

Well thats when it actually got done. But in most cases it remains incomplete.

We do these things for the learning experience.

At least that's me. I've built sooo much stuff just because I wanted to learn how to build it.

What matters is the journey, what you learn on the way...

Perl was a spot on choice for your example.

>> DIY embedded hardware

20 years ago an Arduino was brand new and 50 bucks.

Now any one can get a PCB made. You can do hardware like software (iterative, casual).

This is both silly and amazing!

I wish, and PCBs, yes, but we are still far from "hardware like software (iterative, casual)".

We will be there if we can send off a design and get back a small quantity of reasonably priced fully assembled devices.

And this is not only about ability alone. Learning the skills to assemble a board is pretty realistically possible for almost anyone. It's just so annoyingly boring and tedious once the initial fascination and excitement has worn off. Contrary to when I learned it, it is already a pretty useless skill and will be comletely futile in the future.

Depending on your definition of "reasonably priced," we're already there with JLCPCB's assembly service.

I don't know. There are many PCB services that offer assembly, but as long as have to solder the headers to my Raspberry Pi Pico or Adafruit or what have you myself, it tells me we: We are not there!

The original posting had the word "casual" in it. When I have to worry so much about parts availability and things like this through-hole to prevent prices from exploding it's the opposite of casual.

> I think this is great, but it strikes me as the DIY embedded hardware equivalent of what coders often do.

I think the author already knows this :-)

The primary goal in this project appears to be "fun", not "provide a cheap option for reading keypads".

I mean, the author ate the pain of learning-to-Rust-on-the-STM32, uses it for no discernible gain for a project of this scope, and for good measure adds in a home-written embedded OS.

For something of this scope no multi-task-driven design is necessary, and an 8051-or-cheaper uC with an i2c peripheral and ISRs reading with a while(1) loop writing is more than sufficient.

I attempted making and selling a thing like this (integrating 2x16/2x32 character LCD and keypad) waaaay back in 2003/2004, but the number of hobbyist uC developers just didn't make it worthwhile.

Today, with the arduino already a grandaddy in relative terms, everyone and their dog is doing embedded, so might be a good time for me to relook at all-in-one i2c peripherals for hobbyists.

It's hard to make money building hobbyist-level hardware and selling it to hobbyists. Selling it to commercial users is another story altogether!

I can buy a 5" 800x400 TFT color touch screen with an onboard 32-bit processor that has I2C and SPI ports that can be programmed with the Arduino IDE. And for good measure, implementing an onscreen keypad is already built into the libraries available for it.

Cost is around $30 on Aliexpress. I have a couple of them and they are amazing for the price. A github project has sprung up around these devices: https://github.com/witnessmenow/ESP32-Cheap-Yellow-Display

Guilty as charged! Although it's also an opportunity for practicing useful skills instead of useless ones.

I think of them as the programming equivalent of keeping wood scraps around for later use.

Cliff introduced a useful device for makers, open sourced his embedded rust firmware, and got to improve his embedded async OS in the process. By sharing his work with the world, it could inspire others to give this hard work a try. I really don't think he spent just an afternoon on this, but whatever effort was spent can only in the most cynical lens be viewed as a loss. It was a triumphant hobby project.

Your tiny dinosaur assistant is awesome!

I encountered a similar problem, but solved it with USB keyboards / keypads instead. I managed to get a low-speed USB host working on ESP32. Now I use these instead as much better build quality is available, although they are notably more expensive.

One thing that caught me off guard was that USB keyboard scancodes were different from PS/2. Previously I had tackled the issue using PS/2 keypads and a chip with some firmware that translated the scancodes to 5V serial. This was neat, but sourcing old keyboards eventually became a pain.

Awesome project. Suggestion: turn off autofocus for close-up videos. Focus lock on the mid-to-closest subject. Phones and their tiny sensors have plenty of depth of field.

Why hardware not software?

The electronics are the easy part. What i'd like to know: has any DIYer ever created their own keycaps?

I think I saw some articles about 3D printing keycaps.

I think that this qualifies: https://matt3o.com/

I love keypad-based stuff. When my 1st daughter was born I wanted to make a "jukebox" equivalent to the tape player I had growing up in the 80s. I originally envisioned a bunch of plastic cards with QR codes or NFCs, where each card was a song or a playlist, but eventually settled on the much simpler solution of speaker-RPi-numkey pad, with no display: https://github.com/dmd/nkplay

The drawback is that at 10 years old, she knows lots of songs and artists as "number 84" or "number 328" and has no idea that their actual name is.