Arm DevSummit 2020 debuted this week (October 6 – 8) as an online virtual conference focused on engineers and providing them with insights into the Arm ecosystem. The summit lasted three days over which Arm painted an interesting technology story about the current and future state of computing and where developers fit within that story. I’ve been attending Arm Techcon for more than half a decade now (which has become Arm DevSummit) and as I perused content, there were several take-a-ways I noticed for developers working on microcontroller based embedded systems. In this post, we will examine these key take-a-ways and I’ll point you to some of the sessions that I also think may pique your interest.

(For those of you that aren’t yet aware, you can register up until October 21^st (for free) and still watch the conferences materials up until November 28th . Click here to register)

Take-A-Way #1 – Expect Big Things from NVIDIAs Acquisition of Arm

As many readers probably already know, NVIDIA is in the process of acquiring Arm. This acquisition has the potential to be one of the focal points that I think will lead to a technological revolution in computing technologies, particularly around artificial intelligence but that will also impact nearly every embedded system at the edge and beyond. While many of us have probably wondered what plans NVIDIA CEO Jensen Huang may have for Arm, the Keynotes for October 6^th include a fireside chat between Jensen Huang and Arm CEO Simon Segars. Listening to this conversation is well worth the time and will help give developers some insights into the future but also assurances that the Arm business model will not be dramatically upended.

Take-A-Way #2 – Machine Learning for MCU’s is Accelerating

It is sometimes difficult at a conference to get a feel for what is real and what is a little more smoke and mirrors. Sometimes, announcements are real, but they just take several years to filter their way into the market and affect how developers build systems. Machine learning is one of those technologies that I find there is a lot of interest around but that developers also aren’t quite sure what to do with yet, at least in the microcontroller space. When we hear machine learning, we think artificial intelligence, big datasets and more processing power than will fit on an MCU.

There were several interesting talks at DevSummit around machine learning such as:

• Beyond ML – A Neuromorphic Approach to AI by Paul Isaacs
• tinyML Development with TensorFlow Lite for Microcontrollers and CMSIS-NN by Peter Warden and Fredrik Knutsson
• uTVM, an AI Compiler for Arm Microcontrollers by Thomas Gall
• Machine Learning Made Possible for Embedded Developers with Zero AI Skills by Francois de Rochebouet

Some of these were foundational, providing embedded developers with the fundamentals to get started while others provided hands-on explorations of machine learning with development boards. The take-a-way that I gather here is that the effort to bring machine learning capabilities to microcontrollers so that they can be leveraged in industry use cases is accelerating. Lots of effort is being placed in ML algorithms, tools, frameworks and even the hardware. There were several talks that mentioned Arm’s Cortex-M55 architecture that will include Helium technology to help accelerate machine learning and DSP processing capabilities.

Take-A-Way #3 – The Constant Need for Reinvention

In my last take-a-way, I eluded to the fact that things are accelerating. Acceleration is not just happening though in the technologies that we use to build systems. The very application domain that we can apply these technology domains to is dramatically expanding. Not only can we start to deploy security and ML technologies at the edge but in domains such as space and medical systems. There were several interesting talks about how technologies are being used around the world to solve interesting and unique problems such as protecting vulnerable ecosystems, mapping the sea floor, fighting against diseases and so much more.

By carefully watching and listening, you’ll notice that many speakers have been involved in many different types of products over their careers and that they are constantly having to reinvent their skill sets, capabilities and even their interests! This is what makes working in embedded systems so interesting! It is constantly changing and evolving and as engineers we don’t get to sit idly behind a desk. Just as Arm, NVIDIA and many of the other ecosystem partners and speakers show us, technology is rapidly changing but so are the problem domains that we can apply these technologies to.

Take-A-Way #4 – Mbed and Keil are Evolving

There are also interesting changes coming to the Arm toolchains and tools like Mbed and Keil MDK. In Reinhard Keil’s talk, “Introduction to an Open Approach for Low-Power IoT Development“, developers got an insight into the changes that are coming to Mbed and Keil with the core focus being on IoT development. The talk focused on the endpoint and discussed how Mbed and Keil MDK are being moved to an online platform designed to help developers move through the product development faster from prototyping to production. The Keil Studio Online is currently in early access and will be released early next year.

(If you are interested in endpoints and AI, you might also want to check-out this article on “How Do We Accelerate Endpoint AI Innovation? Put Developers First“)

