5 ms·

This is not about the state of embedded software. It is about one program, the accelerator control of a Toyota. The author of the article is linkbaiting and f

by diydsp 13y ago

This is not about the state of embedded software. It is about one program, the accelerator control of a Toyota. The author of the article is linkbaiting and fearmongering to get you to purchase his/her static code analyzer for C++. As embedded software becomes ever more complex, it will benefit from methodologies developed for other platforms, such as desktop applications, etc. That is all that needs to be said. Please refrain from the "EEs don't know how to program" comments. Thank you.

pjc50 13y ago
As embedded software becomes ever more complex This is part of the problem in itself; the Toyota software appears to be far more complex than it needs to be.
robomartin 13y ago
> Please refrain from the "EEs don't know how to program" comments. No, no. As an EE I can tell you that lots of EE's really suck at software development. They never really took the time to study CS to a reasonable depth. As a result you see code that is just horrid and really naive. I've seen stuff that could blow up boards Hollywood style in a microsecond. Such things as potential timing conflicts turning on two MOSFETs such that you have cross conduction and draw hundreds of amps due to the direct short from +V to GND. Now, on the other hand, "desktop" programmers are equally --if not more-- dangerous than ignorant EE's. They have no clue and no experience with hostile embedded environments. I mean, the simple startup configuration code of some modern microcontrollers is the kind of thing you'd never see in desktop or web development. Then you have a myriad of other issues: watchdog timers, drooping/unreliable power supplies, static discharge-induced reset, load dump in automotive, similar applications, or noisy signals, sensor and key-panel data, potential single bit flip situations in aerospace/radiation environments, thermal issues, etc. The list is huge. These are issues that are far better understood by an EE. And so, the best embedded software developer is probably going to be an EE with real solid training of CS principles as well as an solid understanding of defensive or safety-critical electronic and software design principles. An example that comes to mind was when we designed a high-power motor controller many years ago. This thing could handle thousands of Watts. Testing included full output short circuits, zapping it with static electricity, exposing it to RF via close proximity antennas and coils and other torture tests. We discovered that under very rare conditions the output to go to full power when power was first applied AND the power connection was, I'll say, uniquely noisy. Imagine a corroded connection to a power strip on a marine platform that is moving. When power is applied, if you look at it on an oscilloscope, it looked like the most horrible noise you'd ever seen --except this noise was actually powering the board. We had to build a custom power tester using old motor brushes and an old commutator driven by a small motor in order to simulate ugly power supply scenarios. We later replaced this with a programmable digital system that could do the same. The embedded software and the hardware was then modified to deal with these ugly conditions and much worst cases as well. The thing was nearly bulletproof. So, yeah, drop any EE in front of a compiler and you'll probably end-up with really dangerous code. An EE with the right training and lots of scars would be the best option. Someone with a bachelors or masters in CS and no EE training and embedded world experience could be scary dangerous.
- nickff 13y ago
  I agree wholeheartedly with this comment, as computer and embedded programmers approach completely different tasks from completely different paradigms. The embedded system may have to run for years on end, with no one pressing control-alt-delete, performing a reset, or an update; it may also have to be very robust against unexpected situations, fail-operational or fail-safe or fail-deadly depending on the product, and protect itself from exposure to dangerous signals and environments. On the other hand, computer software must be easily maintained, updated to add new functions, work on new systems, be easy for the end-user to operate, and limited in scope. Expecting people with such different tasks to behave similarly is entirely unrealistic, and foolhardy.
deleted 13y ago
[deleted]
AndreyKarpov 13y ago
We are not the authors of this article. We have just translated the article and posted on our website. But times have you remembered about the analyzer, I want to show other people possibilities of the instrument: http://www.viva64.com/en/examples/ http://www.viva64.com/en/examples/

by diydsp 13y ago

pjc50 13y ago

As embedded software becomes ever more complex This is part of the problem in itself; the Toyota software appears to be far more complex than it needs to be.

robomartin 13y ago

> Please refrain from the "EEs don't know how to program" comments. No, no. As an EE I can tell you that lots of EE's really suck at software development. They never really took the time to study CS to a reasonable depth. As a result you see code that is just horrid and really naive. I've seen stuff that could blow up boards Hollywood style in a microsecond. Such things as potential timing conflicts turning on two MOSFETs such that you have cross conduction and draw hundreds of amps due to the direct short from +V to GND. Now, on the other hand, "desktop" programmers are equally --if not more-- dangerous than ignorant EE's. They have no clue and no experience with hostile embedded environments. I mean, the simple startup configuration code of some modern microcontrollers is the kind of thing you'd never see in desktop or web development. Then you have a myriad of other issues: watchdog timers, drooping/unreliable power supplies, static discharge-induced reset, load dump in automotive, similar applications, or noisy signals, sensor and key-panel data, potential single bit flip situations in aerospace/radiation environments, thermal issues, etc. The list is huge. These are issues that are far better understood by an EE. And so, the best embedded software developer is probably going to be an EE with real solid training of CS principles as well as an solid understanding of defensive or safety-critical electronic and software design principles. An example that comes to mind was when we designed a high-power motor controller many years ago. This thing could handle thousands of Watts. Testing included full output short circuits, zapping it with static electricity, exposing it to RF via close proximity antennas and coils and other torture tests. We discovered that under very rare conditions the output to go to full power when power was first applied AND the power connection was, I'll say, uniquely noisy. Imagine a corroded connection to a power strip on a marine platform that is moving. When power is applied, if you look at it on an oscilloscope, it looked like the most horrible noise you'd ever seen --except this noise was actually powering the board. We had to build a custom power tester using old motor brushes and an old commutator driven by a small motor in order to simulate ugly power supply scenarios. We later replaced this with a programmable digital system that could do the same. The embedded software and the hardware was then modified to deal with these ugly conditions and much worst cases as well. The thing was nearly bulletproof. So, yeah, drop any EE in front of a compiler and you'll probably end-up with really dangerous code. An EE with the right training and lots of scars would be the best option. Someone with a bachelors or masters in CS and no EE training and embedded world experience could be scary dangerous.

nickff 13y ago
I agree wholeheartedly with this comment, as computer and embedded programmers approach completely different tasks from completely different paradigms. The embedded system may have to run for years on end, with no one pressing control-alt-delete, performing a reset, or an update; it may also have to be very robust against unexpected situations, fail-operational or fail-safe or fail-deadly depending on the product, and protect itself from exposure to dangerous signals and environments. On the other hand, computer software must be easily maintained, updated to add new functions, work on new systems, be easy for the end-user to operate, and limited in scope. Expecting people with such different tasks to behave similarly is entirely unrealistic, and foolhardy.

deleted 13y ago

[deleted]

AndreyKarpov 13y ago

We are not the authors of this article. We have just translated the article and posted on our website. But times have you remembered about the analyzer, I want to show other people possibilities of the instrument: http://www.viva64.com/en/examples/ http://www.viva64.com/en/examples/