@klez

What exactly do you do? The reason I ask is because 50 hours a week I'm an Auto Tech. The remaining hours that I'm awake I code. This week my project has been reverse engineering a pc based scanner that I have to learn about how it interacts with OBDII / CAN in an attempt to make a super tool that gives me specific abilities. The people I deal with during day know nothing of computers and the people I deal with at night know nothing of cars.

You are the first person that I have ever heard mention both in the same post.

This is pretty off-topic from the OP, but I want to point out that the ISO standard for OBD-II is a fantastic reference for this kind of project. We built an OBD-II reader for our engineering capstone project, and that ISO standard was an invaluable resource for getting things to work.

If there's a university nearby, you might want to go check out their engineering library and see if they have a copy. I don't recall the ISO number off the top of my head. If you're really serious about the project, I think the book only costs around $400 or so.

Most of the "super abilities" provided by high-end scan tool / ECU flash packages work by using manufacturer-specific data sent over the CAN bus, not OBD-II itself.

Some newer and higher-end cars even use proprietary crypto keyed off of the VIN number and a shared secret to protect from access by third-party tools. There's a good-sized cottage industry in breaking proprietary ECU protocols and crypto, because there's a solid niche market in selling mechanics one $20,000 "multiflash" tool to replace their ten $10000 manufacturer-provided "diagnostic systems," especially in the high-end exotic market.

I was able to find enough resource online to build an ISO OBD-II scanner as my seventh-grade final project, without needing to resort to hunting down the standard. Today there are even open-source projects like http://en.wikipedia.org/wiki/OBDuino which can provide a solid code-based understanding of the three old OBD signaling types (PWM, VPW, ISO), as well as the basic protocol.

I'll let you all get back to topic at hand. I have to say thanks though. I never imagined getting so much helpful info. The super ability I seek seems like it would be in a less secure area because even cheap hardware store tools can do it. I am trying to remove, relocate, or hide fault codes without resetting the emissions monitors. That way as a hush hush marketing ploy of my business I can truly "guarantee to pass" and depending on the solution possibly guarantee to never fail again.

I hit an idea slump in my normal utility making and decided to put my otherwise wasted time to use.

Thanks Again ~

Of all the car I worked on (mostly Mitsubishi and Ssangyong) very few of them had non-standard procedures for erasing DTCs.

I don't know what you mean by 'erasing the emission monitor', unless you mean the freeze frame, which usually gets erased when you erase DTCs with the standard 0x14 request.

Anyway I work exactly as you do, by reverse-engineering official tools.

And I'm not very knowledgeable about cars anyway :)

Or just don't use switch. If it's a small expression, an if/else chain takes no more lines of code and is not less efficient. If it's a large expression, it might be better expressed with a function pointer table.

I'm not a zealot on this stuff, and write switch statements regularly (though I do strongly prefer if chains for most stuff) but if you're really hitting this regularly I think a change in process might be in order.

It can be slightly less efficient when (on supporting architectures) the compiler could automatically generate a jump table in place of stacked conditionals, which it cannot do for a chain of ifs.

This is a myth that won't die. Jump tables can't be branch predicted, so they're generally significantly slower unless the number of cases is very high. And it's not true that the compiler "cannot" emit a jump table for an if chain anyway. A bunch of if/else-if expressions of the form "some_var == constant" can certainly be detected (though again, it probably isn't).

Unfortunately, I'm not able to decide to do this.

Most of our code is machine-generated, and our boss doesn't want to touch the generator in general.

Always close your stuff before filling it. E.g. instead of typing ...

switch (uint8_t bla){ case 0: stuff; ...

... and filling everything as you go along, first type the skeleton ...

switch () {case: break; default: break;}

... and then fill everything in. It's anal/pedantic but it becomes second nature really fast. Do it for everything (loops, structs, functions,...).

I once lost 2 entire days of my life I kid you not hunting an if (a = b) that had to be a == b and decided to change my approach.

I can empathize. I've always felt that implementation of switch statement in C is a bomb waiting to explode.

One of the many good decisions that went into C# is reversing how it works; in other words making it compulsory to explicitly state when you need control to fall from one case to another.

If you're having this kind of problem a lot, now might be an excellent time to start using a lint tool in your development process. It'll catch these things.

Long story short, coding standard and tooling are very poor at my current job.

I'm leaving in a week, so it won't be a problem for me anymore...