Author Topic: GH60 prototype betatesting [Call for layouts, GUI testing]  (Read 151165 times)

0 Members and 1 Guest are viewing this topic.

Offline WhiteFireDragon

  • Posts: 2276
    • youtube
Re: GH60 prototype betatesting
« Reply #200 on: Wed, 30 January 2013, 20:46:50 »
@kmiller8, you might have heated it too much so the glue holding the pads (if you can even call it that...) of the switch pins will lift a lot easier. Compounded with the fact that you might not have gotten all the solder off the switch pins/traces before pulling the switch out. 10 out of 87 keys is not a very good error ratio lol. And what kind of torture test did you put the PCB through?

@alaricljs, Of course the single sided PCB was on purpose, but I'm sure it was more of a business decision to save costs. Of course it'll sound much better publicly to say for testing purposes than to say they cheaped out on the PCB to save money.

Offline alaricljs

  • I be WOT'ing all day...
  • ** Moderator Emeritus
  • Posts: 3715
  • Location: NE US
Re: GH60 prototype betatesting
« Reply #201 on: Wed, 30 January 2013, 20:49:18 »
Well Carter did claim that it had something to do with noise... but whatever.

I got quantity pricing for Costar on "the same design" and CMs margins are admirable from a consumer perspective on the QFR sales.
Filco w/ Imsto thick PBT
Ducky 1087XM PCB+Plate, w/ Matias "Quiet Click" spring-swapped w/ XM Greens

Offline WhiteFireDragon

  • Posts: 2276
    • youtube
Re: GH60 prototype betatesting
« Reply #202 on: Wed, 30 January 2013, 21:10:09 »
Admirable indeed. Small cut in PCB specs that won't matter to most consumers, but huge ~50% reduction in price compared to Filco. But I wouldn't confuse the business decision with performance claims. They claim to worry about noise, yet failed to put a ferrite bead on the cable, something that the Filco cable has (which is not really needed lol). Anyways, I won't go OT on this anymore. Another time and thread for that.

Offline kmiller8

  • Banned
  •  Post Reporting Timeout
  • Posts: 1589
  • Who is that kmiller8 guy?
Re: GH60 prototype betatesting
« Reply #203 on: Wed, 30 January 2013, 21:29:44 »
@kmiller8, you might have heated it too much so the glue holding the pads (if you can even call it that...) of the switch pins will lift a lot easier. Compounded with the fact that you might not have gotten all the solder off the switch pins/traces before pulling the switch out. 10 out of 87 keys is not a very good error ratio lol. And what kind of torture test did you put the PCB through?

I definately heated them too much, but still, I used the same iron on the GH60 board and everything was fine (ok there was ONE pad I thought I lifted, I almost cried)

The torture was my soldering, then desoldering, then resoldering the board with the cheapest Radio Shack Soldering Irons I could find :)





It's such a bad job, and I wuvs it.

This PCB is so well done, I belive that any newb can use any ****ty iron and make a board that works :)

Offline jdcarpe

  • * Curator
  • Posts: 8854
  • Location: Odessa, TX
  • Live long, and prosper.
Re: GH60 prototype betatesting
« Reply #204 on: Wed, 30 January 2013, 23:24:52 »
kmiller8, looks like you may have soldered the switches for R_ALT and R_WIN in the wrong positions? I dunno, maybe it's just how I'm looking at it. I see you placed the Caps Lock in the "Cherry" position, though. Nice. :)

Yeah, if you and I can make these things with our crap Radio Shack equipment (I had to desolder every switch from my board as well, to install the plate), anyone should be able to do it. ;D
KMAC :: LZ-GH :: WASD CODE :: WASD v2 :: GH60 :: Alps64 :: JD45 :: IBM Model M :: IBM 4704 "Pingmaster"

http://jd40.info :: http://jd45.info


in memoriam

"When I was a kid, I used to take things apart and never put them back together."

Offline kmiller8

  • Banned
  •  Post Reporting Timeout
  • Posts: 1589
  • Who is that kmiller8 guy?
Re: GH60 prototype betatesting
« Reply #205 on: Wed, 30 January 2013, 23:45:57 »
kmiller8, looks like you may have soldered the switches for R_ALT and R_WIN in the wrong positions? I dunno, maybe it's just how I'm looking at it. I see you placed the Caps Lock in the "Cherry" position, though. Nice. :)

