No announcement yet.

OEM-ish 'back to basics' ARM/GLCD build

  • Filter
  • Time
  • Show
Clear All
new posts

  • 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.
    4...) TBA...

    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!

  • #2
    So a few more things to add to this:

    First off I have since gotten photos of essentially the visible hardware I am trying to emulate:

    Looking closer at the screen I am looking at a 128 height LCD of at least 240 width or better (if they can be found within reason!). In addition I have found this radio in a few places for <$100 which is really surprising to me but is a good price point I think to essentially gut it for just the screen and front fascia and possibly get an idea if the screen can be salvaged or has to be replaced with my own. At this point I am not 100% sure how that would go.

    Since my initial post I have been looking over LCD options for this build. Either a) Buy the to-be-emulated-and-gutted unit and salvage the screen or b) find a suitable replacement. Unfortunately for both of these they happen to fall under a specific set of criteria: Easily connectable to an existing ARM device which usually limits it to ultimately USB or 4 pin serial (power, tx, rx, and gnd). This specifically kills parallel based displays it seems since there is no direct parallel-to-usb option that works. And to add salt to the wound, many LCD's I have come across that are 128 pixels in height are pretty much parallel based. On top of that, interfacing in software is complex in that everything would have to be written at low level unless there's libraries available for the specific hardware (which I have researched and seem to have limited hardware support in the ones I've looked at and thus restricts LCD options).

    My other option which I have been contemplating is going the TFT route but once again designating a no-frills UI and trying to go a small LCD route if possible. In fact Sparkfun sells a PSP LCD which is 4.3" diagnol and 480x272 in res and great quality. Unfortunately seems no easy way to interface here either and VGA options are all extensive DIY projects. On the upside, if it is based on any sort of video output from the system, it is a bog standard and relatively simpler method of UI building just going with X and SDL or OGL.

    So the hardware side is still in a state of flux at the moment.

    Software side is slow but positive. Unfortunately my PogoPlug Pro board is not cooperating as much as I'd hoped. Mostly because the kernel is not as completely open like other ARM solutions on the market so everything is largely hacked together on this thing. My progress with this thing over the past couple days has involved reflashing my rootfs flash drive numerous times after it has failed to boot after doing basic software updates. At this point I am impatiently waiting on a TTL USB adapter to arrive so I can debug these and hopefully progress forward. I am possibly also looking at getting an RPi next time some are available to order at un-inflated prices just to bypass the annoyances and get this setup functional on a stable and well documented piece of hardware.

    But I have looked into MPD and tying into PulseAudio and ALSA and all encompassing documentation and seems for those it should very well do all that I want and then some. For now I will probably have to test theories out on my headless Ubuntu machine and once I can sort out the PogoPlug or RPi I will move the setup over to that.

    On a related software note I have put further thought into both NAv and Voice functionality and how exactly I'd like to manage that. Both solutions I feel are very intuitive:

    NAV: My original investigation into linux based navigation software has left me fairly unimpressed and unsurprised at that. My initial thought was to use Google's existing routing functionality under Maps. As my research led into it, it appears going this route is practically dead simple barring programming geographical mathematics into the system. Long story made short, Google offers an API for directions where you can supply a basic lat/lon source and destination info (in nearly any format such as how Maps allows now) amongst other options and will return a JSON/XML feed with not only individual turn-by-turn steps but also a full parseable path-line of the full route and individual steps. To the point that in CarPC use could just have it send up the current lat/lon origin and desired destination and with the returned data, parse everything out so the computer can mentally map the path and determine remaining time/distance from current location and even rerouting based on how far off the path you are. In fact my theory is this is how Ford's Sync system functions when it pulls turn-by-turn directions from their phone 411 service. This will be a theory to test in full once I get a functional piece of hardware or a desire to dualboot a form of linux on my laptop again.

    Voice: Along the same lines as above: Although not documented nor supported, Google has a pretty easily accessible service to utilize their voice recognition features which are very accurate. Given network access is available, this should be just as easy. To break it down it works like this: Record a voice command off the mic how you choose. Encode to either Speex or FLAC. Curl up to Google's servers and as a response you get a breakdown of possible results with the top being the most likely and an easily parseable text field. CarPC-side use some language rules to parse it out as you wish.

    Now the downside to both is that they'd require network access to function (at least initially for Nav usage. Unless going off route or starting a new one, once started you should not need connectivity after that). Voice side is inevitable here and will likely be done instead with a linux-native package if something pops up that is suitable. I have not researched this part enough yet. Nav side I have been looking into a data-over-voice system which would negate 3G access and use voice service directly which should be relatively more reliable in corner cases. In theory this setup is completely doable but the million dollar question is getting reliable data modulation/demodulation over the garbled mess that is current cellular voice codecs. This part is definitely an end-of-project feature addition if at all, but worth pondering IMHO.

    'Tis all I have for now. FYI: I do have my USB sound card and one of my first things to get going is 2-to-4 channel audio via ALSA and subsequently volume/balance/eq controls all in software so from the PC side it is just 4 channels of audio straight to a locked gain amp. More on this development to come!


    • #3
      Figured I would come back and do a small update to my progress (or lack thereof, due to work/holiday season/lack of free time). I have since made attempts to get the core OS setup on the PogoPlug Pro (ie: Base Arch Linux install plus a working audio stack and MPD, the necessary core components for any CarPC) but unfortunately have had crappy luck that I am attributing to the more locked down nature of the hardware.

      Numero Uno: Getting the thing to successfully boot from the proper drive with the 'storage drive' attached. Essentially it is designed with a small 2GB-ish flash drive for the OS and then an external USB hard disk (or even SATA if I can get that to work) for data/music storage. Unfortunately the U-Boot bootloader is a pain to figure out and the version on this thing is outdated. With just the OS drive plugged in it boots up fine. With both it and the storage drive attached, it never boots properly until the drive is removed and reboot. It is doable to get it to focus on the OS drive but is way beyond my current reading comprehension into the workings of U-Boot.

      Numero Dos: Device hotplugging/discovery/audio support: An amalgation of all three of these issues, each boot seems to vary what plugged in USB devices will be discovered without having to kick it into gear manually. Along this line, operation of the sound card isn't working as I had hoped and/or MPD doesn't want to cooperate with the stock setup. Until I can get proper device discovery functional, audio workings get put behind here.

      Sidetracking off that, there is an Iomega iConnect in the house which I have been given permission to use how I wish. It essentially follows the same 'embedded device' lines as the PogoPlug save for a few minor changes: Single core 1.2Ghz processor, 256MB RAM, and a mainlined linux kernel which allows it to be kept up to date better unlike the PogoPlug which is mostly relying on a closed source/out of date kernel. On top of that, it runs a newer version of U-Boot and even may be able to shoehorn Grub into it which I do have a better understanding of and I know can be forced to select device booting. So if the PogoPlug refuses to cooperate, this route may be chosen in its place.

      On to newer events: After some more recent thinking I have decided to add a few smaller projects alongside the CarPC build.
      Project #1: GSM/SMS operated remote start/keyless entry system -- Arduino based scratch build. TL;DR Have your standard keyless entry and remote start functions all operated over SMS and fully configurable. With the right setup with the Arduino platform, power usage should be low enough to run 24/7 without significant battery drain.
      Project #2: Remote controlled HVAC system -- Initially keep the system stock and run the necessary controls out of sight behind the dash and keeping the manual controls intact and functional so they work in tandem. Eventually would like to make a display with automatic climate control options.
      Project #3: Serial/I2C network -- Tie in the keyless system, HVAC controls, and the CarPC to speak to each other. I won't exhaustively list all the options but the primary ones in mind are as follows: Allow arbitrary climate control settings to be made via SMS using the GSM module in the keyless system. Start the car and have the keyless system signal the HVAC system to change settings as needed. Also would negate the need for a separate display for the HVAC system and simply have a separate screen on the CarPC for it. This plays out much like BMW's iBus system which allows the different systems to talk to each other and share information as necessary.

      I currently have an Arduino Mega in my posession which I am going to play with as time permits and hope to eventually get it operating as a keyless entry/remote start system. Baby steps though.