I need to buy a whole pile of these, then figure out functions for them to perform later.
That's exactly what I want it to be.
Hopefully we'll see some in the LZ7 as well, and maybe the Hutzy XS even, if that works out. I've also seen people put vandal buttons in the M1, which looks absolutely dope.Case in point:
That video was the reason why I thought about the button controlling LEDs in the first place. Unfortunately this particular setup would require more GPIOs than I have available.
Considering how much time I've wasted over the years getting PWR LED plugged in with the right polarity, your button would be worth it for that alone
We'll see about that once I've managed to make a price estimate for it
Hopefully you're right.Oh stop it, you're making me blush ^^ Thank you!
Oh absolutely! The additional effort required to make multiple buttons work is very low, so yes, that will be madeossible.
I didn't know internal hubs like this existed. I just thought that as mainboards still have at least four internal USB2.0 connections today, at least someone would want to use two buttons. And if two are supported, supporting even more is trivial.
TBH, I already thought about whether it would be possible to implement a two-wire communication like I2C that one could activate to daisy-chain buttons together, but using an internal hub like this is of course a much more robust solution. With this one from NZXT, you could connect eight of these buttons for one heck of a light show
Can't wait to see what you'll come up with! Imagine a larger version of this button (22mm maybe, that seems to be the "large" size on caselabs cases) that would have even more LEDs (maybe two separate rings?) and GPIOs, the possibilities could be endless!
If pairs of the already broken-out GPIO pins could be used for I2C, these could be used to daisy-chain buttons without any extra hardware (and allow for easier synchronisation of multi-button effects than through a shared USB hub). That's a pretty rare use-case though.
Hm, not needing additional hardware (except for a very cheap cable) is of course a significant advantage, but how much easier a synchronisation would be is debatable. The thing is, for effects that require something like this, you'll almost certainly want to use software for controlling the buttons anyway, so to the user it doesn't make much of a difference, they'd actually lose two GPIO pins on the button they might've wanted to use for something else.
And when you do use software to control the buttons instead of reprogramming them, it is much easier for me to handle that kind of complex logic on the computer instead of the microcontroller that uses 70% of its cycles just for the BAM of the LEDs.
An additional problem is that the HDD0 and SW0 pins need to have a resistance of 330R, so for I2C one would have to mod one of those to 0R. While I did account for that with the inclusion of non-populated hand-soldering resistor footprints in parallel to the 330Rs, I don't expect many users to go that far.
I'd guess so, but even if it wasn't that rare, the support for driving external LEDs is a much more interesting feature for many. The one scenario where it would be useful for the buttons to talk to each other is when you want a coordinated light-show powered by the standby voltage of the PSU that is running even with the PC is turned off. But who'd be crazy enough to do that sort of thing?
Since you have an MCU on board, may be you can add a reset functionality when the power button is double clicked / triple clicked.
A tip on the firmware: always have a watch dog timer.
A tip on the firmware: always have a watch dog timer.
I was thinking more in terms of using the buttons completely separate from a PC, for more general usage. e.g. connected up to a Raspberry Pi, or even an Arduino or similar microcontroller. No specific application in mind, more thinking in general terms of things I could do with The One Button To Rule Them All.
While that is a good and useful idea in theory, the button is wired through to the SW GPIOs directly because it needs to work as a button even if it's not powered, so that would automatically turn the PC off/put it to sleep. Incidentally, in doing that, it cuts power to the button, so in that case it will already reset by the power-on reset, and I can of course trigger a reset through software.
What would that reset be useful for, anyway? Apart from resetting if the firmware hangs.
Good tip on the watch dog timer. I know my MCU has support for that and it's enabled by default, but it's set to over two minutes
I'll have to make sure that won't be the case later. A few ms should be enough. Easy: Get a RasPi Zero and use that to control them
The command line tool to control them will be cross-platform.Ain't no latin doe
Though it's a good base for more possible names. Singularis, Solus, Unus, Unicus, Alter, Simplex, Privus. Not too shabby.
I meant the PC reset, not the MCU reset.
Good tip on the watch dog timer. I know my MCU has support for that and it's enabled by default, but it's set to over two minutes
A few 100s of ms is a good balance. Make sure you service the WDT in the main firmware loop and not in any interrupt service routines.
Oh, I see. Yeah sure, that would work. But the user would have to set that in the software, I think. Not sure whether I could detect that.
Last edited:
Can't you provide a header for "reset " output that can be connected to the motherboard, which is activated by one the GPIOs configured as open collector output ?
Yes, and there are a few ways to do this, but there are multiple trade-offs. Remember, I only have four pins to work with on my MCU, the tactile button inside is connected to two of those. All of them are tri-state logic pins with internal pullups. The current setup looks like this (ATTINY symbol for clarity):
Pin 1 and 2 are HDD0 and HDD1, pin 3 and 4 are SW0 and SW1.
These are the options we have:
1. Change the stock configuration of the pins. HDD0 and HDD1 would become RES0 and RES1.
2. Only use one pin for the HDD_LED readout and the other one for triggering the RST_SW. The user would then have to connect one pin to the HD_LED_N pin (is low when HDD is active, high otherwise) on the board and one to the RST_SW_P (pull low to reset).
3. Connect one of the pins of the internal button to GND instead of a GPIO, use the then free GPIO for RST_SW.
None of these address the problem that if I push the button once, the mainboard will already detect that as a power-button press. And unfortunately, there's no way around that unless I require the user to connect the powerbutton to an internal USB connector that is connected to the +5VSB rail (and I'm not sure all mainboards have that, it certainly isn't documented). The button needs to be directly connected to the mainboards PWR_SW pins, otherwise the PC won't start up.
Also remember that every mainboard resets if you hold the power button for a certain amount of time, so it
In theory, for each function (RST_SW, PWR_SW, HDD_LED, drive external LED), I only need one active pin, so I could make all four work that way. Though the better combination would be PWR_SW, HDD_LED and two external LEDs in my eyes.
So the question is, would you rather have: polarity invariance or multiple external functions at the same time?
Last edited:
Sure is. Didn't want to invest thousand or more into a professional CAD package, and after a bit of learning it works quite well.
Personally, polarity invariance. I can't think of a reason why a PC in the 21st century should have a reset switch, but I can imagine not having to do the 50% lottery every time when SFF is often about tucking away cables. Using the pins for various purposes easily seems moot as it will require quite the knowledge outside from the "RST_SW, PWR_SW, HDD_LED, drive external LED" and at that point I'd figure one can use an Arduino and have even more possibilities.
Very good (and interesting) points there. Especially concur about the reset switch.
Similar threads
