There's no LED support

[fredizzimo]

I didn't solder LEDs to the keyboard myself so I'm unable to test and implement this feature myself. It shouldn't be hard to do, using the visualization framework.

If you either want to test or implement this, please contact me.

[kejadlen]

I'd be happy to test this out. Would be interested in implementing it too, but not sure at all where to start.

[tthayer]

I'd be willing to test some things out too. Just need some guidance.

[fredizzimo]

Hi,

Sorry for not replying earlier. I have been and still am on a trip, so I haven't had time to answer and think about this.

But today I had some time in the hotel room to look more into it, It doesn't seem to be as easy as I first thought, but it shouldn't be too hard either. I think the design that makes most sense would be to expose the LEDs as gray scale display that can be controlled the same way as LCD. Each pixel would represent a led, and the color would represent the brightness.

The advantage of doing it this way, rather than something custom would be that then you could use the drawing routines of uGFX, including font rendering. Another advantage is that the same abstraction would work for keyboards with RGB leds as well.

In order to do this, a new uGFX display driver would need to be made, just like the LCD driver (in the drivers folder of the main repository). This driver would have to use the I2C functionality of the Chibios to communicate with the LCD controller according to the specs. http://www.issi.com/WW/pdf/31FL3731C.pdf.

Some tweaking of the makefiles and the chconf is needed, to enable the build of the display, and to enable multi-display support (which works slightly differently than for using just a single display) for uGFX.

A boardfile would also need to be made (also in the drivers folder), that enables the right input and output modes for the pins, to support the I2C communication

Then this would need to be integrated into the visualizer library like the LCD.

I think I can get something for you to test quite soon after I'm back. But I would of course be very happy if the instructions here are enough to get you started in actually implementing itself.

[fredizzimo]

Hi @kejadlen, @tthayer.

I have now implemented the first version of LED support. But I have no idea if it actually works. The only thing I know is that it doesn't crash, and the rest seems to work OK.

So it would be great if you could test it out.

I have submitted my changes in the led branch, so to take it into use you have to do this

git fetch origin
git checkout -b led origin/led
git submodule sync --recursive
git submodule update --init --recursive

Then make and flash both halves. When the keyboard starts you should see a looping test. It would be great if you could take a video or something, so I can see that it works properly, but it's ok if you just verify it yourselves too.

The test should go like this

1. Fade in all LEDs to full brighness in 1 second
2. Show all leds for 1 seond
3. Fade out all LEDs so that they are completely shut down in 1 second
4. Start to fade in a gradient pattern, the outside should be the brightest, and the middle the lightest, in one second
5. Move the pattern from outside to inside for 3 seconds
6. Crossfade the pattern to another one that goes from top to bottom in one second
7. Move the pattern from top to bottom in 1 second
8. Crossfade to a pattern that goes from inside to outside in 1 second
9. Move the pattern from inside to outside for 3 seconds
10. Crossfade to a pattern that goes from to to bottom in 1 second
11. Move the pattern from to to bottom for 3 seconds
12. Fade out all leds in 1 second
13. Start over

You should report anything that isn't as you think it should be. Especially if some or all LEDs are not working, or if the patterns look wrong.

The pattern implementation is in tmk_visualizer/led_test.c
And the actual low level communication mostly in drivers/gdisp/IS31FL3731C

[tthayer]

Nothing is happening with the LEDs. The display backlight on the right-hand half cuts out after a minute and doesn't come back on until the keyboard is replugged in.

[fredizzimo]

Thanks for the report. Guess I have to re-check all the code.

But the fact that the backlight cuts off is very strange. It doesn't happen on mine with no leds installed.

Does the keyboard still work if the backlight is off? And does the LCD go blank too?

[tthayer]

Thanks for working on this! The keyboard continues to function just fine and the LCD continues to cycle through the layers display. 

Sent from Outlook for iPhone

_____________________________

From: fredizzimo notifications@github.com
Sent: Sunday, April 24, 2016 12:32
Subject: Re: [fredizzimo/infinity_ergodox] There's no LED support (#5)
To: fredizzimo/infinity_ergodox infinity_ergodox@noreply.github.com
Cc: Tony Thayer tony.thayer@gmail.com, Mention mention@noreply.github.com

Thanks for the report. Guess I have to re-check all the code.

But the fact that the backlight cuts off is very strange. It doesn't happen on mine with no leds installed.

Does the keyboard still work if the backlight is off? And does the LCD go blank too?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[dervos]

Perhaps as a 'hello world' test you could hook one led port up to a volt meter. It would allow for easier initial testing and you'd be able to verify the test results of others.

[fredizzimo]

@tthayer, I found an issue, there was an off by one error in the code, which had been left by a refactoring I did.

The code was taking care of setting which LEDs are enabled to the hardware. The controller has two blocks, and only one of them is mapped to the keyboard LEDs. And of course the byte layout for those are interleaved, which means that no LEDs would get mapped. So that would explain why nothing shows up.

But this does not explain why the LCD backlight stops working. Although both are LEDs they have nothing to do with each other, and controlled by entirely different controllers. A memory corruption of some sort could be possible, but I doubt it, especially since most values should be re-written when you switch layers. I also think that this would happen on my board without LEDs as they should not affect the software at all.

Some kind of USB power issue could also be possible, if it detects that there's not enough power and shuts the LEDs off. But that also sounds very unlikely since the LEDs were not working and they shouldn't draw any power.

So for now, the most likely cause sounds like there might have been some kind of inference because of the incorrect mapping. So I suggest that you try my fix out.

@dervos Thanks for the suggestion, I guess a multimeter would show at least something, even if the LEDs are PWM controlled. I will try it, if this fix isn't enough, and there are other bugs. I don't want to open the keyboard if it's not necessary, as the acryllic is very hard to align right, at least on my keyboard. I have the first version, where they didn't fix the space between the thumb section, so I have less than one mm of space there.

[tthayer]

@fredizzimo The LEDs still don't power on but the right-hand LCD backlight stays lit now.

[fredizzimo]

@tthayer, thanks for the report, although it's completely the opposite from what I expected.

I will continue reviewing my own code, and test with a mult-meter before I ask you again.

[tthayer]

@fredizzimo No problem. I wish I was able to provide better feedback!

[fredizzimo]

@tthayer, I just pushed a new version, that forces all the LEds on directly from the driver, bypassing all visualization logic.

I get some readings when testing with the multimeter, but it varies from LED to led for some reason. Maybe you could test this to see if some of them light up?

[kejadlen]

@fredizzimo Unfortunately, I'm away from my Infinity until Thursday, but looking forward to helping out with testing and debugging once I get back.

[tthayer]

@fredizzimo That worked! They're all lit now. The right side now feels unresponsive and kind of slow though. Keys on the right side are also 'sticking'.