[arghx7]

Originally Posted by stugray

This is still somewhat related to the OP:
1 - When the ECU boots, I assume that it transfers the software image from Flash Memory to RAM, then begins executing from RAM - Yes?

I'm not an expert on the minutiae of how that kind of low-level handling of data occurs on a production controller (stock ECU that comes on your car). On a $10k prototype ECU, yes that's true for the most part. There are external RAM modules that plug into a modified ECU. And that's why you can make realtime changes to anything that would normally be stored in ROM. On a stock ECU, only small portions run in RAM at a time. It would be WAY too expensive (in the mass production sense) to have the amount of RAM equal or exceed the amount of flash memory on you mom's minivan.

2 - Once the ECU SW is running, the CAN bus monitor may request data by asking directly for memory addresses from RAM? I have a tactrix cable (waiting on definitions) and an ELM327 OBDII monitor. So when the OBDII monitor is requesting data, is the ECU actually just reporting memory contents?

Again, I don't know every detail of how all that is handled on the lowest level of the system and how it varies with manufacturers. What I can tell you is the ECU is sending a ton of messages across the bus in its normal operations. When you send a request through a normal OBD II, you are communicating through a standardized system for requesting data. You are intrusively asking for something; you're not reading RAM values with some tool you can get off ebay. You're reading whatever the ECU chose to report, at whatever speed it decides to give you based on its prioritizing of the bus.

IF you have the right commercial tools, you can read the "real" CAN signals that are already going on the network. Probably the most common commerical tool is Vector CANalyzer. This includes things like vehicle yaw rates, steering angle, turn signal commands, and torque requests from various modules. It's all (or some portions) a bunch of hexidecimal nonsense unless you have access to the CAN .dbc file from the OEM.

3 - I read some of the "AccessTUNER_HelpFile_Subaru" manual from COBB tuning. The way it reads, it sounds like the manual is suggesting that you can make modifications to parameters in the MAPs (obviously in RAM, not flash) while the engine is running. Is that the case?
If not it seems like having to reflash for every tiny adjustment would be a huge PITA (not to mention a risk to the ECU having to do it too often).

If I run a standalone ECU like an AEM EMS, for the most part I can change any important value in the ECU in real time. If I have a prototype stock ECU (which is very very expensive) and all the right resources I can move all the ROM values into an external RAM module. From there, I can change anything I want in real time and record at a very speed.

With an Accessport (and a few other tools out there for various applications), Cobb has cleverly managed to use built-in RAM on the stock ECU so that some realtime changes are possible. So when you tune a WRX with AccessTuner, you get a small list of "realtime maps" which include primary fuel and spark, boost control, rev limiter, etc. This is a tiny portion of all the normal ROM values, but it's all you need for most tuning activities. These values will stay active as long as the battery isn't unplugged. You have to flash the changes to the stock ECU (just like a dealer tool would) to make the changes permanent. The final result is a much easier tuning process for most things in an affordable and usable package.

Some things can be very very difficult or at least time consuming to tune in a vehicle when reflashing is the only method. MAF and injector scaling is a big one, and boost control. IMO, that alone is worth the money for going with Cobb over Opensource on a DIY tuning project if you have a WRX/STi.

Originally Posted by FirestormFRS

That's so far off base. Because they do a better job of controlling documentation than other companies doesn't mean they don't document every single bit of information about every single step of the manufacturing process. The most impressive part of working for them is the level at which you learn to document every single thing.....twice.

Those guys are the kings of crossing your T's and dotting your I's.

I'm not referring to manufacturing. That's something the supplier deals with. I am referring to information on what all the maps in the ECU do and how all the values are calculated. I am referring to information on what tables to modify in what order to actually make useful changes.

Now, are some polished information about controls given to government regulators to satisfy certain questions of OBD and emissions? Of course.