Author Topic: [TMK] Alternative Controller for HHKB  (Read 515285 times)

0 Members and 1 Guest are viewing this topic.

woody

  •  Guest
Alternative Controller for HHKB
« Reply #50 on: Thu, 02 December 2010, 06:02:28 »
Quote from: Soarer;255306
It wouldn't bother the PC side, but on the Teensy it would be more effort, and probably not worth it. But it's certainly possible.

AVR is more than fast enough, just some level of indirection through tables.
The unknown hell of high-level abstraction in the PC HID drivers is what would bother me, so I'd keep the report in a single array.

Quote
Windows scans devices but does NOT issue a SetProtocol command. IIRC this has been given before as an answer to why more than 6KRO is not possible under Windows (without tricks). But, I thought, what if Windows expects the device to initialize to the correct protocol? I'm still not sure exactly when that initialization should happen, so I reset the protocol to NKRO when the host is starting to read the descriptors.

You are supposed to enter boot mode only when SetProtocol is issued. After reset/re-enumeration, you must be back to default (long-report) mode. It doesn't matter if the BIOS set boot mode, once OS loads up it will power cycle the USB ports and re-enumerate devices.

Quote
The BIOS ignores the descriptors it reads, and simply expects to get standard boot mode reports (modifiers + 6 keys). So in the code, there is no descriptor defined that matches boot mode (it sends the NKRO one).

Correct. Boot mode is just a kludge.

Quote
Along the way, I discovered that my BIOS doesn't seem to mind if it gets a larger report, as long as it begins with the standard 8 bytes. I don't know if that could be relied on across all machines.

No, keep it 8 bytes.

Offline Soarer

  • * Moderator
  • Posts: 1918
  • Location: UK
Alternative Controller for HHKB
« Reply #51 on: Thu, 02 December 2010, 07:08:30 »
Quote from: woody;255476
AVR is more than fast enough, just some level of indirection through tables.
The unknown hell of high-level abstraction in the PC HID drivers is what would bother me, so I'd keep the report in a single array.
I meant effort to code, and I'm lazy ;-)
I don't think a shorter 16 byte report would really give any advantage, apart from the satisfaction of being slightly more efficient. For my purpose (a PS/2 to USB adapter) it would also mean I'd have to decide which codes to leave out.

Quote from: woody;255476
You are supposed to enter boot mode only when SetProtocol is issued. After reset/re-enumeration, you must be back to default (long-report) mode. It doesn't matter if the BIOS set boot mode, once OS loads up it will power cycle the USB ports and re-enumerate devices.
Yeah, that's what I found out. I think I should move the 'reset' to where it handles SetConfiguration. The Microsoft tests demand being able to handle SetProtocol to go into full report mode (TD-9.27.3.3), but I've never seen it happen.

Quote from: woody;255476
No, keep it 8 bytes.
Oh, I will. No point in doing otherwise. But I found it curious, because it would mean that a device using the standard report layout, but extended with more keys, would work ok in the bios. Just another reason to ask 'why hasn't someone done this before'?

So why haven't they? Is there a nasty 'gotcha' lurking somewhere that we haven't spotted yet?
« Last Edit: Thu, 02 December 2010, 07:59:27 by Soarer »

woody

  •  Guest
Alternative Controller for HHKB
« Reply #52 on: Thu, 02 December 2010, 07:55:13 »
On the last question - don't really know. Nevermind, though. I think that the original HID intent of having flexible descriptors and the boot mode is enough. How they ended up with most implementations being 6KRO is beyond me.

You and hasu provided great deal of useful information and beat the lazy me. Cheers.

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Alternative Controller for HHKB
« Reply #53 on: Thu, 02 December 2010, 09:23:43 »
I did quick test soarer's method on Ubuntu 10.04, and have no problem !!
But I used 16byte report  rather than 32byte.

My HHKB is USB NKRO on Windows and Linux now :)

