mmccoyd / hillside Goto Github PK

I just wanted jlcpcb to make me some hillside52 PCBs, when I realized that they don't produce sensible prices. I checked the gerber view, and while it does present you with the board in the preview, the logging on the side tells you:

Analysis Results
layers : -1
minimum trace width : >=10 mil
minimum trace spacing : >=10 mil
minimum drill size : null
width : null
height : null
Unable to identify the layers due to the non-standard filename
Can not identify the board outline
...

I've tried with 56 for the same result and compared those to 46 and 48, which both seem to work (gets correct pricing, and Gerber Viewer doesn't complain about anything).

Disclaimer: This is my first time ordering PCBs and I have no idea what I'm doing, so while it's completely possible I messed up somewhere, I always thought downloading and uploading a .zip was fool-proof :D

Hello.
Thanks for your time.
Could you, please, fix it?
Thanks in advance.

qmk_compile_hillside_errors.log

These errors can be fixed by adding the following into config.h, however this does have qmk spew out warnings.
#define VENDOR_ID 0xFEED
#define PRODUCT_ID 0x67C0
#define DEVICE_VER 0x0001
#define DIODE_DIRECTION COL2ROW
#define RGBLED_NUM 5
#define RGB_DI_PIN D3
#define SOFT_SERIAL_PIN D2

Furthermore if the following is not defined in config.h then no key is registered:
#define MATRIX_ROW_PINS
{ D7, E6, B4, B5 }
#define MATRIX_COL_PINS
{ F6, F7, B1, B3, B2, B6 }

By adding all of the above in 'config.h' my own firmware/keymap works, can be compiled and flashed and registers all keys.

jhelvy/splitKbCompare#85

The Hillside 48 seems to get less attention than the Hillside 46.
Would it be possible to update the Hillside 48 so that it has more encoder spots, the hotswap option, and a PCBA?

Hello!

Thanks a lot for this wonderful looking keyboard, and the very helpful detailed instructions!

I'm following the instructions on the Ordering Hillside 52 or 46 page, in order to order a Hillside 46 from JLCPCB.

I'm following the steps detailed in the doc step by step, but after uploading the BOM and top_boards.csv, JLCPCB's preview shows the components positioned completely off the PCB:

This seems to be the only preview JLCPCB shows before placing the order. I've redone the steps three times and I don't think I've missed anything. Is it the case that I've missed anything, or is there an issue with JLCPCB or with the instructions?

Steps to reproduce

1. Download hillside46-gerber-and-pcba_0.1.0 from Releases hill46_v0.1.0.

2. On JLCPCB, follow the instructions from How to Order Five PCBA Keyboards

   Side note: The instructions say "Dimensions: 100 x 143 mm". But after uploading the Gerber file, dimensions are pre-populated and are slightly different: 142.49 width, 99.87 height.

3. At the 'Save to Cart' step, which reads ...

   The preview should show components placed and rotated over spots on the board that look meant for them, in terms of silkscreen lines around them and traces leading to them. The engineers will ensure the final placement, and you will confirm at DFM Analysis later.

   ... the components on the preview are placed away from the PCB board.

The first step is to ensure the pinouts of your MCU are the same as for ProMicro. They should be, but check!

For QMK, I used the converter.

For ZMK it is not possible as split are not supported yet.

Add note about LEDs running on 3.3v outputs.

I can't find any specs or product code for the hot swap sockets.

Does anyone have a layout file for keyboard-layout-editor for a Hillside keyboard?

The one thing that seems to be lacking is the ability to add nice view OLED displays. There is a header apparently for haptic feedback based on the schematic but even if that were compatible there is no good way to add a display cover.

1. Wiki says JS202011AQN / C221662
2. hilside52_bom.csv says SSSS223200 / C115376

Is this a mistake?
Does it matter?
Is the only difference the color of the handle piece? 1 black, 2 white

Greetings,

This is probably an embarrassingly n00b-ish question, but should I also install a SRV05-4ATCT on the right half of the keyboard or should I leave the footprint unpopulated?

Looking at the Gerber, it appears the pads are wired up in a mirror-Y configuration from how the pads are connected on the left half of the keyboard. Looking at the spec sheet for the SRV05, so it wouldn't work with pin 1 in the upper-left like on the left half of the board and I don't think it would work if I rotated the package 180 degrees (though I may be wrong, I am very much a novice).

