Sid King

Senior Firmware Engineer

Biography has not been added


's contributions
    • Peopleware is one of the best books about productive engineering environments I have read. Before anyone sets out to design work space for engineers it should be required read. I also really like the MISRA rules, read those a few years ago while working on robotic vehicle software. Anyone that writes safety critical code should consider adopting them. (It wouldn't hurt for the rest of us to do so as well.)

    • I think the loss of OS independence must be weighed with the cost of a third party RTOS. I have just been through an in-depth evaluation of three major RTOS/TCP/IP Stack providers. While the quality of the commercial offerings is superb, the pricing and licensing models can be somewhat restrictive. I have used Stellarisware from TI on several projects and found it is reliable clean code. I suspect that the coding style issues brought up in this article may be addressed in later releases of TI-RTOS. It seems that this offering will be especially relevant for lower volume design projects that have limited resources or possibly start-ups trying to get something out the door quickly. The TI RTOS isn't for everyone, but I feel it certainly addresses a need. That being said, I don't think we will see it entirely replace the third party products offered for TI processors either.

    • Hope it has longer up-time than my Android phone!

    • I have written software on commercial aircraft embedded control systems governed by DO178-B as well as on-vehicle control software for autonomous vehicles. My view is that we had better require much of the same reliability or greater on ground based autonomous vehicles that we do on commercial aircraft software systems. The margin for error in the air when at 35,000 feet might be +/- 100 feet but on the ground a margin of error of +/- 2 feet might spell disaster. The only difference between autonomous aircraft and autonomous ground vehicles is that a single event on the ground would typically have fewer casualties. However the opportunity for a ground event is several magnitudes greater. My vote is a wait-and-see approach to see how the industry proposes to make autonomous vehicles safe for the general public. The Nevada law that allows autonomous vehicles to be licensed as long as there is a driver and passenger is an excellent first step to getting the level of testing needed before deployment to the general public.

    • I have been working in the tech industry since the late 1970's. My first job as a technician was working for an RF engineer building prototypes. It piqued my interest in radio significantly. As always, time and money were always limited and I kept getting my amateur license as a goal. In the last few years I placed that on my bucket list. (Along with getting my pilot's license!) Long story short, I just took the test and now have a technician class license. (Picking up a couple used transceivers at a surplus sale helped give me the final motivation and might I add eliminated my final excuse!) The technical part of that test was very easy and look forward to upgrading to general class as soon as possible. (Extra class is my end goal.) Especially now, I like being able to improve my skills and challenge myself. I am involved with Zigbee radios in some of my firmware work but find the discipline of preparing for a test invigorating and mind expanding. I am excited to get involved with some of the many new Ham Radio areas involved with Embedded hardware/software/firmware. Embedded systems appear to have really re-vitalized Amateur Radio.

    • As has been said before, Android is not a real-time system platform. Perhaps there are things that can be done to the underlying Linux kernel to make it more so, but it truly is not that way out of the box. Also, in addition to the kernel work to enable these potential real-time capabilities, one would need to use the Android NDK which by-the-way utilizes 'C' to create those applications. As for cost per unit, the memory and processor bandwidth required by Android significantly increases BOM costs. In some applications, that is not a big deal, but the bulk of processors sold are still going into dedicated simple low-cost circuits. (Power consumption is another point where Android does not do as well as a basic or no OS simple application on say an M3 ARM core.) There is a reason why company's like TI continue to release both Android and non Android capable processors for their customers. There is plenty of room for both deeply embedded platforms and the more GUI rich Android type platforms. In the company I work for we are developing some products using Linux/Android but many will continue to use deeply embedded 8, 16 or 32 processors.

    • We have been evaluating using Android for doing an upcoming project. I was tasked with creating a demo to see how well it would fit with what we want to accomplish. Working with Android is really pretty simple. I downloaded the free tools from Google, used an off-the-shelf development board from a popular vendor, (a great place to start) and went from there with their port of Android. For testing I loaded the created app(s) on that board as well as my own Android phone. The simulator was also very helpful. I also created a similar app using QT Quick. Both environments have their advantages/challenges but both seem to really give developers some nice tools to work with if a GUI is needed. I would say that the commercial licensing arrangements with Android are much more friendly than with QT. (Apache license with Android works very well with business strategies.) With QT technically, I can not commercially release any internal demo work that I did using the free tools I downloaded. I would have to re-do all of that work after purchasing the license. Also every developer that uses it needs to have a rather expensive separate license as well. Seems that if QT does not modify their license to be more business friendly, they will likely be left behind... A true shame for such a capable GUI platform.

    • I second the Saleae Logic analyzer. I have one and use it often. I think nearly every firmware guy in my group has one as well. (6 or 7) The price of the tool is not always the best measure of its' utility.

    • Last time I had the opportunity to be in a Heathkit store was back in '79 at the Phoenix, AZ store. I saw an interesting looking older gray haired gentleman dressed in pants with paint on them and he was accompanied by a much younger guy in a suit. Seemed like an odd pair and then I recognized the older gentleman as former U.S. Senator Barry Goldwater. (I understand he was quite the Ham Radio enthusiast.) In my youthful exuberance I walked up and introduced myself to him. He was very kind, personable and fascinating. Too bad more of our modern politicians aren't so much into creating and using cool technology...

    • Seemed to be a very lightweight editorial not really a "Paper"... I am currently working with four different Cortex M3 processors from two vendors. While the peripherals are a little different for each, I use the same compiler/debugger tool chain from IAR all of them. Because of that, my job is greatly simplified. (Tool familiarity, firmware build machine setup, tool cost savings, code generation is consistent as well as a host of other benefits.) Creating an abstraction layer for the unique peripheral differences is not that big of a project. In addition, portable code is do-able and not very difficult to write.