This is the descriptor.
Code: [Select]

        0x95, 0x70,          //   Report Count (112),
        0x75, 0x01,          //   Report Size (1),
        0x15, 0x00,          //   Logical Minimum (0),
        0x25, 0x01,          //   Logical Maximum(1),
        0x05, 0x07,          //   Usage Page (Key Codes),
        0x19, 0x00,          //   Usage Minimum (0),
        0x29, 0x73,          //   Usage Maximum (111),
        0x81, 0x02,          //   Input (Data, Variable, Absolute),

Offline Soarer

  • * Moderator
  • Posts: 1918
  • Location: UK
Alternative Controller for HHKB
« Reply #54 on: Thu, 02 December 2010, 09:28:23 »
What is the constraint on report lengths?
I thought it was powers of two, and that's all that seems to work (32=ok, 30=ng, 24=ng, 16=ok). But I just saw a reference in the docs to a 10 byte HID report... confusing!

woody

  •  Guest
Alternative Controller for HHKB
« Reply #55 on: Thu, 02 December 2010, 10:00:51 »
Just from what I've read - none. Padding problems?

Offline Soarer

  • * Moderator
  • Posts: 1918
  • Location: UK
Alternative Controller for HHKB
« Reply #56 on: Thu, 02 December 2010, 10:11:40 »
I don't think it's that - I wrote some macros to work out how much padding to add to make it up to whole bytes, and they seem to work fine. And I just tried a more hard-coded test of 24 bytes, which also failed.
It's not really important, but as you say, from the docs you'd think there was no restriction other than being whole bytes.

woody

  •  Guest
Alternative Controller for HHKB
« Reply #57 on: Thu, 02 December 2010, 14:13:09 »
Could it be endpoint buffer size and packet signalling?

Offline JBert

  • Posts: 764
Alternative Controller for HHKB
« Reply #58 on: Thu, 02 December 2010, 15:04:10 »
Quote from: Soarer;255494
Oh, I will. No point in doing otherwise. But I found it curious, because it would mean that a device using the standard report layout, but extended with more keys, would work ok in the bios. Just another reason to ask 'why hasn't someone done this before'?

So why haven't they? Is there a nasty 'gotcha' lurking somewhere that we haven't spotted yet?
The answer is easier than it sounds: it takes too much code to run an entire USB HID stack.

So what they do is send a SetProtocol command and then read the raw keyboard data: (written in pseudo-C++ for convenience)
Code: [Select]
unsigned char kbdData[12];
cin >> kbdData;
char key1 = kbdData[4];
char key2 = kbdData[5];
etc...
char key6 = kbdData[11]
Because the boot mode is very strict, they can make assumptions of where the scancodes are and ignore everything else.
IBM Model F XT + Soarer's USB Converter || Cherry G80-3000/Clears

The storage list:
IBM Model F AT || Cherry G80-3000/Blues || Compaq MX11800 (Cherry brown, bizarre layout) || IBM KB-8923 (model M-style RD) || G81-3010 Hxx || BTC 5100C || G81-3000 Sxx || Atari keyboard (?)


Currently ignored by: nobody?

Disclaimer: we don\'t help you save money on [strike]keyboards[/strike] hardware, rather we make you feel less bad about your expense.
[/SIZE]

Offline Soarer

  • * Moderator
  • Posts: 1918
  • Location: UK
Alternative Controller for HHKB
« Reply #59 on: Thu, 02 December 2010, 15:14:44 »
Quote from: woody;255795
Could it be endpoint buffer size and packet signalling?


Ah-ha, that's it, thanks! The PJRC code used the same #define for both configuration of the endpoint in the USB hardware and the max packet size in the endpoint descriptor. The hardware expects a power of two as the endpoint size, but the max packet size can be less than that.

So... we could transmit all valid USB HID key codes in 23 bytes :-)

Offline Soarer

  • * Moderator
  • Posts: 1918
  • Location: UK
Alternative Controller for HHKB
« Reply #60 on: Thu, 02 December 2010, 15:29:16 »
Quote from: JBert;255847
The answer is easier than it sounds: it takes too much code to run an entire USB HID stack.

