Next GH-brewed KB design - 'The Light' (open for discussion)

[Soarer]

Hell... let's fill it with Cree XM-L, direct drive, draw 1kW, output 100,000 lumens, melt the keybord, and burn our retinas and fingertips!

[The_Ed]

My OLIGHT-M21-X has a Cree XM-L with OTF600lm!

22 columns =
("Esc" -> F12 + 2 extra) = 15
(Arrows -> numpad) = 7

[Soarer]

My OLIGHT-M21-X has a Cree XM-L with OTF600lm!

Heh, not running at maximum!

22 columns =
("Esc" -> F12 + 2 extra) = 15
(Arrows -> numpad) = 7

That's not generally how it's done :-)

[rknize]

Since the package is shrouded by the button, it seems like narrow field is what you want.  As for darlington arrays, I've used the ULN2004 types to drive LEDs (and solenoids, motors, etc) in the past.  They are still available in DIP packages.

[The_Ed]

It runs at OTF600lm for 5 minutes before going to 60% so that it doesn't melt itself. But I don't need it on for more that 5 minutes to reach the bathroom at any campsite I've ever been in. 20 lumens is the normal level I use it at.

22 columns was what was talked about a few months ago in this thread. It wasn't my contribution either. I'm fine with either 20 or 21 as well.

[alaricljs]

The_Ed, that's also not how it's done... mainly you just take the number of switches you want and find a nice even matrix.  For a TKL that could be 9x10.  If you find that you want to neaten up the traces for some reason you can then optimize and add columns if you need them.  One of the things I don't think is necessary would be optimizing for ghosting or NKRO since that can all be handled inside the firmware instead of going crazy on the matrix.

[The_Ed]

Physically laid out 7x22 could be electronically 8x20. Is that what you mean? The traces can connect a physical grid into an electrical grid of different dimensions.

[bpiphany]

A more square matrix contains more elements per I/O-pin. Although if you have pins to go around, it may just be more convenient to lay out the matrix in a more rectangular way. In my designs, I've always kept the number of matrix rows equal to the physical rows on the keyboard for simplicity reasons. In this case where a squarer matrix is useful to maximize LED on-time, other optimizations come into play.

Edit: oh, and also, my original idea was to light up one row at a time, and then minimizing the number of rows would be an optimization..

[The_Ed]

We would need extra power to light up a whole row at a time. That's 20+ LEDs drawing current at one time. I thought USB 3 had increased power output. Maybe this will have to be a USB 3 or USB 2 + power brick keyboard.

[bpiphany]

Well, that depends on how much current you put through them... There are the 500mA either way it is done. Even with 30mA LEDs eight at a time don't add up to 500, and with only 6 groups instead of say 13 the duty cycle is more than doubled. And 21x30mA is a bit over 500mA but you'd just need to underpower the LEDs a little.

[Soarer]

Lighting up more than 8 at a time would mean it couldn't simply use PWM channels from the Teensy++ to do the individual levels any more.

[The_Ed]

I just looked at pjrc and it said 9 PWM for teensy++. Where did the 8 we've been talking about come from?

[Soarer]

Can't remember.
Maybe I stopped counting once I found 8 :-)
More likely because we want to keep one timer free for scanning the columns at a regular rate. That could be arranged differently, but it's a lot of hassle for just one extra PWM.

[rknize]

USB3 leds you draw one additional unit but they also upped the current per unit.  I think it gets you close to an amp.  Still, I don't think we'd want to add such a restriction to the design.  Using PWM is how the other vendors are doing it, no?

[bpiphany]

I think it might have been me counting the PWM ports on the ATmega32u4 to 8, but that is not the Teensy++, and I may even have done it wrongly... =P

Not using PWM with ~100 LEDs and say 400mA total current would give 4mA per LED. That might be enough, I don't have the experience to tell. Although I have heard that running a LED at say twice it's continuous rating at a 50% duty cycle will in fact make it appear as brighter. But this needs to be verified by someone who actually knows what he is talking about... So there may be other reasons to "PWM" diodes than current limitations.

Also PWM sort of have two slightly different purposes. First to cycle which LEDs are lit to not exceed the maximum current available. I see this as kind of a forced cycling ending up being a degenerate type of PWM. The other reason probably comes closer to the actual meaning of the acronym "Pulse Width Modulation", it is used to actually control the duty cycle and to vary the power output.

