GH60 rev. B betatesting!

[komar007]

Hi,
most of the testers have already received the GH60 rev. B. The faster we test everything, the earlier we'll produce the final boards.
Let's not hurry too much though, we need well-tested boards.
There are a couple of things that have to be tested: compatibility with various layouts (ISO, ANSI, HHKB, etc), compatibility with extension modules, etc.
We also need to make sure that it's possible to implement full backlighting with the extension module and that the board fits various cases.
I've already tested alixinhzai's case and it fits nearly ok. It was necessary to scrape a thin layer of the USB receptacle's cutout to fit the acrylic plates, but other than that, it's okay.
I'd be very interested in getting a report about how the USB looks in various cases - whether it's centered or shifted.


Here's the current firmware, version 0.2, for rev. B only:  ukbdc_gh60_revB-0.2.hex (21.28 kB - downloaded 451 times.)
Here's the development version of firmware, version 0.3-dev, for rev. B:  ukbdc_gh60_revB-0.3-dev.hex (21.28 kB - downloaded 727 times.)
Slightly modified gui:
* removed sha1 check for firmware generation (overwrite base_firmware.hex with any other firmware version you want to generate layout-ful firmware)
* added all possible extra keys to gh60.xml
Download:  ukbdc_gui_b.tar.gz (35.15 kB - downloaded 697 times.)
Windows users might need to copy the usb directory from the previous version for w7.

Remember about programming the layout after flashing. The firmware comes with no layout.


For those who want to use 0.3 firmware on rev. A, here it is:  ukbdc_gh60-0.3-dev.hex (21.28 kB - downloaded 525 times.)

[MKULTRA]

Hi,
most of the testers have already received the GH60 rev. B. The faster we test everything, the earlier we'll produce the final boards.
Let's not hurry too much though, we need well-tested boards.
There are a couple of things that have to be tested: compatibility with various layouts (ISO, ANSI, HHKB, etc), compatibility with extension modules, etc.
We also need to make sure that it's possible to implement full backlighting with the extension module and that the board fits various cases.
I've already tested alixinhzai's case and it fits nearly ok. It was necessary to scrape a thin layer of the USB receptacle's cutout to fit the acrylic plates, but other than that, it's okay.
I'd be very interested in getting a report about how the USB looks in various cases - whether it's centered or shifted.


Here's the current firmware, version 0.2, for rev. B only: (Attachment Link)
The layout or GUI have not changed. Remember about programming the layout after flashing. The firmware comes with no layout.

When you get the chance can you post the mod you made to ali's case, I have that case 

[jdcarpe]

Using Linux (Ubuntu) I was able to successfully flash the version 0.2 firmware onto the 32U4. Now I just need to compile and flash a working layout onto it. Oh yeah, and assemble the board with switches, case, etc.

[The_Beast]

I got my GH60 soldered up in a poker layout. However, the 8 column seemed not to work. I did try loading different firmware on it a couple of time, and nothing seemed to work.

[komar007]

I got my GH60 soldered up in a poker layout. However, the 8 column seemed not to work. I did try loading different firmware on it a couple of time, and nothing seemed to work.

Which keys didn't work?

[The_Beast]

I got my GH60 soldered up in a poker layout. However, the 8 column seemed not to work. I did try loading different firmware on it a couple of time, and nothing seemed to work.

Which keys didn't work?

If I remember correctly, it was 8, u, j, n

I'll double check when I get home.

[komar007]

I got my GH60 soldered up in a poker layout. However, the 8 column seemed not to work. I did try loading different firmware on it a couple of time, and nothing seemed to work.

Which keys didn't work?

If I remember correctly, it was 8, u, j, n

I'll double check when I get home.

Did you use the firmware from this topic?
It looks like you used the rev. A firmware!
The keys that didn't work should've been 8, i, k, m.
If it was different keys, there's something wrong with your board:/

[The_Beast]

I got my GH60 soldered up in a poker layout. However, the 8 column seemed not to work. I did try loading different firmware on it a couple of time, and nothing seemed to work.

