Close
0%
0%

raspberry pi zero handheld computer

Since rpi zero is unobtainum, I got a few.

Similar projects worth following
This is handheld autonomous computer running on Raspberry Pi Zero. First version is kind of finished and running, now I'm thinking of something better.

Project A

This is computer in brick-like form factor, resembling overgrown calculator.

It contains Raspberry Pi Zero inside, plus WiFi module, some power management. It has 320x240 TFT as display, 4x4 keyboard as input device and analog joystick as pointing device. Along with that two full-size USB A connectors, one 3,5mm jack for headphones and 2x6 pni 0,1" header with some PGIO of RPi Zero broken out. The keyboard and "trackpad" interface si very spartan, but it's included all in single enclosure and gives the rudimentary means of controlling the device. External keyboard or mouse is possible to increase user comfort, but not needed.
It sports Raspbian Linux, with all the software you can run in 320x240 display.

Project B

This is still under development. It will have larger display and qwerty keyboard.


FAQ:
Q: How is this better than my phone/tablet/smart toaster?
A: If you need to ask this question, then it isn't any better.

BOM.xlsx

BOM

sheet - 14.12 kB - 07/25/2017 at 08:10

Download

2i.sch.pdf

Schematics

Adobe Portable Document Format - 66.42 kB - 07/25/2017 at 08:10

Preview
Download

proj_A.zip

Complete package

x-zip-compressed - 38.12 MB - 07/25/2017 at 08:09

