I don't want to disclose that information yet. While I will make all of that information accessible when the product is finished, I'm not going to give potential competitors a head start.
Last edited:
I don't want to disclose that information yet. While I will make all of that information accessible when the product is finished, I'm not going to give potential competitors a head start.
Speaking of competitors ( 
) Adafruit just released an RGB version of the button they sell, if anyone wanted to play with one of those. https://www.adafruit.com/products/3350
) Adafruit just released an RGB version of the button they sell, if anyone wanted to play with one of those. https://www.adafruit.com/products/3350
Speaking of competitors (
Ah yeah, that's exactly what @Curiosity needed. Common anode and three cathodes, so can control it with a basic RGB strip controller or a motherboard with RGB headers if you solder resistors in line with the cathodes. The product page even mentions driving it from 12V specifically.
I agree, not enough RGB. @iFreilicht 's button has atleast 12 times as much RGB. That's RRRRRRRRRRRRGGGGGGGGGGGGBBBBBBBBBBBB.
Don't expect me to market it as an RRRRRRRRRRRRGGGGGGGGGGGGBBBBBBBBBBBB switch though
RGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGB would be a better format for animation frames, anyway.
FUN FACT: For one byte per channel, that's a 288bit code. Which means, in 75Hz display mode, you'd have a whole 2^288^75 possible different animations, which is a number with 8571293257832455907089920912578738339887127197662815055853419161063989264433678238615079426400948581799587146238153674766712648712482156876766915221816697387427233336330743030297338481 decimal digits. Crazy, huh?
RGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGB would be a better format for animation frames, anyway.
FUN FACT: For one byte per channel, that's a 288bit code. Which means, in 75Hz display mode, you'd have a whole 2^288^75 possible different animations, which is a number with 8571293257832455907089920912578738339887127197662815055853419161063989264433678238615079426400948581799587146238153674766712648712482156876766915221816697387427233336330743030297338481 decimal digits. Crazy, huh?
My body's OS BSOD'd trying to read that number and is now working in Safe Mode to keep me from crashing again.
It did remind me of the impossible thingamajig that Picard planned to show "Hugh" to take back and incapacitate the Borg with.
A very cool episode! The one where Data abandons the emotions chip... valued his friendship with Geordi over having emotions.
Yeah sorry, I'm studying for my final exams right now so I can't commit a lot of time to this. I did get my hands on an Arduino Micro and did some testing for the firmware, but I didn't get to write an extensive update yet. Maybe I'll have time this evening. Thanks for reminding me
If "exams are over" is an update, then yes I'll have much more time to work on this now, so I'll at least put out a write-up of the Arduino Micro testing. Sorry for teasing you on that one, I really didn't have the time to make pictures and document everything in readable form.
I'll have much more time to work on this now, so I'll at least put out a write-up of the Arduino Micro testing. Sorry for teasing you on that one, I really didn't have the time to make pictures and document everything in readable form.
Oh, yeah, also I found 0404 RGB LEDs for my keyboard, I may be able to use normal switches depending.If "exams are over" is an update, then yes
Update! First Hardware tests and a surprise!
TL;DR: Got an Arduino Micro to test how stuff would work.
This is what my testing setup currently looks like:
I'll go through the parts and explain what they do and what they simulate.
Most importantly, I tested whether I could flash a new bootloader with the series resistors and the parallel internal I/O pins. As you can see or may already know, there is one series resistor of 330Ω on both P5 and P3 to comply with Intels Front I/O Design Guide, to allow driving the LEDs of existing front panels with the button if so desired. Those pins are also used for the SPI interface, through which the bootloader is flashed onto the MC. Additionally, they are also connected to another I/O pin each for enhanced functionality. In some cases you need isolation circuitry to make sure that the SPI signals can reach the MC unimpeded.
Luckily, all GPIOs are left in their standard state during programming, which means that none of them interfere with the SPI signals. And additionally, the resistors didn't influence the reliability of flashing at all. Even when putting 1K resistors in there, the bootloader flashed perfectly with no issues.
This means that the bootloader of a fully assembled button can be flashed, which in turn means that I won't have to do the assembly myself but can let a contractor take care of that if production volume justifies it. Very useful! Additionally, it gives me a little bit more freedom when laying out the components onto the board.
The only other thing I did so far was to implement a rudimentary version of the non-RGB part of the firmware, which will probably go through many iterations before I'm satisfied with it.
And finally, I had a little chat with the people from Arduino about a possible collaboration! There's nothing set in stone yet, so I don't want to go into any details yet, but I hope we can work something out and I'm very excited for it!
TL;DR: Got an Arduino Micro to test how stuff would work.
This is what my testing setup currently looks like:
I'll go through the parts and explain what they do and what they simulate.
- Arduino Micro: This is basically a breakout of the ATMega32u4, which will be the MC inside the button. Connecting that to my PC, I can implement firmware features easily and check their feasibility before committing to a Prototype PCB.
- The six long orange wires: Those connect the pins PF[014567] of the MC to the "actual" GPIO pins of the button, which I'll be dubbing P[1-6]. The "internal" PF pins offer a separate ADC-channel (analog input) each and PF[4-7] expose the JTAG serial interface on P[3-6] for anyone who wants to use it.
- The multi-coloured wires below those connect the PD[2-3] and PB[0-3] pins of the MC to the P[3-6] "actual" pins. The former two will provide 2-wire serial interface on P[1-2], the latter SPI serial on P[3-6] and all of them can also act as digital interrupt inputs.
- The button and the short wires around it simulate the pushbutton itself and the switch that can be used to free up P1 when required. The configuration seen in the picture is the standard one, where P0 and P1 both connect to one side of the button. When moving the button on the breadboard one column to the right, it is connected to P0 and GND.
- The bridge row of orange wires and resistors represents the actual I/O pins P[0-6]. In the picture, two LEDs are connected to the latter four pins.
- Arduino Uno: This one is set up and programmed to flash a new bootloader onto the Arduino Micro. This was an important part for testing and will be useful in the future as well when I replace the original bootloader with my modified version.
Most importantly, I tested whether I could flash a new bootloader with the series resistors and the parallel internal I/O pins. As you can see or may already know, there is one series resistor of 330Ω on both P5 and P3 to comply with Intels Front I/O Design Guide, to allow driving the LEDs of existing front panels with the button if so desired. Those pins are also used for the SPI interface, through which the bootloader is flashed onto the MC. Additionally, they are also connected to another I/O pin each for enhanced functionality. In some cases you need isolation circuitry to make sure that the SPI signals can reach the MC unimpeded.
Luckily, all GPIOs are left in their standard state during programming, which means that none of them interfere with the SPI signals. And additionally, the resistors didn't influence the reliability of flashing at all. Even when putting 1K resistors in there, the bootloader flashed perfectly with no issues.
This means that the bootloader of a fully assembled button can be flashed, which in turn means that I won't have to do the assembly myself but can let a contractor take care of that if production volume justifies it. Very useful! Additionally, it gives me a little bit more freedom when laying out the components onto the board.
The only other thing I did so far was to implement a rudimentary version of the non-RGB part of the firmware, which will probably go through many iterations before I'm satisfied with it.
And finally, I had a little chat with the people from Arduino about a possible collaboration! There's nothing set in stone yet, so I don't want to go into any details yet, but I hope we can work something out and I'm very excited for it!
Similar threads
