Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
projecttin [2016/03/07 18:21] zashi |
projecttin [2016/05/23 18:33] (current) zashi |
||
---|---|---|---|
Line 3: | Line 3: | ||
Decided I wanted a programmable pocket computer. Something that fits in a tin and runs off a battery. Something I can use to cause all sortsa mischief. | Decided I wanted a programmable pocket computer. Something that fits in a tin and runs off a battery. Something I can use to cause all sortsa mischief. | ||
+ | |||
+ | |||
===== Use Cases ===== | ===== Use Cases ===== | ||
Line 42: | Line 44: | ||
Obviously, the R-pi is the main component. Along with it is the custom built add-on board that connects directly to the R-pi's main header. On the custom add-on board is: | Obviously, the R-pi is the main component. Along with it is the custom built add-on board that connects directly to the R-pi's main header. On the custom add-on board is: | ||
- | * Power Regulation Circuit | + | New Plan: |
- | * This takes power from the 9v battery and efficiently puts out a clean 5 volts. Built using the LM2675-N-50, it has a few (annoyingly large) discrete componets, including an inductor a schotkey diode, and 3 capacitors. Test runs have shown (without any mind to power saving in software) at least 2 hours of run time on the 600 mAh rechargable 9v batteries I have. I absolutely expect this to improve as I tweak the software for power savings. | + | |
- | * <html><iframe class="imgur-album" width="100%" height="550" frameborder="0" src="//imgur.com/a/nf46l/embed?background=ffffff&text=000000&link=4e76c9"></iframe></html> | + | |
- | <del>* OLED screen | + | MSP430 Galore! |
- | * This is mostly mounted here for convenience. It could (and may still) simply be mounted to the case with a few wires (Vcc, GND, SDA,SCL) running to the add-on board. | + | |
- | * Input Devices | + | An MSP430 will be used as to essentially implement ACPI. A lithium ion battery with support (charging) circuitry will power everything (at 3.3V). An MSP connected to the R-Pi via SPI will actuate either a mosfet or a solid-state relay to switch power on and off to the R-Pi. The R-Pi can tell the MSP to power off or a button connected to one of the MSP's GPIO pins can actuate it. The Pi can schedule a wake up time. |
- | * The 5-way switch and Two buttons | + | |
- | </del> | + | Assuming the MSP is not too busy, it will also act as an RTC, communication also via SPI. The Pi can send a command to write the time to the pi and send a command to read the time. Time is stored as a 32-bit unsigned int (uint32_t). The MSP's normal operation is to go into low power mode LPM3 or LPM4. The ACLK, wired to a 32khz crystal keeps track of the time. Every second the MSP wakes, increments it's time, then goes back to sleep. |
+ | |||
+ | The MSP also takes input from the various other buttons (probably gameboy style, d-pad and buttons) and sends them to the Pi via SPI. This frees up the Pi's pins so it can talk to peripherals directly. | ||
+ | |||
+ | At Boot, the MSP also displays a splash screen on the nokia display (so as to acknowledge boot/power on, since the pi takes several seconds to boot). | ||
=== USB Components === | === USB Components === | ||
Line 71: | Line 75: | ||
== Sound Card == | == Sound Card == | ||
- | I definitely want and need a usb sound card. This is to provide a mic-input as well as a second audio out. I'll either make the onboard audio or the usb audio connect to a small speaker that can be driven via line-level audio (if this is too quiet, I may fashion a small class A or B audio amp circuit). | + | I definitely want and need a usb sound card. This is to provide a mic-input as well as a second audio out. I'll either make the on board audio or the usb audio connect to a small speaker that can be driven via line-level audio (if this is too quiet, I may fashion a small class A or B audio amp circuit). |
The sound card will allow the FEK to do audio munging via SOX (can act as voice changer) as well as take analog audio input and transmit it. I may do 2 usb sound cards. one for a permanently affixed speaker and mic and one for auxiliary inputs. | The sound card will allow the FEK to do audio munging via SOX (can act as voice changer) as well as take analog audio input and transmit it. I may do 2 usb sound cards. one for a permanently affixed speaker and mic and one for auxiliary inputs. | ||
Line 82: | Line 86: | ||
- | |||
- | == == | ||
===== Software ===== | ===== Software ===== | ||
Line 98: | Line 100: | ||
==== Display ==== | ==== Display ==== | ||
+ | <del> | ||
I'm using an OLED display ran using an SSD1306 driver chip. There is a linux driver to utilize this screen as a framebuffer device: http://lxr.free-electrons.com/source/drivers/video/fbdev/ssd1307fb.c | I'm using an OLED display ran using an SSD1306 driver chip. There is a linux driver to utilize this screen as a framebuffer device: http://lxr.free-electrons.com/source/drivers/video/fbdev/ssd1307fb.c | ||
+ | </del> | ||
- | === Stack === | + | I'm using a nokia display with a PCD8544 controller. |
- | + | ||
- | - SSD1307fb.c driver to implement as a /dev/fbX device | + | |
- | - <del>Run Xorg with directFB driver to point to /dev/fbX/</del> | + | |
- | * ''export FRAMEBUFFER=/dev/fb1 startx'' | + | |
- | - Tk can run directly (no Window Manager needed) under X, fullscreen. | + | |
- | * (Tcl/Tk will be the main interface driver, it will lunch sub-programs) | + | |
- | + | ||
- | === Update === | + | |
- | + | ||
- | [[http://www.androwish.org/|AndroWish]] distributes an SDL2 library and sdl2wish application! No X server is needed now! Tk is displayed using SDL. SDL is rendered using directfb. The kernel provides an framebuffer interface to the OLED display. | + | |
- | + | ||
- | === Update 2 === | + | |
- | + | ||
- | After all the trouble trying to get that OLED screen to work, and given the cramped conditions of the case, I've decided to make the FEK a headless-device: no screen or buttons on it. Interactions will occur via an ethernet connection. Either through the 10/100 port or via an ad-hoc wifi connection. The principal interface device will be a smart phone that can connect to it via ssh or via VNC. | + | |
==== pikeyd ==== | ==== pikeyd ==== | ||
Line 129: | Line 119: | ||
Because archlinux is designed to work with systemd-udevd (which uses netlink for communication), the kernels are compiled without the old style ''/proc/sys/kernel/hotplug'' or slightly newer ''/sys/kernel/uevent_helper''. So I adapted some sample code from the kernel to make a wrapper for busybox's mdev so hotplug events reported via netlink can be passed to mdev. | Because archlinux is designed to work with systemd-udevd (which uses netlink for communication), the kernels are compiled without the old style ''/proc/sys/kernel/hotplug'' or slightly newer ''/sys/kernel/uevent_helper''. So I adapted some sample code from the kernel to make a wrapper for busybox's mdev so hotplug events reported via netlink can be passed to mdev. | ||
+ | |||
+ | This may be unnecessary since I'm also using devtmpfs. | ||
=== Steps === | === Steps === |