Author Topic: Next GH-brewed KB design - 'The Light' (open for discussion) (Read 109197 times)

bpiphany · « **Reply #450 on:** Thu, 29 March 2012, 17:36:18 »

Quote from: The_Ed;560790

My question of whether or not cherry off-center spacebars will work on this PCB still hasn't been answered.

PCB mounting pin holes should be included wherever they are not eaten whole by another hole. This will allow people to scrounge from old boards and for me specifically to go plateless. Plus I have too many switches with PCB mounting pins I would like to be able to use. Why should everyone be forced to buy new platemount switches? Just include the holes.

I forgot about that question.. After gathering info from the key reference wiki, when designing the phantom PCB, I think I concluded that the off-center spacebar switch coincides with the center-mounted spacebar switch of the cherry symmetrical 1.5-1.0-1.5-7-1.5-1.0-1.5 setup. So that footprint is already included on the PCB. This has yet to be verified though, I think.

Yes, of course it is a nice idea to include the PCB mount holes. I could at least try to do it for the locations of the standard QWERTY setup. Leaving them out for the other options would probably take away almost all of the really pesky overlaps.

The_Ed · « **Reply #451 on:** Thu, 29 March 2012, 19:27:13 »

Sounds good for the spacebar then. I've got like 7 of those cherry off-center spacebars and no other kind left... All the rest were sold...

"locations of the standard QWERTY setup" - Does that mean ANSI 104 or just the 26 letters of the alphabet? Or something else entirely?

alaricljs · « **Reply #452 on:** Thu, 29 March 2012, 20:52:00 »

Everything that doesn't have a variable position I would expect, so... num-row til you hit the backspace end, all the alpha and most punctuations... nav cluster and numpad also I expect... apart from possibly doing different options on the zero/+/enter keys.

bpiphany · « **Reply #453 on:** Fri, 30 March 2012, 05:15:55 »

Ok, so if I did everything correct, the footprints that are labeled SW?:? are the Filco standard ANSI switch locations. And they should all have the PCB mount holes. They should all be good except for maybe a few on the spacebar row.

I haven't bothered to place the diodes properly yet, they are just thrown in there. They should probably be moved to the back as well to be accessible when using a mounting plate.

I am putting the controller parts on the backside between SWs 5:1 4:0 3:0 at the moment, that is why 3:0 is upside down. (In the poker case there is a plastic ridge there that would need to be slightly modified. My main goal s to get everything to work with the Filco cases.)

[ Attachment Invalid Or Does Not Exist ] 46359[/ATTACH]

litster · « **Reply #454 on:** Fri, 30 March 2012, 10:44:26 »

PrinsValium, thanks for the tiny holes! :-)

One question, with SMD, components will be soldered when the PCB is made, I assume. So diodes will be installed to all switch locations, even for the switch locations that are not going to be used, correct? Don't think this is a problem since diodes are cheap and I don't think it would save us money doing it other way. Just checking.

We wouldn't need to remove diodes from the PCB for locations we don't use, right? Just trying to thinking through the steps required to put the keyboard together like the wiki I did for phantom installation.

hazeluff · « **Reply #455 on:** Fri, 30 March 2012, 10:54:46 »

Quote from: litster;561570

PrinsValium, thanks for the tiny holes! :-)

One question, with SMD, components will be soldered when the PCB is made, I assume. So diodes will be installed to all switch locations, even for the switch locations that are not going to be used, correct? Don't think this is a problem since diodes are cheap and I don't think it would save us money doing it other way. Just checking.

We wouldn't need to remove diodes from the PCB for locations we don't use, right? Just trying to thinking through the steps required to put the keyboard together like the wiki I did for phantom installation.

You won't need to remove them. = )

The_Ed · « **Reply #456 on:** Fri, 30 March 2012, 20:36:32 »

Thanks for the holes. So then the only switch I would have issues with is the spacebar correct? Can 2 more holes be put for the cherry off-center spacebar switch or am I pushing my luck?

The_Ed · « **Reply #457 on:** Sun, 29 April 2012, 01:16:28 »

Wow... Has it really been a whole month of silence?...