Which keys didn't work?

If I remember correctly, it was 8, u, j, n

I'll double check when I get home.

Did you use the firmware from this topic?
It looks like you used the rev. A firmware!
The keys that didn't work should've been 8, i, k, m.
If it was different keys, there's something wrong with your board:/

I'm using the TMK firmware since that's also what I'm using on my Rev. A

I'll double check on the non working keys when I get home!

[jdcarpe]

You are using the "new" TMK firmware, right? I think hasu updated it for Rev B support.

[The_Beast]

You are using the "new" TMK firmware, right? I think hasu updated it for Rev B support.

I'll try that out, but as of right now, this is my Rev B:

[komar007]

When you get the chance can you post the mod you made to ali's case, I have that case 

I scraped about 0.5mm of this plastic edge:

Using Linux (Ubuntu) I was able to successfully flash the version 0.2 firmware onto the 32U4. Now I just need to compile and flash a working layout onto it. Oh yeah, and assemble the board with switches, case, etc.

Great! I'm glad it worked;)

[MKULTRA]

When you get the chance can you post the mod you made to ali's case, I have that case 

I scraped about 0.5mm of this plastic edge:
(Attachment Link)

Thanks komar!

[hasu]

You are using the "new" TMK firmware, right? I think hasu updated it for Rev B support.

I'll try that out, but as of right now, this is my Rev B:

Show Image

tmk_keyboard doesn't support Rev B yet at this time. When I get production version of GH60 I'll fix to support all of Rev A, B and final version with one firmware binary.
https://github.com/tmk/tmk_keyboard/issues/64

[TheSoulhunter]

Out of curiosity, does the GH60 use normal pads or trough hole inserts (VIAs and the like)?

[jdcarpe]

Got my GH60 Rev B assembled and flashed with firmware. Unfortunately, I can't figure out how to create a layout for my configuration, using the GUI. I can't get Flip to recognize the keyboard, but I can successfully flash the firmware using linux and dfu-programmer. I just flashed the standard "komar layout" firmware to it, but it's still on the Rev A firmware I believe, because that column doesn't work for me. I'm using HHKB layout with 7-unit spacebar.




I can dig into the TMK firmware and figure that out, but it's going to take some time.

[komar007]

Looks great!
Did you use the firmware from the top of this thread? It should work fine with my layout (as for the column).
As for split backspace, I've yet to add support to the firmware...

[jdcarpe]

Looks great!
Did you use the firmware from the top of this thread? It should work fine with my layout (as for the column).
As for split backspace, I've yet to add support to the firmware...

* jdcarpe is frustrated.

The GUI works under Win7, but it apparently it won't recognize the GH60 to program it. I don't know how to make it output a .hex only.

I can't get the GUI to run under Linux, even after installing python-tk. It says it's missing module _tkinter. So although I was able to flash with the firmware at the top of the thread, there is no layout in it, and I can't program one.

Also, looks like I will need to reflow the diode or something for the "-" key. It's not working.

[komar007]

Working on an update for the gui...
As for tkinter, you need python3-tk

[metalliqaz]

Could always give mine a shot *wink wink*

[jdcarpe]

As for tkinter, you need python3-tk

Okay, that works.

Could always give mine a shot *wink wink*

Next on my list after I get this working.

[komar007]

Okay, I updated the OP with an early development version of 0.3 firmware (with split backspace support) and a new gui.
This gui has all the extra buttons, so there's no need to edit gh60.xml anymore, unless you want to remove the keys you don't use and make it look neater.
The gui includes a new layout gh60b.lay. This layout and all layouts created with the gui are not compatible with 0.2 firmware, but they will work on rev. A, provided that the keyboard is updated to 0.3 firmware. I'll upload 0.3 for rev. A in a while. Done
Unfortunately, layouts created with the old gui will not work in the new one. If you have an old layout file, please send it to me and I'll fix it for the new gui.

[jdcarpe]

