Charles Manning

image
Firmware/Software Engineer

Biography has not been added

cdhmanning

's contributions
Articles
Comments
Discussions
    • An 8051... Really? I'd rather go with something that has some debug capability. AVR, PIC, whatever... but I guess there are cases where an 8051 is cheaper and just 1 cent is worth chasing on huge volumes. People forget that Moore's Law is a wave you can ride both ways: you get more for the same price - everyone knows that; you also get the same for cheaper which means that every year we can put micros into places we could not before. Of course much of that software is really simple - just basic state machines that can be exhaustively tested. Heck, some of those low end AVRs don't even have RAM - that limits what you can do, but also limits what you can screw up.

    • Vehicles have partitioned system buses for safety reasons, making many of these fears moot. Clearly you don't want Android running any of the body/safety electronics or the engine electronics. It would be unacceptable for a software crash or long boot delays after a glitch to prevent the engine from running properly, brakes from working or doors from opening. But those are not factors in an infotainment system. If the radio stops working I can still hit the brakes. If the GPS/route adviser takes 30 seconds to boot, that does not make the car unsafe. I don't buy the threat of Android not being able to handle CAN. Firstly, CAN high level protocols - such as J1939 - are easily processed by Android/Linux. The traffic levels are low: 1700 or so CAN frames per second. I have reliably processed CAN on a WinCE machine running at 60MHz and on older Linux systems. Secondly, even if the CAN on the infotainment system was hacked to go crazy, the link through to the critical CAN buses is (or should be) through a gateway. That gateway is responsible for ensuring that denial-of-service etc do not happen on the critical buses by limiting the type and frequency of message that can be passed from the infotainment system to the engine management system or body electronics. That gateway serves a similar role to a firewall in the internet. If you don't have a proper firewall, then you're screwed.

    • Jack, I still have some catching up to do at only 0x33, but I really think that us oldies have a huge advantage. When we look at a new technology, we have a framework of experience and knowledge to help understand it. The young-uns, however just see new shiny stuff with no context. eg. While everyone goes nuts about this new "cloud computing" thing and don't know what it means, many of us older people recognise that - for the most part - it is really just the thin client stuff of the 1970s delivered over www instead of X. Sure there are some differences that we need to be aware of, but that immediately gives us a handle on what it means. I think that allows us to grasp new technologies and their implications faster and better. Anecdotally there are also plenty places that look favourably on older and more experienced employees. I've never felt I've been given the "you're too old" line.

    • The interpretation of "runtime errors" is pretty open and it is perhaps naive to think that a switch from C to Ada is going to automatically minimize errors. If an Ada system gets a bounds violation which triggers an exception that system is still failing to provide its required function. It is still experiencing a runtime error.

    • If embedded.com really wants to engage the programmer community, then at least get a comment handling system that handles code snippets properly! Aaaargh!

    • This sounds very dangerous to me. C only has very rudimentary type checking and this does away with some of it. Automatic casting and such is Very Bad, IMHO. It is far more preferable to do something explicit, easily achieved with C's macro system. eg. void lock (Lock *); #define LockContainer(x) lock(&((*(x)).Lock) struct Foo { int stuff; Lock Lock; } *f; LockContainer(f);

    • I somewhat dislike "inheretance by composition" that places the "base object" as the first part of the "derived object" because: a) It makes some assumptions about layout. b) It can't support multiple inheretance (not that MI is a good idea...) I tend to use offsetof() and container_of() as per the Linux kernel since that allows more portable and flexible placement of the "base object" parts.

    • Leave out the app installer etc and people can't add Angry Birds or fart apps to your system or modify the apps in any way. It is easy enough to lock down an Android system. Software is hard, but the Android framework is surely no more complex than many other frameworks. It is getting easier to find programmers knowledgeable about Android than, say, Qt.

    • Car analogy: Sports cars are rubbish because they are useless offroad. They are also no replacement for a 5 ton dump druck. Similarly, it is easy to slag off software systems because they don't do everything that you want. Android is good for what it is good at, but it has not been designed to do every embedded Linux task. Luckily software can often be duct-taped together quite easily giving us a system with a sports car front end and dump truck back end. Eagerly awaiting the next installment...

    • I remember back in the day people writing ++i rather than i++ because the Borland C compiler generated different (and faster) code for ++i. However, any compiler worth its salt should figure that a free-standing i++ means exactly the same as i++ and should generate the same code for both. Of course when you throw your own data types into the mix, all bets are off.