Yeah, if you and I can make these things with our crap Radio Shack equipment (I had to desolder every switch from my board as well, to install the plate), anyone should be able to do it. ;D

caps lock and spacebar are cherry position, since I used cherry caps :)

The switches should be in the right place, all my caps fit just fine :x

I had to desolder two boards to build this thing... A Cherry plate mount black with 1/8th working switches, and a plate mount QFR (I used it for 20 minutes before ripping it apart and desoldering the sweet sweet blues)

I went through three soldering irons throughout this project, granted the first two were already half broken from previous "projects"

Offline jdcarpe

  • * Curator
  • Posts: 8854
  • Location: Odessa, TX
  • Live long, and prosper.
Re: GH60 prototype betatesting
« Reply #206 on: Mon, 11 February 2013, 16:32:23 »
Finally got around to reprogramming my GH60 today. A bit of a learning curve there, as this was the first time I've programmed a board. I used hasu's firmware to program the Fn layer in Poker-style. Success! I also tried using HHKB layout on both default and Fn layers, and got that to work, as well.

Code: [Select]
    /* Layer 1: Poker mode
     * ,-----------------------------------------------------------.
     * |  `| F1| F2| F3| F4| F5| F6| F7| F8| F9|F10|F11|F12|       |
     * |-----------------------------------------------------------|
     * |     |   |Up |   |   |   |   |   |   |   |   |Hom|Ins|     |
     * |-----------------------------------------------------------|
     * |      |Lef|Dow|Rig|   |   |Psc|Slk|Pus|   |   |End|Enter   |
     * |-----------------------------------------------------------|
     * |Shift   |Del|   |   |Mut|Vl+|Vl-|   |PgU|PgD|Del|Shift     |
     * |-----------------------------------------------------------|
     * |Ctrl|Gui |Alt |      Space                  |Alt |xxx |Crtl|
     * `-----------------------------------------------------------'
     */
KMAC :: LZ-GH :: WASD CODE :: WASD v2 :: GH60 :: Alps64 :: JD45 :: IBM Model M :: IBM 4704 "Pingmaster"

http://jd40.info :: http://jd45.info


in memoriam

"When I was a kid, I used to take things apart and never put them back together."

Offline gnubag

  • Posts: 509
  • Location: California, US
Re: GH60 prototype betatesting
« Reply #207 on: Mon, 11 February 2013, 18:25:57 »
has any one tried to make 2 permanent layers + 1 function layer?

what i mean by that is:
1. layer qwerty
2. layer dvorak/colemak
and function layer as in fn + 1 = f1 , etc.

so switching between layer 1 and 2 with a toggle switch.

Offline jdcarpe

  • * Curator
  • Posts: 8854
  • Location: Odessa, TX
  • Live long, and prosper.
Re: GH60 prototype betatesting
« Reply #208 on: Mon, 11 February 2013, 18:30:58 »
You can certainly do that. It's in hasu's keycode.h. From hasu's github (https://github.com/tmk/tmk_keyboard):

Quote
2.2 Layer Actions

This sets default layer into current layer. With this action you can return to default layer.

ACTION_LAYER_DEFAULT
Layer Set action sets given layer argument to current layer. Layer Set action can take 0 to 15 as argument.

ACTION_LAYER_SET(layer)
ACTION_LAYER_SET_TOGGLE(layer)
ACTION_LAYER_SET_TAP_KEY(layer, key)
ACTION_LAYER_SET_TAP_TOGGLE(layer)
Layer Bit action XOR bits with current layer. Layer Bit action can take 0 to 8 as argument.

ACTION_LAYER_BIT(bits)
ACTION_LAYER_BIT_TOGGLE(bits)
ACTION_LAYER_BIT_TAP_KEY(bits, key)
ACTION_LAYER_BIT_TAP_TOGGLE(bits)
These acitons change default layer. ACTION_LAYER_SET_DEFAULT(layer) ACTION_LAYER_BIT_DEFAULT(bits)
KMAC :: LZ-GH :: WASD CODE :: WASD v2 :: GH60 :: Alps64 :: JD45 :: IBM Model M :: IBM 4704 "Pingmaster"

http://jd40.info :: http://jd45.info


in memoriam

"When I was a kid, I used to take things apart and never put them back together."

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: GH60 prototype betatesting
« Reply #209 on: Tue, 12 February 2013, 20:22:20 »
a-ha! i have enough ssk assemblies built now that i don't feel bad about populating my gh60 with switches!