In our case the cycling of the groups will constitute an outer power cycle with a fixed duty cycle of 1/8 per group, and within each group there will be a proper (superimposed) PWM at a much higher frequency with a variable duty cycle determining the average power output during that cycle of that group. An image would be great, if I ever get a Boogie Board that could maybe happen... =)

[Soarer]

I posted a mock-up before of what a single LED would get. It didn't thumbnail well :-)

Were you thinking of drawing something like this? ...



Effectively that's a 10% 'outer' PWM from the scanning, with a 50% 'inner' PWM from the PWM, so 5% overall.

[rknize]

Yes, I should have said multiplexing + PWM.

[mkawa]

the question remains: is all this scanning going to need to be done in firmware by the micro? or is there a register it can set every once in a while to control scanning rate and PWM duty cycle? i'm too lazy to read datasheets XD

[Soarer]

the question remains: is all this scanning going to need to be done in firmware by the micro? or is there a register it can set every once in a while to control scanning rate and PWM duty cycle? i'm too lazy to read datasheets XD

Do keep up! I outlined this on the 5th!

Scanning is firmware and does the slower part of the PWM. The faster part of the PWM is done by hardware (setting registers).

Of course this might not be how it ends up, but...

Well I wasn't sure about whether it gave enough control over the PWM to be able to do it in hardware, but actually I think it might.

Timer 2 could be used to run a timebase for the columns at a few kHz.

Timers 1 and 3 can be set to do 8-bit PWM, and have 3 PWM outputs each. Timer 0 is 8-bit anyway, and has 2 PWM outputs.

So each time the column interrupt fires, the handler would do something like...

• disable PWM outputs
• disable column n
• update PWM output compare values
• enable column n+1
• enable PWM outputs
• read keys

Since the column updating forms part of the PWM, any jitter in handling it would result in varying light levels. This would have to be minimised.

The PWM channels should run at some multiple of the column scan frequency. At 16MHz clock and 8 bit resolution they would be running at 62.5kHz. Dividing that by 16 gives roughly 4 kHz, which sounds about right. That would be divided again by the number of columns to get the overall matrix scan frequency, and that wants to be high enough that you don't notice flicker in the LEDs.

(The divide by 16 in that last bit is just so that there are a number of fast PWM cycles in each scan, which helps with minimising the effect of any timing inaccuracies. We can pick whatever divide gives us a nice overall scanning frequency. It would probably be less than 16, to give scanning of a few 100 Hz).

[mkawa]

gerk. i'd rather have a dedicated core for column scanning, so that we don't get any weirdness in scanning the key matrix, but you have a lot more experience with these platforms than i do, so i'll trust you on this one soarer.

[Soarer]

Eek. That would mean communicating between the two! Actually, key scanning is the easy part - it doesn't have to be done anything like as precisely as we'll be doing it :-)

[mkawa]

the two threads would probably just need to share a register. that's precisely what an interrupt register is tbh, it's a message passing channel between a micro and a bunch of autonomous hardware devices.

[Djuzuh]

Just to know, how far are we approximately from a prototype, and when will we be able to run the GB?

[Soarer]

Damn trolls!

[The_Ed]

At this point I'd say at least a year 'till we get things into our hands at the end of the GB.

[Djuzuh]

ok .

Thanks !

[Soarer]

I meant more mkawa with his abstract talk of cores, threads and message passing. But heh!

[Djuzuh]

I meant more mkawa with his abstract talk of cores, threads and message passing. But heh!

OOooooh…

I was so happy about your compliment !

[Soarer]

OOooooh…

I was so happy about your compliment !

'But heh!' implies you too, even if you were less subtle :-p


Those qwerkeys caps look promising! Good timing!

[The_Ed]

The problem I'm gonna have is how to inject code for the rotary encoders I'll be putting into mine. I can't even begin to code it without the rest of the coding finished and debugged. Or I'd have to write everything from scratch. But the electrical layout will have to be finalized before any coding whatsoever can begin.

[Soarer]

The problem I'm gonna have is how to inject code for the rotary encoders I'll be putting into mine. I can't even begin to code it without the rest of the coding finished and debugged. Or I'd have to write everything from scratch. But the electrical layout will have to be finalized before any coding whatsoever can begin.

