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.”
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.
> 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.
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.
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).
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.
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
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.
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.
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.
[+] [-] shermantanktop|1 year ago|reply
“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.”
[+] [-] Tijdreiziger|1 year ago|reply
[+] [-] zer00eyz|1 year ago|reply
>> 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!
[+] [-] Dowwie|1 year ago|reply
[+] [-] barryrandall|1 year ago|reply
[+] [-] lelanthran|1 year ago|reply
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.
[+] [-] epr|1 year ago|reply
[+] [-] Saigonautica|1 year ago|reply
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.
[+] [-] technothrasher|1 year ago|reply
[+] [-] EnigmaFlare|1 year ago|reply
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).
[+] [-] epcoa|1 year ago|reply
[+] [-] ricksunny|1 year ago|reply
edit * models-> modules (autoincorrect)
[+] [-] jareklupinski|1 year ago|reply
https://shop.m5stack.com/collections/m5-controllers
[+] [-] 0xEF|1 year ago|reply
[+] [-] lelanthran|1 year ago|reply
[+] [-] dmd|1 year ago|reply
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.
[+] [-] bayesianbot|1 year ago|reply
[+] [-] lelanthran|1 year ago|reply
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.
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] bhaney|1 year ago|reply
[+] [-] tambourine_man|1 year ago|reply
[+] [-] amelius|1 year ago|reply
[+] [-] caboteria|1 year ago|reply
[+] [-] ykonstant|1 year ago|reply
[+] [-] crystaln|1 year ago|reply