Dec 19th, 2013 - Brought a powered USB hub from work to allow keyboard/mouse and USB wifi adapter to be used at same time. Also using it to power the rpi. - Got wireless adapter working: http://databoyz.wordpress.com/tag/how-to-setup-network-and-wpa_supplicant-conf-file-on-raspberry-pi/ - Installed fbtft drivers: https://github.com/notro/fbtft/wiki#install - Wired ili9340 display: https://github.com/notro/fbtft/wiki/LCD-Modules#adafruit-22 My display isn't the Adafruit one, but it appears to be compatible. - Tried enabling display with sudo modprobe fbtft_device name=adafruit22 Didn't work: noticed in the dmesg output that reported resolution was wrong. This driver is apparently for the old version of the 2.2" Adafruit display. Dec 20th, 2013 - Display is working! Enabled with sudo modprobe fbtft_device name=adafruit22a And it worked perfectly! Ran X windows with FRAMEBUFFER=/dev/fb1 startx and it ran! Framerate seems pretty reasonable. - Started enclosure design in LibreCad: plate.dxf is the outline of the top/bottom plates with (I think) correctly-sized holes for the 6-32 screws that will secure the standoffs. - Ordered board mounts from Adafruit - these are basically standoffs that have slots that fit the edge of a PC board. The Rpi doesn't really have mounting holes as such, so these seem to be the best way to fasten the Rpi to the bottom plate. Dec 21st, 2013 - Ordered .25"x1" hex 6-32 F/F standoffs from Ebay. (25 for $8 with free shipping!) Plan is that 4 of these will connect the plates to each other. The Rpi will be attached to the bottom plate and the display and buttons will be attached to the top plate. - Changed enclosure drawing to make plates 127mm x 77mm: this is 5"x3" (actually slightly more than 3"). This will leave some room for attaching the board mounts for the pi: 5"x2.5" (my original dimensions) would have the edges of the Rpi right at the edge of the plates in the long dimension, leaving no space for the board mounts. Dec 22nd, 2013 - Redoing enclosure design to see if I can make it work with the top and bottom plates being 69mm (2.75") in the narrow dimension. This is to try to take advantage of the following laser cutting service: http://www.spikenzielabs.com/Catalog/index.php?main_page=product_info&cPath=13&products_id=22 $20 for arbitrary cuts on a 5.5"x5.5" sheet of 1/8" acrylic. - Just found out that the CAD drawing (of the RPi outline) was a BOTTOM VIEW. Sigh. - Found out that the official PCB dimensions are 85mm x 56.2mm. Also, according to http://www.raspberrypi.org/archives/tag/mounting-holes the mounting hole locations are at x=25.5mm, y=18.0mm and x=80.1mm, y=43.6mm, relative to the bottom left corner. Updated plate.dxf to reflect this. - The mounting holes are meant to accept M2.5 screws. Ordered from Ebay: - 25x 6mm nylon M2.5 M/F standoffs - 25x M2.5 nylon nuts - 50x M2.5 8mm screws The idea is that the female part of the standoff will be attached to the bottom plate with the 8mm screw, and that the PCB itself will be attached by fastening the nut to the male part of the standoff. Since the standoffs and nuts are nylon, hopefully this will make it less likely to damage the PCB (than metal fasteners would be). The acrylic will be 1/8", which is 3.175mm. This should mean that a bit less than 4mm of the screw will be screwed into the female part of the standoff, which seems reasonable. - The standoffs are 6mm, while the board mounts are .25", which is about 6.4mm. I'm hoping that the .4mm won't make a big difference. If it is an issue, probably I can put a washer between the standoff and the plate to give it a bit of extra height. Dec 23rd, 2013 - Did a CAD drawing of the LCD. Added it to plate.dxf. Discovered that the only way that both the LCD and buttons PCB will fit is if the the LCD is vertical. The LCD fits quite nicely that way, and makes better use of the available space. - Started a CAD drawing of the buttons PCB, and discovered that the 5cm x 7cm protoboard I ordered previously will not fit, either horizontally or vertically. Horizontally, 5cm is too wide to fit between the standoffs. Vertically, 7cm would cause the PCB to stick out from the top plate on one or both sides. Ordered some 4cm x 6cm protoboards from Ebay (from Colorado, they will probably arrive sooner than the 5x7 ones from China). - Added a preliminary button PCB board outline and guess at screw hole locations and sizes to plate.dxf. When the PCB and buttons arrive I will need to come up with some kind of accurate drawing. The 4cm x 6cm size does fit very nicely in a horizontal orientation. Probably only two rows of buttons will be possible, so maybe 2 rows by 3 columns. Should fit and hopefully also leave room for the debouncing circuit. - Ordered some stuff from allelectronics.com: * caps and resistor networks for debounce circuit * 2x13 (26 pin) female IDC headers (for connecting to RPi GPIO header) * 5" 8x1 jumpers * 1.375" 6-32 F/F standoffs (in case the 1" ones don't leave enough room between the top and bottom plates) - Had an idea for the wiring: could the wires from the 8x1 jumpers be crimped directly into the 2x13 IDC header, making connections to arbitrary pins? That would hugely simplify the wiring: the LCD and button board could simply receive connections via a standard 8x1 header (the LCD already has one, could easily solder one on the button PCB.) 8 pins is perfect for VCC, GND, and 1 signal for each of the 6 buttons. Dec 24th, 2013 - Dec 31st, 2013 - Created initial version of software: using ncurses for the UI, but making the models/controllers completely independent of the views so ports to other UI toolkits will be possible. Started by implementing a music player using mpg321 and ogg123 via the remote control interface as a back end. Works fairly well for mp3 playback, ogg playback needs some work because ogg123 doesn't really implement the remote control interface fully. - Pushed repo to github: https://github.com/daveho/carpi - Ordered square pushbuttons from Adafruit: the ones I ordered from Ebay haven't arrived. This is the problem with ordering parts from China: you don't know whether the parts will arrive in a timely manner (or at all). Jan 1st, 2014 - Idea: use attiny2313 to debounce pushbuttons. This should greatly simplify the pushbutton circuit (no resistors/caps needed). The datasheet says it can run from 3V, and this should allow signal compatibility with the RPi. - Started program to run on attiny2313 to do the button debouncing. - Allocating RPi GPIO pins for button inputs: * Button 1: GPIO2 (P1-3) * Button 2: GPIO3 (P1-5) * Button 3: GPIO4 (P1-7) * Button 4: GPIO17 (P1-11) * Button 5: GPIO27 (P1-13) * Button 6: GPIO22 (P1-15) [Pins used by LCD: GPIO18, SCLK, MOSI, CE0, GPIO25, GPIO24] Jan 2nd, 2014 - Used Eagle CAD to capture the pushbutton circuit and design a PCB for it. My plan is to have the PCB made at OSHPark.com (they purchased batchpcb.com, and seem to have a very similar service). First I will test the circuit (and the firmware) on a breadboard. - Built the circuit on the breadboard, with some bugfixes the firmware works fine. Jan 3rd, 2014 - I got the placement of the buttons wrong on the PCB (it was kind of hard to visualize because the board will be mounted upside down.) Rather than re-routing, I just changed the schematic and the firmware to reflect the button placement. No biggie. - Made various tweaks to the PCB. In particular, made it just a bit bigger so the standoffs are a reasonable distance from the cutout in the top plate that will provide access to the buttons. - Ordered PCBs from OSHPark - 3 boards for about $20. - Did plate drawings and a combined top/bottom plate drawing, purchased the Mini Cut service ($20) from SpikenzieLabs, sent them my drawing. Hopefully it's OK - I used pretty much all of the available area. Jan 4th, 2014 - Preliminary implementation of playing videos using omxplayer. Since omxplayer only exists on the RPi, I can't actually test this on my laptop. I've reached the point where I will need to do development on the RPi itself! Jan 5th, 2014 - Refactored button debouncing firmware to be driven by a timer interrupt, and to enter low power mode between interrupts. Seems to work: might be interesting to measure the current draw. The RPi is supposed to be able to source about 50 mA: the attiny2313 should need much, much less than that. Jan 6th, 2014 - Connected the button circuit to the RPi. First, just connected 3.3V power to the attiny2313 and verified that the button outputs changed voltage appropriately when the buttons were pressed. Next, connected the button outputs to the assigned GPIO pins on the RPi. Unfortunately, there is a problem: when PD2 (button 5 output) is connected to GPIO (P1-5) 3 on the RPi, it does not boot successfully. The failure mode is that the video mode is set incorrectly (looks like standard VGA resolution rather than the full 1280x1024 supported by the monitor I'm using), and the boot hangs after enumerating USB devices. The problem appears to be on the RPi side: if any output is connected to GPIO 3, the RPi doesn't boot. With some experimentation, it appears that GPIO 23 (P1-16) doesn't cause the same problem. So, when the button PCBs arrive, I'll need to cut the connection to P1-5 on the RPi header and jumper PD2 to P1-16. Could be worse, I suppose. - Good news! Discovered that GPIO3 (SCL) causes the RPi to boot in safe mode when pulled to ground, which is what the attiny2313 outputs when button 5 is not pressed. Adding "avoid_safe_mode=1" to /boot/config.txt allows the RPi to boot normally. Sweet. No changes should be necessary to the button PCB after all. Here's the documentation of this behavior: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=27457 http://elinux.org/RPI_safe_mode - Idle thought: if the attiny2313 used 0=pressed, 1=not pressed for the button outputs, we wouldn't need avoid_safe_mode=1, and as a bonus, pressing button 5 on power-up would cause the RPi to boot in safe mode. Should probably go with this plan. - Made this change (outputting 0=pressed instead of 1=pressed). Verified that the RPi does boot normally without avoid_safe_mode=1. Jan 7th, 2014 - Built wiringPi library from source. Used the command gpio readall and verified that all of the inputs being driven by the button circuit are high (which is the expected state when the buttons aren't pressed.) This is a good confirmation that the button input is being detected correctly. Jan 8th-10th, 2014 - I received the Adafruit pushbuttons a few days again, and the quality is pretty terrible: the caps don't fit securely, and the "feel" is not that great (too much pressure to activate, tactile click sounds "cheap", etc.) Did a bit of research, and decided that keyboard keyswitches would provide a higher quality experience, and because there is an "enthusiast" community for keyboard hardware, parts and documentation are widely available. I decided to redesign the button PCB for Cherry MX keyswitches. Found an Eagle library: https://github.com/c0z3n/cherrymx-eagle WASD keyboard sells the keyswitches and blank caps: http://www.wasdkeyboards.com/ I ordered the sampler blank keycap set, and 8 Cherry MX brown switches. (The brown ones are tactile, but not "clicky". Redesigning the button PCB was a fairly tight fit, but I think I made it work. I left a 19mm x 19mm area for the keycaps (the WASD keyboard website shows them as 18mm x 18mm). I also left 1mm at the edges. I had to change the enclosure: in particular, I moved the standoffs out a bit, and moved the LCD to the left to make room for the (slightly larger) button PCB. Everything seems to fit, although it was a somewhat tight fit. I sent out the new button PCB for fabrication (again through OSHPark). I'll wait to see whether it works before having the updated enclosure laser cut. Jan 11th, 2014 - Started working on GPIO support using the documented /sys/class/gpio interface, based on the Linux kernel GPIO documentation. This turns out to be really easy to use: writing a pin number to /sys/class/gpio/export "exports" the pin, creating a directory will control files. Also, if you enable interrupts on a pin, you can use poll or select to do a blocking wait for a pin status change. Best of all, Raspbian has a "gpio" group for permitting access to GPIO, eliminating the need for being root to access gpio. (The default "pi" user is in the GPIO group.) It looks like I won't need to use wiringPi after all. Jan 12th, 2014 - The GPIO input is completely working, using interrupts to allow blocking waits! Next step is to generate button press events based on button presses/releases. Jan 13th-16th, 2014 - The Cherry MX brown keyswitches and keycap set arrived from WASD keyboards. The switches don't have the two "stabilizer" posts to the right and left of the center post: not sure if this will be a problem. Keycaps seem quite nice, and they fit the switches very well. - Ordered some stuff from DigiKey: * 3x attiny4313 * 2x 2x13 header * 5' 26 conductor ribbon cable * 2x 2x13 IDC ribbon cable connectors * 6x Cherry MX black keyswitches The keyswitches were only $.81, and they have the left/right stabilizer posts. The "feel" isn't quite as nice as the brown switches, but it's fine and millions of times better than the cheap Adafruit tactile switches. - The first version of the PCB arrived. I soldered on a 20 pin DIP socket (for the attiny2313/attiny4313), an 1x8 header for the LCD, a 2x13 header for the RPi GPIO, and a .1uF cap (as the decoupling cap for the attiny). Next, I programmed one of the attiny4313s from DigiKey with the button firmware. However, I had a huge amount of trouble trying to get the IC into the socket! Two of the pins were bent (pin 4 and pin 11). Fortunately, there does seem to be a good connection, and the circuit seems to work (using a multimeter to observe the voltage level as the buttons are pressed, using a standalone 5V power supply). Note to self: in the future, buy high quality IC sockets. Next step is to interface the board with the RPi. Jan 17th, 2014 - Connected the v0.1 button board to the RPi GPIO, and it worked perfectly! Also connected the LCD, and it worked perfectly as well! Hard to believe. The one problem is that I didn't correctly visualize how the ribbon cable would need to bend to connect to the button PCB, so the 2x13 header on the button PCB is 180 degrees from the correct orientation. This will make cabling very awkward, although I think with a long-ish cable I can probably make it work. The good news is that the v0.2 button board should be easier to connect (I think!), since I'm 95% certain that the cable will run "straight" and not require any twists. Jan 18th, 2014 - Made new combined top/bottom plate drawing for new enclosure design (with the Cherry MX keyswitches). Submitted quote to Pololu (they seem to have better prices than Spikenzie Labs). I *think* I can get 3 copies of the design for around the $25 minimum. - Tested the car LCD with the RPi - worked great. It's fairly low resolution, and the RPi text console didn't look great, but it should be fine for video. Jan 19th, 2014 - Configured the SPI LCD as the boot console according to the instructions here: https://github.com/notro/fbtft/wiki/Boot-console Works great! I'm using the SUN8x16 font (as far as I can tell). I restored the UI functionality, recompiled, and ran the CarPi software using the buttons and SPI LCD as the UI. It works very nicely! The button input reader thread worked the first time I tried it. After installing mpg321, it works as a music player. "Play Alone" by Asylum Party was officially the first music played. Sweet. Next step is to try out (and debug) video playing using omxplayer. There is some preliminary support for playing videos, but I've never tested it. - Tested playing a video (Monsters University) using omxplayer from the command line - works perfectly. - Working on VideoFileNavigatorController (add support for selecting a video file to play), and adding ConsVideoPlayerView. Getting pretty close: doesn't actually play video, but creates the PlayVideo object and shows the correct view. Almost there? Jan 20th-26th, 2014 - Classes started, so I don't have quite as much time to work on this project. Sigh. - The v0.2 button PCBs (with Cherry MX switches) arrived, and the acrylic pieces for the new enclosure designs also arrived. - Mounted the RPi on the bottom plate using the Adafruit board mounts and the M2.5 nylon standoffs. Everything fits nicely and the RPi is very secure. I attached the standoffs, and discovered that the one in the bottom left partially blocks the micro-USB power receptacle on the RPi, if I used the "nice" wider standoffs. My plan is to use a not-as-nice hex standoff in that corner. The hex standoffs are slightly shorter (1.375" rather than 1.425"), but I figure I can compensate with a washer or two. I couldn't attach the top plate because I ran out of 6-32 screws. - On the 26th I went into work to solder and test the new button PCBs, and for the final assembly! - The new button PCB worked great! The Cherry MX switches fit perfectly, and the circuit worked the first time I tried it. With the keycaps installed, the "feel" is great, a huge improvements over the awful Adafruit pushbuttons. Also, I used a different 20-pin DIP socket, and avoided the bent pin issues I had with the previous buttons PCB. - The ME tool room had lots of useful hardware for assembling the enclosure, including some nice nylon washers that worked extremely well for attaching the button PCB and LCD, and also for slightly extending the height of the standoffs. It turned out that IDC connector for the ribbon cable connecting to the button PCB hit the RPi composite video jack. One washer's worth of additional clearance was sufficient to fix this. For the LCD, I had to cut one side of each washer because the LCD stands proud of the PCB it's mounted on, and the washers didn't quite fit in the space between the PCB screw hole and the side of the LCD. Diagonal cutters took care of that with no problem. - I plugged in the RPi to the USB hub, started the software, and was able to use the UI via the pushbuttons. So, the "device" is basically complete! The software needs work because it still doesn't play video, but I think it's pretty close. Jan 27th, 2014 - Sent a pull request with my (extremely minor) updates to the Cherry MX Eagle library. Feb 2nd, 2014 - Finally got video playing working! My previous effort was nearly correct, except that I forgot to call the play() method on the object that managers the omxplayer subprocess. There are still some improvements to be made, but it basically works. - Decided that the cheap LCD monitor I ordered was servicable, but the viewing angle is problematic (image is dim if you're looking directly at it), and mounting it would require some effort. On Ebay, found a slave LCD from a Philips 7012 car dual DVD player for $25. (This is the car DVD player we have now, so we now have 2 slave screens.) This should work well, the viewing angles are good, and it is easy to mount to a car headrest (it comes with a strap). Ordered some camcorder AV cables (for input to the Philips slave screens), and also an extra power cable (I will be modifying it to tie into the 12V that is also supplying the video signal amplifier.) - I also ordered (from Ebay) a USB audio adapter in case we decide the quality of the regular audio output on the Pi is too low. (It was only $5 shipped.) Feb 5th, 2014 - Kate's dad John Swope cut me a 5"x5" piece of plywood on which to mount the video amplifier and a terminal strip (for 12V power connections to the amplifier and the DVD slave screens.) This will sit in the front of the car (in the recess in front of the cupholders) and plug into the 12V from the car power adapter (that also has USB power for the Pi). Feb 7th, 2014 - Screwed the video amplifier and terminal strip to the plywood with #4 wood screws. - The DVD power cables and the camcorder AV cables arrived. Once the extra slave screen arrived all the parts we need will be here! The USB audio adapter also arrived (they actually sent 2 for some reason). Feb 8th, 2014 - Figured out how to use ioctl to "poke" the console to reset the screen blanking timer. Added code to do this whenever a button is pressed. This was needed because the gpio button press/release events don't go through in the input event subsystem (and thus don't automatically reset the screen blanking timer.) I had actually tried to use the Linux uinput device to generate actual key events, but it didn't work correctly and was generally more complicated anyway. - The Philips slave DVD screen arrived. Found a 12V power supply and turned it on - backlight lit as expected. Connected it to the RPi via the camcorder AV cable - no dice. Got a signal on the red connection, but not a valid one. Experimented with different sdtv video modes on the RPi, but none of them worked. The good news is that I found the AV output cable from the master unit (to connect it to a TV), hooked it up to the RPi using an RCA cable, and it worked! So, it appears that the camcorder cable is wired in a fundamentally different and incompatible way. I could have cut the camcorder cable apart and rewired it, but instead I just ordered 2 x 5ft AV cables that were specifically listed as being for the Philips 7012 (to connect it to a TV, and thus hopefully having the same wiring as the working cable.) They weren't too expensive, but it's still a bit annoying. HOWEVER - I think this was the last major hurdle. Once the new cables arrive, and I get the aux adapter installed in the Fit, we should be in business! Feb 12th, 2014 - Did the power wiring on the "piece of wood" (power terminal block and video signal amplifier) by cutting appropriate length wires, crimping ring terminals to them, and attaching the ring terminals to the terminal block. To make the wire/plug assembly that plugs into the car 12V socket, I used the 12V plug from the Philips DVD power cables, and the fuse from the video signal amplifier (which will now serve all of the 12V-powered components). My colleague Dave showed me how to use heat strink tubing on the places where the wires were soldered together, so it looks like a fairly professional job! - Added an "install" target to the Makefile that installs the CarPi binary to /home/pi/Software/carpi/bin. - Modified /etc/inittab to start CarPi automatically as follows by replacing the line that read 1:2345:respawn:/sbin/getty --noclear 38400 tty1 with 1:2345:/bin/su -c /home/pi/Software/carpi/bin/CarPi pi /dev/tty1 2>/dev/tty1 - Modified the software so that the "Shut down" main menu actually uses the shutdown command to shut down the RPi. Feb 13th, 2014 - Noticed that when the backlight on the LCD powers off, the ioctl that disables screen blanking doesn't turn it back on. Need to investigate. - The new AV cables arrived, and the one I tried works perfectly. [We got 10" of snow, but our mail carrier was out making deliveries. Hats off to the US postal service!] I actually tried out (almost) the whole setup in the car, and everything worked great. I was concerned that the RPi might have problems being powered by the car USB power adapter, but it worked fine. The 12V equipment (the video signal amplifer and one of the Philips slave screens) worked great as well, so the "piece of wood" power distribution system seems to be doing its job. All that remains now is to get the aux adapter for the car and install everything for real. - Changed the code to use TIOCL_SETVESABLANK ioctl to disable powersaving mode. We'll see if that works to keep the backlight on. Feb 14th, 2014 - TIOCL_SETVESABLANK does not work to keep the LCD backlight on. What's worse, even explicitly writing 0 to /sys/class/backlight/fb_ili9340/bl_power does not cause the backlight to come back on! Fortunately... - Figured out why my original attempts to use /dev/uinput didn't work: there is a special event type (EV_SYN) that is required to force input events to be pushed to the consumer (i.e., the console). Modified button_input_reader_thread.cpp to generate key events using /dev/uinput rather than directly posting them to the event queue. In theory this should wake up the LCD from power saving mode (same as if a key on a USB keyboard had been pressed.) I haven't tested it yet to see if it will wake up correctly after the backlight has powered down. We'll see... Feb 15th, 2014 - Confirmed that button presses do wake up the LCD (and power the backlight back on). - Added echo 0 > /sys/class/graphics/fbcon/cursor_blink to /etc/rc.local to disable cursor blinking. - Added code to cons_car_pi_app.cpp to enable a solid block cursor rather than an underline cursor. I think this looks a bit better (although it's not really a big deal.) Mar 1st, 2014 - Finally got the aux audio input installed in the Honda Fit (at Wyvon Audio Installations, http://wyvonaudio.com). Set up all of the AV equipment, tried it out with the RPi, and everything works! The sound quality with omxplayer was quite good. Audio from mpg321 is rather quiet: perhaps it doesn't default to 100% gain? Mar 2nd, 2014 - Added support for seeking forwards/backwards by 30 seconds and 10 minutes in the video player. (These are both supported by underlying omxplayer commands.) -