On a side note: what is the purpose of that chip? I know it's an ESD chip, but none of the other boards even have a footprint for it; just the 46. If I were to speculate, I'd guess it has to do with unplugging the headphone cable with the board powered but I'm not sure and didn't see an explanation in the doc.

Links to Colemak and Dvorak layouts broken on 42 keymap page

Hi,
first of all, thank you for this sophisticated piece of awesomeness! Even the LEDs are hidden behind a key. You're a genius!

I've read the Wiki and if I'm right I need to solder some parts myself after PCBA service:

• SK6812MINI-E https://jlcpcb.com/partdetail/OpscoOptoelectronics-SK6812MINIE/C5149201
• Rotary Encoders https://jlcpcb.com/partdetail/Alpsalpine-EC12E1220301/C209763
• Machine pin female sockets like this https://www.mouser.de/ProductDetail/Mill-Max/315-43-112-41-003000?qs=s8Nb1z4Wn%2FRfWrVqQ0TOuQ%3D%3D
• Mill-Max Hot Swap Sockets https://jlcpcb.com/partdetail/millmax-7305_0_15_15_47_27_100/C5189908

Is it possible to add those to the PCBA too?
Regards

Last week I finished building my Hillside 46. I'm using two Type-C ProMicros from Aliexpress.

It worked for a couple of days with the default keymap, I had some issues with the left side working as the right side but I fixed it by adding these two lines to the keymaps/default/config.h file:

#undef SPLIT_HAND_MATRIX_GRID
#define EE_HANDS

I'm compiling with this command:

qmk compile -kb hillside/46/0_1 -km default

And flashing (each side separately):

qmk flash -bl avrdude-split-left hillside_46_0_1_default.hex
qmk flash -bl avrdude-split-right hillside_46_0_1_default.hex

Today I wanted to switch the C keymap and I also set VIA_ENABLE = yes in keymaps/default/rules.mk (not sure why I did both of these changes together, it might have been a dumb idea).

After flashing both sides I noticed only the side connected via USB is working:

• The keys on the other side don't do anything
• The underglow LEDs on the other side don't start
• The ProMicro LED does turn on

When connecting the left side standalone it worked fine, but when connecting the right side standalone it behaved like the right side.

After flashing the original firmware I used and clearing the EEPROM using QMK Toolbox didn't work I found a tip about setting the handedness via QMK Toolbox and that fixed the right side problem.

But still only the USB-connected half is working...

• I checked the VCC->GND voltage on the other half and it's 5V
• I tried resetting the EEPROM (from QMK Toolbox and by mapping a key to QK_CLEAR_EEPROM)

Any suggestions?

EDIT: This is the output when flashing:

❯ qmk flash -bl avrdude-split-right hillside_46_0_1_default.hex

Flashing binary firmware...
Please reset your keyboard into bootloader mode now!
Press Ctrl-C to exit.

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9587 (probably m32u4)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip

avrdude: processing -U flash:w:/Users/david/qmk_firmware/hillside_46_0_1_default.hex:i
avrdude: reading input file /Users/david/qmk_firmware/hillside_46_0_1_default.hex for flash
         with 18256 bytes in 1 section within [0, 0x474f]
         using 143 pages and 48 pad bytes
avrdude: writing 18256 bytes flash ...
Writing | ################################################## | 100% 1.38 s
avrdude: 18256 bytes of flash written
avrdude: verifying flash memory against /Users/david/qmk_firmware/hillside_46_0_1_default.hex
Reading | ################################################## | 100% 0.14 s
avrdude: 18256 bytes of flash verified

avrdude done.  Thank you.

I'm building a wireless Hillside 52 using a kit from Beekeeb. The kit didn't come with a capacitor, and the Parts list says that capacitors are needed only for the Hillside 46 (presumably, this is for the C2 and C3 capacitors on that board though).

Is this capacitor necessary? Is it just a safety measure?

I can't find a way to contact the developers on the Github page for this project. Is there a place where we can discuss Hillside keyboards with them?

Hi,
I got an email from JLCPCB that said the hole in the PCB didn't align with the copper pad in the keyboard (shown in the white circle in the pictures). Is this fine to proceed with the production or I need to fix this by myself 😢
Thanks in advance!

