DaHammer

What type of response times do modern turbo automotive engines require? Does engine management need anywhere near thousanth of a second feedback or response? I guess the root of my questions is there anything (in theory) that a RT embedded software/chip does that I couldn't do on a laptop running something like Linuxworks? Assuming I had the right cable

stevenknapp

Can't speak for the cummins in detail, but can give you an idea of what's involved.

Look at it two ways. There are high precision timer parts. In a gas engine this would be fuel and spark, on the diesel you're just looking at fuel. Either way the output channels aren't the only thing that needs timing hardware. The engine posistion is determined by a pulse train from the crank sensor.

Typically these days you've got some nice hardware to abstract the software from this. I think the 3rd gens have an ASIC from Bosch that does this, the 2nd gens had a seperate fueling box with the Bosch hardware...not 100% sure. In the case of a lot of automotive applications you've got something like the TPU, a Motorola widget found in many of the MPC555 family of CPUs, including the one in your cummins.

What else needs to be time critical? Well the values that are fed to these timers need to be updated frequently. 6000RPM/s is the acceleration I've seen thrown around for worst case engine acceleration/decleration. Keep in mind this isn't just for the engine reving freely, but also what happens when the clutch pops during a downshift. From that, you get requirements of how often these timer that control fuel need updating. The accel/decel also drive how the timers themselves need to operate.

Ok! So how often do you update the timers? Well the easy way is to tie the operation to the engine posistion. Updating them at least once per cylinder per cycle. So say in the Cummins you want the engine controls speced to 5000RPM, which leaves you with calculations to do at least every 4ms. But in reality the rate is quite a bit more frequent. For example some automotive systems have 1ms and 2ms time based tasks in addition to the engine posistion tasks. Gas motors rev a bit higher too, so the engine posistion tasks run more often. Make that motor a V10 or give it a 10k redline and you've got a lot more activity. PLUS they have slower rate tasks, maybe a 10ms, 20ms, 100ms. These slower rate tasks need CPU time to run as well.

Now what all needs to take place in that time? Imagine a budget. Take a period of a few seconds, assume the engine running at max RPM. Each time a task runs you deduct it's time from that budget. You need time left over at the end. In addition you need to take into account context switch time. This is where most big OS's fail. They use most of the time budget on overhead. Real context switch data on linux would be needed here, but last I looked it didn't look good for this application

You've also got to get data in from the sensors and timer system. Then do some math, and then write it back. So in your laptop/cable idea you've got latencies in the comms to deal with. The other hard one is how to get precise interupts across in a deterministic fashon.

SO! I guess the gist is that the laptop lacks the special hardware needed for precise timing of the fuel pulses. Connecting it to that hardware via a serial/USB/parallel cable would introduce latencies to the system. And then your Linux OS probably takes up enough CPU to prevent your application from running.

Nevermind the fact that you would want a second laptop checking the first to ensure that the truck didn't run out of control. Most ECU's that support any drive by wire functions have a small micro monitoring the big one.

Does this help? Is it clear? Let me know, I'll do my best to help.

DaHammer

Thank you for the info...I am in the process of chewing on it a bit and moseying around the internet for more info...I will be back but in the meantime, so just to make sure I am on the right track a couple of questions about the acronyms. TPU is the time processor unit? sort of like a coprocessor that is part of the Motorola chip? Is there a manual available for it or maybe I'll head over to Motorola and snoop around for some white papers.

ASIC...these integrated circuits are specific to certain applications correct?

Do you have a specific example of time-based task @ 4ms? That seems pretty quick..4 thousanths of a second? I thought diesels were ancient lumbering engines...

The applications that I have in mind would be something of the order of allowing the PC running a real-time operating system like Linuxworks (which i *think*) interfaces nicely with the bloated Desktop O/S linux to do the following tasks: The desktop O/S would control all ICE (in-car entertainment) and the RTOS would allow certain "off road only" ECU and boost parameters to be modified...ideally with voice commands. To wit: "Hal, will you please crank up the boost eight PSI...add a smidgen of fuel, run our secret "Superduty coming up behind w/pillar mount gages program" and oh yes...another running of Pulp Fiction on the DVD please" of course GPS, voice, wireless, and anything else could be controlled, modified etc. I was hoping that a RTOS was floating around AND modern PCs had the horsepower to do the work.

When I look at the big picture (probably my problem) I see binary zeros an ones...nothing else. A twenty year old CPU will do over four million clock cycles per second...i dunno, I have a lot of work to do on this....I *thought* since modern CPUs were so fast that they could do what a ASIC could do...didn't give much thought to communication latencys...maybe in a piggyback application they wouldn't matter all that much...If things get really screwed up plow a bunch of zeros into the bus and have the factory take over.

Is it possible (legal?) to emulate a motorola chip by using a solid state memory device such as a CF card...is the motorola souce code available?