+ Flashed the new base firmware in Lunix using dfu-programmer.
+ Installed the new GUI in Linux/Ubuntu. Had to copy the USB directory from the previous version for it to work.
+ New layout file is brilliant. Used it with the GUI to output a new .hex file with my HHKB layout.

- Could not get the GUI to program the GH60 in bootloader mode. "No device present." Used dfu-programmer to flash .hex to keyboard.
- Still need to debug issue with "-" key, and intermittent issue with APP key. I installed used switches (Clears), so the problem may be with the switches I used, or maybe I need to reflow those diodes, etc.

?? What scancode can I use for numpad_plus, numpad_minus, etc.?

[komar007]

+ Flashed the new base firmware in Lunix using dfu-programmer.
+ Installed the new GUI in Linux/Ubuntu. Had to copy the USB directory from the previous version for it to work.
+ New layout file is brilliant. Used it with the GUI to output a new .hex file with my HHKB layout.

- Could not get the GUI to program the GH60 in bootloader mode. "No device present." Used dfu-programmer to flash .hex to keyboard.
- Still need to debug issue with "-" key, and intermittent issue with APP key. I installed used switches (Clears), so the problem may be with the switches I used, or maybe I need to reflow those diodes, etc.

?? What scancode can I use for numpad_plus, numpad_minus, etc.?

Thanks for the report.
The GUI can't flash the keyboard, only program the layout, and this is done in regular more (don't go into bootloader with the button)
The codes for numpad keys start from kp_ (sorry for the confusion, probably it should be numpad_* or np_*), so you're looking for kp_+ and kp_-.
So the problem with "-" concerns just "-"? In this case I hope it's the switch or diode.

[jdcarpe]

Thanks! kp_ makes sense.

To do:

* Debug probable hardware issue (very likely non-pcb-related).
* Try to get all this working using Win7.
* Test metalliqaz' GUI and firmware.
* Delve into the TMK firmware and get it working with Rev B.

[metalliqaz]

I like to use my keypuller to short the switch contacts.  It's the perfect size to reach from the switch post to the diode contact.  Real good for pinpointing the issue between switch/diode/software.

[komar007]

I like to use my keypuller to short the switch contacts.  It's the perfect size to reach from the switch post to the diode contact.  Real good for pinpointing the issue between switch/diode/software.

I use my tweezers for this;)

[hasu]

I updated my source to support Rev.B as well as Rev.A by one firmware binary.

jdcarpe, can you try this? Or someone?
 gh60_lufa.hex (66.43 kB - downloaded 509 times.)
 tmk_gh60_hhkb.hex (65.24 kB - downloaded 393 times.)

Let me know whether these keys work; 8, U, I, K and M.

EDIT added HHKB layout hex.

[jdcarpe]

I updated my source to support Rev.B as well as Rev.A by one firmware binary.

jdcarpe, can you try this? Or someone?
(Attachment Link)

Let me know whether these keys work; 8, U, I, K and M.

Sure, I'll flash it on there during my lunch break today and report back my results.


I can confirm that it works! Typing this on the Rev B with this firmware now.

[hasu]

Thank you, jdcarpe.

I updated my firmware tmk_keyboard to support Rev.B PCB as well as Rev.A. Now one firmware binary works on both PCBs. And some keymap files(HHKB and spaceFN) were added and fixed README.

https://github.com/tmk/tmk_keyboard/tree/master/keyboard/gh60

[codyeatworld]

Thank you, jdcarpe.

I updated my firmware tmk_keyboard to support Rev.B PCB as well as Rev.A. Now one firmware binary works on both PCBs. And some keymap files(HHKB and spaceFN) were added and fixed README.

https://github.com/tmk/tmk_keyboard/tree/master/keyboard/gh60

I'm trying to flash your tmk firmware to a rev A on mac os x.

I was able to use homebrew to install avr, and 'dfu-programmer'.

I'm not sure how to flash a layout though? I can run this with any keymap and I always get the same layout after it flashes. (I was previously running komars firmware with an iso layout.)

Code: [Select]

tmk_keyboard/keyboard/gh60[master]% make KEYMAP=poker
...
Size after:
   text    data     bss     dec     hex filename
  23406      56     178   23640    5c58 gh60_lufa.elf

tmk_keyboard/keyboard/gh60[master]% make dfu
dfu-programmer atmega32u4 erase
dfu-programmer atmega32u4 flash gh60_lufa.hex
Validating...
23462 bytes used (81.83%)
dfu-programmer atmega32u4 reset

edit: fixed code quote

[jdcarpe]

Thank you, jdcarpe.

I updated my firmware tmk_keyboard to support Rev.B PCB as well as Rev.A. Now one firmware binary works on both PCBs. And some keymap files(HHKB and spaceFN) were added and fixed README.

https://github.com/tmk/tmk_keyboard/tree/master/keyboard/gh60

I'm trying to flash your tmk firmware to a rev A on mac os x.

I was able to use homebrew to install avr, and 'dfu-programmer'.

I'm not sure how to flash a layout though? I can run this with any keymap and I always get the same layout after it flashes. (I was previously running komars firmware with an iso layout.)

Code: [Select]

tmk_keyboard/keyboard/gh60[master]% make KEYMAP=poker
...
Size after:
   text   data    bss    dec    hexfilename
  23406     56    178  23640   5c58gh60_lufa.elf

tmk_keyboard/keyboard/gh60[master]% make dfu
dfu-programmer atmega32u4 erase
dfu-programmer atmega32u4 flash gh60_lufa.hex
Validating...
23462 bytes used (81.83%)
dfu-programmer atmega32u4 reset

edit: fixed code quote

If you're going to flash the TMK firmware on there, you'll need to edit the layout file and compile it to .hex first, before flashing your new firmware .hex to the GH60.

You can download the TMK firmware from hasu's Github. The readme will tell you how to edit the layout file for your platform (GH60) and compile it.

[codyeatworld]

If you're going to flash the TMK firmware on there, you'll need to edit the layout file and compile it to .hex first, before flashing your new firmware .hex to the GH60.

You can download the TMK firmware from hasu's Github. The readme will tell you how to edit the layout file for your platform (GH60) and compile it.

What I am doing above then?

Well I figured I'd edit the layout file after I flash one of the predefined layouts.

https://github.com/tmk/tmk_keyboard/blob/master/doc/build.md#3-make

Code: [Select]

3. Make

Build firmware using GNU make command. You'll see <project>_<variant>.hex file in that directory unless something unexpected occurs in build process.

mkae -f Makefile.<variant> clean
make -f Makefile.<variant>
I'm not really sure what Makefile.<variant> refers to?

[hasu]

You can also compile with PJRC USB stack with Makefile.pjrc but there is no reason to do so if you are not sure. Use just 'make'(= make -f Makefile) and go with LUFA.

You can define you keymap with creating keymap_codyeatworld.c, after that do 'make' to compile and flash it.

    $ make KEYMAP=codyeatworld
    $ make KEYMAP=codyeatworld dfu

If you need more help about tmk_keyboard come and join the TMK thread. I dont want to derail this thread for my firmware. http://geekhack.org/index.php?topic=41989.0

[codyeatworld]

Thanks a lot hasu and jdcapre.  It's working now.

[komar007]

Has anyone built the GH60 rev. B prototype with all the LEDs on?
I can buy some and solder them myself, but I thought if someone has already done it, they could test it...

[swill]

I would like to see if I can get a bit more information on a few things about this pcb.  Some questions may seem strange, but help me out if you can.

- Is the controller soldered on the underside of the pcb?
- Are all of the LED resistors SMD and which side of the pcb are they soldered on?
- Is the USB connection soldered onto the underside of the pcb?
- Do I see a reset button under the caps lock key?  Which side is that on?
- I see about a dozen through hole resistors, which side are they mounted on?