I have ordered all required parts to build my Hillside. The only thing I don’t really know with is how to solder the encoders. One of the holes in the PCB doesn’t seem to be wide enough.

Here’s a photo of what I mean:

How am I supposed to deal with this? Do I just cut off the second wide leg?

It's just an idea, not yet as sophisticated as your work ;)
But fixing an empty battery within 5 seconds replacing it, putting the empty one into the charger and use it for weeks/months before you need to repeat? Sounds good to me.

https://www.amazon.de/-18650-battery-holder/dp/B081HW4TGR

Pinta crashed while painting mockup :'( So here's the text-only-edition:
I'd place the battery right above the first thumb key with enough space for an OLED, extend the board and screw the holder to it.
What do you think?

Better solutions are appreciated.

Some MCU do not handle split well without this. Add commented out entry to enable it at keymap level.

• Keymap config
  • default
  • default_dot_c
  • via
  • vial
• Parts MCU docs
• Troubleshooting doc

Prompted by issue #1

I just received a hillside48 with a Sea Micro atmega32u4 USB-C microcontroller (ordered on beekeeb), and I experienced some challenges uploading the QMK firmware using DFU. I think I have solved the problem (or at least found a workaround), but I still have not gotten around to solder the keys to my keyboard and tested it, so I will have to write a update once that is completed.

Tldr: use avrdude to flash the MCU

I think this issue is with QMK or the microcontroller, but for now I wanted to add it here. Perhaps something could be written about it in the documentation.

My problem was when running the qmk flash command.

~ qmk flash
Ψ Compiling keymap with make -r -R -f builddefs/build_keyboard.mk -s flash KEYBOARD=hillside/48/0_1 KEYMAP=gbthreepwood KEYBOARD_FILESAFE=hillside_48_0_1 TARGET=hillside_48_0_1_gbthreepwood INTERMEDIATE_OUTPUT=.build/obj_hillside_48_0_1_gbthreepwood VERBOSE=false COLOR=true SILENT=false QMK_BIN="qmk"


avr-gcc (GCC) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Size before:
   text	   data	    bss	    dec	    hex	filename
      0	  18082	      0	  18082	   46a2	hillside_48_0_1_gbthreepwood.hex

Copying hillside_48_0_1_gbthreepwood.hex to qmk_firmware folder                                     [OK]
Checking file size of hillside_48_0_1_gbthreepwood.hex                                              [OK]
 * The firmware size is fine - 18082/28672 (63%, 10590 bytes free)
