Close
0%
0%

Funkey Zero

Fun on a keychain - based on LitcheePi Zero

Similar projects worth following
Last year we entered the HaD prize with Keymu, a powerful keychain sized open source emulation console. Keymu's great success was an enormous surprise that got us thinking about production... but Rome wasn't made in one day.
We completely rethought Keymu: dedicated Linux distribution made from scratch, optimized emulators, new frontend, faster processor, better resolution screen, better audio, better buttons…better everything.

Funkey Zero started as an intermediate step before getting into production, allowing us to “quickly” test our improvements, but has now become way more than that. The more we worked on it, the more the “let’s be quick about it” became “yeah…no, let’s make some badass prototype here”.

And here it is, Funkey Zero: a completely rethought form factor than Keymu, improved hardware and software… and wholly shared with you. We hope you’ll enjoy it as much as we do !

No, the FunKey Zero is not YARPBRGC (Yet Another Raspberry Pi-Based Retro Gaming Console, sorry Eben ;-))!

Actually, it must be considered as an original “concept toy” for our tiny (42x46x17mm) #Keymu - open source keychain-sized gaming console .

Unfortunately, the Keymu design was based on the Intel Edison module, which has been retired abruptly with a very short notice by Intel during last September :-(

This situation led us to quickly find the best replacement core that fits into this tiny form factor. But with these stringent overall dimensions, even the Rpi Zero is too large!

And as unfortunately it is not possible to buy the bare Broadcom BCM2835 chip to put it on a smaller custom board, we had to find another candidate CPU that provides a similar very small footprint.

We tried to focus a SoC with integrated DRAM like in the BCM2835 where it is integrated as a PoP (Package on Package) device, as this saves a lot of real estate on the board, and in the meantime simplifies greatly the board layout and PCB requirements.

We found only a single serious candidate fitting these specifications: the AllWinner V3s chip, which is a single core ARM Cortex A7 1.2GHz with FPU, NEON SIMD acceleration and with 64MByte of integrated DDR2 RAM. This may not sound much, but we determined that this processing power and RAM capacity is just enough to run our intended retro game emulators at full speed on our tiny 240x240 pixel screen.

So we decided to design a new version of the keymu project with a custom board based on the AllWinner V3s, using the same external hinged 42x46x17mm form factor.

But in order to validate some key design points, we are now building an intermediate non-hinged prototype based on the LicheePi Zero module, which uses the same chip:
https://licheepizero.us/
https://www.indiegogo.com/projects/licheepi-zero-6-extensible-linux-module-on-finger-wifi-diy#/

Here comes the FunKey Zero!

Although this prototype is larger than our target Keymu device, it is still very cool and enables us to test a lot of mechanical, electronic and software features of the final device with only a very small effort.

At the same time, it demonstrates some interesting design tricks that we can and will openly share with our fellow hackers !

FunKey Zero 3D STEP.zip

FunKey Zero board 3D file in STEP format

x-zip-compressed - 3.70 MB - 04/20/2018 at 08:24

Download

FunKey Zero Gerber.zip

FunKey Zero board production files in gerber RS274D format

x-zip-compressed - 722.75 kB - 04/20/2018 at 07:53

Download

FunKeyZero.ods

FunKey Zero board BOM in LibreOffice Calc format

spreadsheet - 13.76 kB - 04/20/2018 at 07:51

Download

FunKeyZero.brd

FunKey Zero board layout in EagleCAD format

brd - 436.62 kB - 04/20/2018 at 07:51

Download

FunKeyZero.sch

FunKey Zero board schematics in EagleCAD format

sch - 423.07 kB - 04/20/2018 at 07:50

See BOM
Download

View all 6 files

  • 2 × C1, C4 C0603_10U_X5R_20%_CER_6V3
  • 1 × C2 C0603_1U_X7R_10%_CER_6V3
  • 1 × J5 MH7-1RA
  • 1 × J6 DF37NB-24DS-0.4V(51)
  • 1 × L1 MMZ1608Y601B

View all 31 components

  • Design Decisions: The Buttons​

    Squonk4205/15/2018 at 21:46 6 comments

    U/D/L/R and A/B/X/Y button pads and START/SELECT buttons

    One of our most difficult constraint for the #Keymu - open source keychain-sized gaming console is the overall thickness of the device: since it is a clam-shell design where the lid contains the LCD screen, this removes a few mm to the total thickness that must stay < ~15 mm. If you remove from this figure 2x enclosure wall thickness of at least 1 mm, the PCB thickness of 1.2 mm and components height of ~1.5 mm (because of the micro USB connector, mainly) and the battery, this does not leave much room for these button pads.

    Thus, we started to search for the thinnest button we could get: standard tactile switches are too thick, and the first idea is to reduce the button shaft length, eventually remove it altogether. Performing a search on Digi-Key for tactile switches sorted by actuator height off PCB leads to these 0.35 mm height, 4.10 mm square button:

    We thought we had the ultimately thinnest button on Earth, until we discovered the Arduboy tactile dome buttons:

    (Check the #Printable buttons for tactile domes project for more details).

    The secret is using these tiny metallic pieces that are curved (0.3 mm height for these example ones) and act as springs:

    We found these RK22170 models at Snaptron, which were very kind to provide us a free sample kit and a hundred of these (easy to lose) thingies.

    The only PCB footprint you need are 2 bare copper arcs with a central copper circle (no solder mask on all of these!), the dome will make an electric contact between these when pressed. You also need a small ex-centered vent hole to help the air below the button to escape on the bottom side of the PCB, that's all!

    In order to keep them in place, you need to stick the domes on a piece of rubber tape, and it is actually not that easy: the required accuracy is rather tight, as the upper plastic button must press right in the middle of the dome, or the button stroke is extremely shorten.

    Although we did the PCB with these footprints, we are not sure yet if we will keep these or not, or go back to our previous SMT ones because of this strict alignment problem: SMT assembly seems much easier to perform than glue these jumping domes on a piece of rubber tape.

    Rear LEFT/RIGHT and RESET Buttons

    For these buttons, we needed the smallest right-angle SMT buttons possible, and we found these B3U-3000P(M)-B models from Omron (3 mm x 2.5 mm x 1.2 mm, without shaft) :

    We choose the model with a boss and made a footprint with a hole in the PCB in order to have a mechanical pin that would make this SMT button resist large forces that could tear it off the PCB.

    For the RESET button, it is mounted recessed on the PCB and will require a small paper clip to be inserted in a hole on the enclosure to activate it.

    As for the rear LEFT and RIGHT buttons, we designed a 3D printed piece with a flexible axis between the 2 large external plastic buttons that presses on the actual button shaft with some very nice elasticity. We were a little bit skeptical about this solution when we designed it, but it proves to be quite nice, the haptic characteristics are very good!

    ON/OFF Slider

    We wanted to have a real ON/OFF slider, but as usual, we needed it to be as small as possible!

    However, as this is a power switch, it had to withstand the maximum current that the device could draw, ~200 mA.

    We found this small PCM12SMTR slider switch that can handle 300 mA which is only 6.7 mm x 2.6 mm x 1.4 mm, without the knob:

    ESD Protections

    As discussed in our previous log, it is very important to protect all user-accessible buttons and keys from ESD by adding a TVS diode as close as possible to the button pins, with a short path to a good ground plane in order to shunt the ESD energy to ground as much as possible, thus protected all subsequent devices connected to the button.

    For this purpose, we used some tiny 0402 bidirectional...

    Read more »

  • Design Decisions: The Screen

    Squonk4205/13/2018 at 17:46 0 comments

    Apart from the core itself, the next important decision is the the choice for the LCD screen.

    Dimensions

    As stated earlier when we discussed about the core, the whole point for the FunKey Zero project was to prototype as much features as possible for the #Keymu - open source keychain-sized gaming console device.

    We determined that the maximum dimensions should not exceed ~ 40 mm x 40 mm x 15 mm, or we should not call it a keychain emulator anymore ;-)

    For the Keymu, we considered that the screen should be as large as possible and adopted a "clam shell" form factor to protect the fragile screen and buttons from impacts on the keychain.

    But these decisions seriously restrict the available screen size: if you consider that the screen can fill the whole 40 mm x 40 mm surface, the maximum possible standard screen size that works is then 1.5" or 38.1 mm in diagonal, or 26.94 mm square.

    Screen Interface

    First of all, the picture to be displayed must be buffered ("frame buffer") on one side, either on the CPU side, or in the screen module itself, which leads to 2 different screen module types:

    • in the first case, the screen module does not contain any RAM and is just a "dumb" display that needs to be constantly refreshed in order to display a picture, using pixel clock, horizontal and vertical sync signals, and of course, the pixel data, usually in an RGB666 (18 data bits from D0 to D17) or RGB888 (24 data bits from D0 to D23), plus a few additional signals. These screens are mostly used to display "live video" coming from a camera sensor like in Handycams or dashboard cams
    • in the second case, the screen module contains a memory, often called Graphic RAM (GRAM) that does not need constant refreshing in order to display a picture. This type of screen is generally used for static displays like UI with buttons, check boxes and sliders

    In the case of "dumb" screen module, the screen interface is generally called "RGB", with a variant "RGB8" where each color component is transferred one after the other (each pixel needs 3 transfers).

    For the screen module featuring internal GRAM on the other hand, there are several standard interfaces used to drive them:

    1. for the smallest screens, an I2C bus is used. As these screen do not contain many pixels, the I2C bus with its maximum speed of 400 Kb/s is more than enough to drive these, and it only requires 4 wires: VCC, GND, SDA (Serial DAta) and SCL (Serial CLock). At 25 fps and 65536 colors, the maximum resolution you can expect is thus... 32 x 32 pixels!
    2. for screens with more pixels, the I2C bus just is too slow to allow high fps numbers, and an SPI bus is used instead, which requires a few additional wires, usually: VCC, GND, SDI (Serial Data In or MOSI), SCLK (Serial CLocK), CS (Chip Select), RS (Register Select), RESET and most of the time a separate power supply for the LED backlight. Speed is often specified up to 8 or 10 MHz, and at 25 fps and 65536 colors, the maximum expected resolution is 128 x 128 pixels. But it is not uncommon to have integrated screen controllers going up to 40 or 50 MHz and in this case, the resolution can go up to 240 x 240 pixels with the same picture parameters!
    3. in order to reduce the required interface speed, some screen modules use parallel buses with 8, 9 , 15, 16 or 18 bit bus, dubbed "MCU", "MPU", "Intel", "8080" or "6800"
    4. for the screens with the highest resolutions (including the ones used in smartphones and tablets), the interface used is a high speed differential serial, user-unfriendly interface called MIPI DSI (Display Serial Interface) requiring a specific controller, only available in high-end mobile phone CPUs

    Clearly in our case, solution #1 is not possible, as well as solution #4, as we don't have the corresponding DSI interface in our CPU. This leaves us with solution #2 or #3 or a dumb...

    Read more »

  • EMC: EMI, RFI, ESD

    Squonk4205/12/2018 at 08:50 0 comments

    No, these acronyms are not new state-sponsored 3-letter agencies, but they are sometimes considered as dreadful!

    ElectroMagnetic Compatibility: ElectroMagnetic Interference, Radio-Freqency Interference and ElectroStatic Discharge, this is what these mean.

    This subject is seldom covered during hobby electronic discussions, because it is not essential (things will "work" without them), it is difficult to understand and in this regard is like some kind of "black magic", and even if you already know it, this subject is just boresome;-)

    So why bother?

    Actually, our own experience shows us that EMC is really the difference between a working prototype on the bench and a reliable product in the wild!

    Another serious motivation is that any device must be certified for compliance against EMC standards in order to be transported, sold, distributed or even used outside a lab.

    This is why we decided to take EMC into consideration right from the start for our FunKey Zero project, as the goal is to prototype as many features as possible for the #Keymu - open source keychain-sized gaming console that we would really like to turn into a usable end-user product.

    EMC

    ElectroMagnetic Compatibility (EMC) is both a device characteristic and a branch of electrical engineering that deals with unintentional generation, propagation and reception of electromagnetic energy which may cause unwanted effects. The corresponding issues are emission (whether deliberate or accidental), coupling and susceptibility (or its opposite immunity).

    Please note that from an EMC compliance test point of view, this means that a device is potentially both a source and a victim of interference.

    EMI

    On the other hand, ElectroMagnetic Interference (EMI) is the disturbance generated by an external source that affects an electrical circuit, i.e. it is the phenomenon itself, not the characteristic or the study of it.

    As the equivalent electrical element between 2 coupled devices is a complex impedance that can be a resistor (R), a capacitor (C) or an inductor (L), or any combination thereof, the coupling can be linearly detailed as conduction, electrostatic coupling or electromagnetic induction, respectively.

    Continuous Interference

    A Continuous Wave (CW) interference arises where the source continuously emits in a given range of frequencies. This type of interference is divided into sub-categories according to the considered frequency range.

    For lower frequencies (typically less than a wavelength), conduction coupling is predominant and may affect 2 conductors in phase (such as a disturbance that hits both conductors at the same time) or out of phase. In the first case, this phenomenon is called common-mode coupling, whereas the second is called differential-mode coupling. This distinction is important, as the first class of common-mode coupling may be more easily handled to greatly attenuate the disturbance when the 2 conductors carry opposite signals ("differential signals"), whereas the second class of differential-mode coupling is much more difficult to deal with. In this last case, only frequency filtering is effective.

    RFI

    For higher frequencies and when the source and victim are separated by a large distance (typically more than a wavelength), both devices act as radio antennas: the source emits or radiates an electromagnetic...

    Read more »

  • Design Decisions: The Core

    Squonk4205/09/2018 at 11:56 2 comments

    Form Factor

    The main goal for the FunKey Zero project is to prototype the maximum number of features for our final #Keymu - open source keychain-sized gaming console  machine. The keychain form factor is the most limiting parameter: roughly, we determined that 4 cm x 4 cm x 1.5 cm were the maximum allowed dimensions to stay practical, which leaves just enough room to fit a 1.5" screen, not much larger. This rules out event the small Raspberry Pi Compute module (67.6 mm x 30 mm) or Zero (65 mm x 30 mm) as the core processor board for the project.

    Screen Resolution

    With a lot of tricks, it is possible to stuff some emulators with a 128 x 128 pixel resolution on an ESP32, for example, like the small PocketSprite.

    But based on our Edison Keymu experience, we determined that a 128 x 128 pixel resolution was barely acceptable to play some games with small fonts, so we tried to get a screen with a higher resolution, still fitting the 1.5" size.

    If you search well, you can find on AliBaba some screen in this form factor with a resolution of 320 x 320 pixels but unfortunately, to handle the large amount of data to display, they use a high speed differential serial, user-unfriendly interface called MIPI DSI (Display Serial Interface) requiring a specific controller, only available in high-end mobile phone CPUs :-(.

    We were lucky to find a nifty 240 x 240 pixel 1.5" screen with a simple SPI interface that is just perfect, which is now available at Adafruit.

    RAM

    However, a 240 x 240 pixel  in 24-bit RGB color image takes a little bit more than 168 KB of RAM memory to store in a frame buffer, which is out of reach for most Micro-Controller Units (MCUs), except for the largest one.

    Instead, we turned to bigger Central Processing Units (CPUs) with enough RAM memory, and if possible able to run a Linux OS in order to benefit from the existing software base, including already running game emulators.

    But this extra RAM comes at a price: to reach these capacities, you need to use Dynamic RAM (DRAM) instead of the Static RAM (SRAM) used in MCUs. These are generally provided as external chips, with high-speed bus connections, requiring extra-careful PCB layout and trace routing, not counting for the required real estate on the board.

    CPU with Integrated DRAM Memory

    Considering the Raspberry Pi, for most models, this DRAM complexity problem was solved using a clever technique called Package on Package (PoP), which consists in soldering the DRAM package on top of the CPU itself.

    Unfortunately, only a few chips outside the unreachable Broadcom CPUs used in the Raspberry Pi are using the same technique :-(

    We found Next Thing Co.'s GR8 chip which combines a 1GHz Allwinner R8 ARMv7 Cortex-A8 processor with NEON SIMD extensions and a Mali-400 GPU. 256MB of DDR3 SDRAM in a single 14 mm x 14 mm x 0.8 mm package. Hopefully, we only found it too late, as Next Thing Co. is now dead, RIP.

    Another option is the Octavo OSD335x-SM module which combines a 1GHz TI Sitara ARM Cortex-A8 AM335x processor and up to 1GB DDR3 memory into a slightly larger 21 mm x 21 mm x 3.08 mm package. This chip is used in the PocketBeagle. Sure, it contains almost all the required components, but it is about 1/4 of our total PCB area... More worrisome, this chip (like the GR8) is based on an older design ARM Cortex-A8, which has been superseded by the smaller, simpler and more power-efficient ARM Cortex-A7 in 2013. Be careful, the ARM version numbering is very confusing!

    We then discovered the Allwinner V3s chip wich combines a 1.2GHz ARM Cortex-A7 with NEON SIMD and VFPv4 extensions and 64MB DDR2 memory into a user-friendly 16 mm x 16 mm x 1.6 mm (including pins) LQFP128 package. No more worries regarding the power consumption, but now some concern...

    Read more »

  • Licenses & repositories

    Squonk4204/23/2018 at 08:40 0 comments

    The software released for the FunKey Zero project is licensed under the Gnu General Public License, version 2 or (at your option) any later option.

    This includes the material provided in our buildroot-licheepi-zero Github repository.

    The electronic hardware and mechanical design are released under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

  • Current state of things

    c.Invent04/22/2018 at 14:50 2 comments

    Hi everyone, many logs/files/links have been published in the last couple of days ! We’re very excited to be sharing all of this with you but we know it’s a lot of information, so if you are a bit lost and wondering the exact state of advancement of Funkey Zero this log is for you.

    Mechanical design and printing

    The mechanical design is done and tested. If you remember that Keymu was made with Solidworks, this time, we redesigned everything from stratch using Fusion 360. You can find the source files in the project links or here.

    We printed and tested the tolerances of our design using a Prusa i3 MK2 with a 0.1mm precision and a classic nozzle width of 0.4mm. Appart form the buttons which are still a bit too large, your prints should all fit together pretty easily. One precision though: we printed the top part in 2 halves, as well as the bottom part. See this log for more precisions. It is up to you to follow this method or not obviously but, believe us, it leads to pretty nice results.

    Electronics and Assembly

    Right now we have soldiered the essential parts : power management, screen, audio and debug pins. We have cut a hole in the bottom half of the case on order to let debug serial cables get in as you can see in this picture :

    The PCB/Case assembly went great:  for now there are no problems of tolerances, but we still have not put the snap domes and tested the buttons, so we’ll keep you updated.

    Regarding what’s been soldiered we had some minor issues for the screen and had to add a few cables, the power management part and the audio Jack work perfectly but not the speaker for now. It might be the soldiering itself or something else, we’ll have to dig a bit deeper but it should not be a serious issue.

    The BOM and schematics have been shared with you obviously, so if you want to join us in this debugging fun we’ll be more than happy to welcome you 😊

    Software side 

    On the sofware side of things, things are going pretty smoothly for now but we still have a lot of work.

    Boot time and Logo

    As you might know from our log "Linux Distribution", we developed our own linux distribution from the ground up for Funkey Zero and we are very proud to say that the boot time in under 3 seconds. It’s so fast we made a video for you to be able to believe us :

    As you can see we also added a boot logo, which is – for now – very simple and prone to evolve. But it’s still nice to be welcome by something else than a serial console.

    Usb mass storage

    Part of our new distribution is the possibility to connect Funkey Zero to any computer and it will be mounted as a USB mass storage device… basically a usb key. There is no easier way to transfer your roms than this :

    Optimized Emulators :

    Guys, having a 240x240 screen resolution is great. On Keymu the resolution was 128x128 and was acceptable but not very comfortable to play games such as Zelda or Pokemon in which you need to read a lot. This time, with Funkey Zero, the resolution is very comfortable, so even if our processor only has 64MB of RAM and a single core 1.2Ghz processor, we wanted to be able to make the most of it.

    Thanks to optimized emulators for ARM made mostly by notaz for the Pandora, we were able to re-adapt and re-build many emulators for our ARM v7 processor and our 240x240 resolution. We realized that once optimized, the V3S processor was actually a surprising powerhorse ! It even runs PS1 games at only 70% CPU load. And guys, oh what a pleasure to hear and see Final Fantasy IX running on this thing !!! Words are not enough, just watch :

    For the future, we plan to port many more emulators and the work is in fact already underway so stay tuned 😉

    TODO

    So… if in the video above you didnt see me playing it’s for a reason : the buttons and the whole button mapping interface is still under development....

    Read more »

  • Linux Distribution

    Squonk4204/21/2018 at 20:29 0 comments

    Distro Choices

    The AllWinner V3s and by extension the LicheePi Zero are designed to run Linux kernel-based operating systems, which includes both a distribution called "CamDroid" (a lightweight operating system based on Android) with a good support for MIPI cameras and H.264 video codecs, or more conventional Linux-based distributions, with a choice between an EmDebian or buildroot-based distribution.

    Camdroid

    We definitely discarded the CamDroid distro, as it requires the non-public AllWinner SDK to build which is  encumbered with closed-source blobs, as we don't need its specificities here. Moreover, support seems very difficult, as all that can be found is mainly in Chinese.

    Regarding plain Linux distros, there are some pre-built EmDebian and buildroot-based images with several build options (Xorg, gcc, Python, LXDE, minimal) available for download at https://licheepizero.us/.

    EmDebian

    Despite its attractive Debian-flavored facilities (well-known structure, number of available pre-built binary packages), we also discarded the EmDebian distro because:

    • This distro is dead: "As of July 2014, updates to the Emdebian distributions ceased. There will be no further updates and no further stable releases."
    • Even if it is tagged as "embedded", the resulting size is rather large for such a small amount of RAM
    • boot time is > 10 s

    Buildroot

    Thus, we turned to buildroot to provide our distro. "Buildroot is a simple, efficient and easy-to-use tool to generate embedded Linux systems through cross-compilation.". And this is really true:

    • its core infrastructure is just a few hundred lines of make code
    • it uses make code and kconfig for the configuration interface and language. Both technologies should be familiar to all embedded Linux developers
    • compiling the whole distro is fast and don't take hours, even when re-building the cross-toolchain from scratch
    • it is designed for small to medium sized embedded systems

    On the down side, there is no runtime package management system (dpkg, rpm) and complete rebuilds are often required...

    Linux Distro Dissection

    Actually, an embedded Linux distribution is not a single piece of firmware: a first consideration are the required tools that are running on the host or build system, as opposed to the software running on the target machine.

    Host

    In the case of buildroot, you have the core system which is made up of a few hundred lines of make code and kconfig scripts to run a simple menuconfig-like configuration interface. There are also a few required utilities that are built from their source tarball packages. But the piece of meat is the cross-toolchain that includes all the tools required to build executable software that will run on the target machine. With buildroot, you have the choice either to use a pre-built toolchain or build your own from scratch. Guess what we chose ;-)

    Target

    On the target side, each independent piece of software is called a package, and is made up of a small, mostly declarative makefile, some patches and the source tarball package that is fetch from the original package maintainer location. These packages are cross-compiled using tha above toolchain and put into a set of firmware images that are burned into the target machine.

    Even on the target machine, there are several distinct pieces of software that must be considered, described here in their boot order:

    Boot ROM (BROM)

    This one cannot be modified, as it is a read-only software that is first run upon boot-time. It is in charge of bringing up the minimum resources to startup the CPU. It also reads some GPIO inputs with either pull-up or pull-down resistors known as bootstrap configuration to select some operating options such as clock frequency, boot device, etc.

    Secondary Program...

    Read more »

  • Component Selection

    Squonk4204/21/2018 at 10:02 3 comments

    Like described in the project details, we decided to use the LicheePi Zero module as the core of our FunKey Zero device. As explained, this module features an AllWinner V3s SoC, which has just the right capacity for our purpose, and a minimum size because of its integrated DDR2 RAM:

    With a size of 44.65 mm x 25.53 mm x 8.00 mm, it is small enough for the FunKey Zero, but not for our final keymu device. It features a low power consumption and all the required peripheral that we need.

    Another very important part in our design is our small 1.5" LCD screen. It has an amazing 240 x 240 pixel resolution, while using a simple SPI-based interface and not a complex DSi interface based on the differential high-speed MIPI specification, which requires a dedicated controller that is only available in higher-end SoC:

    For audio playback, we wanted to have an internal speaker. But given the reduced dimensions, we tried to find the smallest available one, which has a very small 10 mm diameter, with a total height of 2.9 mm, out of which 1.4 mm can be inserted into a PCB hole, thus only having a height above PCB of 1.5 mm:

    We use a simple mono audio playback through a MAX97000DETB+ amplifier. This amp has all the required characteristics, but uses a non user-friendly DFN10 package, so we designed a special footprint with long pads to make it easier to solder.

    We also provided an external audio headphone connection using a standard TRRS 3.5 mm audio jack. We chose a mid-mount model, i.e. one which requires a cutout in the PCB. This way, we can "mask" its height into the PCB thickness, leaving only a 1.5 mm height below and above the 1.2 mm thick PCB:

    To keep the design as thin as possible, we found the best solution was not to use standard tactile switches, but to use tactile domes instead: with dimenions of 5.59mm x 4.19mm and a height of only 0.3mm, they only requires a copper area on the PCB and costs nothing:

    We also need some right-angled tactile switches for the rear left and right button, as well as for the recessed RESET button:

    We took the smallest we could get, but we may experiment with softer (no-click) ones for the rear buttons to bring a better play experience.

    We needed an ultra-small slide switch for the on/off function, here is the one we found, only 7.7mm x 3.5mm x 1.4mm, not counting the knob itself:

    We had to add a separate microUSB connector instead of using the LicheePi Zero built-in one, as we need to get access to its +5V pin in order to feed a LiPo battery charger circuit. We choose a common model with through-hole pins in order to avoid tearing it off the board if you don't pull the chord straight. 

    The LiPo battery charger chip is a standard MCP73812T-420I/OT, followed by an ideal diode made up of a P-MOSFET and a Schottky diode, like originally used in the OLIMEXINO-32U4 board. The ideal diode will allow charging the LiPo battery while the USB is connected by disconnecting the battery from the load, and reconnect it to the load when the USB chord is not connected. Clever, isn't it?

    The only remaining mechanical part is the small DF37NB-24DS-0.4V(51) connector, matching the LCD screen connector. It is a very fragile part that does not withstand too much heat from the soldering iron, so we designed a special footprint with as long as possible pads in order to solder it using the capillarity effect as much as possible.

    For debug, we features a 7-pin right-angle 2.54mm pitch header, compatible with standard FTDI cables while bringing some extra signals on non-essential pins and adding on extra pin.

    The only remaining active part is an N-MOSFET used to drive the screen backlight from a V3s GPIO pin.

    We made provision for TVS diodes on all user-accessible parts to prevent ESD, these are small 0402 TVS that can be optionally mounted, and a dedicated USB ESD protection a close as possible to the USB connector.

    All other parts are passive resistors, capacitors or ferrite beads in 0603 form factor, as we have a lot...

    Read more »

  • 3D-printed parts with no flat face

    Squonk4204/21/2018 at 09:11 2 comments

    3D printing is a great technology, allowing people to prototype 3D parts at a minimum cost.

    But like all technologies, 3D printing with a Fused deposition modeling (FDM) has its own limitations, different from other techniques to produce 3D parts, like plastic injection using a mold.

    One major drawback is that all parts must have a flat surface lying on the 3D printer bed, and overhangs cannot be too steep or bridges too long. This seriously limits what shapes you can obtain. Also support material is not always ideal, or easy to remove especially in such small and detailed prints. 

    In particular, it is not easy to get fancy enclosures for electronic devices like we need for the FunKey Zero project: as you can see, the casing has no flat surface, it has many fillets and holes outside, and ribs, bulkheads and standoffs inside. Of course, the enclosure needs to be split into 2 parts (top & bottom) in order to put the PCB inside, but still, each half of the case is still pretty complex on both of its sides.

    Moreover, we would like to get 3D-printing parts that are as close as possible to the equivalent achievable plastic-injected parts, in order to validate them before making an expensive mold.

    We used one technique that we did not see anywhere else for such a purpose: further cut each half of the enclosure shell top & bottom part into 2 sub-parts featuring a flat joint plane and glue them together. You can find similar techniques to 3D-print a horse body for example, but it looks like nobody had the idea to apply this to complex enclosures. We may try to get a patent from this idea ;-)

    Seriously, here is an example print for the FunKey Zero PCB assembly which is everything but flat:

    And here is how it is actually 3D-printed:

    You can then assemble the 2 halves using Loctite glue to obtain the final complex part while still respecting very precise dimensions. 

    We did the same for the top & bottom part of the enclosure, resulting in parts that have many details both inside and outside with no visible flat surface (the glued joint plane is almost invisible and with an added thickness so small it's indistinguishable).

    Let us know what you think of this idea and if this is helpful for your projects!

  • Screen is working!

    Squonk4204/20/2018 at 07:47 5 comments

    We got a design bug on the LCD PWM MOSFET: the LEDA signal was driven by the N-MOSFET source instead of sinking by tits drain. We had to cut 2 traces and the problem was fixed, the backlight started to work.

    But there is another problem with the LCD RESET signal, looks like it is not always pulled to VCC as it should. We may have to unsheathe the scope to debug.

    But at least, the LCD is working, as you can see!

View all 11 project logs

  • 1
    Soldering the LCD connector

    First solder the LCD connector J6 as it is delicate. Make sure to keep the soldering iron as far away as possible from the connector plastic body, as it melts very easily.

  • 2
    Soldering the audio amplifier

    Second, solder the audio amplifier chip U1 as it is rather difficult to solder too: it is a QFN10 package with a special footprint that should make things easier by using the capillarity effect

  • 3
    Soldering the speaker

    We recommend to solder the speaker SP1, directly onto the PCB.

View all 8 instructions

Enjoy this project?

Share

Discussions

RandyKC wrote 05/09/2018 at 16:37 point

I came for the game but stayed for the write up!

I really appreciate the time you’ve spent sharing your design decisions. Very instructive and appreciated!

Thank you.

  Are you sure? yes | no

Squonk42 wrote 05/10/2018 at 08:24 point

Thank you, we will try to publish more logs detailing the design, stay tuned!

  Are you sure? yes | no

DeanChu wrote 05/08/2018 at 05:16 point

This is amazing!!! I noticed allwinner v3s when I was trying to make my own retro gaming console as it is small and easy to use. But the spec of this chip seems insufficient for me because I have no experience optimizing emulators. At last I chose raspberry pi compute module 3 #RETRO-CM3: A POWERFUL RETROPIE HANDLED GAME CONSOL .

Really looking forward to the final release of this cool keychain. And I wonder if it is possible to get a copy of the developing version of your system because I am really interested to integrate the v3s chip and all the peripherals in a single PCB.

  Are you sure? yes | no

Squonk42 wrote 05/10/2018 at 08:23 point

Thank you @DeanChu, we noticed your project too, very interesting!

At 1.2GHz, the V3s has just the required power to emulate most of these retro games. What needs to be optimized is the display: most emulators are using the SDL library, and non-optimized 2D graphic operations rapidly bring the CPU to 100% usage... This is where you get the most benefit when optimizing the code, which generally consists in removing unnecessary copies and image resizing: unlike the Raspberry Pi, the v3s has no GPU, so all these operations are performed by the CPU and are very costly.

What do you mean by "developing version"? Hardware, software? We tried to provide as much as we can that is stable enough, but you are welcome to join the party! Let us know what you need.

  Are you sure? yes | no

DeanChu wrote 05/10/2018 at 09:08 point

Thank you for the reply, really helpful for me to understand how you unleash the potential of this tiny thing. 

And by "developing version" I mean a flashable .img which contains at least some emulator demos. Then I can start to layout and test of an "all in one" version pcb which will be open source for sure.

  Are you sure? yes | no

fabian wrote 04/24/2018 at 20:27 point

How I can play in tempest? is possible to run ruby on this machine? or mruby?

  Are you sure? yes | no

c.Invent wrote 04/27/2018 at 13:03 point

Hi Fabian, maybe tempest is ambitious ;) but there is no problem for installing ruby.

  Are you sure? yes | no

