I have seen a significant drop off of companies conducting code reviews, which is unsettling because code reviews are still extremely valuable.
The code review process is challenging, and real-time embedded systems have the additional challenge of software and hardware interfaces. That is why I recommend adding a hardware designer to participate in the code review. It can really help to solve problems quickly that may arise during the review.
I have heard Management's reasons to forgo code reviews:
1. It ties up precious resources
2. Not sure how to conduct one properly
3. Might upset a few of our developers
4. The meeting becomes an excuse to attack someone
5. Not on the schedule
But I feel that in spite of all the trouble it may entail, the goal of creating high-quality, sustainable, maintainable code in a timely manner is well worth the effort. I have found design reviews and code reviews to be invaluable tools to improve the actual quality of the software, stimulate growth, enforce coding standards and find bugs early.
In my experience, having led code reviews and having been a member of peer teams reviewing code, I always felt that it was a positive learning experience. Oftentimes simply asking the developer basic questions and allowing them to explain their thinking leads to amazing results.
Are you using code reviews as an integral part of your embedded development experience? What challenges are you having?
-Gary
When it comes to technological solutions, you want a firm that has a proven track record of excellence. As one of the first software and hardware consulting firms in the Northeastern United States, Advanced Decisions is a leader in the industry. Our strength is not only in the experience that we bring, but also in our approach to developing solutions.
Showing posts with label embedded development. Show all posts
Showing posts with label embedded development. Show all posts
Friday, September 28, 2012
Monday, September 24, 2012
Changing to a New Embedded Development Platform
I imagine that for you, as for me, changing to a new firmware development platform is a serious undertaking.
We have all used plenty of development platforms and software development kits (SDKs) from various manufacturers in our careers--and since most of them share a great degree of commonality, we are comfortable with changing to a new embedded development platform. However, I find that the significant challenge lies in discovery of the differences between what we have used and are familiar with and the nuances of the new platform.
Changing to a different development platform is typically accompanied by a change in chip family and / or manufacturer. I find that truly mastering the new platform involves both reading through the reference materials while working with the new tool kit. (For application programmers, the creation of the ubiquitous "Hello World" software program is still the typical starting point.)
But embedded programmers face a different set of challenges. We actually have to get the hardware working first for any software to run (i.e. the Board Support Package (BSP) and the accompanying evaluation board).
In many embedded development projects, product hardware is designed and developed in parallel with the new firmware. Since the product hardware is usually based upon reference designs from the chip manufacturer, making sure the SDK's board support package works properly with the manufacturer's evaluation board is a natural first step.
I start by installing the SDK on my development computer, getting it operational and integrating it with the source control program that I plan to use. Since a typical microprocessor or microcontroller can be configured in so many ways I focus on modifying the BSP to get the evaluation board operational as close to the final product configuration as possible. Once I can demonstrate that I can configure the BSP to control the evaluation board specific hardware (e.g. LEDs blinking, testing memory, exercising I/O, and communication via USB, Bluetooth, RS232 or LAN) then I am ready to turn my attention to developing the product firmware. Often the initial firmware evolves to the boot-up diagnostic software for the embedded product.
What tips or process do you suggest when transitioning to a new embedded development platform?
-Gary
We have all used plenty of development platforms and software development kits (SDKs) from various manufacturers in our careers--and since most of them share a great degree of commonality, we are comfortable with changing to a new embedded development platform. However, I find that the significant challenge lies in discovery of the differences between what we have used and are familiar with and the nuances of the new platform.
Changing to a different development platform is typically accompanied by a change in chip family and / or manufacturer. I find that truly mastering the new platform involves both reading through the reference materials while working with the new tool kit. (For application programmers, the creation of the ubiquitous "Hello World" software program is still the typical starting point.)
But embedded programmers face a different set of challenges. We actually have to get the hardware working first for any software to run (i.e. the Board Support Package (BSP) and the accompanying evaluation board).
In many embedded development projects, product hardware is designed and developed in parallel with the new firmware. Since the product hardware is usually based upon reference designs from the chip manufacturer, making sure the SDK's board support package works properly with the manufacturer's evaluation board is a natural first step.
I start by installing the SDK on my development computer, getting it operational and integrating it with the source control program that I plan to use. Since a typical microprocessor or microcontroller can be configured in so many ways I focus on modifying the BSP to get the evaluation board operational as close to the final product configuration as possible. Once I can demonstrate that I can configure the BSP to control the evaluation board specific hardware (e.g. LEDs blinking, testing memory, exercising I/O, and communication via USB, Bluetooth, RS232 or LAN) then I am ready to turn my attention to developing the product firmware. Often the initial firmware evolves to the boot-up diagnostic software for the embedded product.
What tips or process do you suggest when transitioning to a new embedded development platform?
-Gary
Monday, March 26, 2012
Headless Embedded Systems
Something I have started to notice is the growing use of tablets to serve as the primary user interface for real-time embedded systems. This is in direct opposition to the long term tendency for embedded systems to sport integrated and increasingly sophisticated user interfaces.
At first glance this does not appear to be such a good idea due to the economics. The unit cost of a tablet is quite expensive. Only certain embedded systems could even consider the use of a tablet as the primary user interface due to the cost factor. However its use can make sense, in certain products, especially when considering the total cost of creating a custom graphical user interface.
Integrated graphical user interfaces require custom electronics and software. Much of the development is geared to integrate the user input and display devices with the rest of the system software. A great deal of software is often required to simply display data to a user or receive input from the user. This software device layer often takes a significant chunk of the development time and resources. And the application program that the user interacts with must still be written.
In the past year, several companies I have met with are considering the use of tablets or even smart phones for their user interface needs. They expect to reduce the complexity and the cost of developing the new product by essentially eliminating custom development of a graphical user interface. Leveraging an off-the-shelf solution enables the companies to get their product to the market sooner.
So I am curious, are you also seeing this as an emerging trend?
At first glance this does not appear to be such a good idea due to the economics. The unit cost of a tablet is quite expensive. Only certain embedded systems could even consider the use of a tablet as the primary user interface due to the cost factor. However its use can make sense, in certain products, especially when considering the total cost of creating a custom graphical user interface.
Integrated graphical user interfaces require custom electronics and software. Much of the development is geared to integrate the user input and display devices with the rest of the system software. A great deal of software is often required to simply display data to a user or receive input from the user. This software device layer often takes a significant chunk of the development time and resources. And the application program that the user interacts with must still be written.
In the past year, several companies I have met with are considering the use of tablets or even smart phones for their user interface needs. They expect to reduce the complexity and the cost of developing the new product by essentially eliminating custom development of a graphical user interface. Leveraging an off-the-shelf solution enables the companies to get their product to the market sooner.
So I am curious, are you also seeing this as an emerging trend?
Subscribe to:
Posts (Atom)