I THINK ∴ I'M DANGEROUS

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Last revision Both sides next revision
projecttin [2016/05/23 16:52]
zashi
projecttin [2016/05/23 17:10]
zashi
Line 50: Line 50:
 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. 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.+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 and sends them to the Pi via SPI. +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>​ +
-  * Power Regulation Circuit +
-    * 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 haveI 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>​ +
- +
-  * 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> ​+
  
  
Line 89: 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 100: Line 85:
  
  
- 
-==  == 
  
 ===== Software ===== ===== Software =====
Line 116: 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'using a nokia display ​with 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 smart phone that can connect to it via ssh or via VNC.+
  
 ==== pikeyd ==== ==== pikeyd ====
Line 147: 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 ===