quick q though: it looks like the pads aren't tinned. are they? am i just blind or something?

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline WhiteFireDragon

  • Posts: 2276
    • youtube
Re: GH60 prototype betatesting
« Reply #210 on: Tue, 12 February 2013, 21:10:07 »
Why would switch pads need to be tinned? If you're talking about all the other pads for SMD components, I already soldered everything on for yours.

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: GH60 prototype betatesting
« Reply #211 on: Tue, 12 February 2013, 21:46:28 »
switch pads.

not tinned -> flux -> heat -> flow

tinned -> heat -> flow

not a big deal either way, just curious

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline WhiteFireDragon

  • Posts: 2276
    • youtube
Re: GH60 prototype betatesting
« Reply #212 on: Tue, 12 February 2013, 23:09:16 »
If you put it that way, then phantom doesn't come "tinned" either. Usually through-hole pads won't come pretinned. Your solder wire has rosin in it, which acts as a flux when you solder. Even if you use solder paste, there's already flux mixed in there.

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: GH60 prototype betatesting
« Reply #213 on: Tue, 12 February 2013, 23:58:49 »
yes, i don't remember the phantom boards coming tinned either (but i ended up giving all of mine away so.. ;)). the reason i ask is because if the pads are tinned and i flux them first then flow, i find that i end up having to scrub the crap out of some rosin later. but, if the pads aren't tinned, i like a quick swipe of rosin before applying the iron to get the whole joint up to temp that much quicker.

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline __red__

  • Posts: 194
Re: GH60 prototype betatesting
« Reply #214 on: Wed, 13 February 2013, 08:46:40 »
<<==--  Not a fan of pre-tinning...

Offline komar007

  • Thread Starter
  • Posts: 712
  • Location: Poland
    • komar's blog
Re: GH60 prototype betatesting
« Reply #215 on: Wed, 13 February 2013, 09:16:40 »
The pads are not tinned, but they're gold-plated. That's enough for easy soldering.
GH60 rev. B w/ ali's case|Cherry G80-3000 HFU/05|IBM Model M (51G8572)
Check out the GH60 project! | How to make a keyboard

Offline __red__

  • Posts: 194
Re: Re: GH60 prototype betatesting
« Reply #216 on: Wed, 13 February 2013, 09:22:29 »
The pads are not tinned, but they're gold-plated. That's enough for easy soldering.

Enig ftw!

Offline sordna

  • Posts: 2247
Re: GH60 prototype betatesting
« Reply #217 on: Wed, 13 February 2013, 09:52:30 »
I rarely need to pre-tin stuff... except things like lousy/old visibly corroded capacitor or audio socket terminals, or multi-strand wires. PCBs are almost always fine, unless they are ancient. Unless you do SMD soldering, you don't even need flux in my experience; a good rosin-core solder will do fine by itself.
Kinesis Contoured Advantage & Advantage2 LF with Cherry MX Red switches / Extra keys mod / O-ring dampening mod / Dvorak layout. ErgoDox with buzzer and LED mod.
Also: Kinesis Advantage Classic, Kinesis Advantage2, Data911 TG3, Fingerworks Touchstream LP, IBM SSK (Buckling spring), Goldtouch GTU-0077 keyboard

Offline __red__

  • Posts: 194
Re: GH60 prototype betatesting
« Reply #218 on: Wed, 13 February 2013, 16:11:16 »
Right, but tinned PCBs are **horrible** for doing SMD.  The components fall off the pads.

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: GH60 prototype betatesting
« Reply #219 on: Thu, 14 February 2013, 00:22:25 »
gold plated? sweet!

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: GH60 prototype betatesting
« Reply #220 on: Sat, 16 February 2013, 01:27:01 »
ok, assembled but not soldered down yet with a vortex poker plate and pcb mount clears i had lying around. only note so far is that the switch fixturing pegs/holes are very tight when the switches are plated. the tolerances in cut and flatness of the plate as well as the pcb conspire to make it difficult at best to make sure all switches are flush against the pcb. a couple of holes in the plate design and board distributed evenly would make this much more straightforward scratch that, it'll just push the plate down..
« Last Edit: Sat, 16 February 2013, 01:46:16 by mkawa »

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline sordna

  • Posts: 2247