Download

  • Project B

    jaromir.sukuba09/24/2017 at 08:25 0 comments

    While drawing first sketches of my overgrown calculator computer, it was clear I will not finish here. I thought of having something slightly bigger, with better display and full-blown QWERTY keyboard. As it still belongs to RPi zero handheld computer, I decided to call this project B, while first one is project A.

    I think the biggest limitation of project A is its display - while being small and relatively low power, 320x240 will not cut it for many GUI applications. I took a look around and it's not easy to find SPI displays of higher resolution and I'm not surprised by this. The amount of data required to refresh such as amount of pixels would be outside the reach of SPI transfer; leading to either high SPI clocks, or slow refresh. Most of displays with higher pixel resolution are having parallel interface; the cheaper ones without any controller. This is called DPI interface and the LCD is designed to be fed with constant stream of data, just like scanned television or VGA monitors, with both horizontal and vertical synchronization pulses. Fortunately RPi do contain DPI controller and it can be enabled and used.

    The better part of display being "dumb" is that displays are mostly interchangeable and one is not limited in choice of particular controller. They have even mostly the same connector with the same pinout. I opted for 5" 800x480 LCD module from tme.eu and made simple breakout board for it, taking inspiration from TFT friend by adafruit. It contains nothing but step-up converter for backlight and single resistor in series with pixel clock line, to decrease slew rate and possible ringing on this fast and long PCB trace. After a bit of playing with overlays and config.txt in /boot directory I got it working relatively painlessly and the result is great. In fact, it looks crispier in reality compared to relatively dull colors on photographs.

    There is really nothing but single resistor on bottom side

    NoThe whole setup takes approximately 1,5 Watts during run. It could be lower, but this is still manageable

    Now I'm in the process of adding keyboard and pointing device to this - not the joystick I had on project A, but touchpad. This is going to be non trivial process, as most of the GPIO pins are taken by DPI interface and this time I don't want to run everything from internal USB. Stay tuned.

  • Howto, github update

    jaromir.sukuba07/25/2017 at 08:16 0 comments

    I updated my github repository and added some comments to readme file

    Notice also https://github.com/jaromir-sukuba/pi_zero_computer/blob/master/other/howto file describing steps to make the device running from vanilla Raspbian Image.

    I also uploaded design files here on hackaday, in single big package. BOM and schematics are also separately, for easy viewing of those files.

  • Modus operandi

    jaromir.sukuba07/24/2017 at 11:59 0 comments

    As I wrote in FAQ - if you need to ask what is this project for, you probably don't need it. I build it for my own enjoyment during design and build, as well as machine to allow me to better learn programming/scripting languages (and to listen to my favorite tunes while doing so) and as ultimate nerd status symbol to carry around.

    What about browsing hackaday on lynx?

    Chromium works here too, but due to small display it isn't very enjoyable to use.
    With SDCC and stm8flash I can edit, build and upload firmware on STM8 targets

    or on arduino platform

    I believe STM32 targets should work too, as well as PIC devices, using my programmer. Here you can see nano editor, editing my code to talk with STM32L011 MCU onboard, reporting battery voltage.

    Oh and don't forget to backups. Here is my take on SD card backup system.

  • Project A, kind of finished

    jaromir.sukuba07/24/2017 at 11:38 0 comments

    Well, I lied, because projects like this one are never actually finished. But let's say I'm not going to do any major rework from now.

    It took one more board revision and a little bit of coding to come up with final hardware

    In the meantime, I made some minor changes to circuit, but the overall concept was still the same. Complete schematics is here https://github.com/jaromir-sukuba/pi_zero_computer/blob/master/hw/2i.sch.pdf but for sake of simplicity here you have hand drawn block diagram

    Heart of the device is Raspberry Pi Zero. The power is delivered from two LiPo cells in series, MCP73844 acting as charging IC and three TPS562200 are performing DC/DC down conversion to get three voltages:
    * 5V for RPi
    * 5V for USB
    * 3,3V for WiFi

    All of them are individually switchable from the STM32L011 and this is under RPi control via serial interface (native serial port of RPi), the STM can also report status of battery and charging controller. The STM32L011 itself is always powered via MCP1700 voltage regulator. Power consumption of the device in sleep mode is approximately 10uA.

    Since RPi has only one USB port, I used FE1.1s USB hub IC to have USB WiFi RTL8188EUS module and USB keyboard/mouse devices along with two general purpose USB ports.

    STM32F072 interacts with all tactile user IO (keyboard, joystick, mouse buttons) and acts as USB HID device for RPi, with interfaces to both keyboard and mouse. Since having 4x4 matrix keyboard (reasons why I opted for this keyboard are here and here) obviously brings some complications compared to full-blown 104 key keyboard, so I had to be a bit creative about the key combinations assignment. The bottom row keys act as modifier keys, but after a bit of trying, it is not that hard to remember.

    Gray keys denote pressed modifier keys. With no modifier keys pressed, you have to top layout - press key 7 once, you get 'p', press one more within 800ms, you get 'q', then 'r', then 's'. For special characters, press first modifier keys. I tried to arrange them in some logical manner, grouping related characters, like parenthesis or +-* symbols. For running executables in bash, press left modifier, hit first and second button, this types ./, then name of executable (using tab key saves you some typing). Forethink the executable filenames at least a bit and you can run most of them in a few key hits.
    User interface is completed by TFT, with ILI9341 controller. It can be bought through usual Asian sources. There is nothing special about it, interfacing this kind of display has been done to death.
    Audio is quite straightforward - the RC lowpass filter is no surprise to RPi users, TDA1308 acting as headphone amplifier is jelly-bean component, in intended application.
    Enclosure is 3D printed, in three parts and is designed to keep the whole package together using 4 pieces of M2,5 screws

    Threaded inserts are used to keep everything in place and to allow repeated teardown of the case, so much needed when tinkering with the device. Self tapered screws would be easier, but not as reliable choice here.

    Overall dimensions are 16,3x7,3x2cm

    Should have used BananaPi for scale, but RPi 3 should do the job too.

  • Project A, how it started

    jaromir.sukuba03/24/2017 at 18:02 0 comments

    Intro

    I decided to make two different portable computers with raspberry pi zero: one would have low-end user interface, perhaps low price and dimensions; another one with bigger display and keyboard, somehow resembling smaller laptop PC.

    Project A is the smaller one. A lot of work has been done, but I couldn't find time to write logs here, so this is somehow retrospective description of how I did the design process. I also included some photos of prototype, to attract you to future logs ;-)

    Project A, motivation

    The project has to fit those constraints:

    - raspberry pi zero as main processing unit

    - at least 320x240 pixels LCD

    - some form of keyboard and

    - some form of pointing device to allow handheld use

    - at least one USB 2.0 interface, with A type connector

    - on/off switchable via single button, negligible current draw when off

    - no touchscreens

    - easy to source components

    The last one is more difficult than it may look. Internet is not short of various displays and especially keyboard connected to all forms of whatever-pi class computers, but those are often gutted Chinese consumer items, like Xbox chatpad containing and PIC device back in the day, but nothing but asphalt blob on newer ones. While the difference is next to none for average consumer, it can be dealbreaker for open-source project, prepared for others folks to reproduce and build upon. So I want to build the thing using basic and obtainable components, available from multiple sources.

    Implementation

    The main limiting factors for overall dimensions of the device is the size of user IO - display, keyboard, pointing device, so I have to choose those ones first.

    For display I experimented with PAL/NTSC displays from Chinese sources, designed for parking camera in your car. While perhaps usable for its intended purpose, it doesn't fit very much the "availability point" above and the picture quality leaves a lot to be desired, not to mention the fact the analog/digital interface takes a lot of current, what is a problem for portable battery powered gadget. The only real option here is digital interface. Another usual suspect is HDMI, but the connector is bulky, interface takes a lot of valuable juice too and brings price higher. Those two options don't require any configuration nor programming, so being more hardware than software oriented guy, I have to resort for "more complicated" methods (though being quite easy, in fact). I took inspiration from #Portable Raspberry PI Zero and bought some ILI9341 TFTs.

    I ended up having three different sizes - 2,2", 2,4" and 2,8", all being electrically the same. The 2,2" is most common and cheapest of the three. The former ones are somehow more expensive, but the size of display is IMHO good fit for this project, especially in 2,8" variant. I debugged the interface on Raspberry pi 3, easy to use for it's populated 0,1" header and Ethernet interface for headless access.

    Keyboard is problem as usual. Calling @davedarko as reference for second time, I'm not the only one having this problem. See me reply in here for some more background info. Long story short, I decided to use the same keyboard as on my #Pavapro - portable AVR programmer project. It is available locally and through Asian suppliers and seems to be more-less jellybean part.

    For pointing device, I opted for joystick, moving mouse cursor in similar way as pointing stick on some notebook computers. After a long search, I decided to use joystick designed to be replacement part of PSP1000 and others. While it is exception to the "availability rule", it is available in huge amounts from a lot of sources, including local ones, so - while not being particularly happy about it - I had to accept it as solution. It's dimensions and electric interface are well defined, so future replacements will be good fit too.

    Having, the main parts identified, I had to arrange it somehow. I thought of three different variants:

    1, Display on top, keyboard left and joystick right

    2, Landscape...

    Read more »

  • First log

    jaromir.sukuba01/14/2017 at 23:15 0 comments

    I actually started this project in november or so, but haven't got myself to write something about it. Then, 1kB contest appeared and I was busy by squeezing as much code into 1024B as possible, so 1GB memory rpi zero received only little of my interest.

    I made board hosting rpi zero, USB hub, USB Wi-Fi module, two USB A ports, audio filter and amplifier for headphones, power supplies for all the goodies and microcontroller to control it all.

    Honestly, I'm not exactly sure why I opted for USB WiFi module instead of ESP8266

    Battery is two 18650 cells in series, here is charging/switching circuit for it. In bottom right corner is 5V DC/DC supply for USB. There are two more DC/DC supplies - 5V for rpi, 3,3V for WiFi.

    Display is 4,3" composite input. The picture quality is not good at all. Higher contrast transitions are blurry and display is leaving "ghosts", look

    leaving the window here for a minute or so and hiding it

    By the way, the original display was more than poorly made. It's internal regulator was set to 4V, supply voltage for display controller was dropped by serial resistor. The worst crap I've ever seen. Resistor wasn't dropping enough, chip got 3,6V and overheated, drawing too much current. The DC/DC converter for backlight was fed via another dropping resistor, decreasing its efficiency. Replacing the series resistor by proper 3,3V regulator and letting the DC/DC fly by removing its resistor, I saved approximately one third of display power consumption. Another saving could be introduced by replacing LDO by switching DC/DC, but probably I will not go this way, as the composite output is really poor.

    Ther

    There is also PIC16LF1526 on board, running always from its own low-power linear regulator, drawing 2uA when idle.

    Its tasks are: turning other power rails on and off, scanning keyboard even when rpi is off, doing keyboard interface to rpi, measuring power supplies. Currently it just turns the supplies on and idles forever.

    This thing isn't doing anything exciting right now, is incomplete, but will serve as guinea pig for another experiments.