Conclusions

Arm DevSummit had a lot to offer developers this year and without the need to travel to California to participate. (Although I greatly missed catching up with friends and colleagues in person). If you haven’t already, I would recommend checking out the DevSummit and watching a few of the talks I mentioned. There certainly were a lot more talks and I’m still in the process of sifting through everything. Hopefully there will be a few sessions that will inspire you and give you a feel for where the industry is headed and how you will need to pivot your own skills in the coming years.

Originaly posted here

Recovering from a system failure or a software glitch can be no easy task.  The longer the fault occurs the harder it can be to identify and recover.  The use of an external watchdog is an important and critical tool in the embedded systems engineer toolbox.  There are five tips that should be taken into account when designing a watchdog system.

Tip #1 – Monitor a heartbeat

The simplest function that an external watchdog can have is to monitor a heartbeat that is produced by the primary application processor.  Monitoring of the heartbeat should serve two distinct purposes.  First, the microcontroller should only generate the heartbeat after functional checks have been performed on the software to ensure that it is functioning.  Second, the heartbeat should be able to reveal if the real-time response of the system has been jeopardized.

Monitoring the heartbeat for software functionality and real-time response can be done using a simple, “dumb” external watchdog.  The external watchdog should have the capability to assign a heartbeat period along with a window that the heartbeat must appear within.  The purpose of the heartbeat window is to allow the watchdog to detect that the real-time response of the system is compromised.  In the event that either functional or real-time checks fail the watchdog then attempts to recover the system through a reset of the application processor.

Tip #2 – Use a low capability MCU

External watchdogs that can be to monitor a heartbeat are relatively low cost but can severely limit the capabilities and recovery possibilities of the watchdog system.  A low capability microcontroller can cost nearly the same amount as an external watchdog timer so why not add some intelligence to the watchdog and use a microcontroller.  The microcontroller firmware can be developed to fulfill the windowed heartbeat monitoring with the addition of so much more.  A “smart” watchdog like this is sometimes referred to as a supervisor or safety watchdog and has actually been used for many years in different industries such as automotive.  Generally a microcontroller watchdog has been reserved for safety critical applications but given the development tools and the cost of hardware it can be cost effective in other applications as well.

Tip #3 – Supervise critical system functions

The decision to use a small microcontroller as a watchdog opens nearly endless possibilities of how the watchdog can be used.  One of the first roles of a smart watchdog is usually to supervise critical system functions such as a system current or sensor state.  One example of how a watchdog could supervise a current would be to take an independent measurement and then provide that value to the application processor.  The application processor could then compare its own reading to that of the watchdog.  If there were disagreement between the two then the system would execute a fault tree that was deemed to be appropriate for the application.

Tip #4 – Observe a communication channel

Sometimes an embedded system can appear to be operating as expected to the watchdog and the application processor but from an external observer be in a non-responsive state.  In such cases it can be useful to tie the smart watchdog to a communication channel such as a UART.  When the watchdog is connected to a communication channel it not only monitor channel traffic but even commands that are specific to the watchdog.  A great example of this is a watchdog designed for a small satellite that monitors radio communications between the flight computer and ground station.  If the flight computer becomes non-responsive to the radio, a command could be sent to the watchdog that is then executed and used to reset the flight computer.

Tip #5 – Consider an externally timed reset function

The question of who is watching the watchdog is undoubtedly on the minds of many engineers when using a microcontroller for a watchdog.  Using a microcontroller to implement extra features adds some complexity and a new software element to the system.  In the event that the watchdog goes off into the weeds how is the watchdog going to recover? One option would be to use an external watchdog timer that was discussed earlier.  The smart watchdog would generate a heartbeat to keep itself from being reset by the watchdog timer.  Another option would be to have the application processor act as the watchdog for the watchdog.  Careful thought needs to be given to the best way to ensure both processors remain functioning as intended.

Conclusion

The purpose of the smart watchdog is to monitor the system and the primary microcontroller to ensure that they operate as expected.  During the design of a system watchdog it can be very tempting to allow the number of features supported to creep.  Developers need to keep in mind that as the complexity of the smart watchdog increases so does the probability that the watchdog itself will contain potential failure modes and bugs.  Keeping the watchdog simple and to the minimum necessary feature set will ensure that it can be exhaustively tested and proven to work.

Originally Posted here