Re: GH60 prototype betatesting
« Reply #221 on: Sat, 16 February 2013, 01:57:34 »
Push the plate down, and then raise it after soldering the switches? Sounds a bit difficult... couldn't it rip out switches when you pull the plate back up?
How about simply pushing down hard on the PCB during soldering so that the pressure between the table and the PCB will cause the switch to make full contact?
Kinesis Contoured Advantage & Advantage2 LF with Cherry MX Red switches / Extra keys mod / O-ring dampening mod / Dvorak layout. ErgoDox with buzzer and LED mod.
Also: Kinesis Advantage Classic, Kinesis Advantage2, Data911 TG3, Fingerworks Touchstream LP, IBM SSK (Buckling spring), Goldtouch GTU-0077 keyboard

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: GH60 prototype betatesting
« Reply #222 on: Sun, 17 February 2013, 01:19:51 »
i actually have a pretty clean solution, but don't have the parts to implement it yet.

take a second plate (luckily, imav has tons), and use that to apply force on the switches against the PCB using the retainer holes. parts needed are: extra plate (1), M2x16 (or longer) machine screws, matching nuts and washers. tighten in a cross pattern. the switches should all lock in using this method.

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline gnubag

  • Posts: 509
  • Location: California, US
Re: GH60 prototype betatesting
« Reply #223 on: Sun, 17 February 2013, 01:34:18 »
i actually have a pretty clean solution, but don't have the parts to implement it yet.

take a second plate (luckily, imav has tons), and use that to apply force on the switches against the PCB using the retainer holes. parts needed are: extra plate (1), M2x16 (or longer) machine screws, matching nuts and washers. tighten in a cross pattern. the switches should all lock in using this method.

so the metal picture would be:

PCB-plate/switches/hold down plate
where the hold down plate would be pushing the switches into the pcb?

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: GH60 prototype betatesting
« Reply #224 on: Sun, 17 February 2013, 03:37:18 »
yep, exactly. the machine screws and nuts are used to apply pressure between the hold down plate and PCB

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: GH60 prototype betatesting
« Reply #225 on: Sun, 17 February 2013, 14:33:54 »
ok my board works ootb; thanks for loading a firmware wfd. i think i reversed the polarity on the caps LED though. i followed the polarity diagram on the bottom of the switch since the pads were all circular and didn't indicate polarity. did you follow the switch diagram in the layout kumar? if not, maybe you should make one of them square and/or add a silkscreen for the pads that are pos

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline jdcarpe

  • * Curator
  • Posts: 8854
  • Location: Odessa, TX
  • Live long, and prosper.
GH60 prototype betatesting
« Reply #226 on: Sun, 17 February 2013, 14:43:20 »
ok my board works ootb; thanks for loading a firmware wfd. i think i reversed the polarity on the caps LED though. i followed the polarity diagram on the bottom of the switch since the pads were all circular and didn't indicate polarity. did you follow the switch diagram in the layout kumar? if not, maybe you should make one of them square and/or add a silkscreen for the pads that are pos

Yeah, I had to plug the board in and touch the legs of the LED to the pads to find polarity.
KMAC :: LZ-GH :: WASD CODE :: WASD v2 :: GH60 :: Alps64 :: JD45 :: IBM Model M :: IBM 4704 "Pingmaster"

http://jd40.info :: http://jd45.info


in memoriam

"When I was a kid, I used to take things apart and never put them back together."

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: GH60 prototype betatesting
« Reply #227 on: Sun, 17 February 2013, 14:45:54 »
blech. ok imo that's a bug, but it's easy to fix with any of the above remedies, and it's not a bad idea to put indicate the polarity of all diodes on the board anyway. nothing else really stands out to me, but i literally just got it together.

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline IvanIvanovich

  • Mr. Silk Underwear
  • Posts: 8199
  • Location: USA
Re: GH60 prototype betatesting
« Reply #228 on: Sun, 17 February 2013, 15:20:49 »
A (+) is marked on the switch housing, does it not match up correctly on the pcb?

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: GH60 prototype betatesting
« Reply #229 on: Sun, 17 February 2013, 15:33:58 »
unless i flipped it last night (i was tired...) it doesn't seem to

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline komar007

  • Thread Starter
  • Posts: 712
  • Location: Poland
    • komar's blog
