And I'm not happy about that, that's the one drawback to the TJ.
But - since you ask: I'm a retired computer/electronic tech and sometime engineer. I've lived and breathed microprocessors for decades, and made my living in that field. There are some things that a microprocessor can improve - and that can even be an engine when the darn thing is working correctly. Among other things, I worked for an industrial computer company for 13+ years - we were ALL about microprocessor control of darn near everything. I was also involved with this company's CAM setup, back in the day when CAM wasn't in wide use and we had to roll our own - blah, blah, blah.
But hanging a microprocessor on EVERYTHING, whether or not it makes any sense, much less economic sense, is stupid. In school, I was taught how cheap microprocessors would bring product costs down and reliability up. I'm sure that happened in some instances, but for the most part, all I see is increased costs and decreased reliability with little to no benefit to the end user. Coupled with that high-tech bugaboo, "Obsolescence" you have a disaster.
What is the #1 problem category discussed on this very forum? The damn computer and its sensors. The whole thing is a design nightmare because the tolerances between the computer and the sensors are too damn tight, nobody but MOPAR can make sensors that work reliably with the too-tight parameters in the computer. Trust me, I've BTDT - we had a similar problem with a certain product that was designed by a pretty much sheer genius of an engineer - but the design had zero tolerance for different batches of silicon, and had to be tweaked constantly when a new batch of chips came in because the guy was an idiot and ignored good design practices. For those who have a technical bent: It was an asynchronous digital state machine. You read that right - ASYNCHRONOUS. It depended on the propagation delay of each gate being constant in order to work. Switch silicon, different prop delay, failure. Guy got fired over it, even though it *was* a bitchin' design.
Getting back to our Jeep PCM: Thank Goddess for
@Wranglerfix or the Jeep TJ community would be up shit creek without a paddle. Yet the replacements cost beaucoup bucks - so much for "cheap" microprocessors. I'm sure there's no more than $50 worth of parts in the thing, but Wranglerfix can't source parts for anywhere near that, hence his necessarily high prices. If I could walk into Autozone and get a new computer for $50 - the way it should be - it wouldn't be an issue.
One of my many hats I wore over the years, was firmware writing/debugging in assembly code for about 10 years. I see buggy firmware - aka "embedded software" in things all the time. Fairly often, I can even come up with a good guess as to why something is acting the way it is - a certain overthought microprocessor Coke machine that was constantly crashing comes to mind. The most common problem and I see it ALL the time: Latency, latency, latency, latency EVERYWHERE. The grumpy old man says "You have megabytes of memory, gigahertz of clock cycles, and you still have more latency than something I could have created in 1982 with a 2 megahertz processor with 8K of ROM and 4K of RAM!" I would have been FIRED FOR CAUSE if I had written code as bad as the crap I see every damn day. Grumpy old man says "Write the damn thing in assembly and you won't have such problems." - but in reality a good C compiler with a programmer that knows how to use it will be PLENTY good enough 99.99999% of the time, esp. with today's fast processors and tons of memory. Hell, I drove a new Ford pickup a few years ago, and there was latency in the HORN. Why was a critical safety item run through the computer in the first place? Somewhere around 300ms latency from what I could tell. If you're going to insist on controlling the horn with the computer, then you use a modern processor's "fast interrupt". The ISR (Interrupt Service Routine) pushes the accumulator onto the stack, loads it with the command byte to turn on the horn relay, outputs same to the horn control port, pops the original accumulator value back, and returns from interrupt. What the FUCK are you doing for 300ms? Doable on a 1 megaherz 6502 ca 1977. Probably doable on a 4040 or even 4004 ca 1972!
I am convinced that a lot of these code monkeys not only didn't pass CS-101, but that many of them never even saw the inside of a CS-101 class. I'm talking basic, simple mistakes and doing things everyone who has been in a CS-101 class more than 6 weeks knows NOT to do. And I've seen it even from some of the biggest names in the business. Don't open a file and then leave it open. Don't read from non-existent I/O ports. Balance your stack. Always initialize your hardware. Fucking test your code, then give it to somebody else to test - they'll find all kinds of problems that you never will. If you're programming in C, "malloc" your memory then fucking CHECK that you actually got the memory you need, don't ASSUME...
As for car features - unless "it" solves a real problem and is demonstrably better than "before", I'm not usually interested. None of the crap put on modern cars makes any sense whatsoever. I don't want to pay for it, I don't want to pay to maintain it (Like I just did with my wife's car, the "telematics" unit went out), and I certainly don't want to deal with the hassle during the "ownership experience". Like I said, roll up the window, push the lock button and close the door! No key needed, no waste of time using the key just to roll up the windows. Of course, that problem can be solved by throwing yet MORE expensive tech at it - which makes even less sense.
Sorry for the tome - you asked...