Tag Archives: Embedded software

5 Embedded Systems Tools to Decrease Costs & Time to Market

By Jacob Beningo – A typical developer, on average, spends around 40% of his or her time debugging software. This can lead to increased costs and time to market as developers grapple with system complexities and try to understand how various software components are interacting in their system. There are several tools that I use in my own development cycle that I have found to be indispensable. They help not just to understand the software, but also to decrease my costs and time to market. Let’s examine several of these tools:

  • Tool #1—A Trace-Enabled Debugger
    Whether it’s an ARM Keil ULINKplus or a j-Trace, these tools provide a developer with the ability to access streaming trace capabilities and the memory on an embedded target.
  • Tool #2 – Micrium µC Probe
    Micrium’s µC Probe can be used for real-time visualization of variables and data in an embedded application.
  • Tool #3 – Percepio Tracealyzer
    Tracealyzer can be integrated into an RTOS-based application to record the events that are happening in the application, such as task context switches, interrupts, mutex locks and unlocks, along with many other events that occur.
  • Tool #4 – SEGGER System View
    The tool contains just four views, but it’s enough to still get useful information about how the application is behaving, which is great for a free tool.
  • Tool #5 – SEGGER Ozone
    Ozone allows developers to see how good their code coverage is while letting them monitor function execution and see every instruction that has been executed in the code.


Updates from Siemens

Automotive Software Development
Siemens – Embedded software is driving remarkable new business opportunities in the automotive industry and fueling innovation in connectivity, electrification, and autonomous vehicle development.

However, managing automotive software development complexity is a big challenge. The complexity is driven by the difference between mechanical and software system product development approaches. Most automotive programs are managed in a three- to five-year cycle.

They follow a gate-based development paradigm with strict checkpoints and certifications. Software development, on the other hand, is incredibly fast paced, as it follows agile processes where collaboration and rapid innovation is key.

Typically, development of mechanical and electrical systems are managed within product lifecycle management (PLM) tools, whereas software development is managed with application lifecycle management (ALM) tools. The challenge is to combine these two inherently different product development methodologies. Software and hardware engineers working on their respective ALM and PLM applications must be able to access information across all the lifecycle related processes.

Hardware and software integration and co-development is a major challenge and a key contributor to quality issues, launch delays, and recall related penalties. more>


Get Hands On When Debugging Real-time Embedded Software

By Jacob Beningo – The greatest challenge facing embedded system developers is debugging software. Embedded systems have become highly complex, running real-time operating systems, connectivity stacks, USB, and security among a wide variety of other system code even before getting to the application.

Yet a significant number of engineers that I encounter still only use breakpoints to debug their software, despite the many modern and advanced techniques available to engineers today.

For this reason, I have created an opportunity to learn modern debugging techniques by developing an online course. The 45-minute per day free course will take place July 11-15, and will walk engineers through a hands-on approach to debugging real-time embedded software.

In order to get a real feel for how the techniques can be used, the course will be using an NXP K64F Freedom board that includes an ARM Cortex-M4 processor running at 120 MHz with 1 MB of flash space and 256 kB of RAM. The K64F board comes with Arduino R3 headers already populated along with a myriad of other features such as Ethernet, accelerometer, SD card slot, camera expansion header, on-board debugger, LEDs, and a few others. At only $35USD, the board is a very inexpensive, yet powerful development kit well suited for exploring debug techniques. more> http://goo.gl/xqq9px

Beyond the RTOS: A Better Way to Design Real-Time Embedded Software

By Miro Samek – An RTOS (Real-Time Operating System) is the most universally accepted way of designing and implementing embedded software. It is the most sought after component of any system that outgrows the venerable “superloop.”

But it is also the design strategy that implies a certain programming paradigm, which leads to particularly brittle designs that often work only by chance. I’m talking about sequential programming based on blocking.

Blocking occurs any time you wait explicitly in-line for something to happen. All RTOSes provide an assortment of blocking mechanisms, such as time-delays, semaphores, event-flags, mailboxes, message queues, and so on. Every RTOS thread, structured as an endless loop, must use at least one such blocking mechanism, or else it will take all the CPU cycles. Typically, however, threads block not in just one place in the endless loop, but in many places scattered throughout various functions called from the thread routine.

This excessive blocking is evil, because it appears to work initially, but almost always degenerates into a unmanageable mess. The problem is that while a thread is blocked, the thread is not doing any other work and is not responsive to other events. Such a thread cannot be easily extended to handle new events, not just because the system is unresponsive, but mostly due to the fact that the whole structure of the code past the blocking call is designed to handle only the event that it was explicitly waiting for. more> https://goo.gl/k7OPPc