Re: GH60 prototype betatesting
« Reply #230 on: Mon, 18 February 2013, 09:19:45 »
Good point. I'll add polarity info to the silkscreen in the final version.
GH60 rev. B w/ ali's case|Cherry G80-3000 HFU/05|IBM Model M (51G8572)
Check out the GH60 project! | How to make a keyboard

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: GH60 prototype betatesting
« Reply #231 on: Mon, 18 February 2013, 15:24:14 »
just test-fit in a PURE case. fit looks good modulo what has already been mentioned

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline rknize

  • * Administrator
  • Posts: 1728
  • Location: Chicago
    • metaruss
Re: GH60 prototype betatesting
« Reply #232 on: Mon, 18 February 2013, 16:41:25 »
I usually set the assembly on a coaster or similar and apply pressure to the PCB with my palms as I solder the leads in an area.  I've had to do this on Filcos and other commercial boards, too.  You can't completely rely on the plate/PCB geometry to do all of the work for you.  However, being a double-sided PCB, it will probably handle a few unseated switches much better than a Leo or QFR will.
Russ

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: GH60 prototype betatesting
« Reply #233 on: Mon, 18 February 2013, 21:20:29 »
i think the unique challenge was that i was using pcb-mount switches and a plate. anyway, the board is small enough that you can just mash on it in every which way while it's viced and eventually everything will be flat enough. the second plate trick is quite nice though, particular for builders who will be making these in volume

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline IvanIvanovich

  • Mr. Silk Underwear
  • Posts: 8199
  • Location: USA
Re: GH60 prototype betatesting
« Reply #234 on: Sat, 23 February 2013, 22:19:19 »
The polarity on the caps lock LED is fine. Marking for A is + just as it is supposed to be. Nothing went amiss for me while building. All the mounting positions for my layout are fine and work correctly. The only minor gripe I have was with the caps lock position switch. The mounting pin shares a center hole. It made it more difficult to align the switch perfectly straight and I had to do some tricky stuff to keep it in place while soldering to make sure my SUPER BLACK was fully seated. I also used a locking switch for my right shift. I find it kind of sucky as you have to bottom it out hard to get it to latch and it is hard to get it to release. Oh well, it might be coming off.
As far as the rotated switches go, I had no problems with that with my Cherry keycaps and it is a non issue for me just as I suspected.
Now comes the hard part of the programming.

So... can someone explain to me like Barney style how I make the layout how I want it... I don't understand.
« Last Edit: Sat, 23 February 2013, 22:44:41 by IvanIvanovich »

Offline IvanIvanovich

  • Mr. Silk Underwear
  • Posts: 8199
  • Location: USA
Re: GH60 prototype betatesting
« Reply #235 on: Sun, 24 February 2013, 00:22:54 »
I made some progress and got this far
Code: [Select]
static const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
/*
* Poker Layer
*/
/* Layer x000: Default Layer
* ,-----------------------------------------------------------.
* |Esc|  1|  2|  3|  4|  5|  6|  7|  8|  9|  0|  -|  =|Backsp |
* |-----------------------------------------------------------|
* |Tab  |  Q|  W|  E|  R|  T|  Y|  U|  I|  O|  P|  [|  ]|    \|
* |-----------------------------------------------------------|
* |Caps  |  A|  S|  D|  F|  G|  H|  J|  K|  L|  ;|  '|Return  |
* |-----------------------------------------------------------|
* |Shift   |  Z|  X|  C|  V|  B|  N|  M|  ,|  .|  /|Shift     |
* |-----------------------------------------------------------|
* |Ctrl|Alt |      Space                 |Fn  |Gui |App |Ctrl|
* `-----------------------------------------------------------'
*/
KEYMAP_ANSI(
ESC, 1,   2,   3,   4,   5,   6,   7,   8,   9,   0,   MINS,EQL, BSPC, \
TAB, Q,   W,   E,   R,   T,   Y,   U,   I,   O,   P,   LBRC,RBRC,BSLS, \
CAPS,A,   S,   D,   F,   G,   H,   J,   K,   L,   SCLN,QUOT,     ENT,  \
LSFT,Z,   X,   C,   V,   B,   N,   M,   COMM,DOT, SLSH,          RSFT, \
LCTL,LALT,          SPC,                     FN2, RGUI,APP, RCTL),
/* Layer x001: Arrow */
KEYMAP_ANSI(
TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS, \
TRNS,TRNS,UP,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS, \
TRNS,LEFT,DOWN,RGHT,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,     TRNS, \
TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,          TRNS,   \
TRNS,TRNS,          TRNS,                    FN2,TRNS,TRNS,TRNS),
/*
* Momentary Fn Layer
*/
/* Layer x100: Default + Fn'd */
KEYMAP_ANSI(
GRV, F1,  F2,  F3,  F4,  F5,  F6,  F7,  F8,  F9,  F10, F11, F12, TRNS, \
TRNS,TRNS, UP,  TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,PSCR,PAUS,VOLU,VOLD,MUTE, \
TRNS,LEFT,DOWN,RGHT,TRNS,TRNS,TRNS,TRNS,TRNS,INS,HOME, PGUP,      TRNS, \
TRNS,TRNS, TRNS,FN0,TRNS,TRNS,TRNS,TRNS,DEL,END,PGDN,           TRNS, \
TRNS,TRNS,          TRNS,                     FN2, TRNS,TRNS,TRNS)
};

