Advertisement

sgh798

image
manager

Biography has not been added

sgh798

's contributions
Articles
Comments
    • WiFi or Bluetooth may be suitable for IoT products in houses, but there are many hundreds of millions of industrial IoT devices due to be installed in the next few years where those protocols are completely unsuitable. Also the concept of a WiFi smoke detector is terrifying - the number of times I have to restart my WiFi router because it's hung up, am I expected not to have functional smoke detectors every time that happens? Safety devices such as these must be developed in a completely different manner (ISO26262 etc) to domestic WiFi routers - combining the two would be illegal in most countries. And what about power consumption? A smoke detector must run for a few years on a single battery, as most installations do not have mains power. What is a WiFi connection going to do to the battery life?

    • The Motorola MC88000 definitely belongs in here - Motorola's first attempt at a RISC processor, I guess killed off by their involvement in the Power PC programme shortly afterwards. It was nice CPU though. I also played about with the AMD 27000 RISC microprocessor, which failed but had a slightly elongated life in microcontroller form. It was used in a printer design I had some involvement with. The one thing I remember is the instruction following a branch statement was always executed due to the pipelining, which made assembly programming a bit weird! Of course AMD got rather distracted by the PC market since then!

    • I was thinking about the MC6809, but not sure if you could say it was a flop, it went in quite a few home computers. Of course the release of the 68000 just a year or so later killed it off, a shame as it was a really nice CPU. It lasted many more years in the guise of the very similar 68HC12 microcontroller though.

    • Bwalker came close to the important point here! The emissions requirements are a given. All automotive companies must achieve them otherwise they won't sell any cars. The solution is of course a well designed engine with a well designed Engine Management ECU. The idea that one rogue engineer could secretly "fix" the problem with a special software mode because the mechanical engine design was not good enough is ridiculous! I've worked on Engine Management ECUs and they run to tens of thousands of lines of code - they're not knocked up in the corner by Bob on his PIC16! There will have been a whole team of firmware engineers working on this product, with a Project Manager guiding them all the way, and a Development Manager on his back. Put yourself in one of those software engineer's positions. If the mechanical design isn't good enough, you're going to shout "it's not good enough". Why would you risk your job doing something dodgy when it's not your fault anyway, and you have nothing to gain personally from doing it? I think it's quite clear that this was a business decision, not made by individual engineers, but by management somewhere with their big bonuses at stake. It's the senior management that got the big rewards from this decision - millions of sales. We engineers don't get big sales bonuses. The fact that a couple of software engineers have been blamed for this is scandalous in my mind. This is senior management dodging the bullet, and the rest of the world accepting their word for it because they have no idea of how embedded software development works. I can assure Bwalker that the "individual engineer" (actually a team) would have been rewarded with a plate of cakes and a 'well done guys' comment on the company intranet - definitely not worth a prison sentence!

    • Thanks for that Jack. Last year I implemented a large quality improvement programme in our embedded firmware development team, and investigated a great many software metrics. Complexity was one of them (measured 4 different ways including McCabe), and we analysed the complexity of over 300 functions which had contained detected bugs. Surprisingly there was no correlation between a function's complexity and the probability of it containing a defect. On further analysis, we found 75% of the defects were in the *interactions* between functions, tasks and modules (e.g. timing, data sharing, etc) rather than in the functions themselves. Therefore it was the complexity of the architecture rather than the code that was important. I think many of the software quality tomes make assumptions which seem perfectly reasonable when you read them, and it's only when you come to implement it in practice that you find they're not all correct! Or maybe our team are different from everyone else!

    • 1. Add support for binary numbers. Still supporting Octal, but not binary, is an anachronism! I always have a file "binary.h" which defines b00000000 to b11111111 but it can't always be used. 2. Allow "rotates" as well as shifts. All microcontrollers support rotates, often in both forms (through carry and into carry), so why shouldn't C? Not sure what the syntax would be but access to the carry flag during a rotate is sometimes (admittedly rarely) useful, but implementing it in C is horrible. 3. Plenty of other tiny niggles gathered over 35 years that I can't think of now, but nothing major. If any major changes were necessary, other languages would have evolved (which they did) that embedded engineers would all dump C and start using (which they didn't)!