OEM-ish 'back to basics' ARM/GLCD build
So to start off here, I should note that as time has gone on I have been thinking about doing a CarPC installation in my soon-to-be vehicle. But with around ~5 years of driving experience under my belt and my own personal habits I have come to the realization that a full blown VGA LCD based machine with all the bells and whistles is way overkill, a potential distraction, and as always poses the usual 'hacks' necessary to fit a full PC and the fixins in a car environment. This is not to say I am against full CarPC builds. I am all for them. But I do believe they have their place and specific uses.
In my specific build I decided I would go a bit 'ballsy' on it. Much of this has been well inspired by both Ford's Sync system (the non-touch screen versions, where much is focused on voice control and the small info display and bluetooth connectivity for data services) and Kia's non-UVO multimedia radio (best picture I could find of decent resolution: \[link\]). Sync I have not had any personal experience with but have done extensive research since it first came out. Kia's system I have had personal experience with and have to say it is very well done. Not overly flashy, but tastefully integrates and manages all the main media sources which are FM/AM, CD, USB/AUX playback, and Sirius. All with a non-touch graphic LCD display which is even perfectly readable in full on sunlight beating down on it. And of course all the usual hardware buttons to control everything and does it well with how it is set up.
I have been running a very many number of ideas through my head and jotting them down as I go along. The essential design would be an embedded ARM device running a fully stripped linux install just enough to run the CarPC necessary functions. Display would not be a TFT but a simple graphic LCD to just show the necessary info. Combine that with a full smattering of intelligently placed hardware buttons flanking it and contextual/'as it makes sense to use' voice commands. The contextual part should allow narrowing down of what the system is expecting from the driver and greatly reduce mixups in voice commands. As Ford's Sync does it, you start off by stating what mode you desire to command (phone, usb, etc..) or forego that and go straight to commands of what current mode you are in. In which they are mode-based. ie: Phone it would only expect 'dial XXXXXX' or 'call John Doe' while usb/music would expect 'play artist XXX' which can be further focused in by responding to what is in the music database or contact list for phone.
Currently I have a Pogoplug Pro which, for better or worse, is not ever going to be run stock again because their software is crap IMHO. But the hardware is great and is already set to customize and strip down to a barebones linux OS. Talking about a dual core ~700Mhz processor, 128MB ram, 128MB internal flash, 4 USB ports, internal SATA port, onboard Wifi in mPCI-e formfactor, and open serial port which I plan to use. To boot, researching power supply details I am probably looking at somewhere between 5-10W depending on load and devices connected and investigating chips on the board it looks like it should be able to handle unregulated 4-18V DC (although I will be testing this extensively with more 'stable' unregulated sources to confirm and probably regulate it anyways to be safe). Devices external to this are going to be a USB based soundcard. This is currently on its way and is a Diamond Xtreme 7.1 card (which will likely feed the 4 channel Mp3car amp). Graphic LCD which will be run off the internal serial port if I can help it. USB GPS, 3G data card, ~20GB sata drive run on the internal sata port and probably a separate USB drive for main 'internal' music storage with a dedicated usb port free somewhere for 'external' music usage which the port will be extended in the dash somewhere.
This is where the ballsy part comes in: Much of this build is going to be about software. The hardware I already have well laid out in my head, but the software part is going to be all custom. I am not a programmer by trade, but I have been told I do think like one. I have been involved closely with a few active software projects written in C and have no trouble reading code for the most part, debugging compiler errors and warnings, and to a point even adding some simple code here and there with google at hand. I have also had plenty of experience in PHP and can do some more simple-to-moderate stuff. I have been meaning to start from the ground up on learning a new language that I could potentially use down the road for other projects. This has me pondering between python and Java, leaning towards Java due to potential Android development. This may be the ultimate path I go down for this.
Given this is completely new territory for me with this build, it will understandably take a bit of time to get going but I plan to start the process very shortly and do plenty of indoors development work on the intended hardware to be installed. And being hardware will be one of the very last things to be delved on in the process, not much pics for those carpc-porn types here. ;) But I will try to keep things updated here.
Second potential roadblock so far is finding a good LCD to work with that has enough resolution and looks good in a car environment. The very popular 128x64 Sparkfun offers looks great, but it doesn't delve much into sunlight readability and the visible 'dot gap' in the screenshot bugs me and would like to keep that minimal for aesthetic reasons. Vertical resolution may also be an issue but I have to do some visual planning and see how I want the 'GUI' laid out and if it will fit.
But overall in the end, potentially it should work extremely well given the underlying linux OS. Namely, for example, BlueZ means all aspects of phone and even A2DP integration should work flawlessly or at least a lot better than Windows based FE's. GPSD is pretty much supported by every GPS focused linux app and shares GPS data between applications which allows 'sharing' to just work without fussing with port splitters. And with being able to strip the system down to just bare basics necessary, resource usage will be minimal thus power usage as well, and boot/shutdown should be very quick allowing the whole system to be powered off and on with ACC power and not having to muss with hibernate/suspend/etc..
Right now with the ideas going through my head, here is the current step-by-step process I plan to follow along:
1) Initial language learning, sample code, etc..
2) Play around with linux configuration such as PulseAudio configuration for car use (ie: expand 2 channel audio to 4 channels and exposing some basic EQ and balance/panning to be used in software later)
3) Investigate use of MPD as the main media backend and writing a client for it to display and be controlled with the prior planned hardware setup. Music will be the initial focus and once it is near-solid I will look towards expanding into more modes of the system.
This is what I have for now. It is a bit all over the place with the post but wanted to get the initials down. I will add more as I get around to it and probably clean up this post. Willing to answer any questions people have. :) I am actually very hopeful with this project and want to see where it goes!