View all 6 project logs

Enjoy this project?

Share

Discussions

J0K3RS-L4UGH wrote 08/31/2022 at 16:15 point

Is this being sold anywhere?

  Are you sure? yes | no

teraz wrote 01/06/2022 at 16:39 point

I search a computer for a week working time on one charge (or month)

  Are you sure? yes | no

Wenting Zhang wrote 01/16/2017 at 16:30 point

Hi nice project! Is that big FPC connector reserved for the keyboard? Composite video is of really poor quality even with a great display so I would recommend abandon it. Actually I have a similar project based on Raspberry Pi Zero, USB Hub, Microcontroller, and a LCD. I connected the LCD to Raspberry Pi's DigitalPixelInterface(DPI), and the image is just crisp and sharp with a resolution of 640*480. I think DPI can transfer image up to 1024*768@60Hz with no problem. Another advantage of DPI is that it doesn't require any decoding chip like composite or HDMI. DPI is the native interface of many LCD panels (I believe including the one you are currently using), directly connect the signal from Raspberry's GPIO to raw LCD panel and it's done. Of course, DPI is GPU accelerated just like composite and HDMI, it doesn't require extra CPU time to display. (I mean, in contrast, SPI or I80 screens like Adafruit 2.2 LCD would require CPU time to just transfer the data, it's just inefficient.) You probably want to try that out.

  Are you sure? yes | no

