USA Firmware


USA Firmware is an award winning provider of design services located in Brecksville, Ohio. USA Firmware's team is made up of expert level best in class talent. As a result our customers return on investment is maximized for the life of the design. 

USA Firmware
Smart and Connected

USA Firmware

's contributions
    • Porting firmware is more common as technology improves. Bare-metal firmware ports can be difficult to do without some planning. This article covers some basic concepts to improve the likelihood of success.

    • Firmware is coming of age. This series addresses the changes happening in the industry that are helping firmware to mature and find its footing.

    • Simplification is the byproduct of creating basic C objects, using some simple RTOS features, and abstracting the hardware.

    • Virtual development is here and the timing is dead on, as more and more industries demand connected embedded systems.

    • If you're a C programmer who isn't yet proficient in C++, this doesn't mean you can't use simple object-oriented practices in C. This blog we discuss placing public variables.

    • Although most C programmers aren't proficient in C++, they can still use simple object-oriented practices. This series of blogs presents simple ways to use object-oriented practices in C.

    • Keep in mind that the emphasis is on replacing the old code with drivers. What is assumed here is that you have neither HAL nor driver in the legacy base. So to move it safely to a new environment you start with a HAL. Once moved if you intend on maintaining the old behavior it's probably best to hang on to the HAL but have HAL call into a driver layer. This allows you to easily go back and forth for testing purposes and minimize the differences between the hold and new behavior. Thanks for the observation.

    • Actually you are touching on the issue. The underlying issue is that the older code may suffer from the lack of a clean isolated driver. As a result the code likely has hardware specific elements in the code vs. a simple and platform independent interface to work with. A lot of what I write about is how to transition from old poorly constructed code. We all see it and the idea is to help make a transition away using good practices. HAL itself isn't the issue. HAL abstracts the hardware away from the firmware which is precisely what a good driver should do. Thanks for your comments!

    • Here is my 'alternative' to Step Number 2 'Python Style' and I'm not talking about the programming language: Step Number 2 (The Monty Python Version): “First shalt thou take out the Holy Pin, then shalt thou count to three, no more, no less. Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then lobbest thou thy Holy Hand Grenade of Antioch towards thy firmware, who being naughty in My sight, shall snuff it.”

    • Hello Pkumarn, Thank you for the feedback. You are correct, this is primarily good practice! I'm trying to teach the reader about the importance of object oriented C, abstraction of the hardware and how a real time OS can aid in using these two important principles to develop simple and well constructed topologies. Not all firmware engineers utilize these principles since the majority of us come from EE backgrounds. The title of the article is intended really just to marry the 3 topics. In retrospect it could have been more clear as you imply. All good points, thank you! Bob

    • Hi John, No you didn't miss anything. I think you're right. I'll put something together for a follow up article. Thanks for the feedback! Bob

    • Thanks for your comments Allen. Interestingly I have some personal connections to both Kodak and RIT. My father graduated from RIT in the 60's, spent his career at IBM and much of my family are or were Kodak folk. Thanks again.

    • Thanks for the comments. Perhaps a half year of C++ but I would stand by a full year of C, it's too pervasive. Another area we could reduce might be requiring all four Knuth courses. This would allow us to fit in a bit more math. This is a work in progress so I appreciate the feedback.