fabian wrote 04/27/2018 at 13:59 point

ruby game, nice ;-)

  Are you sure? yes | no

fabian wrote 04/27/2018 at 14:01 point

tempest need rotor potentiometer, or cilinder pad.https://en.wikipedia.org/wiki/Tempest_(video_game) tempest on normal button is very hard

  Are you sure? yes | no

c.Invent wrote 04/29/2018 at 09:04 point

Oh you meant this version of tempest ? Then yes there will definitely be an Atari emulator on Funkey Zero!

  Are you sure? yes | no

ꝺeshipu wrote 04/20/2018 at 10:57 point

By the way, I would absolutely love to read more about the design decisions you made there. I can see some very interesting approaches with the pcb cutouts — I suppose your goal was to make it as thin as possible?

  Are you sure? yes | no

Squonk42 wrote 04/20/2018 at 19:51 point

Yes, this is one of our main design goal.

As this device is really a "concept toy" for our tiny (42x46x17mm) #Keymu - open source keychain-sized gaming console, we wanted to test some key software, electronic and mechanical features for the final design. Making it as thin as possible is very important, and enables us to test the tactile dome switches, the RR/RL right-angle button switches, the LCD and connectors, the mid-mount audio jack whose height is partially masked by the PCB thickness and of course the battery

  Are you sure? yes | no

Squonk42 wrote 04/20/2018 at 07:54 point

Thank you!

  Are you sure? yes | no

davedarko wrote 04/20/2018 at 07:33 point

this really is quite a cute console you have there! :)

  Are you sure? yes | no

c.Invent wrote 04/20/2018 at 08:36 point

Thanks davedarko, coming from the Fameboy maker this comment  carries a lot of weight!

  Are you sure? yes | no

davedarko wrote 04/20/2018 at 08:41 point

hehe thanks :) #FAME BOY is far from perfect, lot of stuff needs work but I'm proud of the concept. you have a nice board design and concept, looks pretty neat and I'm looking forward to see more! Good luck!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates