someEmbeddedGuy

image
Senior Firmware Engineer

Biography has not been added

someEmbeddedGuy

's contributions
Articles
Comments
    • Sigh. I have a real affinity for several early microcontrollers like the RCA 1802 or the 8051. They got into my blood and I have never quite gotten them out. (Haven't tried that hard!) The bit and pin handling instructions for the 8051 are incredible and while the power consumption of the 1802 was unequaled, each eventually like all of us become bright points in history. I now use ARM M3 and soon M4 core based designs. The tools, performance, peripherals and memory options are incredible. I would have a hard time going back to the resource constrained days of the 8051 and I suppose am okay with merely remembering them... Sid

    • Just about everything I am involved with in the embedded world is ARM based. (We still have a couple legacy AVR centric products that will soon be replaced with ARM devices.) New designs will also be ARM centric. Just too rich of an ecosystem internally and externally not to use it.

    • Saleae has certainly come up with a winning product. I have used mine extensively. I have written custom a custom plugin to analyze IR signals. It is well built and the included RS232,I2C capabilities make it invaluable in developing serial applications. Probably the most valuable debugging tool I have next to my DMM. The only thing more I would ask for is a couple analog channels.

    • 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.

    • 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.