Flashing for bootloader: atmel-dfu
Bootloader Version: 0x00 (0)
Checking memory from 0x0 to 0x6FFF...  Empty.
Chip already blank, to force erase use --force.
Checking memory from 0x0 to 0x46FF...  Empty.
0%                            100%  Programming 0x4700 bytes...
[ X  ERROR
Memory write error, use debug for more info.
make: *** [platforms/avr/flash.mk:173: flash] Error 254

Directly calling the dfu-programmer software gives the same error:

dfu-programmer atmega32u4 flash hillside_48_0_1_gbthreepwood.hex --debug 2
     target: atmega32u4
    chip_id: 0x2ff4
  vendor_id: 0x03eb
    command: flash
      quiet: false
      debug: 2
device_type: AVR
------ command specific below ------
   validate: true
   hex file: hillside_48_0_1_gbthreepwood.hex

Checking memory from 0x0 to 0x46FF...  Empty.
0%                            100%  Programming 0x4700 bytes...
[ X  ERROR
Memory write error, use debug for more info.

The following works, and afterwards it seems that the qmk flash also started working:

avrdude -p atmega32u4 -c flip1 -U flash:w:hillside_48_0_1_gbthreepwood.hex

Output is:

avrdude warning: USB bDeviceClass = 255 (expected 254)
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9587 (probably m32u4)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip

avrdude: processing -U flash:w:hillside_48_0_1_gbthreepwood.hex:i
avrdude: reading input file hillside_48_0_1_gbthreepwood.hex for flash
         with 18082 bytes in 1 section within [0, 0x46a1]
         using 142 pages and 94 pad bytes
avrdude: writing 18082 bytes flash ...
Writing | ################################################## | 100% 1.12 s 
avrdude: 18082 bytes of flash written
avrdude: verifying flash memory against hillside_48_0_1_gbthreepwood.hex
Reading | ################################################## | 100% 0.44 s 
avrdude: 18082 bytes of flash verified

avrdude done.  Thank you.

I now get the following upon issuing qmk flash:

Ψ Compiling keymap with make -r -R -f builddefs/build_keyboard.mk -s flash KEYBOARD=hillside/48/0_1 KEYMAP=gbthreepwood KEYBOARD_FILESAFE=hillside_48_0_1 TARGET=hillside_48_0_1_gbthreepwood INTERMEDIATE_OUTPUT=.build/obj_hillside_48_0_1_gbthreepwood VERBOSE=false COLOR=true SILENT=false QMK_BIN="qmk"


avr-gcc (GCC) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Size before:
   text	   data	    bss	    dec	    hex	filename
      0	  18082	      0	  18082	   46a2	hillside_48_0_1_gbthreepwood.hex

Copying hillside_48_0_1_gbthreepwood.hex to qmk_firmware folder                                     [OK]
Checking file size of hillside_48_0_1_gbthreepwood.hex                                              [OK]
 * The firmware size is fine - 18082/28672 (63%, 10590 bytes free)
Flashing for bootloader: atmel-dfu
Bootloader Version: 0x00 (0)
Checking memory from 0x0 to 0x6FFF...  Not blank at 0x1.
Erasing flash...  Success
Checking memory from 0x0 to 0x6FFF...  Empty.
Checking memory from 0x0 to 0x46FF...  Empty.
0%                            100%  Programming 0x4700 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x7000 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
Validating...  Success
0x4700 bytes written into 0x7000 bytes memory (63.39%).
make: *** [platforms/avr/flash.mk:173: flash] Error 254

There is still a error 254 message, but at least it seems like some uploading did happen.

Apparently JLCPCB has changed their process for specifying parts placement. They now require separate BOM and CPL files and the file in the release do not work.

Looks like I was able to make it work by splitting the file into 2 files

I made a the BOM file by deleting the placement information and changing the Package header to Footprint and Val column to Comment.

I made a CPL file by deleting the Package and Val column.

For my master/slave boards with Pro Micro I had to add the following define into config.h:
#define SPLIT_USB_DETECT

This solved the issue of the master not receiving slave key presses since the slave side did not recognize itself correctly as slave.

The build guide for the Hillside is fantastic, but it's missing a page describing how to hook up the battery, off switch, and capacitor. Which set of batt pos / gnd do you solder the battery leads to?

It's also missing info about closing the jumper for i2c things on the page on adding the resistors.

Would it be possible to create variations of the Hillsides whose TRRS ports are replaced by USB-C ports?

Hi there, could you publish the PCBA files for the 52 key version of the keyboard please?

Current situation:
Left and right board soldered diodes + reset + TRRS + socketed Pro Micro.
Both sides have a Pro Micro flashed with default firmware (cooked by 'https://config.qmk.fm')
Both the left and right side work by themselves, all keys are working.

When testing for continuity (USB disconnected) and TRRS connected, the 'data' pin of the left Pro Micro is connected to the right Pro Micro 'data' pin. VSS and GND are also showing continuity.

So currently I suspect the firmware to not recognize that it should act as 'slave'.

Any suggestions/pointers are very much appreciated at this point.

Hi there I just finished assembling my hillside 52. The right half does not work when I flash it with the right nice nano firmware. However, if I flash it with the left's firmware, it works. What is amiss? As I understand I can leave the handedness jumpers open as ZMK handles it in software. So, what's the issue?

I use the QMK configurator's keyboard tester to test for keystrokes
Cheers,
Karthik

Hi community,

The hillside52 keeb is by far the best keyboard I have ever used. In my opinion it really deserves more attention.

That's why I decided to gift 8 of my left over PCBs to 4 kind people who want to build their own but dread the ordering process.
All you need to pay for is shipping. Therefore it is the cheapest if you live in Germany. (~5 €)

You can contact me via Telegram. My usernames at GitHub and Telegram are the same.

Regards
Manuel

Received PCBs:

1. @johannes-jp
2. @tokazio