Safe Speed Forums

Quite!

Reminds me of the old chestnut about the Infamous IBM "printer upgrade" scam! (Urban legend possibly, but neverthless quite believable)

_________________
"The road to a police state is paved with public safety legislation"

That would imply some sort of time-based code which either kept track of absolute time (and why would you need to do that in an ECU?), or a non-volatile value that was constantly incremented from the moment the ECU was first powered up after programming (perhaps a mileage or engine runtime counter - both of which you could reasonably predict an upper bound for given how long you, in a burst of wild optimism, expect the engine to survive and thus cater for when choosing the size of the variable...)




In a similar vein, you almost certainly also never own the whole TV, VCR, DVD player, washing machine, microwave, fridge/freezer, vacuum cleaner, alarm clock, radio, central heating boiler, phone, digital watch, calculator, camera...




In all likelihood, it won't happen. With a semi-intelligent engineer writing the code and actively testing for out of bounds values as input to a piece of code, or for potential rollover when modifying a value, and with the release candidate system then being subjected to a rigorous test regime which exercises the whole system over a period of x hours/days/weeks/months (delete as appropriate), noddy errors like this should never make it out of the door. It can still happen, but programmers have learned from the mistakes of their peers, so you'd have to be a really crap design engineer not to be aware of the risks, and an even crappier test engineer not to exercise the system in ways that push the potentially dangerous values towards/beyond their limits.

_________________
Chris

I've put the operative word in bold. Every prominent person in the computer industry expects all large programs to have errors, Twister. You must know that the combinatorial explosion of full path analysis makes exhaustive testing impossible in a finite timescale. So it goes, and multi-threading makes it a hundred time worse!



That’s not all. Cars were once a passion, but now they are no more distinguished than a TV, VCR, DVD player, washing machine, microwave, fridge/freezer, vacuum cleaner, alarm clock, radio, central heating boiler,
phone, digital watch, calculator, camera…

PS: do you know how to set command line options in NetBeans? I'm using it instead of Eclipse...

PPS: Don't worry, got it. Right click on Project, properties.

It doesn’t have to be that way. All the car computers do the exact same thing – monitor analog and digital instruments, compute responses, and send signals to actuators of various kinds. It’s not really rocket science – even I was doing this stuff back in ’75, with pneumatic computers (believe it or not).

It’s a defined art, so there is scope for commoditisation, with the hugely increased reliability and reduced costs that it brings. But makers hate “reduced costs” so they load the systems with “trade secrets”, to squash competitors.

We need to reassert control over them, and tell them to serve their customers properly using commodity components. I’m fed up with those guys all re-inventing the same wheel over and over again, and each putting in their own set of mistakes. No wonder the cost of motoring is so high.

Ah yes, the "computer industry", where end-users are treated as beta testers and ready access to the internet has given rise to the concept of rolling out fixes on a regular basis as and when the bugs are discovered, rather than trying to minimise the number of bugs shipped in the first place

However, we were talking about embedded systems, and I'm sure you know what a difference this makes. Yes, regardless of the target environment, the more lines of code you have, the more likely you are to have an error. But when you're targetting a system, which once it's let loose in the big wide world cannot easily be updated, then you pay considerably more attention to getting things working properly before you ship. You also (usually) have the advantage of being in full control of the runtime environment, at least at the software level if not also at the hardware level, which makes life easier.




Which is why I personally steer well clear of using such desktop-like programming techniques in my embedded code. Whilst I'm sure there are some embedded systems where using multi-threading is a genuinely sane design decision, so far I've been able to get everything done with single-threaded code supplemented by the bare minimum of interrupt handlers, and I suspect the majority of embedded systems are no different. Call me old fashioned, but I do like to know what my systems are doing at all times

_________________
Chris

Yes. And some of the satellite systems I have worked on are considerably more difficult to update than a car computer. Yet even there, as you know, glitches get through to the launch pad and into space. Actually, keeping a spacecraft operational is nothing more than a sequence of endless kludges to fix design faults in it. Rather like a car!