Anyway...I appreciate the post and will pick it apart for info..(I printed it out) When I get spun around (likely) I'll give another yell.....thanks.............Rob

AK RAM

01000100011011110010000001111001011011110111010100 10000001110010011001010110000101101100011011000111 10010010000001110100011010000110100101101110011010 11001000000111010001101000011001010111100100100000 01101000011000010111011001100101001000000110000101 10111001111001001000000110100101100100011001010110 00010010000001110111011010000110000101110100001000 00011110010110111101110101001000000110000101110010 01100101001000000111010001100001011011000110101101 10100101101110011001110010000001100001011000100110 1111011101010111010000111111

stevenknapp

TPU, Time processor unit, yup there are docs at the motorola web site. Keep in mind there are people who make careers understanding the nuances of this gizmo. I don't find it to be the most straightforward bit of hardware. In short, it's a small co-processor with some specific I/O hardware.

ASIC = Application Specific Integrated Circuit. Yup.

The tasks that run at the different time bases is pretty application specific and even implementation specific. Ford might do one set of stuff, GM another. To put things in perspective, at 4000 RPM you've got ~45ms between combustion events. You've got about .04ms per degree of engine rotation. And you're placing THREE fuel pulses in about a 8ms window. At the same time you're doing math on the crank sensor to determine what the engine itself is doing.

I *thought* since modern CPUs were so fast that they could do what a ASIC could do...

Keep in mind that the stock ECU has a ~60MHz PowerPC with very "fast" local memory. It's not all that crappy. Your desktop may be 3GHz, but the DDR SRAM is likley 333MHz, and there are a good number of wait states for the first access of the burst. While it's up to some debate, in general control software is thought of as being linear, so caches don't really help as they do on the desktop.

The reason you've still got the ASIC is the timing. You need/want accuracy of your fuel pulses to resolutions of less than one degree, <.04ms. This is the domain of specific timer hardware.

Rather than build a new ECU out of linuxworks, your better bet would be to buy a known working fueling box, and have your invehicle PC control it some how.

DaHammer

01001111011001100010000001100011011011110111010101 11001001110011011001010010000001110111011001010010 00000110010001101111001011100010111000101110011010 01011101000010000001101001011100110010000001100001 01101100011011000010000001101010011101010111001101 11010000100000011011110110111001100101011100110010 00000110000101101110011001000010000001111010011001 01011100100110111101110011001011100010111000101110 011100100110100101100111011010000111010000111111

The Boss Hog

Ther are only 10 kinds of people . . . those that understand digital and those that don't

The Boss Hog
(Not original but what the heck . . . )

sherod

Better watch out or I'll pull out the Hex and Grey Code.

Interesting thread guys.

Ed

spots

Interesting????

AK RAM

01001010011101010111001101110100001000000110001101 10100001100101011000110110101101101001011011100110 011100100001

MikeyB

I'm quietly watching this thread to see where it going.

BTW, here's the white paper on the Bosch CANBus system.

http://www.canbus.us/

MikeyB

Grey Rider

I respectfully disagree with steven a little bit here. I believe a modern PC is PLENTY fast enough to handle the sampling frequencies involved with any reciprocating internal combustion engine out there. For example, 8ms is an absolute eternity in which to perform 3 fuel injection processes: it's only 375n hz. Then, due to the Nyquist criterion (anti-aliasing requirement that sampling frequency must be at least equal to twice event frequency, for those not familiar with signal processing), we'd want to run at at least 750 Hz. Call it 1 KHz to be even. This is extremely slow.

Let's say we have an indy car engine running at 18000 RPM. And just to make it hard we're trying to read the crank position sensor, which has 360 timing teeth on it to be picked up and read by a sensor. So you've 360 events/revolution to record. This works out to be 108 KHz. Again, due to Nyquist, we need at least 216 KHz sampling, so let's say we use 250 KHz. This is not particularly fast. More than enough time to take care of operating system overhead and calculations between readings. I speak from experience.

Such a data rate is extremely slow and manageable. All you need is a DAQ board from someplace like National Instruments, along with their LabView softare and all this could be accomplished. It would be a little tricky interfacing with the ECM, but it could be done with time and dedication.

BensBud

I love the fact that there are other geeks here too. I'm an EE by degree and a software engineer in practice - automation...

Grey Rider, I think you've got a problem in the math in your example? Maybe I read it wrong, but 18000 RPM * 360 events/Rev == 6,480,000 (but it's still in minutes - needs to be multiplied by 60 again to get to Hz)... You're looking at a one-to-one sampling rate of 388.8 MHz...

Grey Rider

Hmmm...here's my logic:

18000 RPM = 300 RPS
(300 rev/sec)*(360 events/rev) = 108000 events/sec

Or, 108KHz. Am I still making a mistake (quite possible!)?

Grey Rider

Oh, I see your mistake. You must DIVIDE by 60 to get Hz, not multiply by 60!