/*
 * Fn action definition
 */
static const uint16_t PROGMEM fn_actions[] = {
/* Layout */
[0] = ACTION_LAYER_BIT_TOGGLE(1),              // FN0 Arrow toggle(C)
[2] = ACTION_LAYER_BIT(4),                     // FN2 Fn
};


but when I try and generate the file I only get an error ***missing separator*** I don't understand the problem.

EDIT:  So I tracked down that problem, of some space or whatever it was that it was not expecting, but now am getting another stupid error that makes no sense to me of ***commands commence before target.
What the F*CK does it mean? I am not a programmer if that is not obvious. I need some kind of simple visual programming tool. This sh!t is pissing me off.

EDIT 2: I got a little farther maybe? Now getting ***interrupt/exception caught (code = 0xc00000fd, addr = 0x4217b3) whatever the hell that is supposed to mean. I give up for now.

EDIT 3: OK, so I lied. I kept going... lol. Got passed whatever that was... as I still have no clue but I basically just started over again. Anyway I am now getting a no rule to make target error. This is really incredibly tiresome and convoluted. Nope wait, scratch that back to ***interrupt/exception caught (code = 0xc00000fd, addr = 0x4217b3) FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU!!!

EDIT 4: So apparently it's not good to install winAVR in program files. How retarded. Ok, so anyway after reinstalling it in the root of C as it requires apparently like it's Windows 3.11 I finally got some crap to appear about compiling such and such mucky muck for it to finally error out on some rubbish about 'expected } before { token on line 109 of keymap.c. I checked line 109 and there is not those character there. I don't understand. I really am giving up for now this time for real. I just hope someone can give me some answer tomorrow on how to make this crap work.
« Last Edit: Sun, 24 February 2013, 10:19:25 by IvanIvanovich »

Offline IvanIvanovich

  • Mr. Silk Underwear
  • Posts: 8199
  • Location: USA
Re: GH60 prototype betatesting
« Reply #236 on: Sun, 24 February 2013, 09:26:35 »
So I finally got something to work sort of. The make finishes without error, and I was able to load the hex file. Testing it in aqua most of the primary layer is fine, though there are a couple keys doing something other than what I designated. When trying to use the Fn key all hell breaks loose. It start outputting random character instead of what I designated, then upon release the primary layer types garbage and then just stop responding after a few presses require to unplug the keyboard before any typing will resume. I have no idea what is going on here.

Offline hasu

  • Posts: 3350
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: GH60 prototype betatesting
« Reply #237 on: Sun, 24 February 2013, 09:53:56 »
Your FN2 does XOR current layer with 4, this take you to layer 4. But you don't have layer 4.
If you are not familiar with XOR, you can use LAYER_SET action instead. In many case you won't need LAYER_BIT action.


Code: [Select]
static const uint16_t PROGMEM fn_actions[] = {
/* Layout */
[0] = ACTION_LAYER_BIT_TOGGLE(1),              // FN0 Arrow toggle(C)
[2] = ACTION_LAYER_BIT(4),                     // FN2 Fn
};

Offline IvanIvanovich

  • Mr. Silk Underwear
  • Posts: 8199
  • Location: USA
Re: GH60 prototype betatesting
« Reply #238 on: Sun, 24 February 2013, 10:22:18 »
Thank you for responding, but I am not following that completely. I have like zero programming knowledge and was just editing your exisiting keymap_poker.h file. I understand you are saying there is an error for what I am trying to accomplish and where, but can you show me the needed change to make it do what I am looking for?
« Last Edit: Sun, 24 February 2013, 10:24:40 by IvanIvanovich »

Offline hasu

  • Posts: 3350
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: GH60 prototype betatesting
« Reply #239 on: Sun, 24 February 2013, 11:29:58 »
Im not sure what you are trying on you keymap. But try this.
If this does not work you can still wait for komar's firmware and GUI tool.

Code: [Select]
static const uint16_t PROGMEM fn_actions[] = {
/* Layout */
[0] = ACTION_LAYER_SET_TOGGLE(1),              // FN0 Arrow toggle(C)
[2] = ACTION_LAYER_SET(2),                     // FN2 Fn
};
« Last Edit: Sun, 24 February 2013, 11:31:51 by hasu »

Offline IvanIvanovich

  • Mr. Silk Underwear
  • Posts: 8199
  • Location: USA
Re: GH60 prototype betatesting
« Reply #240 on: Sun, 24 February 2013, 11:56:57 »
Ah ok I see. That is simple enough. I will give it a try when I get home from work.

Offline IvanIvanovich

  • Mr. Silk Underwear
  • Posts: 8199
  • Location: USA
Re: GH60 prototype betatesting
« Reply #241 on: Sun, 24 February 2013, 19:17:47 »
That sort of worked. The FN layer is accessible and does everything it is supposed to, but when I let go of the Fn key the Fn layer was still engaged instead of returning to the default letters on primary layer. Primary layer was fine before pressing Fn and send everything it should, but stopped working right after. Like Fn is a lock (that does not turn off once engaged) which is not what I was after.

Ok, so playing a hunch based on my way of logic, I changed it back to ACTION_LAYER_BIT but defined it as (1) and did a little tweaking to some things and now it is working perfectly with just 2 layers. So now that I have something with basic functionality I will keep going on with the other layers of cursor lock and embedded numpad one at a time. Also, just in case anyone else like my layout here is the working keymap.h

Code: [Select]
static const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
    /*
     * Poker Layer
     */
    /* Layer x000: Poker Default Layer */
    KEYMAP_ANSI(
        ESC, 1,   2,   3,   4,   5,   6,   7,   8,   9,   0,   MINS,EQL, BSPC, \
        TAB, Q,   W,   E,   R,   T,   Y,   U,   I,   O,   P,   LBRC,RBRC,BSLS, \
        CAPS,A,   S,   D,   F,   G,   H,   J,   K,   L,   SCLN,QUOT,     ENT,  \
        LSFT,Z,   X,   C,   V,   B,   N,   M,   COMM,DOT, SLSH,          RSFT, \
        LCTL,LALT,NO,          SPC,                     FN0, RGUI,APP, RCTL),
    /*
     * Poker Momentary Fn Layer
     */
    /* Layer x100: Poker Default + Fn'd */
    KEYMAP_ANSI(
GRV, F1,  F2,  F3,  F4,  F5,  F6,  F7,  F8,  F9,  F10, F11, F12, TRNS, \
TRNS,FN1, UP,  TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,PSCR,PAUS,VOLU,VOLD,MUTE, \
TRNS,LEFT,DOWN,RGHT,TRNS,TRNS,TRNS,TRNS,TRNS,INS,HOME, PGUP,      TRNS, \
TRNS,TRNS, TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,DEL,END,PGDN,           TRNS, \
TRNS,TRNS,NO,          TRNS,                     FN0, TRNS,TRNS,TRNS)
};

/*
 * Fn action definition
 */
static const uint16_t PROGMEM fn_actions[] = {
    /* Poker Layout */
    [0] = ACTION_LAYER_BIT(1),                     // FN0 Fn
};

Thanks for the tip and starting off point from your files hasu, I surely would not have gotten anywhere for quite awhile otherwise.
« Last Edit: Sun, 24 February 2013, 19:32:01 by IvanIvanovich »

Offline hasu

  • Posts: 3350
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: GH60 prototype betatesting
« Reply #242 on: Sun, 24 February 2013, 19:45:41 »
EDIT: I didn't read all of your post. OK. It seems to work now. Ignore me.

Great so far.
It looks like you FN layer doesn't have any return path to primary layer.

Did you read README already? You don't seem to do that. It is not enough but better than nothing.
You'll need to read Section '3 Layer' and '4 Layer Switching' at least.

If you read already it and became lost in your keymap it means my poor documentation and Engrish.
I want to improve it correction, suggestion or any feedback are welcome.
« Last Edit: Sun, 24 February 2013, 19:52:34 by hasu »

Offline IvanIvanovich

  • Mr. Silk Underwear
  • Posts: 8199
  • Location: USA
Re: GH60 prototype betatesting
« Reply #243 on: Sun, 24 February 2013, 19:57:27 »
I just wanted it to be on while holding only and it seems to be doing that right now so I am satisfied for the moment. I don't use the 2nd layer very much, only very seldom so I just need it to be accessible for a second while I press whatever key I need.
I tend to only skim through readme to get the gist of things then jump in head first. Just looking at the files and stuff I got most of the idea of what I was supposed to be doing there. I am more of a learn by doing and trial and error person. Though sometimes I can frustrate myself on some things that are more technical like this by doing things that way.

I found most of documentation fine, but maybe you assume that people have a higher level of knowledge in some cases. Some thing might not be simple enough or need more detailed explanation for beginner. Like for me, the most advanced thing I have done that resembles any kind of coding was for my rainmeter set up.
« Last Edit: Sun, 24 February 2013, 20:03:38 by IvanIvanovich »

Offline IvanIvanovich

  • Mr. Silk Underwear
  • Posts: 8199
  • Location: USA
Re: GH60 prototype betatesting
« Reply #244 on: Mon, 25 February 2013, 11:05:46 »
I seem to be talking to myself a lot here lol.
I have come across one issue, well one for me anyway. This keyboard does not seem to be able to wake my PCs from sleep. I also tried reflash with not my firmware and tried komar again just to see. Does anyone else have this problem?

Offline alaricljs

  • I be WOT'ing all day...
  • ** Moderator Emeritus
  • Posts: 3715
  • Location: NE US
Re: GH60 prototype betatesting
« Reply #245 on: Mon, 25 February 2013, 11:08:49 »
This is normal for Hasu's FW in my experience.  I think he put in a special key combo to intentionally wake the PC...

shift-shift-print screen.

Someone on DT sent me a link to a patch they made to get around this, but it's gone now.  All I have is the description:

Quote
I declared a new state in keyboard.c named STANDBY, added it to the state machine in process_key() and do the processing there. The only downside it has right now is that I evaluate in the same function if the keyboard is in STANDBY or not. I can imagine that this part could be in another place to be more efficient
Filco w/ Imsto thick PBT
Ducky 1087XM PCB+Plate, w/ Matias "Quiet Click" spring-swapped w/ XM Greens

Offline komar007

  • Thread Starter
  • Posts: 712
  • Location: Poland
    • komar's blog
Re: GH60 prototype betatesting
« Reply #246 on: Mon, 25 February 2013, 11:16:14 »
It's also normal for my firmware, simply because I haven't implemented it yet, but it will be available for sure.
GH60 rev. B w/ ali's case|Cherry G80-3000 HFU/05|IBM Model M (51G8572)
Check out the GH60 project! | How to make a keyboard

Offline IvanIvanovich

  • Mr. Silk Underwear
  • Posts: 8199
  • Location: USA
Re: GH60 prototype betatesting
« Reply #247 on: Mon, 25 February 2013, 11:25:08 »
I'm used to be able to press any key at all on any other keyboard to wake the pc don't need a special key, and I have it disable on my mouse to wake the pc because it would wake it randomly.

Offline jdcarpe

  • * Curator
  • Posts: 8854
  • Location: Odessa, TX
  • Live long, and prosper.
Re: GH60 prototype betatesting
« Reply #248 on: Mon, 25 February 2013, 11:32:40 »
I'm used to be able to press any key at all on any other keyboard to wake the pc don't need a special key, and I have it disable on my mouse to wake the pc because it would wake it randomly.

My Rosewill won't wake my Dell PC at work (several years old) when connected by USB. No matter what keys you press, nothing happens. I have to keep a PS/2 keyboard connected to wake it, or disable sleep mode on that PC.
KMAC :: LZ-GH :: WASD CODE :: WASD v2 :: GH60 :: Alps64 :: JD45 :: IBM Model M :: IBM 4704 "Pingmaster"

http://jd40.info :: http://jd45.info


in memoriam

"When I was a kid, I used to take things apart and never put them back together."

Offline IvanIvanovich

  • Mr. Silk Underwear
  • Posts: 8199
  • Location: USA
Re: GH60 prototype betatesting
« Reply #249 on: Mon, 25 February 2013, 12:24:24 »
That is fine, but any other keyboard I own will wake my EVGA P55 and my Zotac H67. So it not a question of my PCs not support wake on usb.