If you have a pcb soldered up, would you mind looking at the profile (thickness) and tell me which of the components are raised away from the pcb the most?  I am assuming it would probably be the usb connector, maybe the reset button (if thats what that is) and potentially the controller.

And for the final and most important question.  How raised away from the pcb is the tallest component that is soldered on?  If you have a pair of calipers and can give me a pretty detailed number that would be ideal.

I am trying to figure out what my relative bounds are for the thickness of the silicon sheet in my case design.  I will have cutouts in the silicon for the components that are very raised (like the usb connector and the controller).

[Kdash]

Has anyone built the GH60 rev. B prototype with all the LEDs on?
I can buy some and solder them myself, but I thought if someone has already done it, they could test it...

Hi komar007! you means WASD, poker arrows fn and esc's? I soldered it with LEDs on and it works~I use the tmk's firmware.

[Kdash]

This is my GH60 rev B version

[komar007]

I would like to see if I can get a bit more information on a few things about this pcb.  Some questions may seem strange, but help me out if you can.

- Is the controller soldered on the underside of the pcb?
- Are all of the LED resistors SMD and which side of the pcb are they soldered on?
- Is the USB connection soldered onto the underside of the pcb?
- Do I see a reset button under the caps lock key?  Which side is that on?
- I see about a dozen through hole resistors, which side are they mounted on?

- yes,
- there are no smd resistors, all of them are THT and they are to be soldered by the user on their own; they can be soldered on either side, depending on the case/plate, etc,
- yes,
- yes, it's between caps-lock and A, on the underside,
- all THT resistors are for the LEDs, and they are mounted wherever the user wants them.

If you have a pcb soldered up, would you mind looking at the profile (thickness) and tell me which of the components are raised away from the pcb the most?  I am assuming it would probably be the usb connector, maybe the reset button (if thats what that is) and potentially the controller.

Here it is, in order:
USB receptacle - 4.1mm
reset switch - 3.1mm
capacitors C3 and C8 - 1.3mm
controller - 1.1mm

And for the final and most important question.  How raised away from the pcb is the tallest component that is soldered on?  If you have a pair of calipers and can give me a pretty detailed number that would be ideal.

I am trying to figure out what my relative bounds are for the thickness of the silicon sheet in my case design.  I will have cutouts in the silicon for the components that are very raised (like the usb connector and the controller).

Assuming the extension module is not soldered, than probably the tallest will be the LED resistors, if they are mounted on the underside. Unfortunately, this depends on what resistors are used. I can't tell you now which we'll ship in the set, because I haven't chosen them yet.


Congratulations on the case design. It looks very good so far. I like thin cases which don't have space inside. It reduces the noise significantly. Currently using Ali's acrylic case, I wouldn't change it for anything else, even pretty aluminum cases.


-------

Has anyone built the GH60 rev. B prototype with all the LEDs on?
I can buy some and solder them myself, but I thought if someone has already done it, they could test it...

Hi komar007! you means WASD, poker arrows fn and esc's? I soldered it with LEDs on and it works~I use the tmk's firmware.

 
Thank you, that's great. So we have that tested. Now it would be good to find someone who has soldered all of the LEDs;) But I don't think many people did this since they won't work without the extension module which isn't available yet.

This is my GH60 rev B version
(Attachment Link)

 


Congrats. I like the layout!

[regack]

Is there some information about the LED extension module somewhere in a thread that I don't know about/can't find?

[komar007]

Is there some information about the LED extension module somewhere in a thread that I don't know about/can't find?

No, there isn't anything except there will be such a module in the future. I've sorta kinda started working on it.

[swill]

If you have a pcb soldered up, would you mind looking at the profile (thickness) and tell me which of the components are raised away from the pcb the most?  I am assuming it would probably be the usb connector, maybe the reset button (if thats what that is) and potentially the controller.

Here it is, in order:
USB receptacle - 4.1mm
reset switch - 3.1mm
capacitors C3 and C8 - 1.3mm
controller - 1.1mm