So what they do is send a SetProtocol command and then read the raw keyboard data: (written in pseudo-C++ for convenience)
Code: [Select]
unsigned char kbdData[12];
cin >> kbdData;
char key1 = kbdData[4];
char key2 = kbdData[5];
etc...
char key6 = kbdData[11]
Because the boot mode is very strict, they can make assumptions of where the scancodes are and ignore everything else.

Oh, I understand boot mode :) Sorry, what I said before wasn't clear... when I said 'why hasn't someone done this before'?, the 'this' meant switching to a better mode when an OS starts, since it has a full HID stack.

edit: The quirk that my BIOS doesn't mind longer reports, as long as the first 8 bytes match a boot mode report, if universal, would've made it easy for keyboards to support more than 6KRO - they wouldn't even need to switch.

So far, all I know is that switching works on my PC, the 'gotcha' could be that it doesn't work on other PCs.
« Last Edit: Thu, 02 December 2010, 15:32:23 by Soarer »

woody

  •  Guest
Alternative Controller for HHKB
« Reply #61 on: Fri, 03 December 2010, 06:23:25 »
Good news, Soarer. So W7 and XP work. I saw that hasu verified Linux, too. We can safely expect that OSX is on par.

USB NKRO proved to be as expected.

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Alternative Controller for HHKB
« Reply #62 on: Fri, 03 December 2010, 08:08:25 »
I have a bad news.
Windows 2000 failed to handle my 16byte report. :<

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Alternative Controller for HHKB
« Reply #63 on: Fri, 03 December 2010, 09:53:47 »
It seem that my code was insufficient.

Windows 2000 could handle the report in second try.


Quote from: hasu;256242
I have a bad news.
Windows 2000 failed to handle my 16byte report. :<

woody

  •  Guest
Alternative Controller for HHKB
« Reply #64 on: Fri, 03 December 2010, 09:54:56 »
Was it bit array like Soarer did?

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Alternative Controller for HHKB
« Reply #65 on: Fri, 03 December 2010, 09:58:15 »
yes, it was.

Offline v193r

  • Posts: 73
Alternative Controller for HHKB
« Reply #66 on: Thu, 13 January 2011, 20:19:45 »
Quote from: Laser Freud;247946
Thanks for posting, this is very helpful information. I have the HHKB pro 2 and I want to keep the USB hub intact, so instead of replacing the controller completely I'm going to program an AVR to just translate the address bits on 6-11 to the remapped keys.


anyone know how this is possible to do? or a tutorial prehaps? id like change my layout from qwerty to colemak natively thru the kb(hhkb2) without replacing the controller.

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Alternative Controller for HHKB
« Reply #67 on: Thu, 13 January 2011, 23:12:31 »
Quote from: v193r;278250
anyone know how this is possible to do? or a tutorial prehaps? id like change my layout from qwerty to colemak natively thru the kb(hhkb2) without replacing the controller.


What he said is technically possible with additional hardware, but I think replacing the controller is easier way.



Quote from: ripster;278269
My Realforce 87U has DIP Switch setting 4 for firmware upgrade.  Don't think the HHKB has that.


You're right. HHKB's controller is not programmable.
Unfortunately 87U's MCU Fujitsu MB90F377 is not taste of geeks/hackers :)
I think GCC has no support for this MCU.
« Last Edit: Thu, 13 January 2011, 23:14:37 by hasu »

Offline raeb

  • Posts: 15
Alternative Controller for HHKB
« Reply #68 on: Thu, 20 January 2011, 14:38:31 »
Awesome work.

I've been toying with the idea of a teensy controller, but I'm quite unexperienced with this stuff.  Any good documentation recommendations on where I could start?

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Alternative Controller for HHKB
« Reply #69 on: Thu, 20 January 2011, 23:14:50 »
Quote from: raeb;281822
Awesome work.

I've been toying with the idea of a teensy controller, but I'm quite unexperienced with this stuff.  Any good documentation recommendations on where I could start?


I think PJRC's USB keyboard example code is a good start point.
It was a start point of my firmware too.

Then you can consult existent keyboard firmware projects.
You can use google to get a documentation on each topic,
but I think no comprehensive documentation exist.


Following is list of keyboard firmware projects for AVR:
PJRC USB Keyboard/Mouse Example
    http://www.pjrc.com/teensy/usb_keyboard.html
    http://www.pjrc.com/teensy/usb_mouse.html
kbupgrade
    http://github.com/rhomann/kbupgrade
    http://geekhack.org/showwiki.php?title=Island:8406
c64key
    http://symlink.dk/projects/c64key/
rump
    http://mg8.org/rump/
    http://github.com/clee/rump
dulcimer
    http://www.schatenseite.de/dulcimer.html
humblehacker-keyboard
    http://github.com/humblehacker
    http://www.humblehacker.com/keyboard/
    http://geekhack.org/showwiki.php?title=Island:6292
ps2avr
    http://sourceforge.net/projects/ps2avr/

Offline v193r

  • Posts: 73
Alternative Controller for HHKB
« Reply #70 on: Tue, 01 February 2011, 01:51:30 »
any word on when this will work on the hhkbp2? i want native colemak and maybe usb nkro.

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Alternative Controller for HHKB
« Reply #71 on: Tue, 01 February 2011, 02:58:41 »
This picture from rdjack21's post will be very helpful for you.

Pro2 uses 2 lines each for 5V and GND, 9 lines for signals. It seems to be almost same as Pro.
I think you can use same method for Pro2 though you should trace PCB patterns for accuracy.


Offline Mazora

  • Posts: 252
Alternative Controller for HHKB
« Reply #72 on: Tue, 12 July 2011, 10:19:35 »
hasu: what are mouse keys and what are they used for ? I guess you don't always have access to a mouse in your work environment?
HHKB Pro 2: black case white keys
Filco Masjestouch v2 / MX-Reds / hard lending pads /Dye-sub keycaps
RF-87UW

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Alternative Controller for HHKB
« Reply #73 on: Tue, 12 July 2011, 11:07:49 »
Mouse keys is a virtual pointing device implemented on my keyboard firmware, OS see it as a real mouse device so any special settings are not needed.
Mouse keys is enough for most my daily work, but complicated GUI job like CAD, Photoshop and Eclipse need a real mouse.

FYI: Xorg, OS X and Windows also have a mouse key function.
http://en.wikipedia.org/wiki/Mouse_keys

Offline jackerran

  • Posts: 2
Alternative Controller for HHKB
« Reply #74 on: Mon, 19 September 2011, 07:32:01 »
I followed the advice given by hasu and traced the pcb for the pro2  I could verify that the LS145 pin positions were correct and the HC4051's C pin was in the correct position. HC4051's A and B appeared to be right but I could not verify. And I could the 2 tracers going to the TP1684, but could not tell their position. It looked good enough for me so I compiled the software and hooked up the teesnie++. The keys seemed to work fine and so did the various modes. I used the following diagram to hook up my HHKB pro2 to the teensie++.
Code: [Select]


Keyswitch PCB connector                                 Teensy++ pins
    -------------------------------------------------------------------------------
     1  Vcc(5V)                                             5V
     2  Vcc(5V)
     3  TP1684    KEY: Low(0) when key pressed              PE6 input(pulluped)
     4  TP1684    KEY_PREV: assert previous key state???    PE7 output
     5  HC4051    A(bit0) select 8 rows(0 to 7)             PB0 output
     6  HC4051    B(bit1)                                   PB1 output
     7  HC4051    C(bit2)                                   PB2 output
     8  LS145     A(bit0) select 8 columns(0 to 7)          PB3 output
     9  LS145     B(bit1)                                   PB4 output
    10  LS145     C(bit2)                                   PB5 output
    11  LS145     D(enable) Low(0) enable selected column   PB6 output
    12  GND
    13  GND                                                 GND


I have not mounted and installed the chip yet, but as soon as I get all the parts needed to mount and install it, I will.

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Alternative Controller for HHKB
« Reply #75 on: Mon, 19 September 2011, 08:17:15 »
Nice work! Thank you, jackerran.

This must be helpful to pro2 owners who want to mod.
I will added it on the article some time soon.

Offline Dox

  • Posts: 312
Alternative Controller for HHKB
« Reply #76 on: Mon, 19 September 2011, 16:20:11 »
Thanks to jackerran and hasu! looks like  it's time to order a teensy++ for my pro2!
ErgoDox x2 | DoxKB x2 |   IBM SSK   | HHKB pro2

Offline hemflit

  • Posts: 84
Alternative Controller for HHKB
« Reply #77 on: Sat, 05 November 2011, 01:22:23 »
Woooo it's working it's working I'm typing this from my PROGRAMMABLE HHKB :)
Muahaha, the sky is the limit now. Now I can take a year off to come up with my own fn-layers. :)

Hasu, you're a genius! Thank you so much for this!

Hey Dox, thanks for nudging me in some other thread to finally do this.

BTW I'm running it on Teensy 2.0 (tweaked a line or two) and it seems it will fit almost perfectly in the space around the mini-USB hole in the case. (That's plain HH Pro, not Pro 2.) I'll just need to sand down like 0.1mm of plastic and it's snug.
[ Attachment Invalid Or Does Not Exist ] 30899[/ATTACH]

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Alternative Controller for HHKB
« Reply #78 on: Wed, 09 November 2011, 03:49:37 »
Good to hear that!
And mmm, nice setup of Teensy.
Thanks, hemflit.

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Alternative Controller for HHKB
« Reply #79 on: Tue, 18 June 2013, 19:47:35 »
I got warning  that this topc is old from system when I posted this :)  No post for 2 years!

This has been heart of my daily driver keyboard and worked well for me in two years. My TMK firmware has developed and evolved mainly on this contoller, this mod is still my main project,  NOT DEAD.

I desigend prototype of controller PCB for Pro2 which is in prouction somewhere in China.
« Last Edit: Tue, 18 June 2013, 19:52:23 by hasu »

Offline alaricljs

  • I be WOT'ing all day...
  • ** Moderator Emeritus
  • Posts: 3715
  • Location: NE US
Re: Alternative Controller for HHKB
« Reply #80 on: Tue, 18 June 2013, 19:58:41 »
The topic was certainly growing dust bunnies... the project certainly not :)

Don't know too many people willing to crack open their HHKB and go at it with an iron though.
Filco w/ Imsto thick PBT
Ducky 1087XM PCB+Plate, w/ Matias "Quiet Click" spring-swapped w/ XM Greens

Offline Aranair

  • Posts: 215
  • Location: Singapore
  • Software Engineer @ PocketMath
    • Tech blog
Re: Alternative Controller for HHKB
« Reply #81 on: Tue, 18 June 2013, 20:01:38 »
If its confirmed to be free of any problems.. I might lol:0

Present  : HHKB Pro 2 Type-S White | HHKB Pro 2 White Blank | Ergodox EZ
Past      :  Poker 2 Brown | Black Widow Ultimate Blue | Filco TKL Brown

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Alternative Controller for HHKB
« Reply #82 on: Tue, 02 July 2013, 13:56:32 »
Got it today. Now my spare pro2 got new controller.

Offline WhiteFireDragon

  • Posts: 2276
    • youtube
Re: Alternative Controller for HHKB
« Reply #83 on: Tue, 02 July 2013, 14:12:52 »
AND? Does it work ok?

Offline Wraul

  • Posts: 211
  • Location: Sweden
Re: Alternative Controller for HHKB
« Reply #84 on: Tue, 02 July 2013, 14:34:07 »
Got it today. Now my spare pro2 got new controller.
Show Image


Wow, nice.
Will I be able to get my hands on one of those?
There are a few things keeping me from buying a HHKB. Having a programmable controller would change that.

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Alternative Controller for HHKB
« Reply #85 on: Tue, 02 July 2013, 18:30:58 »
It works well after tweaking code a bit. It is full functional as USB keyboard now, all parts needed for this  are installeed in picture. Right part of PCB is optional for wireless option which is in development.