jaromir.sukuba wrote 01/16/2017 at 22:40 point

Thanks.

Yes, the FPC is for keyboard.

I feel like digitally-interfaced displays are the only usable way to go. Currently I'm playing with 320x240 ILI9341 TFT - and the picture is sharp and clean, as expected from digital transfer. It is connected via SPI and AFAIK it uses DMA, so it shouldn't be *very much* CPU clock hungry, or at least I can't see any obvious performance drop. I'm almost happy about it, just the resolution and size is bad. Something like 4-5" and minimally 450 horizontal and 300 vertical pixels are really needed. Some dialog windows are just unusable.

I know there is possibility of DPI connection, but it takes a lot of GPIO pins - https://www.raspberrypi.org/documentation/hardware/raspberrypi/dpi/README.md But for basic 5-6-5 it should be workaround-able. When looking for DPI displays, is there something to be careful about? Some caveats? Perhaps I can reuse the LCD in composite screen, throwing away converter IC and accessing digital signals directly.

That your project is this one? https://hackaday.io/project/19412-pibor-zero I'll take a look at it. 

  Are you sure? yes | no

Wenting Zhang wrote 01/16/2017 at 23:19 point

Yes, that's my project. SPI with DMA won't eat up much CPU time. I used to use one without DMA, it was just slow. There are some SPI screens have a resolution of 480*320 and a size of 3.5", probably they can do the job. As for DPI screens, the first thing to mention is that some display need to be initialized via SPI before it can display normally (while some screens don't). The one I used require this, so I connected its SPI to a dedicated micro-controller. Most common DPI screens are 4.3" 480*272 40pins one and 5.0" 800*480 40pins one. These two do not require SPI configuration. There are also 3.97" 800*480 DPI TFTs available on Aliexpress, they usually require SPI configuration. The second thing to mention is that, Raspberry Pi's DPI now requires a minimum pixel clock of 32MHz (it used to be 16MHz). It is just too high so if you are connecting your screen with like breadboard, you are probably not gonna to see the image at all. A PCB is required to even just test.

  Are you sure? yes | no

Craig Hissett wrote 01/15/2017 at 09:25 point

Great start man!

It already looks like a great development board, but it will make a great little netbook; can't wait to see how the case development takes shape!

  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