REVIVE! EAT THE FLESH FROM OUR FINGERTIPS!

Oh... And it's my 20th birthday today!

...

Has there been any progress on anyone's prototypes?

hazeluff · « **Reply #458 on:** Sat, 02 June 2012, 11:44:20 »

Quote from: The_Ed;585368

Wow... Has it really been a whole month of silence?...

REVIVE! EAT THE FLESH FROM OUR FINGERTIPS!

Oh... And it's my 20th birthday today!

...

Has there been any progress on anyone's prototypes?

I've got a lot to do at the moment, This is something I plan to do, but it will be quite a while...

Soarer · « **Reply #459 on:** Sat, 02 June 2012, 21:12:37 »

Quote from: hazeluff;606439

Thats the main thing I like. But, i'm worried because the time an LED is "ON" is maximum only 1/numCol.

Not a problem if you use bright enough LEDs :-)

hazeluff · « **Reply #460 on:** Sat, 02 June 2012, 21:16:04 »

Quote from: Soarer;606445

Not a problem if you use bright enough LEDs :-)

I'm thinking if we don't put the limiting resistor/allow for forward biasing above the typical continuous voltage, and by cycling through the columns (The LED would pretty much see a square wave with a small duty cycle), we can get away with bright/normal brightness of the LED, without burning them out.

Soarer · « **Reply #461 on:** Sat, 02 June 2012, 21:29:10 »

Quote from: hazeluff;606446

I'm thinking if we don't put the limiting resistor/allow for forward biasing above the typical continuous voltage, and by cycling through the columns (The LED would pretty much see a square wave with a small duty cycle), we can get away with bright/normal brightness of the LED, without burning them out.

You'll need some current control, even if it's only a small resistor (per LEDROW).

Also, efficiency tails off when you over-current them; you don't get twice as much light with twice the current.

Nice LEDs are pretty cheap bought by the 100 :-)

alaricljs · « **Reply #462 on:** Sat, 02 June 2012, 21:35:50 »

This is the chip I had been looking at. An ON 16 channel LED driver: CAT4016VSR-T2. Uses 1 resistor on a pin to set max current, and then you can do PWM externally for individual leds.

hazeluff · « **Reply #463 on:** Sat, 02 June 2012, 21:52:25 »

Quote from: Soarer;606454

You'll need some current control, even if it's only a small resistor (per LEDROW).

Also, efficiency tails off when you over-current them; you don't get twice as much light with twice the current.

Nice LEDs are pretty cheap bought by the 100 :-)

Yeah, I meant in general increasing current. And I know, we'd hit saturation. But more brightness is more brightness. >< We'd probably get more from a brighter LED than from my dodgy suggestion of going over voltage/current.

Quote from: alaricljs;606459

This is the chip I had been looking at. An ON 16 channel LED driver: CAT4016VSR-T2. Uses 1 resistor on a pin to set max current, and then you can do PWM externally for individual leds.

How does SIN work for this device? As for PWM individual LEDs, then we'd be going back to the design with mosfets controlling the LEDs? There is no way of doing PWM for each LED (in the sense we have 1 pin per LED), well we could but we need some way of creating the PWM outside the MC and having circuitry to hold it at certain duty cycles?

Soarer · « **Reply #464 on:** Sat, 02 June 2012, 22:10:38 »

Quote from: alaricljs;606459

This is the chip I had been looking at. An ON 16 channel LED driver: CAT4016VSR-T2. Uses 1 resistor on a pin to set max current, and then you can do PWM externally for individual leds.

So... one of those in place of the LEDROW transistors? or in addition to?

alaricljs · « **Reply #465 on:** Sat, 02 June 2012, 22:13:20 »

Here's a quick pic of the layout for my LED test board w/ 1 of them acting as sink and source using 6 transistors.

[ Attachment Invalid Or Does Not Exist ] 52144[/ATTACH]

Soarer · « **Reply #466 on:** Sat, 02 June 2012, 22:37:57 »

Oh, I see. And then just update it very often. Very, very often for individual PWM style control!

ediit: Hmm. Sending so many updates to it could be a problem for the Teensy - not in sending the actual serial data, but deciding what to send when.