Yes, I have a plan to part with some of spare PCBs and parts. After some short testing I'll be able to offer some completed controllers or DIY kits. At this time wireless option will not be available.
And PCB and schematic data will also be available some after.

Offline esoomenona

  • Gnillort?
  • Posts: 5323
Re: Alternative Controller for HHKB
« Reply #86 on: Tue, 02 July 2013, 20:22:21 »
Do you think it might be possible to make one that allows the two USB ports to work with things like flash drives? Possibly wirelessly, if you ever get that going?

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Alternative Controller for HHKB
« Reply #87 on: Tue, 02 July 2013, 21:29:48 »
It is possible with wired USB connection of course. If USB hub function is installed no firmware support is needed.

But in case of wireless it is impossible realistically with my firmware, i think. You may need more powerful and resource rich platform like Raspberry Pi.

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Alternative Controller for HHKB
« Reply #88 on: Mon, 08 July 2013, 23:22:48 »
Seems like it has worked well so far.

- With this controller HHKB get programable while losing its USB Hub function as you can see.
- You can install the controller PCB very easily with just screw drivers.
- Components on right half part of PCB are not implemented it is for protyping purpose only and I don't know whether this part works or not atm.

Wraul, if you are still interested in getting this PM me.

Offline Wraul

  • Posts: 211
  • Location: Sweden
Re: Alternative Controller for HHKB
« Reply #89 on: Tue, 09 July 2013, 01:18:12 »
Seems like it has worked well so far.

- With this controller HHKB get programable while losing its USB Hub function as you can see.
- You can install the controller PCB very easily with just screw drivers.
- Components on right half part of PCB are not implemented it is for protyping purpose only and I don't know whether this part works or not atm.

Wraul, if you are still interested in getting this PM me.

Great to hear that it is working.
Very inspiring work.

Yes I'm still interested in getting one.
I'll send you a PM.

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Alternative Controller for HHKB
« Reply #90 on: Thu, 11 July 2013, 06:38:30 »
My KiCad project of the controller PCB has repository on github now. I'm happy to share this with the community.
https://github.com/tmk/HHKB_controller

DISCLOSURE: This is my second PCB project, far from professional job. However, it still works!


Offline esoomenona

  • Gnillort?
  • Posts: 5323
Re: Alternative Controller for HHKB
« Reply #91 on: Sat, 20 July 2013, 13:58:51 »
Great work though! I look forward to the day when we can possibly make a HHKB controller with wireless/BT capability and a USB hub that does something. And I'm sure it will all stem from the great job you've put out so far here.

Offline nathankot

  • Posts: 1
Re: Alternative Controller for HHKB
« Reply #92 on: Sun, 08 September 2013, 04:10:17 »
I ordered one of hasu's tmk board replacements for the hhkb pro 2 and it is amazing! Fast response + delivery, everything just fits together perfectly, highly recommended if you don't want to risk damaging your board like me.

Being able to mod your own keyboard is like programming heaven, check out my blog post about this:  http://nathankot.com/blog/2013/09/05/modding-the-happy-hacking-keyboard/

Still tweaking my keymap but I couldn't be happier!!! Thanks hasu :)

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Alternative Controller for HHKB
« Reply #93 on: Mon, 09 September 2013, 07:11:41 »
nathankot, Great writeup!

Fn key on 'F' in you Vim layer is a great example of use of Dual-role key.
Fn key on home row key is extreme! :D haha

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Keymap Editor
« Reply #94 on: Mon, 09 September 2013, 11:24:33 »
I was working on this web based keymap editor recently. Now it can do the job somewhat.


This editor is a fully client side javascript web applicaton without using web app server, it works enven without network connection.  You can download hex file after editing your keymap, just need to program it without compile process.

You can try this at: http://tmk.github.io/tmk_keyboard/editor/hhkb/