The rest of this doesn't really need any interrupt pins (INT1 .. INT7), so we could make sure to leave you a couple of those - how about port E, that gives you 4, would that be enough? I'd say it's worth you doing some test code just so you know exactly what you would need, in terms of pins and timers etc.

[The_Ed]

I can code C++ and would be able to use 12 (10 but 12 is easier) variables to make them into "keys" for the regular scanning.

[Djuzuh]

Can I Helps into coding light effects please ?

[The_Ed]

Crap, I'll need more variables... 14 minimum.

[Soarer]

Timer 2 could be used to run a timebase for the columns at a few kHz.

Timers 1 and 3 can be set to do 8-bit PWM, and have 3 PWM outputs each. Timer 0 is 8-bit anyway, and has 2 PWM outputs.

Heh, I just noticed that OC1C and OC0A are on the same pin! Swapping the uses of timers 0 and 2 sorts it out.

[The_Ed]

It's 5:16AM and you bastards have me coding...

2 rotary encoders

18 variables and a switch case...

[Soarer]

I can code C++ and would be able to use 12 (10 but 12 is easier) variables to make them into "keys" for the regular scanning.

You're fine for variables, the Teensy++ has loads of memory :-)

We'll be using 32 or so of the I/O pins. For many of them, it doesn't matter which though.

And we'll be using all the timers, if we go with this PWM method. If you want to time the inputs at all, it would have to be using a timebase derived from either a PWM or the scanning timer.

[Soarer]

Can I Helps into coding light effects please ?

Knock yourself out!

First, how are the display buffers going to work? For output we obviously need one that's the LED matrix. For drawing into we probably want a buffer based on the physical layout - which maybe has extra rows/cols in it, e.g. between number and function rows, that don't get copied to the output.

[The_Ed]

This probably only makes sense to me. 2 rotary encoders = 20 variables.

It still may cause a slight delay that may be visible in the LEDs. It may have to have a delay so that it processes when it's doing the PWM.

Code: [Select]

X   X X   X
X   X X   X

  X     X

  X     X
  X     X
  X     X
  X     X

  X     X
Edit: No more switch case.

[Djuzuh]

Knock yourself out!

First, how are the display buffers going to work? For output we obviously need one that's the LED matrix. For drawing into we probably want a buffer based on the physical layout - which maybe has extra rows/cols in it, e.g. between number and function rows, that don't get copied to the output.

Alas, I have almost no knowledge in µcontrollers or electronics, and can't really follow what you are talking about.

Could you link me to some more information on this project (maybe the existing code), and/or some documentation?

[The_Ed]

So it will either process at the end of scanning and slightly delay/shorten the PWM cycle, or process during the PWM cycle if that's possible. It would be ideal to process it during the PWM cycle.

Can it process the PWM cycle and rotary encoder code at the same time?

[Soarer]

Alas, I have almost no knowledge in µcontrollers or electronics, and can't really follow what you are talking about.

Could you link me to some more information on this project (maybe the existing code), and/or some documentation?

Hmm, there isn't exactly much existing code yet!

By buffer I just mean a 2D array for storing the brightness for each LED, and double-buffered so that you can draw into one while the interrupt is reading from the other.

What I was thinking though, is that the drawing buffer could have more pixels in it than we have LEDs - perhaps a full 7x21 grid. That would make certain effects easier to implement, and more, well, effective :-)

Also, how about having multiple LEDs under the spacebar, to make it more of a grid there? No reason we can't have some LEDs that don't have switches.

These high-level things need thinking of as well as the low-level stuff!

So it will either process at the end of scanning and slightly delay/shorten the PWM cycle, or process during the PWM cycle if that's possible. It would be ideal to process it during the PWM cycle.

Can it process the PWM cycle and rotary encoder code at the same time?

Couldn't you process the encoders' signals on interrupts? You could have one for each signal wire. Your interrupt might be delayed a little if the scanning interrupt fires just before you get an input, but it shouldn't be by too much, and wouldn't happen often. The reverse, where your interrupt fires just before the scanning interrupt, could disrupt the LED brightness, but if you code your interrupt to be quick that should be ok too - I reckon you could code it very cleanly that way, since in each interrupt handler you already know which signal has changed.

[The_Ed]

