I was just thinking about this the other day. Why wouldn't it work?
Phone to USB to breakout board that connects to and drives sensors, injectors, spark plugs, etc. Phone can be the gauge cluster as well. Flash the entire screen in different colors should you hit high temp or knock or low oil pressure, etc. It should have plenty of processing power. Also, would be an easy way to start data logging with the integrated sensors on the phone like GPS and accelerometers.
Does this already exist and I don't know about it?
It wouldn't work because AFAIK it's still impractical to impossible to run software on top of a full multitasking general-purpose OS and get the timing resolution needed to run an engine reliably.
Edit: You could move the timing-sensitive bits to an external dedicated hardware device, but at that point it's more like using a phone as an interface to a Speeduino.
By the time you have that breakout board, how far are you from a basic Megasquirt?
You have to take all the high load bits out and drive them with something, and I'd bet you'd need a driver to run the drivers, because I'm betting the full time capacity of a usb port would be measured in milliamps.
Keith Tanner said:
By the time you have that breakout board, how far are you from a basic Megasquirt?
Yeah, I was going to say with Megasquirt, I don't really see the point in trying to reinvent the wheel so to speak.
z31maniac said:
Keith Tanner said:
By the time you have that breakout board, how far are you from a basic Megasquirt?
Yeah, I was going to say with Megasquirt, I don't really see the point in trying to reinvent the wheel so to speak.
Well, the breakout board may be similar to an MS, but basic MS doesn't have a screen, accelerometer, GPS, etc built in. Also different from an MS, I have at least 2 or 3 old phones just laying around.
In terms of re-inventing the wheel - how did we end up with stuff like megasquirt in the first place? 
GameboyRMH said:
It wouldn't work because AFAIK it's still impractical to impossible to run software on top of a full multitasking general-purpose OS and get the timing resolution needed to run an engine reliably.
Edit: You could move the timing-sensitive bits to an external dedicated hardware device, but at that point it's more like using a phone as an interface to a Speeduino.
And there are no other OS options for a phone that still give you access to the screen and sensors and stuff that would be better? Sorry if dumb question Im not really up on phone stuff.
Robbie said:
GameboyRMH said:
It wouldn't work because AFAIK it's still impractical to impossible to run software on top of a full multitasking general-purpose OS and get the timing resolution needed to run an engine reliably.
Edit: You could move the timing-sensitive bits to an external dedicated hardware device, but at that point it's more like using a phone as an interface to a Speeduino.
And there are no other OS options for a phone that still give you access to the screen and sensors and stuff that would be better? Sorry if dumb question Im not really up on phone stuff.
Not for a phone, if it were a PC maybe some weird RTOS could do the job.
Robbie said:
z31maniac said:
Keith Tanner said:
By the time you have that breakout board, how far are you from a basic Megasquirt?
Yeah, I was going to say with Megasquirt, I don't really see the point in trying to reinvent the wheel so to speak.
Well, the breakout board may be similar to an MS, but basic MS doesn't have a screen, accelerometer, GPS, etc built in. Also different from an MS, I have at least 2 or 3 old phones just laying around.
In terms of re-inventing the wheel - how did we end up with stuff like megasquirt in the first place?
Oh, I totally understand how stuff like the MS comes to be, including the evolutionary process. I'm just wondering, by the time you've engineered the breakout board and written the controlling software on the phone - how much are you saving vs simply designing a new ECU with an on-board processor and no interfacing problems? Does the ECU need an accelerometer and GPS? If that's important to your plan, then it makes sense. But if you're simply looking for a way to do basic engine management, those capabilities don't offer any benefit. If you want the screen, then your custom ECU can simply have a bluetooth connection that lets you access readouts from the ECU on the phone.
I guess this is the question - what benefits do you get from the phone? You're not going to save any real effort over designing your own from-scratch ECU. You won't save much money because processors are cheap. So it's about the extra capabilities offered by this phone. Or the challenge, which is cool.
And even if the sensors in the phone (accel, gyro, GPS, baro, etc) are useful for your application, it makes far more sense to use a real-time processor for the ECU (like used in Megasquirt, Speeduino, rusEfi, etc), and have the phone send the sensor data to the ECU over the tuning interface, CAN, or similar.
I really don't see that working.
I have had similar thoughts. After all, our phones are powerful enough to launch rockets into space, missiles across the globe, and Android's in particular run(or maybe ran?) on a Linux base. Yes, I'm stating those as facts, compared to the computer systems used in the 60s-80s our modern Facebook checkers are super computers.
I just think that things like Megasquirt and other proper standalone ecu's make better screwdrivers in this situation.
Maybe a programmer with time on their hands and a passion for craziness could do it, but mass market appeal might not be there.
Of course I know less than nothing about CAN buses and interactions of modern car computers so maybe just wishful thinking.
Keep in mind that our phones are general purpose devices that don't make very good use of their hardware.
For example, the old Link ECU we used to sell had a pretty weedy processor that was mocked by outsiders - but it ran custom code written in assembly language specifically to run a turbocharged Miata, and every single bit of memory was used. The more generalized ECUs we see today might be more flexible, but they don't start as fast or do as good a job of boost control as that old Link did. It's pretty easy to overlook the effectiveness of dedicated hardware with dedicated software.
The phone has far too much of the wrong type of hardware and not enough of the right type. For an ECU you need analog-to-digital converters so you can read simple analog sensors, hardware CAN bus interfaces to read more advanced digital ones, and most importantly a CPU that provides timing guarantees. Embedded systems at this level are all about precise timing, the Linux kernel running underneath Android might support real-time processing, but the Android layer on top does not. Even if it did, modern general purpose CPUs don't provide the kind of timing guarantees you want, because they will take over control at unpredictable intervals to go off and do background "housekeeping" stuff. (The management of the phone radio hardware which *is* timing dependent is run on special hardware that's added alongside the ARM general purpose microprocessor, often in the same chip package. It's pretty special purpose though, and not something you could easily use to do ECU stuff).
ECUs are built with microcontrollers, which are chips designed expressly for this sort of application, and have all the stuff I mentiond above. The Motorola 68HC11 family is a long-standing microcontroller line and is what's in the Megasquirt. The Atmel AVR is another family that's at the core of the Arduino, other common ones are the PIC and Intel 8051.
If you want to add GUIs, wifi access, etc to an ECU, the best way to do it is to have a secondary processor running a high-level general purpose OS and have it use a serial port to send commands to the ECU and receive data back. This is essentially what's happening if you run TunerStudio on a tablet plugged into the USB port on an ECU. Two computers each doing the things that they're specialized for, with a simple communications mechanism between them to keep stuff in sync.
I believe you will need a real time kernel. Easy to do on an embedded device you build yourself, hard on something locked down like a phone. I believe the USB connection will be too slow for ignition and fuel outputs. You will need a fast CAN bus connection to do that.
If the phone has an audio jack you could possible connect before the D/A converter and program some very fast outputs. Surface mount soldering is a PITA though.
