Linux Takes On Automotive Apps
loconet writes "Linux Devices has released an article about Metrowerks setting out to drive Linux further into the automotive telematics market by launching what it calls "Automotive Grade Linux," a version of Linux enhanced with non-traditional features to address the specific requirements of automotive telematics."
It would be nice if they would start to use Linux in all machines where they wanted to write code with minimum overhead. I know people that have written large ammounts of code for everything from car computer systems to alarm clocks and its usually it some form of basic or C. Imagine if most of these products starting using a simple Linux system where you could reuse all kinds of crazy crap. You could be running toaster timers to clock your laps around a track in your car :D
What automotive telematics is not
Automotive telematics does not include areas of automotive computing that involve powertrain management (such as fuel-injection microcontrollers), or what Metrowerks terms "body/safety/chassis" computing applications. These applications are typically based on proprietary process-based real-time OSes such as QNX, VxWorks, AE, LynxOS and others.
http://www.busyweather.com/
Why try and do this with Linux when TRON is already the most widely used operating system for millions of devices? Or is it just the geek factor of knowing you're buying a car with a penguin inside?
This is a test. This is a test of the emergency sig system. This has been only a test.
http://linuxdevices.com/news/NS6531324140.html
The car has a computer onboard. It takes one to know one, so to speak. You have to interface with the onboard diagnostic system to read the trouble codes it has stored. You can read the codes with a simple tool. According to the article, this has nothing to do with diagnostics, though; that was about the only thing the article didn't mention. Way to many buzzwords. The article did mention:
If you're going to have a network interface and drive a terminal or a gui, you can either reinvent Linux, poorly, or you can use whatever portions of Linux help. Since you can fit the entire OS on a single floppy, I don't think it has to be any heavier than is really necessary.
See what I've been reading.
Windows doesn't "power" any cars; it runs some telematics systems, but it definitely doesn't run any EMS systems I'm aware of (and I work for a large powertrain electronics supplier, so I have some knowledge here).
Most EMS' I've seen run on OSEK (DC particularly likes OSEK) or VxWorks. A few run on home-written RTOSes (mostly written by Russian coders).
---
Mod me down, you fucking twits. Go ahead. I dare you.
(I read with sigs off.)
More valves = more air. More air coming in means more efficient combustion, generally.
All modern automobile engines I'm aware of (with the exception of Mazda's rotary) are OHV.
"Pushrod" engines have the camshaft in the bottom of the V of a V-type engine, just above the crankshaft, and driven by a chain off the crankshaft. The camshaft pushes on rods, which then push levers (rocker arms) which operate the valves. This wastes a lot of energy, and generally is limited on the RPMs (unless you're building race engines). To get more than 2 valves per cylinder, you'd need a lot more pushrods and lobes on the cams (which there isn't room for), or some extra levers/paddles over the valves to split the force of the pushrod. But that can flex, and flex is bad. And you'll waste more energy regardless.
An Overhead Cam engine has the camshafts directly above the valves, no pushrods. To add a second pair of valves, move the first set to the side, along with their camshaft, and put a second set right next to them. These engines are much easier to run at high RPMs.
Well, the true HEMI design from the '50s and '60s can do it with 2 valves per cylinder. The new one requires more than '60s knowledge to do it, due to all the computer controls which haven't been cracked yet. The engine hasn't been picked over by the shadetree "hackers" yet. And can it do it and still meet emissions?
QNX is based off BSD.
QNX is a small RTOS with a micro-kernel architecture and a message-passing structure (that has big libraries on top of it, to make it feel like Unix)
BSD is an interactive, time-sharing system that was designed on VAXen for a serial terminal environment.
Thus, QNX & BSD are about as different as BSD and OS/360 are (but for much different reasons, of course).
"I don't know, therefore Aliens" Wafflebox1