Two months ago we announced that we’ll be moving to a much more powerful ARM processor instead of the AVR - and one month ago we said that we’ll be using an even powerful one. Moving to a new processor architecture is a big deal, especially with a short amount of time - but we were able to make it happen without hurting the project schedule.
We’ve been working heavily on the new firmware lately, and we’re happy to let you know that it’s paid off big time! This is how the left side of my desk looks:
The rightmost FRDM-K22F board contains the insanely powerful MK22FN512VLH12 processor and runs the firmware of the right keyboard half. It shows up as a fully-fledged USB device, implementing a keyboard interface, a mouse interface, and a generic HID interface. This means that it can act as a keyboard, as a mouse and it’s also able to communicate with the host computer (to transfer configuration data, etc). As proof of this, a button on this board makes it send the scancode of the letter “a” to the host computer, another button scrolls with the mouse downwards, and a script that I’ve written makes the RGB LED display any color.
The middle FRDM-KL03Z board acts as the left keyboard half, and it communicates via the right half via the I2C protocol. A button on this board moves the mouse pointer leftwards, and another button moves it rightwards.
The leftmost board is an Open Bench Logic Sniffer which sniffs the communication of the aforementioned boards, so that the firmware can be debugged more easily.
Want to watch a half minute video of how it works? Pop that corn, then enjoy the view!
Working on the new firmware is a labor of love. Being an advocate and practitioner of clean code, I’ve made sure that it’s not merely working, but supremely readable. There’s a lot of code to be added, but it should be easily hackable by the UHK owner.
Progress on Agent
Arpi has been giving Agent some love. Now you can switch between keymaps in the side menu and change to the macro view interface. This is still considered to be a mockup, but more and more things are working, so you’re welcome to click around!
The UHK in the Wild
Our most beautiful master prototype is truly a word traveller. It’s been in San Francisco and New York to be seen by the media and you at getgeeked, then travelled to Moscow, only to arrive to Singapore to be featured at Hackware v1.2, then went back to Hungary, had a trip to Spain for a testing session, and recently landed in DevConf in Johannesburg!
A UHK was given away by DevConf to a speaker and an attendee, and they liked our prototype so much that they’re in the process of purchasing a 10-pack.
Our sincerest thanks go to Mark Pearl, organizer of DevConf, who got in touch with us, and helped to make this happen!
What’s Next?
The firmware has progressed so far, it’s now time to redesign the PCBs to feature the new processors instead of the old AVRs. There’s also a lot in the works on the mechanical design front, so stay tuned.
Talk to you on 2016-04-14!
7 Comments
Thank you for the update!
Thanks for reading, Adam!
Has the change in processor affected the security locking bits?
Hi Cedrick! The planned security modes are unchanged despite the change in processor. As for locking the flash with lock bits I'm not sure whether that's possible because I'm not an ARM expert, but I wouldn't consider it a good practice because it would make the firmware of the UHK non-upgradable.
I'm just curious, but is it still possible to use a long (10 meters) cable between the two halves? and am I still be able to change the length of the cable? From my own experience with using I2C I walked into trouble with replacing a short (10 cm) cable with a longer (20 cm) cable. But now you want to replace a 20 cm? cable with a 10 meter cable.
Very good point, Edbo. The maximum cable length is indeed shorter due to the capacitance of the I2C bus. But I tested I2C communication between the halves a couple of weeks ago with a 20 meter long cable and it worked at 100K baud. The plan is that if communication gets unreliable because of external noise then the baud rate will be throttled by the master (which is the right keyboard half). We can detect this condition by using checksums. The throttled baud rate shouldn't effect user experience in any major ways, possibly apart from competitive gaming, where folks will hardly ever use a 20 meter long cable.
Thanks for the update.
Comments are closed.