Yup. IO expander chips are the real deal. Having good knowledge on them would enable you to extract a lot of value from even the tiniest of micro controllers.
Especially ones tht have an SPI or an I2C interface.
From the Reddit thread the article is based on, OP says:
> I want to run an unmodified QMK firmware so I can keep up with updates without having to continually merge my changes into HEAD, and in my research with IO expanders I would have to rewrite the matrix scanning code.
QMK supports a “custom matrix” option which makes using an IO expander or demux extremely easy. We use them for the NIBBLE keyboard. The API is stable and keeping changes in the working tree would be fine. It’s more likely the keymap would break at some point for some reason other than the matrix driver.
You can disable the new layout in your user preferences[0]. If you scroll down to "Beta options", you can untick "Use new Reddit as my default experience".
HN likes to cry about lack of blogs but always tell to visit original source aka SV startup link.
You can skip every news like that was well and just go to "source".
I recently found out that there exist a Pico W although it is always out of stock at all vendors in my country. This could give some serious competition to ESP. Any idea when these supply chain issues will get resolved?
The Pico W may not have been in stock for you yet. I believe the earliest it shipped from vendors was July 5th, so it's probably worth your while to keep checking back.
A significant flaw of the Pico W is that its idle power draw is too high for battery operation. Rules out a ton of applications that you typically would use a wireless microcontroller like the ESP32 or nRF5x for.
As far as I can tell the Pico W is worse than the ESP32 in most ways. The ESP32 was released in 2016!
The Pico and Pico W are strange… I suspect the audience (much like the Raspberry Pi) is a “my first microcontroller” crowd.
Just like the Raspberry Pi was “my first Linux embedded anything” crowd.
These are both great and I fully support it! However, Raspberry Pi remains the champion even when faced with vastly superior hardware because of the documentation, community, ecosystem, and first mover advantage.
Here not only is Espressif offering superior hardware they’re doing so with an ecosystem that’s been in the making for almost a decade going back to the ESP8266.
It runs MicroPython, anything in the Arduino ecosystem, Platform IO support, the Espressif low level IDF, AND you can Google just about “esp32 + anything” and find almost endless libraries, examples, etc.
This SDK doesn’t have Bluetooth working while the ESP32 ecosystem is in such a mature state there are projects dedicated to cameras, audio projects, a million other peripherals, and even on board inference with TensorFlow Lite (which has been around for two years).
The Pico and Pico W will be very successful because they have the Raspberry Pi name but it’s strange to me they’re introducing a solution that gets pretty handily beat in all aspects by hardware that’s been readily available for half a decade.
I’m sure users and customers have been asking for it and there are other factors at play (contracting, supply chain, who knows) but I don’t quite understand (especially for the tinkerer) what advantage(s) this really provides over the ESP32 (as one example).
It is really nice to see a company firing on all cylinders. It is interesting to see them get a training partner and release a language targeted development board (to be released soon?).
The pico competes exactly in the same world where Arduino does. The Arduino Uno still sells for 30$ despite a very old and limited AVR chip. Pico is a great deal compared to that, at 5$ for a double core ARM cortex M0 (and more flash, ram, real DAC, etc).
Yes, the ESP32 might also be a good deal in that space. ESP used to have their own weird architecture though? I think newer ones are RISC-V? Some people might prefer a somewhat more standard cortex-M.
There is a way, but it requires 7+16=23 sense wires on the input side. The MCU is acting as the multiplexer. Representing the information about the pressed key is more compact than physically sensing and discriminating which key was pressed.
The obvious way to use fewer pins is to have a decode IC, e.g. 74238 which would take 3-bit input and pull one of 8 outputs high or 74138 which does the same with active low.
With your 112 key matrix, you can then use 14 input lines to make an 8x14 matrix, so you'd need a total of 17 GPIO pins.
Forgot to note, if you're really short of GPIO, you could also use two 8-line to 1-line data selector chip, e.g. 74151, so you'd have a 74138 to select one of 8 rows, and two 74138 which select a column each, and two further input pins to read from the result. That would reduce GPIO down to 8 (6 out, 2 in).
And just in case you're reallyreally short of GPIO, you can use a 74595 shift register to feed the column and row selection, so you'd just need clock and data outputs.
You could also use 74251 8-to-1 multiplexer as that has an output enable, so you could use your remaining 2 outputs from the shift register to enable one of the two multiplexer chips. If you're not latching the outputs on the shift register, then you'd want a resistor between the two outputs so they don't fight.
So then, the ultimate reduction in GPIO would be to 3 lines - clock, data, in.
Obviously, for each of these, as you reduce the number of IO pins, you increase the time required to scan the matrix.
74595s are incredibly useful, compatible with SPI interfaces, and completely forgotten by today's engineers.
I have a current project where I needed to drive a large number of CS lines on a SPI bus. Others suggested I/O expanders and even - good lord - an entire M0 controller to handle it. I solved it with a bitbanged chain of 74HC595s, under $1 in BOM cost.
This is very standard thing with any pre-made embedded microcontroller to hijack pins where you can. Sometimes it comes at the expense of being able to program the board in a standard way. :)
35 comments
[ 64.7 ms ] story [ 957 ms ] threadEspecially ones tht have an SPI or an I2C interface.
> I want to run an unmodified QMK firmware so I can keep up with updates without having to continually merge my changes into HEAD, and in my research with IO expanders I would have to rewrite the matrix scanning code.
https://old.reddit.com/r/raspberry_pi/comments/w37gx2/i_free...
[0] https://www.reddit.com/prefs/
gopher://forthworks.com:7004/0/%7eraspberry_pi/%3aw37gx2
It's pretty much the only way I can tolerate Reddit.
It's probably 50% hug and 50% some other innocuous social physical contact on the very first date.
Granted, I dated a lot in the Tinder era, so it was fairly common to first meet someone on the first date, and initial chemistry can vary wildly.
I've tried to filter it out with uBlock Origin, but so far haven't been successful. :(
https://www.espressif.com/en/news/ESP32-C5
As far as I can tell the Pico W is worse than the ESP32 in most ways. The ESP32 was released in 2016!
The Pico and Pico W are strange… I suspect the audience (much like the Raspberry Pi) is a “my first microcontroller” crowd.
Just like the Raspberry Pi was “my first Linux embedded anything” crowd.
These are both great and I fully support it! However, Raspberry Pi remains the champion even when faced with vastly superior hardware because of the documentation, community, ecosystem, and first mover advantage.
Here not only is Espressif offering superior hardware they’re doing so with an ecosystem that’s been in the making for almost a decade going back to the ESP8266.
It runs MicroPython, anything in the Arduino ecosystem, Platform IO support, the Espressif low level IDF, AND you can Google just about “esp32 + anything” and find almost endless libraries, examples, etc.
This SDK doesn’t have Bluetooth working while the ESP32 ecosystem is in such a mature state there are projects dedicated to cameras, audio projects, a million other peripherals, and even on board inference with TensorFlow Lite (which has been around for two years).
The Pico and Pico W will be very successful because they have the Raspberry Pi name but it’s strange to me they’re introducing a solution that gets pretty handily beat in all aspects by hardware that’s been readily available for half a decade.
I’m sure users and customers have been asking for it and there are other factors at play (contracting, supply chain, who knows) but I don’t quite understand (especially for the tinkerer) what advantage(s) this really provides over the ESP32 (as one example).
Oh, and it’s cheaper and VERY readily available.
It is really nice to see a company firing on all cylinders. It is interesting to see them get a training partner and release a language targeted development board (to be released soon?).
https://www.espressif.com/en/news/ESP_RUST_training
https://github.com/esp-rs/esp-rust-board
The pico competes exactly in the same world where Arduino does. The Arduino Uno still sells for 30$ despite a very old and limited AVR chip. Pico is a great deal compared to that, at 5$ for a double core ARM cortex M0 (and more flash, ram, real DAC, etc).
Yes, the ESP32 might also be a good deal in that space. ESP used to have their own weird architecture though? I think newer ones are RISC-V? Some people might prefer a somewhat more standard cortex-M.
Shouldn't there be some way to just logic it down to something like 7?
Need to break out the karnaugh map.
With your 112 key matrix, you can then use 14 input lines to make an 8x14 matrix, so you'd need a total of 17 GPIO pins.
You could also use 74251 8-to-1 multiplexer as that has an output enable, so you could use your remaining 2 outputs from the shift register to enable one of the two multiplexer chips. If you're not latching the outputs on the shift register, then you'd want a resistor between the two outputs so they don't fight.
So then, the ultimate reduction in GPIO would be to 3 lines - clock, data, in.
Obviously, for each of these, as you reduce the number of IO pins, you increase the time required to scan the matrix.
I have a current project where I needed to drive a large number of CS lines on a SPI bus. Others suggested I/O expanders and even - good lord - an entire M0 controller to handle it. I solved it with a bitbanged chain of 74HC595s, under $1 in BOM cost.