And for the final and most important question.  How raised away from the pcb is the tallest component that is soldered on?  If you have a pair of calipers and can give me a pretty detailed number that would be ideal.

I am trying to figure out what my relative bounds are for the thickness of the silicon sheet in my case design.  I will have cutouts in the silicon for the components that are very raised (like the usb connector and the controller).

Assuming the extension module is not soldered, than probably the tallest will be the LED resistors, if they are mounted on the underside. Unfortunately, this depends on what resistors are used. I can't tell you now which we'll ship in the set, because I haven't chosen them yet.

Congratulations on the case design. It looks very good so far. I like thin cases which don't have space inside. It reduces the noise significantly. Currently using Ali's acrylic case, I wouldn't change it for anything else, even pretty aluminum cases.

Thank you very much for the details on this.  I ordered a couple sheets of 1/8" (3.175mm) 40A silicon.  That will be my starting point.  I may have to up that thickness to 3/16 given the numbers you just sent.  I am making the assumption that if I do cutouts for all of the items you mentioned there, I may have enough room.  If all of the resistors are soldered on the underside of the pcb, I am expecting them to give me the extra 1mm I need for the usb connector to fit.  I expect the pcb to probably sit ~1mm away from the silicon sheet because of all of the solder joints and resistors, so the 1/8 thickness MAY still work.  Once I have the boards in hand and the 1/8" sheet in hand I can determine if I have to go up to 3/32 with the silicon pad.

Thanks for the help... 

[komar007]

Okay, the accidental short error is fixed and from my point of view everything is okay now. I sill want to make absolutely sure the backlight module fill fit and work with the current electrical design of GH60. Except for that I'd like to wait until agodinhost gets his prototype to work on the bluetooth module. Then I'll be totally sure we can start production.

[hasu]

Great. GH60 seems to be mature enough now.

Who is working on the backlight module? It seems that lrow* and lcol* pins are enough to control LEDs, though.
As for Bluetooth I think that finishing protyping could take very long, it is not simple job at all. And I think the PCB also has enough IO pins to *prototype* Bluetooth module,  But it may not if we needs power management like battery charger and power source selection(USB/battery).

Backlight and Bluetooth options are must? I'm not sure whether you or one of GH60 orgnaizers promised buyers backlight and Bluetooth options officially/clearly. I don't remember how these options were added to original design. As one of GH60 buyers I for one don't want to wait for another half year... Sorry for the whine.

EDIT: Ah, I'm not betatester, don't have real rev.B PCB. I just see circuit and PCB design with KiCAD. Github repository doesn't have the latest design? https://github.com/komar007/ghkb

[jdcarpe]

I agree with hasu. I don't think we need to delay production in waiting for these optional modules. If some change needs to be made later on, to make it compatible with the chosen Bluetooth module, you could make a new "BT-compatible" revision. I'm sure the backlighting module will be workable on the Rev C boards, as others have tried it, and reported that it works, other than the "shorting" error. Correct?

Neither of these options was a design parameter, and should be treated as separate projects. You not only added the LED holes at each switch location, but you also ran traces for them, and broke them out to expansion pads. That was an added bonus!

In my opinion, we are ready to proceed once your final error correcting revision has been completed.

[komar007]

Okay, I think you're right. We should start ASAP. The final files are not in the repo yet. And I think, to make it more fair to the participants, I won't publish them until production is complete, keeping the rev. B's status "faulty". This way I can be sure the GH people will get the finished boards first, before somebody else produces them on their own. Not that I mind if someone produces GH60 alone at all of course. But this way we'll give priority to the participants who have paid for prototyping and other stuff.
I hope that the lack of bug information in this thread means lack of bugs, and not that those who got their prototypes didn't have the time to test them. Anyway, if someone has found something, please say it now or never!;D

[agodinhost]