This is greatly inspired by Yuri Khan's great work of TECK layout configurator and stole its ideas about share URL and hex download.
https://github.com/yurivkhan/teck/
http://yurivkhan.github.io/teck/

Offline MarioRicalde

  • Posts: 2
Re: Alternative Controller for HHKB
« Reply #95 on: Mon, 09 September 2013, 14:05:54 »
That's so nice Hasu! I'm going to be testing it soon.

Any kind of UI will help many users of this mod.

Thanks for the hard work.

Offline mikelanding

  • Posts: 84
  • Location: Thailand
Re: Keymap Editor
« Reply #96 on: Tue, 10 September 2013, 05:06:26 »
I was working on this web based keymap editor recently. Now it can do the job somewhat.
Show Image


This editor is a fully client side javascript web applicaton without using web app server, it works enven without network connection.  You can download hex file after editing your keymap, just need to program it without compile process.

You can try this at: http://tmk.github.io/tmk_keyboard/editor/hhkb/


This is greatly inspired by Yuri Khan's great work of TECK layout configurator and stole its ideas about share URL and hex download.
https://github.com/yurivkhan/teck/
http://yurivkhan.github.io/teck/
Wow. This is awesome stuff. Are you able to do it for Ergodox user base on cub-uanic's tmk firmware for Ergodox?
HHKB Type-S | Kinesis Advantage | Maltron 3D 2Hand | Ergodox (62g ErgoClear)

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Alternative Controller for HHKB
« Reply #97 on: Mon, 16 September 2013, 21:22:48 »
I posted this 'cause some people asked me by PM if spare controller boards remain on my hand for last weeks. Thanks for your interest!

All spare boards already had gone now. But I have a plan of next production of PCB. It will cost $20-30 for the completed board excluding shipping. (Shipping to US are estimated about $12 for EMS or $6 for Registered Air Mail.)

Plz watch this thread if you are interested. And your ideas or suggestions on next revision of PCB are welcomed.


FYI, Revision A looks like this.
http://geekhack.org/index.php?topic=12047.msg948923#msg948923

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Alternative Controller for HHKB
« Reply #98 on: Mon, 16 September 2013, 21:30:25 »
Wow. This is awesome stuff. Are you able to do it for Ergodox user base on cub-uanic's tmk firmware for Ergodox?

Yes, it is completely possible to port this to any tmk projects including Ergodox.

I described some on how the keymap editor works in this post. I can help someone with interest in job for this port.
http://geekhack.org/index.php?topic=48106.msg1044581#msg1044581

Offline hasu

  • Thread Starter
  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Rev.B PCB
« Reply #99 on: Mon, 02 December 2013, 22:03:51 »
I'll start to design Rev.B PCB before long. Before start the work I'd try to ask some.

1) Rev.A users, do you have any flaw or thought on the board?
If you have requeset, complain, suggestion or anything, post it here(or PM me if it needs). Feedback from real users is very important and helps me a lot.

2) Other suggestion or idea on this?
Are there missing or wanting features?
(But... Don't say about USB hub and DIP switch :) I don't need them!)
Or recommended compornent supplier PCB manufacturer or other production service?

3) Any advices on circuit or PCB work?
I'm not an expert of electronics at all. No doubt I did and will make many mistakes. I need advices.


Why Rev.B?
Rev.A works well with HHKB pro2 and Type-S as a wired USB controller. The reason why I set to Rev.B is to add wireless option with Bluetooth. Rev.B still works as USB controller and also can  connect with wireless if you install BT module and other parts on it. In my plan you can switch between USB and Buletooth, and Li-po battery are charged with USB.

Wired controller part of Rev.A has no apparent flaws so I wont change its design except for some parts are removed or replaced, while its wireless portion has some flaws to be fixed. In Rev.B I'll use new module Roving RN-42 and add FET switching circuit for power control between USB and battery.


Rev.A
KiCAD project:
https://github.com/tmk/HHKB_controller/tree/revA
PCB image:
http://i.imgur.com/NHAavrm.jpg
Schematic:
* HHKB_controller.pdf (134.27 kB - downloaded 1589 times.)