alaricljs · « **Reply #467 on:** Sat, 02 June 2012, 22:45:14 »

Yes, and while I have zilch in code due to lack of time... It's based on a working keyboard design that had full individual led control w/ PWM.

edit: running on an ATMEGA32U2 btw (the working design)

hazeluff · « **Reply #468 on:** Sun, 03 June 2012, 00:10:27 »

Quote from: alaricljs;606494

Yes, and while I have zilch in code due to lack of time... It's based on a working keyboard design that had full individual led control w/ PWM.

edit: running on an ATMEGA32U2 btw (the working design)

I'm guessing we are still cycling through the columns individually using that IC and applying the PWM to the row (transistors)?

If that's the case, I can see the whole thing working nicely.

I got the gists of it from the following:
http://www.eetasia.com/STATIC/PDF/200805/EEOL_2008MAY13_CTRLD_OPT_AN_02.pdf?SOURCES=DOWNLOAD

But am unsure how it operates still. Is SIN shifted through registers, and then Latch is used to cause the registers to be passed onto and saved in the latches?

__red__ · « **Reply #469 on:** Sun, 03 June 2012, 08:21:07 »

Quote from: alaricljs;606481

Here's a quick pic of the layout for my LED test board w/ 1 of them acting as sink and source using 6 transistors.

(Attachment Link) 52144[/ATTACH]

Judging by the 50x50mm you'll be getting 10 of these boards back in about 2-3 weeks :-)

Any chance we can see the source schematic? I'm having a hard time visualizing the design from the board.

Soarer · « **Reply #470 on:** Sun, 03 June 2012, 08:39:01 »

Conceptually, you can ignore the serial input and the latching. Just think of it as being 16 bits sent from the CPU which set the outputs of that chip on/off.

The transistors just invert 6 of the outputs (needed because the 'off' state of an output is high impedance). That makes it work to drive a matrix of LEDs.

To light them all without flicker, the CPU will need to update the chip at about 1kHz or so. To then do some PWM to vary the brightness of each individual LED would need more updates - how many more depends on how many levels of brightness you want (and how many the CPU can manage!).

hazeluff · « **Reply #471 on:** Mon, 04 June 2012, 11:27:54 »

Quote from: Soarer;606643

Conceptually, you can ignore the serial input and the latching. Just think of it as being 16 bits sent from the CPU which set the outputs of that chip on/off.

The transistors just invert 6 of the outputs (needed because the 'off' state of an output is high impedance). That makes it work to drive a matrix of LEDs.

To light them all without flicker, the CPU will need to update the chip at about 1kHz or so. To then do some PWM to vary the brightness of each individual LED would need more updates - how many more depends on how many levels of brightness you want (and how many the CPU can manage!).

So we're still setting the column pins one at a time and then using PWM applied to the row transistors?

Otherwise, I get it.

Soarer · « **Reply #472 on:** Mon, 04 June 2012, 13:32:43 »

Yeah, something like that. Not sure which way round works out best for the timings (or if it matters, really). So while one column is 'on', the rows get updated multiple times to do the PWM. (It couldn't use the Teensy's hardware PWM, of course, it doesn't have enough channels!)

bpiphany · « **Reply #473 on:** Mon, 04 June 2012, 14:56:20 »

The Teensy has 8 PWM channels, an 8x12 matrix would constitute a full size keyboard, but probably isn't optimal. I guess there are other ways to solve it with external components. It would also be using up a lot of pins. It would be cool with individually controllable LEDs, but perhaps individual intensity is a bit overkill?

Soarer · « **Reply #474 on:** Mon, 04 June 2012, 15:23:30 »

Yeah, Teensy++ has quite a few channels, but they're split over 3 or 4 timers so would be hard to synchronise. If this scheme worked on a '32U2 though, it would've been doing the PWM in software on an interrupt, I guess.

hazeluff · « **Reply #475 on:** Mon, 04 June 2012, 15:58:25 »

Quote from: Soarer;607376

Yeah, Teensy++ has quite a few channels, but they're split over 3 or 4 timers so would be hard to synchronise. If this scheme worked on a '32U2 though, it would've been doing the PWM in software on an interrupt, I guess.

If we use an array of transistors, like proposed before, then there shouldn't be any (major) timing considerations since it can be all handled on the MC. We definitely need the Teensy++ tho. The different timers won't matter I'm pretty sure.

But if we use a shift register/clocked registers, then we have to synchronize the MC with the registers and create appropriate timing signals.

bpiphany · « **Reply #476 on:** Mon, 04 June 2012, 16:22:59 »

True, they run off different timers. I don't know if that would be such a big problem though.. They would be running pretty much in sync. They might get reset to different values, but if they are not able to do several pulses during one light-up of the LED very bad effects will happen anyways..

I shouldn't get myself involved too much in this. I'm not quite interested enough to put too much effort into it. But if you whirl up some schematic and want help or guidance with KiCAD I will happily help out.

Soarer · « **Reply #477 on:** Mon, 04 June 2012, 16:49:12 »

Likewise, I'm not interested in the sense that I'd want trick lights myself, but I can't resist the odd comment :-)

They would have to do quite a few pulses per column strobe is my guess. But the downside would just be fewer controllable intensity levels if not, or a slightly 'unsteady' look to it.

hazeluff - PWM is all about timing! If the MC has to do it in software it takes a fast running interrupt, which mustn't be held up by anything else. In a controller 'anything else' just means USB handling though, and there are ways around that, to a point.

hazeluff · « **Reply #478 on:** Mon, 04 June 2012, 16:53:56 »

Quote from: Soarer;607421

Likewise, I'm not interested in the sense that I'd want trick lights myself, but I can't resist the odd comment :-)

They would have to do quite a few pulses per column strobe is my guess. But the downside would just be fewer controllable intensity levels if not, or a slightly 'unsteady' look to it.

hazeluff - PWM is all about timing! If the MC has to do it in software it takes a fast running interrupt, which mustn't be held up by anything else. In a controller 'anything else' just means USB handling though, and there are ways around that, to a point.

I'm not sure why it needs an interrupt or why timing is involved. I might be missing something here, But when I was using an Arduino, it is possible to set PWM on output pins very easily, so I don't know what could go wrong...I'm assuming the MC the teensy is using could do the same thing.

Soarer · « **Reply #479 on:** Mon, 04 June 2012, 16:56:18 »

Quote from: hazeluff;607426

I'm not sure why it needs an interrupt or why timing is involved. I might be missing something here, But when I was using an Arduino, it is possible to set PWM on output pins very easily, so I don't know what could go wrong...I'm assuming the MC the teensy is using could do the same thing.

Are we getting our wires crossed here? I was talking about individual light levels per LED, but maybe you are talking about a single level for all LEDs? That would indeed be a lot simpler :-)

REVENGE · « **Reply #480 on:** Mon, 04 June 2012, 17:16:21 »

Is this going to be full or reduced layout? I'm still waiting for a custom 75% style keyboard like the Choc Mini / Race.

featherodd · « **Reply #481 on:** Tue, 05 June 2012, 00:41:33 »

Hey guys, I just found out about this thread. Could someone get me caught up with what you're thinking for LED portion of the board?

I was considering getting a Phantom PCB to attempt to prototype out an addressable LED board.

I have some experience using addressable strips from Adafruit (http://www.adafruit.com/products/306), both from an Arduino and streaming raw pixel data from Processing. For prototyping I was thinking of using a series of RGB strands and simply hacking up some keycaps to get them squished on a board somehow.

The great thing about the drivers used in these strips is that they can handle PWM internally. 7-bit for the LPD8806 based strips. 8-bit for the WS2801 based strands. The LPD8806 driver has the added advantage of being able to drive two RGB pixels (or six LEDs).

*apologies if this has been well covered in a previous post. didn't scan all 33 pages.

featherodd · « **Reply #482 on:** Tue, 05 June 2012, 00:44:54 »

*new poss are limited to the amount of links they can contain. here's a link the Adafruit's WS2801 based strand: http://www.adafruit.com/products/322

The_Ed · « **Reply #483 on:** Tue, 05 June 2012, 00:48:24 »

Neither of those will fit inside the switch.

[ Attachment Invalid Or Does Not Exist ] 52280[/ATTACH]

hazeluff · « **Reply #484 on:** Tue, 05 June 2012, 00:53:36 »

Quote from: Soarer;607430

Are we getting our wires crossed here? I was talking about individual light levels per LED, but maybe you are talking about a single level for all LEDs? That would indeed be a lot simpler :-)