Regarding the BT module:
- I do agree with JD and hasu, I think we should move on,  it should be treated as separate projects. To be completelly honest I was waiting for Komar - if he waits for me we will be in loop forever ... 
- My main idea is to keep everything simple and modular as possible. I'll need two pins from the atmega (tx/rx) to send/receive AT commands - I think we already reserved these pins some time ago.
- Until so far we decided to use the RN-42 HID module. I'm still looking for some alternatives, just in case.
- Most of the basic stuff that will be required is already selected (Level converter, Booster/Charger and lipo). Not a big deal on it anyway.
- Hasu mentioned the power source selection - most probably we will need to make some hack to power feed the board but we can do it later ...

+1 move on
+1 treat as separate projects

[hasu]

Okay, I think you're right. We should start ASAP. The final files are not in the repo yet. And I think, to make it more fair to the participants, I won't publish them until production is complete, keeping the rev. B's status "faulty". This way I can be sure the GH people will get the finished boards first, before somebody else produces them on their own. Not that I mind if someone produces GH60 alone at all of course. But this way we'll give priority to the participants who have paid for prototyping and other stuff.

I can totally understand your thought and I found my use of the word "buyers" in previous post was improper. We all participants are taking risks of development and production to make this great thing happen, and should be proud of this. We are not just buyers or consumers.

I hope that the lack of bug information in this thread means lack of bugs, and not that those who got their prototypes didn't have the time to test them. Anyway, if someone has found something, please say it now or never!;D

Betatesters, please!

- My main idea is to keep everything simple and modular as possible. I'll need two pins from the atmega (tx/rx) to send/receive AT commands - I think we already reserved these pins some time ago.

Not that ATmega hardware UART RXD/TXD pins(PD2/PD3) are reserved for matrix, we should use software UART with GPIO pins to interface BT module. From my experience with WT12 this is not a problem, but I've not tried RN42 with software UART yet.
http://geekhack.org/index.php?topic=40514.msg859852#msg859852

- Hasu mentioned the power source selection - most probably we will need to make some hack to power feed the board but we can do it later ...

Yes, I agree.

[komar007]

- My main idea is to keep everything simple and modular as possible. I'll need two pins from the atmega (tx/rx) to send/receive AT commands - I think we already reserved these pins some time ago.

Not that ATmega hardware UART RXD/TXD pins(PD2/PD3) are reserved for matrix, we should use software UART with GPIO pins to interface BT module. From my experience with WT12 this is not a problem, but I've not tried RN42 with software UART yet.
http://geekhack.org/index.php?topic=40514.msg859852#msg859852

Yes, unfortunately I used those pins before I knew we would have an extension module, and then I didn't want to change too much before production. Then it appeared we did another run of prototypes, so I could have changed it then, but I didn't think about it. Now it's too late again, I want as little changes as possible, because there will be no prototypes anymore.
So we're left with software communication. On the other hand, I think I'm going to use atmega8a for the backlight module for example, and this means I'll have just one pin left for communication, so I'll have to use some simple 1-wire interface for this. Since the bt module won't need very much data transferred, anything software based shouldn't be a problem. Especially if the whole USB stack won't work at the same time, we'll have nearly all of the processor time to do communication.

- Hasu mentioned the power source selection - most probably we will need to make some hack to power feed the board but we can do it later ...

Yes, I agree.

What I'm slightly concerned about is powering the board from the extension module and charging from USB. While just feeding power through VCC and GND pins on he ext' module is not a problem, it can be tricky if we want the possibility to connect USB at the same time to charge the battery. I haven't thought about it, but I do hope it'll be possible to do this without modifications to the mainboard's design.

[agodinhost]

We did mentioned it previously here.

Using the RN-42 I think we are okay with software UART (I don't know about the WT giga - mine never went home, sniff)

... On the other hand, I think I'm going to use atmega8a for the backlight module for example, and this means I'll have just one pin left for communication ...

This guy does not have support for USB, we will have to use some firmware-only usb driver ...
The tmk firmware works on it? Your firmware will work on it?

IMHO, it's not a good moment to change the uC.
-1 atmega8a, sry.

Would not be easier to add one shift register like the mcp23017 or mcp23018??