Yes, keep it simple, as long as the loop is fast enough to service the events as they come in. Out of interest, how do you “decouple” the incoming events from the servicing of them? A circular queue? What about overflow?

There's absolutely nothing to stop you buying any of the aftermarket fuel injection systems and replacing the one on your car. You then get complete control of all the programming. Better still, pop down to Maplins and just make one yourself!

Unfortunately, it's a bit trickier than most people imagine on cars that need to meet current emissions limits. The whole reason the industry abandoned carburettors was because they couldn't meter the engine's fuel requirements precisely enough. If you look at the very last carburated cars from the early 1990s, they are festooned with vacuum pipes and other gizmos to try and make them good enough but in the end, fuel injection was just a better all round solution.

Getting back to that little Indian car, if you're expecting it to turn up with a nice old SU carb on the side of the head to fiddle with and a distributor with "points" in it and a pinch bolt so that you can swivel it round, I think you'll be disappointed! Unless it has less than 20 horsepower, it will need all the same complex stuff as any other car - ECU, all the sensors, catalyst, onboard diagnostics... The manufacturers don't fit all this for fun, they're forced to do it by legislation!

I'm also not convinced by the assertion that ALL modern cars are characterless "white goods". (Veyron anyone)? Did Marinas and Allegros and Maestros have "character"? They might nowadays - simply by virtue of their rarity, but I think they were pretty ordinary in their day. I think pre-war cars WERE a lot more different to one another than their modern counterparts but that happens in pretty much any field. When first invented, we (mankind) are on the steep part of the learning curve. The innovations are very radical and come very quickly. Gradually, as we learn what works and what doesn't, we converge on solutions that are ever more similar. (trains, planes, etc).

In my opinion it all went down hill after the Stanley Steamer, the Sentinel Steam Wagon and the Turner Manufacturing Company (Wolverhampton) steam powered car which ran on paraffin!

_________________
www.thatsnews.org.uk / www.thatsnews.blogspot.com / http://thatsmotoring.blogspot.com/

Or a VX Monaro/VXR8, Ford GT40, Dodge Viper, McLaren SLR, Fiat Multipla, Smart, anything wearing a Lamborghini, Pagani, TVR, Ascari etc. badge There's plenty of cars out there that don't just look as if they've been forged from the same mould as the car next to them, and which are more than just a means of getting from A to B.

_________________
Chris

Ok, my apologies, but really suggesting that a failed lambda sensor means a trip to the dealers doesn't exactly give me the impression of a person able to use a socket set.



LOL, my 1990 Volvo has a lambda sensor. I wonder if it's ever been replaced?


You should probably look at VEMS then. It's a completely open source ECU, both the hardware design and the software are freely available (though the developers will sell you a pre-made one if you like). Apparently it works quite well. I'm aware of a couple of people using it in their 200SXs.
OpenECU is more about extracting the software from the manufacturers ECU, finding out where the maps are in the ROM image, tinkering with those and uploading it again. There's a company called ECUtek who make complete replacement software for Subaru ECUs that is easier to map. The older Nissan ECUs are a little more work as the maps are stored in a ROM that has to be physically replaced, fortunately if you have any brains then when you do this you'll replace it with a ROM socket and from then on it's dead easy. You can even have switchable maps by getting a ROM with higher capacity than Nissan's one and hooking up the extra address pins to one or more switches.
My GF is currently working on a project relating to the automatic gearbox ECU in her 200sx, by intercepting the signals from said ECU to the gearbox she can figure out how to select those gears, then you just need a micro controller (which is all an ECU really is) sat in the middle of those wires listening to them and keeping track of what gear the autobox ECU thinks its in and a switch on the dash as to whether it passes those signals on or not. If not then you need two more buttons to make her device change up or down a gear. Instant flappy paddle conversion!
Of course this has been delayed as the 200SX is currently her only way of getting to work!