c.Invent
Project Logs
General
| Alive and Kicking |  |
| Photo shoot side by side with PocketSprite |  |
| FunKey gets social ! (Website, newsletter and social networks) |  |
| FunKey Revision B is out! |  |
| Meet the team |  |
| Project roadmap |  |
Mechanical design
| STL files and Exploded view |  |
| 3D Printed prototypes before injection molding |  |
Electronic Design
A bit of History
It’s now been a bit more than two years since we entered the HaD contest with Keymu: an open-source keychain-sized multi-emulator handheld console which received quite an unexpected success.
Keymu did not pretend to be more than a prototype destined to be built by anyone willing to get their hands dirty. And even though it was often asked to be produced and sold, the world of difference between prototyping and producing kind of humbled us into taking it slowly.
We first needed to focus on correcting electrical and software issues Keymu had, that is why we started working on a new prototype without a foldable design but with almost everything new under the hood. The prototype turned out pretty great, so much so that we decided to give it a name and enter once again the HaD prize: this was last year’s FunKey Zero.
A lot has happened in a year, among which the expansion of our team of enthusiasts to the grand number of three, now bringing together the much-needed professional mechanical hindsight to our electrical+software knowledge.
Keymu and its optimized design can now be born again, merging with all FunKey Zero’s improvements, thought for production and readier than ever to bring fun on your Keychain, meet the FunKey Project.
Characteristics
| Dimensions | 42.5x44.5x13.8 mm |
| Processor & RAM | ARM Cortex-A7 @ 1.2GHz. Extensions: NEON, VFPv4. 64MB of RAM DDR2 up to 400MHz |
| Storage | SD card 16GB |
| Display | LCD IPS screen, 1.52”, 240x240 px |
| Audio | 10 mm mono speaker, 500mW |
| Battery | 420mAh Li-ion battery for hours of gameplay |
| Recharging and loading games | via Micro USB port |
What’s new?
Mechanical design
FunKey’s most discernable new features is the return of the foldable design but it's only the tip of the iceberg. Everything is new here, and of course the details will be presented more thoroughly in future logs but, to get a sense, here are the main new features:
- The casing
Completly rethought, it is now a slimmer package than Keymu and way smaller one than Funkey Zero: only 42.5x44.5x13.8 mm when closed.
It is also now sturdier thanks to a combination of snap/fit parts and two small screws on the back.
- The active hinge
The flexible cable between the screen and the mother board now passes through the hinge without enduring any stress. The cable is actually already enrolled inside the hinge so that closing and opening the console will not fold the cable in two (like it was the case with Keymu) but keep enrolling and unrolling it instead.
Also now, like with foldable phones, there is a satisfying snap when closing the console, and the spring in the hinge ensures that it stays firmly closed.
- The buttons
The biggest improvement was done to the L/R buttons which were very tiny and unclickable on Keymu. They now are basically the whole bottom left and right side of the console:
The playing buttons are also now bigger and even more comfortable since we added more space between the game buttons and the directional pad so that both thumbs cannot interfere with each other.
- Other improvements
On/off/menu button that can only be accessed when the console is open, notification LED for charging and low battery info, better cord attachment for the keychain, nice FunKey logo on the back (that we’re still trying to get illuminated thans to the screen's backlight).
Electrical design
For those who followed the first Keymu project, you’ll know it was based on a daughter board designed to function around the now extinct Intel Edison module (may it rest in peace). The next iteration: Funkey Zero, was a way for us to prototype with new processors. Our final decision was to use the Allwinner V3s since it was a QLP package (easy to solder by hand) and already packing 64MB of DDR2 RAM. You can find more details in this dedicated Log entry.
Our main concern was stepping down from an Edison module with 512MB of RAM to a processor with only 64MB. Would it allow us to run the same emulators? Also the power management part was already handled in the Edison, we now had to design it ourselves since the V3s is only the processor.
We got our hands on a module built around the V3s: the licheepi Zero, which already took care of the power management and prototyped a daughter board around it which then became the Funkey Zero project. This allowed us to test the processor and to ease our fears: not only is the V3s capable of running the emulators the Intel Edison handled, but as an ARM processor it could actually handle more thanks to the great community of hackers out there and - as part of the A7 family of processors - was very power efficient (actually, it is a more power-efficient version of the A8).
Based on that we built a whole new board for FunKey with at its heart the V3s, a dedicated power management chip, an SD card reader, micro-USB connection, micro speaker, and many other improvements.
The board was designed to be the slimmest possible so that the whole space under the board would be allocated to the battery, in contrast to Keymu where only half the bottom space could be use since the other half was used up by the Intel Edison module. This allowed us to bump up the battery size from 240mAh to 420mAh:
Firmware improvements
What we started with Funkey Zero keeps being improved. We are trying to optimize everything that is why we built Funkey’s dedicated Linux distribution with Buildroot adding the strictly required packages. Buildroot is an amazing tool to which this project even allowed us to contribute by adding native configurations for the Leechi Pi Zero board (but we’ll talk more about that in our logs).
Many questions are still unanswered regarding the way we want to go with our distribution and we are always re-questioning ourselves as to which compromises would be best for performances versus ease of implementation. For example, an open question is still whether to use X11 or not, this would allow us to use windowing systems, easily display transparent notifications, or even compile programs using more complex graphic libraries (SDL2, OpenGL) but at the cost of adding a significant overhead in processing power and RAM. Solutions without X11 are sparse and forces us to consider older graphic libraries, use tricks to launch different graphical programs in the framebuffer at once and manage them, maybe even add notifications overlay… but would relieve our processor’s load and RAM usage, saving battery life and/or allowing more emulators to run.
Keeping this in mind we are trying to develop everything with the older SDL1.2 graphic library which allows for programs being run with X11 or directly in the framebuffer.
We’ve compiled, tested and adapted various open-source emulators based on SDL1.2 and are still trying to improve them further (cropping/zoom options, quick saves, consistent menus…) for the best experience possible.
We’ve now also added a clean smooth frontend launcher based on RetroFE, that was greatly modified to also run now in SDL1.2 and add options specific to FunKey. Our goal is to provide a great overall experience.
