Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
projecttin [2016/03/07 18:21] zashi |
projecttin [2016/05/23 17:10] 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> | + | MSP430 Galore! |
| + | |||
| + | 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. | ||
| + | |||
| + | 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. | ||
| - | <del>* OLED screen | ||
| - | * 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 | ||
| - | * The 5-way switch and Two buttons | ||
| - | </del> | ||
| === USB Components === | === USB Components === | ||
| Line 71: | Line 74: | ||
| == 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 85: | ||
| - | |||
| - | == == | ||
| ===== Software ===== | ===== Software ===== | ||
| Line 98: | Line 99: | ||
| ==== 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 118: | ||
| 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 === | ||