No I am talking about different levels of light per LED, not all LEDs...

If we look back at that schematic prins made. We're using the column pin from the switch matrix to also determine which column of LED to choose from. And with the LED Row pins we can apply PWM to set intensity of the LED at (Col,Row).

Tho Im not sure if the teensy has enough pins that can do PWM.

featherodd · « **Reply #485 on:** Tue, 05 June 2012, 01:05:50 »

Quote from: The_Ed;607641

Neither of those will fit inside the switch.

(Attachment Link) 52280[/ATTACH]

Just for prototyping purposes, would probably have to cut the keycaps in half or something barbaric like that. LPD8806 drivers should optimally be surface mounted to the PCB board in series. They should be able to drive most 5V RGB LEDs (I think).

The_Ed · « **Reply #486 on:** Tue, 05 June 2012, 01:06:36 »

I think it will all come down to putting 2 teensy's. One that will poll the switches, and one to PWM the individually controlled LEDs. That's basically what the original nixie ramos had to have done.

The_Ed · « **Reply #487 on:** Tue, 05 June 2012, 01:12:23 »

Quote

The system is all controlled by 2 Atmega 168 micro controllers that run arduino. One of them handles all time-keeping and button/alarm events and the other handles displaying the digits on the tubes. Essentially I have one micro-controller as a master that sends short serial messages that tell the second micro-controller of what time it should display on the tubes.

[ Attachment Invalid Or Does Not Exist ] 52281[/ATTACH]

We would have enough pins to do anything we could think of with 2 teensy's. And it would probably be a lot simpler of a layout too.

The_Ed · « **Reply #488 on:** Tue, 05 June 2012, 01:16:40 »

Quote from: featherodd;607652

Just for prototyping purposes, would probably have to cut the keycaps in half or something barbaric like that. LPD8806 drivers should optimally be surface mounted to the PCB board in series. They should be able to drive most 5V RGB LEDs (I think).

If you want to destroy one of your own boards for science, be my guest. Ripster, our fellow scientist, was banned so he can't grace us with any more of his wikis here.

featherodd · « **Reply #489 on:** Tue, 05 June 2012, 03:32:28 »

Quote from: The_Ed;607658

If you want to destroy one of your own boards for science, be my guest. Ripster, our fellow scientist, was banned so he can't grace us with any more of his wikis here.

It's the easiest way I can think of mocking up a board with fully adressable RGB backlighting, especially with code examples and Arduino libraries for drivers I am familiar with. If anyone else has a better suggestion, I'm all ears.

Shame I found out about the Phantom group buy so late. Would have been awesome to start with a Teensy based dev board.

Anyone know if the schematics for the Phantom PCB boards are available?

Parak · « **Reply #490 on:** Tue, 05 June 2012, 06:33:41 »

For in-key backlighting, one is limited to a T1 LED with two leads, /maybe/ three leads with a bit of cutting of the switch. Two lead bi-color LEDs can only show one color or the other, but the three lead is an actual tricolor. External backlight might be able to use 5mm RGB LEDs if you find space for them or use light pipes, or using SMD RGB LEDs. In any case, RGB or even bi-color is quite considerably more expensive on a per LED basis than single color.

On the controller level, taking advantage of multiplexing and PWM allows for fairly drastic reductions in power and pin usage at the expense of microcontroller cycles. Which shouldn't be a big deal with the speed of the ones currently on the market.

bpiphany · « **Reply #491 on:** Tue, 05 June 2012, 07:35:30 »

SMT LEDs wont work optimally with a mounting plate, at least not without some solution to transfer the light up to the surface. Are there any T1 RGB LEDs? Modifying the switch housings to accept 4 leads might be feasible. Or drilling a 3 mm hole straight thru and using a light pipe with SMT LEDs.

