Rolf Segger started development tool company Segger Microcontroller 29 years ago in Monheim am Rhein, Germany, more recently branching out with a realtime operating system called emPower
emPower aims to overcome the microcontroller shortage – isn’t this aimed at new designs to allow developers to switch more easily, but the shortages will be over in 12 to 18 months which is how long it will take new designs to come to market as boards will have to be redesigned and retested?
Whether the chip crisis will really be over in 12 to 18 months, I'm not so sure. emPower OS will certainly help: If you are already using it, it is much easier to change the microcontroller. It depends on the complexity of the applications, but we're talking days or weeks to make the switch. If you are not using it yet, we have fairly simple APIs, so porting to emPowerOS is usually straightforward. It seems that for many companies risk management is not a priority, but cost savings is. The more painful it is, the more companies will rethink, and this crisis seems to be quite painful, so it will have an impact on future purchasing policies.
Will the increased focus on modules with a standard pinout help solve this problem?
Switching between microcontrollers on the hardware side is not the big issue. We see modules in high-end computing and we have customers with high-end CPUs, and that's where we see the modules where the board design is difficult, such as impedance-controlled interconnects or multilayer architectures.
We don't see the modules in microcontrollers because it's easier to design the board, and Segger is more in the deeply embedded space. The biggest challenge is in the software. We have about 5 % of customers who have worked in deep embedded and moved to larger processors.
Segger supports both ARM and RISC-V architectures – will RISC-V be a significant competitor in the general purpose microcontroller market or is it more a dedicated embedded controller for applications such as AI?
We see RISC-V everywhere, but more as a companion or hidden chip. It's definitely a growing market. As a general-purpose device, we see it in China, but at this point in surprisingly small volume. One problem we see, unfortunately, is that it's based on a 30-year-old design and the code density is not great and can't compete with ARM, and that's a bit of a problem for embedded microcontrollers.
Traditionally, we support all kinds of CPUs, including Renesas, but lately we've been focusing heavily on ARM and RISC-V, and that's really all we support with Embedded Studio.
Does the open source nature of RISC-V give Segger a challenge on debug support? There are many, many different variants of RISC-V cores being developed – that must be hard to support. Do you have to pick the key ones to support or is there a technical solution to this?
For RISC-V, there are two different debug specifications that are not exactly compatible, and it seems that most developers stick to them. There is some flexibility that makes it harder, but it is doable. There are many different implementations, but it's still doable - we find that the implementations we get are generally 90 to 99 % compliant with the specifications.
Trace is not yet standardized and is still at an early stage. We see some demand for Trace, and we support the on-chip Trace, not the off-chip TPIU specification (TPIU stands for trace port interface unit). But maybe 80 % of our customers are not using Trace, it seems that people are not used to it yet. Off chip trace for RISC-V is something we are working on and plan to release by the end of the year.
Are you making use of machine learning in your tools eg for pattern recognition? Will that increase?
We don’t do that in our tools. There hasn’t been a need for that. Our customers use it. We are full of ideas for what we can do already.
- Segger ports dev tool to Apple M1 chip
- Segger to support SiFive Insight debug/trace platform
- Segger adds J-Link support for Raspberry Pi
- Segger moves RTOS to 64bits
- Segger releases SystemView under Friendly Licensing
Do you need to support more security features in development tools?
Security is a big thing in all areas and growing with IoT. EmCrypt and emSecure have all of these algorithms covered – we sell them as products but we also use the libraries in our debug probes and flashers. With the debug probes, Arm has secure and non secure modes, there is a clear trend to that, the same in flashers. There’s clearly more need for encryption and authentication certificates. There’s no one way of doing it and our goal is to support all of that.
If there is something that’s really critical, people use high security modules – if you spend enough effort there is a way to read out the program inside of regular microcontrollers even if read-out protection is active.
With quantum computers I am personally not convinced they will be available to crack sophisticated security algorithms any time soon. Segger is not in the business of developing encryption algorithms, we implement them and use them. The decision as to the algorithm people use is not our decision – if they switch to a different algorithm, we will support it.
Next: Security challenges