I really wish there were more beginner developer friendly diy options for car entertainment. I’ve been considering making a carputer out of a raspberry pi, however, half the solutions are proprietary (looking at Qt), however there were some demos of this running on an rpi. So that is a nice development.
I’d rather just put a normal Linux distro there, however, I’m not feeling like waiting 8 seconds every time I turn in my car.
Apple CarPlay is in the same boat requiring an MFi private certificate, and no way to provision a short lived cert like they do for iPhones.
> I’d rather just put a normal Linux distro there, however, I’m not feeling like waiting 8 seconds every time I turn in my car.
I've been working on a Pi Zero W based carputer (really, it's headless and just interfaces with my phone over Bluetooth / the existing radio head unit and steering wheel menu and controls).
Boot time is probably around ~8 second mark currently (fully booted with buildroot / systemd, it's powered from 12V switched by the key) and it already feels fast enough. I normally start my car, put on my seat belt and look around. By the time I've finished doing that it has connected to my phone.
Of course, it would be possible to do even smarter things. Hook up a low power micro that can interface with the CAN bus and a MOSFET, and you can instead power it from the battery and turn it on when the car is unlocked and off after a timeout based on the engine going off.
which "proprietary" bits of Qt do you think you'd need? There isn't much that's not LGPL or GPL - and while the safety renderer could have automotive applications, you wouldn't care about it for a DIY entertainment system.
> I’d rather just put a normal Linux distro there, however, I’m not feeling like waiting 8 seconds every time I turn in my car.
Suspend-to-RAM works decently to avoid this, and to avoid it sucking the battery dry, Suspend-to-Flash can be used. Yes this will take some time for restoring RAM... but again, to avoid the user noticing that time, why not start the wakeup process when the user unlocks their car / opens a door?
On desktops and laptops, it Usually Should Just Work (tm). The general culprits for issues are proprietary graphics and wifi drivers as well as shoddy BIOSes with broken ACPI tables, but I never had to dig this deep.
For embedded systems, the situation is more complex, as the chipset needs to support it - suspend itself is not the problem in most cases, but wakeup is - for example, the Raspberry Pi does not have a dedicated interrupt (https://github.com/raspberrypi/linux/issues/1281). If you're working with an embedded chipset, your best bet is the manufacturer, they have to deal with that in the BSP.
Whenever I read comments like this, I think "Why is he trying to use a 10+ years old Ubuntu, or similar"?
Or do I just make way luckier buying choices? Suspend to anything has worked flawlessly out of the box for my devices since 10+ years.
Do you have a specific example of what is not an "obviously bad hardware combination choice", but yet still does not correctly support Suspend-to-RAM?
You might want to give eCos a try. This should be runnable on a Raspberry. I managed to port Luvit (Luas NodeJS) in a few days. Then you should have a system booting within 500ms.
I've been in the same boat. If you really want a hackable infotainment without a TON of work and electrical problems, your best bet is an Android head unit which supports aftermarket OS's. It's not perfect, but you save yourself the headache of getting the CAN Bus working, connecting the Audio, getting the startup right etc etc.
I’d rather just put a normal Linux distro there, however, I’m not feeling like waiting 8 seconds every time I turn in my car.
Apple CarPlay is in the same boat requiring an MFi private certificate, and no way to provision a short lived cert like they do for iPhones.