alaricljs · « **Reply #492 on:** Tue, 05 June 2012, 07:38:34 »

No, 3mm packaging does not support 4 leads.

The_Ed · « **Reply #493 on:** Tue, 05 June 2012, 07:48:40 »

There are 4 holes in the bottom of every switch. 2 out of 4 leads would have to be bent though to go through them. But since the top receptacle only supports 3mm, 2 or 3 lead dual color LEDs would be the maximum feasible.

Soarer · « **Reply #494 on:** Tue, 05 June 2012, 07:48:51 »

Quote from: hazeluff;607645

No I am talking about different levels of light per LED, not all LEDs...

If we look back at that schematic prins made. We're using the column pin from the switch matrix to also determine which column of LED to choose from. And with the LED Row pins we can apply PWM to set intensity of the LED at (Col,Row).

Tho Im not sure if the teensy has enough pins that can do PWM.

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.

featherodd · « **Reply #495 on:** Tue, 05 June 2012, 15:40:48 »

Quote from: PrinsValium;607768

SMT LEDs wont work optimally with a mounting plate, at least not without some solution to transfer the light up to the surface. Are there any T1 RGB LEDs? Modifying the switch housings to accept 4 leads might be feasible. Or drilling a 3 mm hole straight thru and using a light pipe with SMT LEDs.

Agreed, would definitely have to modify the switch housing to accept either 4 prong LEDs or to pass through 3.5mm light pipes.

hazeluff · « **Reply #496 on:** Tue, 05 June 2012, 18:18:56 »

Quote from: Soarer;607774

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.

I don't quite understand why we need interrupts.

Taking the phantom firmware as a start/example. The polling is a loop and in there there is a loop that goes through the column pins, why can't the PWM be processed within that? Otherwise what you proposed in the interrupt above seems like how it would be done.

So umm just adding comments into this code:

Quote

for(; {
_delay_ms(5); // Debouncing
for(col=0; col *col_port[col] &= ~col_bit[col];
_delay_us(1);
//Turn off PWM (LED ROW) outputs
for(row=0; row //Do w/e setup needed for PWM
//Enable PWM (LED ROW) outputs
key_id = col*NROW+row;
if(!(*row_port[row] & row_bit[row])) {
if(!pressed[key_id])
key_press(key_id);
}
else if(pressed[key_id])
key_release(key_id);
}
*col_port[col] |= col_bit[col];
}

As for the discussion on RGB LEDs, I don't think it's wise to try and implement so many things at once. Also, the extra pins don't fit in the switches without significant modification.

Soarer · « **Reply #497 on:** Tue, 05 June 2012, 18:34:55 »

Having an interrupt for the column scanning gives it accurate timing. You need that so each LED is on for (1/num_cols) * (256/pwm_val) * 100 % of the overall scan time. Without it, you might have some other interrupt fire during a column strobe which would make that one take a longer time than the others, and the light level wouldn't be right!

hazeluff · « **Reply #498 on:** Tue, 05 June 2012, 19:02:43 »

Quote from: Soarer;608187

Having an interrupt for the column scanning gives it accurate timing. You need that so each LED is on for (1/num_cols) * (256/pwm_val) * 100 % of the overall scan time. Without it, you might have some other interrupt fire during a column strobe which would make that one take a longer time than the others, and the light level wouldn't be right!

Makes sense now. Maybe it wouldn't affect it too much if we don't do interrupts, unless that difference in timing is significant. Just a speculation.

Also, the keyboard polling and lighting both will be interrupts?

featherodd · « **Reply #499 on:** Tue, 05 June 2012, 19:30:23 »

Quote from: hazeluff;608178

As for the discussion on RGB LEDs, I don't think it's wise to try and implement so many things at once. Also, the extra pins don't fit in the switches without significant modification.

I think you're right. A fully addressable RGB board would be soo bad ass, but it is better to have a board many people can collaborate on and share code sketchs for controlling the LEDs. A kit where it is necessary to heavily mod the switches would be much more difficult.

News:

Author Topic: Next GH-brewed KB design - 'The Light' (open for discussion) (Read 109197 times)