All my coding experience is with computers, not electronics... I'm used to just plain processing information into output. I've never used PWM, interrupts, and other things of that nature.

Rotary encoders are 2-bit devices. 4 sets of 2-bits is a single input. They need to be polled like the switches. The variables (10 per rotary encoder) process the polled information into the 8-bit codes required for an input.

[Soarer]

Just think of the interrupt as doing a lot of the work for you - if you poll you have to figure out whether any signal has changed, but the interrupt tells you that straight off.

With a rotary encoder you don't have to wait for a set of 4 input changes - each single change can be one step, because it's possible to determine which direction it's going in based on the state of the unchanged signal.

[mkawa]

Damn trolls!

hah! that's the problem with you embedded types; can't see the forest for the trees!

anyway if we can get a prototype (bread?) board together, hacking up a basic demo should be pretty quick

[Djuzuh]

Hmm, there isn't exactly much existing code yet!

By buffer I just mean a 2D array for storing the brightness for each LED, and double-buffered so that you can draw into one while the interrupt is reading from the other.

What I was thinking though, is that the drawing buffer could have more pixels in it than we have LEDs - perhaps a full 7x21 grid. That would make certain effects easier to implement, and more, well, effective :-)

Also, how about having multiple LEDs under the spacebar, to make it more of a grid there? No reason we can't have some LEDs that don't have switches.

These high-level things need thinking of as well as the low-level stuff!



Couldn't you process the encoders' signals on interrupts? You could have one for each signal wire. Your interrupt might be delayed a little if the scanning interrupt fires just before you get an input, but it shouldn't be by too much, and wouldn't happen often. The reverse, where your interrupt fires just before the scanning interrupt, could disrupt the LED brightness, but if you code your interrupt to be quick that should be ok too - I reckon you could code it very cleanly that way, since in each interrupt handler you already know which signal has changed.

Having a real actual grid to work with while programming would be awesome !

and hm… how will you control the lights? Will there be some sort of FN + something, or will we have dedicated buttons do control the light?

Also, will we be able to change the inserted effects afterwards with the PC?

[Soarer]

Having a real actual grid to work with while programming would be awesome !

Exactly! Now... I want ripples :-D

[Djuzuh]

Meh, ripples can't hold up with a decent typing speed xD.*But it definitively HAS to be on the keyboard imo :]

[The_Ed]

Just think of the interrupt as doing a lot of the work for you - if you poll you have to figure out whether any signal has changed, but the interrupt tells you that straight off.

With a rotary encoder you don't have to wait for a set of 4 input changes - each single change can be one step, because it's possible to determine which direction it's going in based on the state of the unchanged signal.

24ppr with only 2-bits would be an insane 96 inputs per rotation and you could only input a multiple of 4. Rotary encoders have physical "bumps" for every ppr. I consider one "bump" as one input. Which means that even though I can tell direction from 2-bits, I still have to use 8-bits for one input.

Remembering about the bumps means I have to rethink the code slightly. I think I know how I'll do it. Positives and negatives from the 2-bits. When 4 is reached in either direction it inputs. But only when it's between "bumps".

I'm down to 16 variables and the inputs will exactly line up with the "bumps".

The polling frequency of 1000hz for the rotary encoders lines up exactly with the polling frequency of the switches. Why would I use an interrupt instead of the polling that's already happening? That seems like a waste of processing.

[Soarer]

24ppr with only 2-bits would be an insane 96 inputs per rotation and you could only input a multiple of 4. Rotary encoders have physical "bumps" for every ppr. I consider one "bump" as one input. Which means that even though I can tell direction from 2-bits, I still have to use 8-bits for one input.

Remembering about the bumps means I have to rethink the code slightly. I think I know how I'll do it. Positives and negatives from the 2-bits. When 4 is reached in either direction it inputs. But only when it's between "bumps".

I'm down to 16 variables and the inputs will exactly line up with the "bumps".

The polling frequency of 1000hz for the rotary encoders lines up exactly with the polling frequency of the switches. Why would I use an interrupt instead of the polling that's already happening? That seems like a waste of processing.

OK, so you have a 'bumpy' encoder, that doesn't change much really

Have you got a datasheet for the encoder? I'm wondering how quickly it outputs the sequence...

The interrupts only do processing when necessary - you can't get less wasteful than that!

The switch scan rate hasn't been decided yet, btw.