How to build your very own keyboard firmware
-
- Location: New Zealand
- DT Pro Member: -
I was wondering if someone could help me.
I would like to make a 4 button keyboard but seeing I'm a super Noob I have know idea what I'm doing.
I brought a Teensy 3.2 but now after looking for ways to program it I'm not sure if that was the best option as everyone else seems to be using Teensy 2's.
Is there pre-written .ino file that I can open in Arduino compiler that I can edit then compile to my Teensy?
I would like to make a 4 button keyboard but seeing I'm a super Noob I have know idea what I'm doing.
I brought a Teensy 3.2 but now after looking for ways to program it I'm not sure if that was the best option as everyone else seems to be using Teensy 2's.
Is there pre-written .ino file that I can open in Arduino compiler that I can edit then compile to my Teensy?
-
- Location: United Kingdom
- Main keyboard: Monterey K102 White Alps
- Main mouse: Corsair sabre RGB optical
- Favorite switch: SMK 2nd Gen
- DT Pro Member: -
Hey guys, I don't normally post on this site but rather GH hence my low stats here. Recently I've been busy with college so haven't had time to fix my keyboard.
Anyways, this keyboard worked when i made it a long time ago. the only problem was a few keys didn't register. now i have time, i decided to check my code and found problems. after cleaning the code up and trying 'make -f makefile' i get the error:
"Makefile:135: ../../tmk_core/rules.mk: No such file or directory
make: *** No rule to make target '../../tmk_core/rules.mk'. Stop."
this looks like a simple case of going into the makefile and changing the dir but i have checked it and changed it many times and it still gives the same message. I'm 100% sure this is a stupid mistake and somebody will maybe give me a hint as to why.
Also, i don't find it necessary to include my code because it is a directory problem. i will if i need to. if somebody has already had this problem solved, i appologize for wasting time.
UPDATE
i re-downloaded the tmk-keyboard file and put my gh60 folder into it. it now says all of my keys are undeclared.
Thanks
Anyways, this keyboard worked when i made it a long time ago. the only problem was a few keys didn't register. now i have time, i decided to check my code and found problems. after cleaning the code up and trying 'make -f makefile' i get the error:
"Makefile:135: ../../tmk_core/rules.mk: No such file or directory
make: *** No rule to make target '../../tmk_core/rules.mk'. Stop."
this looks like a simple case of going into the makefile and changing the dir but i have checked it and changed it many times and it still gives the same message. I'm 100% sure this is a stupid mistake and somebody will maybe give me a hint as to why.
Also, i don't find it necessary to include my code because it is a directory problem. i will if i need to. if somebody has already had this problem solved, i appologize for wasting time.
UPDATE
i re-downloaded the tmk-keyboard file and put my gh60 folder into it. it now says all of my keys are undeclared.
Thanks
- Cortes
- Location: Spain
- Main keyboard: Logitech G710+
- Main mouse: Logitech G400s
- Favorite switch: Mx Brown
- DT Pro Member: -
Hi people!, I came here asking for some help, because I'm totally lost with my personalized keyboard based on teensy 2.0.
First of all, I do not speak English, and I'm translating all this into Uncle google
The question is that this is my second keyboard based on Teensy 2.0, and the functional part of keyboard works correctly, but the question is that this second keyboard sends it backlight and I'm very lost with it.
My idea is to have 2 independent leds, backlight and leds case, and I would use pins B6 and B7
I have these parts of code backlight.c that gave me the user breh:
I want to do something like breh does on your numeric keypad, have specific keys (the ones above the arrows) for the regular backlight, power on / off / more brightness / less brightness, and in another layer to control the LEDs of the case.
Here also the complete keyboard configuration:
Https://dl.dropboxusercontent.com/u/5052546/Shiro.rar
Two pics
First of all, I do not speak English, and I'm translating all this into Uncle google
The question is that this is my second keyboard based on Teensy 2.0, and the functional part of keyboard works correctly, but the question is that this second keyboard sends it backlight and I'm very lost with it.
My idea is to have 2 independent leds, backlight and leds case, and I would use pins B6 and B7
I have these parts of code backlight.c that gave me the user breh:
Code: Select all
/*
Copyright 2013 Mathias Andersson <wraul@dbox.se>
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include "backlight.h"
#include "eeconfig.h"
#include "debug.h"
backlight_config_t backlight_config;
void backlight_init(void)
{
//check signature
if (!eeconfig_is_enabled()) {
eeconfig_init();
}
backlight_config.raw = eeconfig_read_backlight();
backlight_set(backlight_config.enable ? backlight_config.level : 0);
}
void backlight_increase(void)
{
if(backlight_config.level < BACKLIGHT_LEVELS)
{
backlight_config.level++;
backlight_config.enable = 1;
eeconfig_write_backlight(backlight_config.raw);
}
dprintf("backlight increase: %u\n", backlight_config.level);
backlight_set(backlight_config.level);
}
void backlight_decrease(void)
{
if(backlight_config.level > 0)
{
backlight_config.level--;
backlight_config.enable = !!backlight_config.level;
eeconfig_write_backlight(backlight_config.raw);
}
dprintf("backlight decrease: %u\n", backlight_config.level);
backlight_set(backlight_config.level);
}
void backlight_toggle(void)
{
backlight_config.enable ^= 1;
eeconfig_write_backlight(backlight_config.raw);
dprintf("backlight toggle: %u\n", backlight_config.enable);
backlight_set(backlight_config.enable ? backlight_config.level : 0);
}
void backlight_step(void)
{
backlight_config.level++;
if(backlight_config.level > BACKLIGHT_LEVELS)
{
backlight_config.level = 0;
}
backlight_config.enable = !!backlight_config.level;
eeconfig_write_backlight(backlight_config.raw);
dprintf("backlight step: %u\n", backlight_config.level);
backlight_set(backlight_config.level);
}
void backlight_level(uint8_t level)
{
backlight_config.level ^= level;
backlight_config.enable = !!backlight_config.level;
eeconfig_write_backlight(backlight_config.raw);
backlight_set(backlight_config.level);
}
// Plank Code for Backlight
//#include <avr/io.h>
//#include "backlight.h"
#define CHANNEL OCR1B
// Plank is OCR1C
void backlight_init_ports()
{
// Setup PB7 as output and output low.
DDRB |= (1<<6);
PORTB &= ~(1<<6);
// Use full 16-bit resolution.
ICR1 = 0xFFFF;
// I could write a wall of text here to explain... but TL;DW
// Go read the ATmega32u4 datasheet.
// And this: http://blog.saikoled.com/post/43165849837/secret-konami-cheat-code-to-high-resolution-pwm-on
// Pin PB7 = OCR1C (Timer 1, Channel C)
// Pin PB6 = OCR1B (Timer 1, Channel B)
// Compare Output Mode = Clear on compare match, Channel C = COM1C1=1 COM1C0=0
// Compare Output Mode = Clear on compare match, Channel C = COM1B1=1 COM1B0=0
// (i.e. start high, go low when counter matches.)
// WGM Mode 14 (Fast PWM) = WGM13=1 WGM12=1 WGM11=1 WGM10=0
// Clock Select = clk/1 (no prescaling) = CS12=0 CS11=0 CS10=1
TCCR1A = _BV(COM1B1) | _BV(WGM11); // = 0b00001010;
TCCR1B = _BV(WGM13) | _BV(WGM12) | _BV(CS10); // = 0b00011001;
backlight_init();
}
void backlight_set(uint8_t level)
{
if ( level == 0 )
{
// Turn off PWM control on PB6, revert to output low.
TCCR1A &= ~(_BV(COM1B1));
CHANNEL = 0x0;
// Prevent backlight blink on lowest level
PORTB &= ~(_BV(PORTB6));
}
else if ( level == BACKLIGHT_LEVELS )
{
// Prevent backlight blink on lowest level
PORTB &= ~(_BV(PORTB6));
// Turn on PWM control of PB6
TCCR1A |= _BV(COM1B1);
// Set the brightness
CHANNEL = 0xFFFF;
}
else
{
// Prevent backlight blink on lowest level
PORTB &= ~(_BV(PORTB6));
// Turn on PWM control of PB6
TCCR1A |= _BV(COM1B1);
// Set the brightness
CHANNEL = 0xFFFF >> ((BACKLIGHT_LEVELS - level) * ((BACKLIGHT_LEVELS + 1) / 2));
}
}
Here also the complete keyboard configuration:
Https://dl.dropboxusercontent.com/u/5052546/Shiro.rar
Two pics
Spoiler:
-
- Location: USA
- Main keyboard: Pok3r
- DT Pro Member: -
@richfiles - Did you ever get an answer to your question from several months ago? I'm digging through TMK/QMK threads here and at GH to understand how, among other things, the keymap.h file works.richfiles wrote: ↑ What I want to know, is where the matrix definitions need to be ordered by electrical sequence, or if the values are arbitrary, and allow for physical sequence (as long as the values are correctly defined). The obviously functional way is to lay the matrix out electrically. This seems to be what's assumed.
My question then is which (if either, or both, or neither, or 42 ) would be correct?
My question is, are the values entered into the table above dependent on position in the list, or just by content. It'd be FAR easier to follow the second layout, but I don't know if it screws with the code to mix and match rows and columns like that, or whether it's all good, as long as the numbers match.
Basically, is the code expecting all the rows and columns to be in a neat and orderly incrementing layout (all the columns, in order, 0 to the maximum, for row one, then repeating for row two, and so on), or is this list arbitrarily defining the intersection values based not he numbers entered (arbitrarily defining what key labels are to be used for each matrix intersection, without regard to were in the list the sit, so long as row and column numbers match up)?
-
- Location: Virginia
- Main mouse: Logitech Trackman
- Favorite switch: Cherry MX
- DT Pro Member: -
I have my code compiling and ready to load, but I'm using a Teensy 3.2. Can I not use gh60 with a Teensy 3.2? It doesn't appear to be supported, I'm in a bind though and would really like to use my 3.2. Is there a way around this?
-
- Location: Stockholm, Sweden
- DT Pro Member: 0011
The GH60 has a ATmega32u4 microcontroller on the board already so there is no need for an additional controller board. You could save it for another project.
-
- Location: sweden
- DT Pro Member: -
Good job on the tutorial!
But I have a problem, when Im in the GH60 directory I can get everything to work. But I wanted a own directory so I copied the files I needed. Now when I run the make command I get:
I don't want any leds at all so how would I specify that?
But I have a problem, when Im in the GH60 directory I can get everything to work. But I wanted a own directory so I copied the files I needed. Now when I run the make command I get:
Code: Select all
tmk_core/protocol/lufa/lufa.c:694: undefined reference to `led_set'
tmk_core/common/keyboard.c:182: undefined reference to `led_set'
-
- Location: United States
- Main keyboard: Logitech G710+
- Main mouse: Roccat Tyon
- Favorite switch: Cherry Browns
- DT Pro Member: -
Would it be possible for someone to compile this for me? I can't figure it out for the life of me.
https://drive.google.com/drive/folders/ ... sp=sharing
https://drive.google.com/drive/folders/ ... sp=sharing
-
- Location: vietnam
- Main keyboard: Dell Quitekey RT7D5JTW
- Favorite switch: Gateron Blue
- DT Pro Member: -
interesting project. i'm currently researching to do something like you do. Let me know if you have solution on your code.Cortes wrote: ↑Hi people!, I came here asking for some help, because I'm totally lost with my personalized keyboard based on teensy 2.0.
First of all, I do not speak English, and I'm translating all this into Uncle google
The question is that this is my second keyboard based on Teensy 2.0, and the functional part of keyboard works correctly, but the question is that this second keyboard sends it backlight and I'm very lost with it.
My idea is to have 2 independent leds, backlight and leds case, and I would use pins B6 and B7
I have these parts of code backlight.c that gave me the user breh:
I want to do something like breh does on your numeric keypad, have specific keys (the ones above the arrows) for the regular backlight, power on / off / more brightness / less brightness, and in another layer to control the LEDs of the case.Code: Select all
/* Copyright 2013 Mathias Andersson <wraul@dbox.se> This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>. */ #include "backlight.h" #include "eeconfig.h" #include "debug.h" backlight_config_t backlight_config; void backlight_init(void) { //check signature if (!eeconfig_is_enabled()) { eeconfig_init(); } backlight_config.raw = eeconfig_read_backlight(); backlight_set(backlight_config.enable ? backlight_config.level : 0); } void backlight_increase(void) { if(backlight_config.level < BACKLIGHT_LEVELS) { backlight_config.level++; backlight_config.enable = 1; eeconfig_write_backlight(backlight_config.raw); } dprintf("backlight increase: %u\n", backlight_config.level); backlight_set(backlight_config.level); } void backlight_decrease(void) { if(backlight_config.level > 0) { backlight_config.level--; backlight_config.enable = !!backlight_config.level; eeconfig_write_backlight(backlight_config.raw); } dprintf("backlight decrease: %u\n", backlight_config.level); backlight_set(backlight_config.level); } void backlight_toggle(void) { backlight_config.enable ^= 1; eeconfig_write_backlight(backlight_config.raw); dprintf("backlight toggle: %u\n", backlight_config.enable); backlight_set(backlight_config.enable ? backlight_config.level : 0); } void backlight_step(void) { backlight_config.level++; if(backlight_config.level > BACKLIGHT_LEVELS) { backlight_config.level = 0; } backlight_config.enable = !!backlight_config.level; eeconfig_write_backlight(backlight_config.raw); dprintf("backlight step: %u\n", backlight_config.level); backlight_set(backlight_config.level); } void backlight_level(uint8_t level) { backlight_config.level ^= level; backlight_config.enable = !!backlight_config.level; eeconfig_write_backlight(backlight_config.raw); backlight_set(backlight_config.level); } // Plank Code for Backlight //#include <avr/io.h> //#include "backlight.h" #define CHANNEL OCR1B // Plank is OCR1C void backlight_init_ports() { // Setup PB7 as output and output low. DDRB |= (1<<6); PORTB &= ~(1<<6); // Use full 16-bit resolution. ICR1 = 0xFFFF; // I could write a wall of text here to explain... but TL;DW // Go read the ATmega32u4 datasheet. // And this: http://blog.saikoled.com/post/43165849837/secret-konami-cheat-code-to-high-resolution-pwm-on // Pin PB7 = OCR1C (Timer 1, Channel C) // Pin PB6 = OCR1B (Timer 1, Channel B) // Compare Output Mode = Clear on compare match, Channel C = COM1C1=1 COM1C0=0 // Compare Output Mode = Clear on compare match, Channel C = COM1B1=1 COM1B0=0 // (i.e. start high, go low when counter matches.) // WGM Mode 14 (Fast PWM) = WGM13=1 WGM12=1 WGM11=1 WGM10=0 // Clock Select = clk/1 (no prescaling) = CS12=0 CS11=0 CS10=1 TCCR1A = _BV(COM1B1) | _BV(WGM11); // = 0b00001010; TCCR1B = _BV(WGM13) | _BV(WGM12) | _BV(CS10); // = 0b00011001; backlight_init(); } void backlight_set(uint8_t level) { if ( level == 0 ) { // Turn off PWM control on PB6, revert to output low. TCCR1A &= ~(_BV(COM1B1)); CHANNEL = 0x0; // Prevent backlight blink on lowest level PORTB &= ~(_BV(PORTB6)); } else if ( level == BACKLIGHT_LEVELS ) { // Prevent backlight blink on lowest level PORTB &= ~(_BV(PORTB6)); // Turn on PWM control of PB6 TCCR1A |= _BV(COM1B1); // Set the brightness CHANNEL = 0xFFFF; } else { // Prevent backlight blink on lowest level PORTB &= ~(_BV(PORTB6)); // Turn on PWM control of PB6 TCCR1A |= _BV(COM1B1); // Set the brightness CHANNEL = 0xFFFF >> ((BACKLIGHT_LEVELS - level) * ((BACKLIGHT_LEVELS + 1) / 2)); } }
Here also the complete keyboard configuration:
Https://dl.dropboxusercontent.com/u/5052546/Shiro.rar
Two picsSpoiler:
-
- Location: United States
- Favorite switch: Cherry MX brown
- DT Pro Member: -
Hi! I just built a keyboard using matt3o's excellent guide, and have been working on the firmware for the last week or so, but I hit a snag a couple days ago. I based mine off of the teensy_lc_onekey example in tmk_keyboards, and all of the keys work except the F keys and a few of the action keys (copy, paste, undo, again). The mouse keys all work, and the layers are working correctly. When I try to use the F1-F12 keys, though, it either does nothing or outputs a number and tilde, like 0~ or 5~.
I have put most of my changes here: https://pastebin.com/GSGqK9Cy
Picture of board, put together (totally unnecessary): https://www.instagram.com/p/BTOqX7hBD89 ... s_in_socks
Please help! I really want to close up my new keyboard!!
I have put most of my changes here: https://pastebin.com/GSGqK9Cy
Picture of board, put together (totally unnecessary): https://www.instagram.com/p/BTOqX7hBD89 ... s_in_socks
Please help! I really want to close up my new keyboard!!
-
- Location: Germany
- Main keyboard: ISO50
- Main mouse: Kensington SlimBlade
- Favorite switch: Gateron green
- DT Pro Member: -
This doesn't look wrong to me. How do other keyboards behave in this context?deirdreinamber wrote: ↑When I try to use the F1-F12 keys, though, it either does nothing or outputs a number and tilde, like 0~ or 5~.
-
- Location: United States
- Favorite switch: Cherry MX brown
- DT Pro Member: -
F1/F2 control brightness, F7-F12 control media
- richfiles
- Location: MN, USA
- Main keyboard: Logitech DiNovo Edge
- Main mouse: Microsoft Optical Notebook Mouse
- Favorite switch: Alps SKCM Amber "Taxi Yellow"
- DT Pro Member: -
Honestly... No, I never got my question answered, and sadly, my keyboard is STILL sitting without firmware. It's a pretty paperweight at the moment. I got busy at work, and then I got really into my Kerbal Space Program instrument/control panel, then i had to deal with an injury, then a dead motherboard... And now Nearly a year has passed, and I still don't have a functioning keyboard.lunas wrote: ↑@richfiles - Did you ever get an answer to your question from several months ago? I'm digging through TMK/QMK threads here and at GH to understand how, among other things, the keymap.h file works.richfiles wrote: ↑ What I want to know, is where the matrix definitions need to be ordered by electrical sequence, or if the values are arbitrary, and allow for physical sequence (as long as the values are correctly defined). The obviously functional way is to lay the matrix out electrically. This seems to be what's assumed.
My question then is which (if either, or both, or neither, or 42 ) would be correct?
My question is, are the values entered into the table above dependent on position in the list, or just by content. It'd be FAR easier to follow the second layout, but I don't know if it screws with the code to mix and match rows and columns like that, or whether it's all good, as long as the numbers match.
Basically, is the code expecting all the rows and columns to be in a neat and orderly incrementing layout (all the columns, in order, 0 to the maximum, for row one, then repeating for row two, and so on), or is this list arbitrarily defining the intersection values based on the numbers entered (arbitrarily defining what key labels are to be used for each matrix intersection, without regard to were in the list they sit, so long as row and column numbers match up)?
On the bright side, I got my number pad plate manufactured, so I have that! Unfortunately, it still does nothing...
That only means i now have to consider the numberpad as well as the regular keyboard, making my firmware needs even more complex now than when I was just asking about getting the main keyboard up and running... At this point, I think I need a dedicated thread to figuring out how to make a firmware for this. Now, it not only needs to do the regular polling of the main keyboard, but it also now needs to monitor the state of a logic input to determine if the external number pad is present, and ONLY if it is, then poll a port expander over I2C (and to ignore the I2C ports if the logic signal tells the numberpad is detached.
For someone with no C experience, I really feel like I'm in way over my head with this... Hardware is what I know...
- j0d1
- Location: Montreal
- Main keyboard: IBM Model F107
- Main mouse: Logitech M570
- Favorite switch: Buckling Spring
- DT Pro Member: 0203
Holy cow this keyboard is gorgeous, it MUST become functional.
If you have a Teensy 3.2 (other variant may work but I'm not sure...), I can help you, if you're willing to ditch TMK/QMK and build your own firmware under Linux.
I tried TMK/QMK and I found them overly complicated for my needs.
I decided to code my own firmware _from scratch_ (well it runs on top of Teensyduino): https://github.com/jodigiordano/mode_ke ... aster/code
Its a keyboard with layers and controllable RGB LEDs so the code can become way more simpler for your needs.
If you're interested, I can strip down my code to its bare minimum so you have an easy-to-understand firmware to drive your main board. Then you can build on top of it to control the other board!
If you have a Teensy 3.2 (other variant may work but I'm not sure...), I can help you, if you're willing to ditch TMK/QMK and build your own firmware under Linux.
I tried TMK/QMK and I found them overly complicated for my needs.
I decided to code my own firmware _from scratch_ (well it runs on top of Teensyduino): https://github.com/jodigiordano/mode_ke ... aster/code
Its a keyboard with layers and controllable RGB LEDs so the code can become way more simpler for your needs.
If you're interested, I can strip down my code to its bare minimum so you have an easy-to-understand firmware to drive your main board. Then you can build on top of it to control the other board!
-
- Location: Beamspringville
- Main keyboard: 4704
- DT Pro Member: 0186
So, the ~ plus characters is actually correct for function keys. That's what they've output for 30-40 years.deirdreinamber wrote: ↑F1/F2 control brightness, F7-F12 control media
What you're used to is what modern manufacturers have done where they've made the default for those keys fn+Fkey which usually maps to your media / brightness. It's frequently a bios setting.
If that is what you want for your keyboard, you need to change the mapping in firmware so that instead of emitting F1-F12 it emits your specials...
-
- Location: United States
- Favorite switch: Cherry MX brown
- DT Pro Member: -
Interesting. I tried the specials, and they weren't working either, but it seems like that's just an incorrect setting to track down. Thank you, that's one of those not-easy-to-google-for problems. :/
- richfiles
- Location: MN, USA
- Main keyboard: Logitech DiNovo Edge
- Main mouse: Microsoft Optical Notebook Mouse
- Favorite switch: Alps SKCM Amber "Taxi Yellow"
- DT Pro Member: -
I'm running a Teensy 2.0 in this thing. It's very hand wired... and laced into the keyboard.j0d1 wrote: ↑Holy cow this keyboard is gorgeous, it MUST become functional.
If you have a Teensy 3.2 (other variant may work but I'm not sure...), I can help you, if you're willing to ditch TMK/QMK and build your own firmware under Linux...
I'm potentially open to anything, I suppose, though I'm running a Hackintosh with a rarely used Windows 10 volume as a bootable option. If I ever get another SSD, I thought I'd maybe put Ubuntu on like I had on my old PC and my PS3. My biggest problem, is my C coding skills ultimately amount to looking at existing commented code examples, and modifying them (through many mistaken iterations) to my needs... I don't actually have a grasp of much of any of the fundamentals yet. Worse, what little I did learn, pretty much faded away in the literal year that's passed since I last tried to do this.
Since I still have to hand wire my number pad yet, I figure, if I can just get the basics working for the main keyboard, I'd probably be alright. It was literally just one question that had me hung up on TMK (at least as far as I'd gotten). I would imagine finishing what I started would be the quickest path to a functioning main keyboard, and I can look at other firmware options when it comes time to integrate the numberpad functionality.
- j0d1
- Location: Montreal
- Main keyboard: IBM Model F107
- Main mouse: Logitech M570
- Favorite switch: Buckling Spring
- DT Pro Member: 0203
What kind of switches do you use?richfiles wrote:I'm running a Teensy 2.0 in this thing. It's very hand wired... and laced into the keyboard.
I'm puzzled, there seem to be way more wires than needed, do you have the schematics for this?
Yeah if you are near to make it work on TMK, maybe the best course of action is to continue on this path.richfiles wrote:Since I still have to hand wire my number pad yet, I figure, if I can just get the basics working for the main keyboard, I'd probably be alright. It was literally just one question that had me hung up on TMK (at least as far as I'd gotten). I would imagine finishing what I started would be the quickest path to a functioning main keyboard, and I can look at other firmware options when it comes time to integrate the numberpad functionality.
- richfiles
- Location: MN, USA
- Main keyboard: Logitech DiNovo Edge
- Main mouse: Microsoft Optical Notebook Mouse
- Favorite switch: Alps SKCM Amber "Taxi Yellow"
- DT Pro Member: -
I use Gateron Blue, but some have green springs. The top housings have all been dyed blue, to match the anodized aluminum plate.
The reason there are more wires is I have LEDs in every switch. All LEDs are amber, controlled from a PWM pin of the Teensy 2.0. There are actually 4 banks of 22 LEDs, covering the 88 total keys. LEDs are wired in series pairs with a 100 Ohm resistor inline, and those 11 pairs are then wired in parallel and driven by a simple transistor driver. There are 4 transistor drivers, to spread out current load, so no individual driver transistor is more than approximately 50% its max current rating. Keeps the transistors unstressed. The LEDs are set to only generate a mild ambient light. They're not very bright, but that's cause I want them USB powered. I'll start the keyboard at low brightness, when powered on. With the number pad plugged in, I think I might lock out the highest brightness level.
The thicker wires are for power and LEDs. The thin blue wires are rows, columns, and data to the Magsafe port. The layout compresses 88 keys into a 13x7 matrix, to allow one LED PWM line, one Caps Lock line, two I2C wires, and a Sense wire that changes logic level when the numberpad is attached or detached.
I only mention TMK, cause I actually was through a lot of the work to make it work. I just was stumpped at the onequestion, and life happened right when I hit a wall, and it took me a year to come back to this.
I've got a crude row column schematic, and I have the row column connection guide posted. The LEDs were done in my head, so I've never drawn out a schematic for their configuration.
**EDIT** Posted this from a Chromebook on my break at work... And it double posted? Weird. Fixed.
The reason there are more wires is I have LEDs in every switch. All LEDs are amber, controlled from a PWM pin of the Teensy 2.0. There are actually 4 banks of 22 LEDs, covering the 88 total keys. LEDs are wired in series pairs with a 100 Ohm resistor inline, and those 11 pairs are then wired in parallel and driven by a simple transistor driver. There are 4 transistor drivers, to spread out current load, so no individual driver transistor is more than approximately 50% its max current rating. Keeps the transistors unstressed. The LEDs are set to only generate a mild ambient light. They're not very bright, but that's cause I want them USB powered. I'll start the keyboard at low brightness, when powered on. With the number pad plugged in, I think I might lock out the highest brightness level.
The thicker wires are for power and LEDs. The thin blue wires are rows, columns, and data to the Magsafe port. The layout compresses 88 keys into a 13x7 matrix, to allow one LED PWM line, one Caps Lock line, two I2C wires, and a Sense wire that changes logic level when the numberpad is attached or detached.
I only mention TMK, cause I actually was through a lot of the work to make it work. I just was stumpped at the onequestion, and life happened right when I hit a wall, and it took me a year to come back to this.
I've got a crude row column schematic, and I have the row column connection guide posted. The LEDs were done in my head, so I've never drawn out a schematic for their configuration.
**EDIT** Posted this from a Chromebook on my break at work... And it double posted? Weird. Fixed.
-
- Location: Argentina
- Main keyboard: Ti-99/4A
- DT Pro Member: -
Hi. I'm electronic engineer but my experience in coding is very limited (some BASIC in the past...)
My project is a Commodore 64 Keyboard, switching between "Emulator Mode" and "PC Mode", and having some RGB LED switching color according which mode is on.
For Emulator Mode, a plain matrix is needed. Emulator takes care of the rest (VICE Emulator in Positional Configuration for most "pure" emulation). For PC Mode, some remapping and macros are needed.
So my questions are:
1. Can I use a Teensy 2.0++ (90USB1286)? (I have three of those). Do I have to change anything else in makefile besides MCU = at90usb1286 ?
2. Any guide how to integrate LED control to the code?
3. I know how to use TeensyLoader for loading an .hex file to the T2.0++, but how do I compile in Windows?
PS: Actually my goal is getting a R-Pi 3 inside the C-64 case and having the closest experience possible to a real C-64.
My project is a Commodore 64 Keyboard, switching between "Emulator Mode" and "PC Mode", and having some RGB LED switching color according which mode is on.
For Emulator Mode, a plain matrix is needed. Emulator takes care of the rest (VICE Emulator in Positional Configuration for most "pure" emulation). For PC Mode, some remapping and macros are needed.
So my questions are:
1. Can I use a Teensy 2.0++ (90USB1286)? (I have three of those). Do I have to change anything else in makefile besides MCU = at90usb1286 ?
2. Any guide how to integrate LED control to the code?
3. I know how to use TeensyLoader for loading an .hex file to the T2.0++, but how do I compile in Windows?
PS: Actually my goal is getting a R-Pi 3 inside the C-64 case and having the closest experience possible to a real C-64.
-
- Location: vietnam
- Main keyboard: Dell Quitekey RT7D5JTW
- Favorite switch: Gateron Blue
- DT Pro Member: -
Rejerh wrote: ↑For whoever is interested, after quite some difficulties and still wondering how everything works I managed to make my backlight work.
My set up is as follows:
1- All my 69 Leds with some resistors in series (be careful to take strong enough resistors so you don't try to get more than 500mA out of the USB port) are connected in parallel to the VCC and to one of the outside pins of a transistor (not the middle one).
2- The transistor has its middle pin connected to PD7 on a teensy 2.0 and its last pin connected to the GND.
The idea is to control the PWM on the PD7 to make the transistor open and close more or less to control the brightness of the Leds
I have designed schematic to control 84 led of my keyboard. As instruction of Rejerh, but it draw more than 500mA for those leds.
Rejerh, Matt3o or anyone please take a look at my attached pic and advise... thank in advance
- Attachments
-
- keyboard_84_led_schematic.png (129.64 KiB) Viewed 10413 times
-
- Location: vietnam
- Main keyboard: Dell Quitekey RT7D5JTW
- Favorite switch: Gateron Blue
- DT Pro Member: -
Could you explain in more detail? I'm afraid we dont have enought controller pin for this.__red__ wrote: ↑This isn't the way I would solve this problem. Consider using an LED driver IC, charlieplexing, or individually addressable LEDs.
- Mieber
- Location: Deutschland, Leinfelden-Echterdingen
- Main keyboard: G80@work / whitefox@home
- Main mouse: Razer Deathadder
- Favorite switch: MX Clear
- DT Pro Member: -
I just created the following post to request help with my setup. One minute after I posted this I realised my mistake, as I ignored the following sentence:
Hello, I soldered my own whitefox and trying to get it running with hasu's firmware. My first try resulted in keys not working as expected at all. So I created a very stripped down test setup that contains only two columns and two rows.
My setup:
Teensy 2.0 ++
Whitefox Plate
This is my soldered setup:
As you can see my connected rows are D3 (top) and D2 (lower) and the columns are F5 (left) and F4 (right) (as seen from the front).
Attached you can find my complete setup files. The relevant parts are:
config.sh
keymap_my.c
Makefile
matrix.c - Rows: D3 (top) and D2 (lower) / Columns: F5 (left) and F4 (right)
keymap_common.h
I mapped the four keys to 1,2,3,4. But what happens is this:
After I adjusted that my setup is working now. I decided to still post this as it maybe could help someone:Start counting from the right. The first bit is PIN0, the last is PIN7. Just set the pins you use to 1. Peachy, isn't it?
Hello, I soldered my own whitefox and trying to get it running with hasu's firmware. My first try resulted in keys not working as expected at all. So I created a very stripped down test setup that contains only two columns and two rows.
My setup:
Teensy 2.0 ++
Whitefox Plate
This is my soldered setup:
As you can see my connected rows are D3 (top) and D2 (lower) and the columns are F5 (left) and F4 (right) (as seen from the front).
Attached you can find my complete setup files. The relevant parts are:
config.sh
Code: Select all
#define MATRIX_ROWS 2
#define MATRIX_COLS 2
Code: Select all
const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
/* 0: qwerty */
KEYMAP(1, 2, \
3, 4),
};
Code: Select all
MCU = at90usb1286
OPT_DEFS += -DBOOTLOADER_SIZE=4096
Code: Select all
static void init_cols(void)
{
// Input with pull-up(DDR:0, PORT:1)
DDRF &= ~(1<<5 | 1<<4 );
PORTF |= (1<<5 | 1<<4 );
}
static matrix_row_t read_cols(void)
{
return (PINF&(1<<5) ? 0 : (1<<0)) |
(PINF&(1<<4) ? 0 : (1<<1));
}
static void unselect_rows(void)
{
// Hi-Z(DDR:0, PORT:0) to unselect
// HERE I DID IT WRONG! THIS IS NOT HOW IT SHOULD BE:
// DDRD &= ~0b00110000;
// PORTD &= ~0b00110000;
// THIS IS CORRECT, COUNT FROM RIGHT :)
DDRD &= ~0b00001100;
PORTD &= ~0b00001100;
}
static void select_row(uint8_t row)
{
// Output low(DDR:1, PORT:0) to select
switch (row) {
case 0:
DDRD |= (1<<3);
PORTD &= ~(1<<3);
break;
case 1:
DDRD |= (1<<2);
PORTD &= ~(1<<2);
break;
}
}
Code: Select all
#define KEYMAP( \
K00, K01, \
K10, K11 \
) { \
// ANOTHER MISTAKE I MADE. I MAPPED THE SAME KEY IN TWO ROWS (K01)
{ KC_##K00, KC_##K01 }, \
{ KC_##K10, KC_##K01 } \
}
- Pressing 1 results in 13
Pressing 2 results in 2
Pressing 3 results in 13
Pressing 4 results in 2
- Attachments
-
- tst_whitefox.zip
- All test files that I used. Mind: they still contain the mistakes I made. See my text.
- (76.3 KiB) Downloaded 268 times