ARM’s Technical Conference called TechCon™ is running between October 29th and 31st at the Santa Clara Convention Center in California.
This year I shall be making the trip over to present three classes:
- Can Existing Embedded Applications Benefit from Multicore Technology?
- Virtual Functions in C++ on the ARM Architecture
- Developing a Generic Hard-Fault Handler for ARM Cortex-M3/Cortex-M4
For those of you who are regular readers of this blog you’ll recognise the Generic Hard-Fault Handler from a previous post.
The class “Can Existing Embedded Applications Benefit from Multicore Technology?” came about as it seemed that not a day would goe by without an announcement of a major development in multicore technology. With so much press about multicore, I started to wonder whether I should consider using multicore technology in my typical embedded applications?
From a software developer’s perspective, however, all the code examples seem to demonstrate the (same) massive performance improvements to rendering fractals or ray-tracing programs. The examples always refer to Amdahl’s Law, showing gains when using, say, 16 or 128 cores. This is all very interesting, but not what I, and hopefully most embedded developers, might consider embedded. This class discusses multicore from a more traditional embedded viewpoint.
Many Embedded-C programmers still believe that C++ leads to slow, bloated programs. Though this viewpoint may have had limited foundation over a decade ago, it is misplaced for the core aspects of C++ (classes, inheritance, and dynamic polymorphism). With a modern ARM C++ cross-compiler, it is also misplaced for the more advanced features (templates and exception handling). In the class “Virtual Functions in C++ on the ARM Architecture”, I will be focusing on the performance and memory of the C++ virtual functions, type info and look at the use of multiple inheritance in an ARM embedded environment.
If you are planning to attend TechCon this year then please look me up. I will be making the presentations available via the blog after the event.
- Disassembling a Cortex-M raw binary file with Ghidra - December 20, 2022
- Using final in C++ to improve performance - November 14, 2022
- Understanding Arm Cortex-M Intel-Hex (ihex) files - October 12, 2022
Co-Founder and Director of Feabhas since 1995.
Niall has been designing and programming embedded systems for over 30 years. He has worked in different sectors, including aerospace, telecomms, government and banking.
His current interest lie in IoT Security and Agile for Embedded Systems.
Looking forward to the presentation on virtual functions in C++. I've spent a lot of time explaining the reality of this to companies who are afraid of the "huge penalty" of virtual functions, there is a lot of FUD there (and a little bit of warranted concern).
Steve Dewhurst also used to give a talk at ESC about the "true cost" of virtual functions, going down into the assembly level (I think it was even on an ARM, probably not a Cortex) and contrasting it with the standard C alternative ("switch on type") which tends to be horribly cluttered and typically less efficient.
And your if your blog article on hard-fault exception handlers is any indication, I'm sure the talk at ARM Techcon will be extremely useful and enlightening.
Hopefully it'll be useful. When you start getting into Multiple Inheritance it get's very interesting.
I'm looking forward to the presentations later on.
I'm guessing that one convenient usecase for a multicore processor in an embedded system is to make it easier to reason about the real-time behavior of the system. Instead of messing around with trying to share a processor between several real-time tasks and non real-time tasks just put the real-time tasks on a few different spare processors. (This may make extra sense on multicore processors based on big.LITTLE where you may have a few small cores available that it doesn't make sense to use for code with high performance requirements.)
(Otherwise I'm of the opinion that you shouldn't bother with actively implementing multicore support in your application if you can avoid it due to the extra complexity. Although I admit to possibly being a bit too pessimistic here about the abilities of the programmers who actually have to write such support.)