Any book recommendations for C++ techniques for deeply embedded systems? I know how to do this, but I kind of picked it up by osmosis in the
90's. I need a book I can recommend to folks.
I'm not looking for something that assumes a hard disk and a Pentium or Power PC -- I'm looking for a solid reference for using C++ in a deeply embedded system that's going to have a ton of code anyway but will benefit from the ease of translating good design to code that C++ provides.
(and if you want to have the whole C++ vs. C flame war again -- please start another thread, I've heard your arguments before and they didn't apply then).
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
Pardon me Tim, this is a end user point of view and is almost trivial ... Please don't forget you are talking to designers
There are some uninterruptable power supplies driven by a PowerPC (Freescale PowerQUICC).
After years programming C/C++ on Posix systems (Embedded sys and Desktop) i can say that this is likely the same recurrent issues we have to face. So IMHO there is no special book helping us to become a better programmer, just read code, copy, experiment new implementations ... and refine our skills, forget and relearning all by another way ... It take years.
The engine assembly would be too hot. Some are under the hood, but far from the engine. Some are inside the passenger compartment. Toyota now probably wish they had not push this "drive by wire" technology too hard.
Why? Haven't you heard? It *can't* possibly be the electronics at fault... (yeah, sure)
I wonder what the legal consequences would be of someone reverse engineering one of these controllers *and* the black box/log. I suspect you would end up spending lots of money being harassed! :<
If the engine management computer dies then the engine stops working, yes. But we're not at the point yet where just because one part of your car dies you throw away the whole car.
That's because there's this technology that's still not quite dead yet called "repair". Perhaps you're young and haven't heard of it. You take your car to someone called a "mechanic"; they figure out which parts of the car are broken, and they replace them. Car manufacturers have very cleverly made their cars so that many of the parts are interchangeable, which means that instead of tossing out the whole car, your mechanic just tosses out the broken parts, and puts in new ones at much less than the cost of the whole car.
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
That presumes that: a) the "mechanic" can actually identify the broken part, and: b) a replacement part is actually available.
a) usually happens, but I often have problems with b). Older cars.
The last time I had a problen with b), after a lot of digging around I found the part on Amazon.com ??? What's a bookseller doing selling automotive parts??
--
ArarghMail003 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the extra stuff from the reply address.
That is why I am questioning its definition as "deeply embedded" within the engine (using the definition of deeply embedded from earlier in the thread). If it's in its own box then it isn't embedded within the engine, its a completely separate component of the car.
Interesting divergence of definitions. Without really arguing with you ('cause there's no really good definition of 'embedded' yet, much less 'deeply embedded'), let me give you mine:
Establish a spectrum of uses of a microprocessor.
On one end, put the computer that I have on my lap -- it runs Linux (or Windows), I'm composing a newsgroup response on it, there are games and office programs and scientific analysis programs lying dormant on it. It can do a bazillion different things, all oriented to the user, but without attaching additional hardware to it the thing is incapable of turning a motor, lighting a light (other than the screen backlight), maintaining a temperature, making a spark plug fire at a certain time, etc.
On the other end of this spectrum put a microcontroller that does nothing with its clock cycles but retrieve voltage measurements from one or more ADCs, perform signal processing algorithms on the readings, then writes the calculated values out to DACs. Give it no keyboard or keyboard interface, give it no screen or screen driver. If you're smart you'll give it a diagnostic interface so it can talk to an external computer, but in normal use that diagnostic interface won't be active.
I label the one end of the spectrum "regular old computer" or "personal computer", and the other end of the spectrum "deeply embedded". Even if that deeply embedded processor is mounted on a post in a grain field in Nebraska, even if it is so physically 'un-embedded' that it is sun-bleached and has bird droppings on it, functionally it is still 'deeply embedded' and about as far from a PC as you can get, even when a farm hand eats his lunch with his back against the pole, playing solitaire on his laptop.
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.