Home > On-Demand Archives > Theatre Talks >

The Quest for Simplicity

Henk Muller - XMOS - Watch Now - Duration: 34:05

Modern software engineering practices and embedded systems development are often in conflict.

Software engineering has seen major progression in the last few decades – the way we design systems has changed with object oriented methods (including the ability to add layers of abstractions and generic types); inheritance has significantly altered how we implement systems, and garbage collection has improved many programmer’s sleep. Combined, these advances have given us improvements in maintainability, verification, reusability, and time to market.

The issue at hand is that not all of these mechanisms translate into efficient structures – the driving force between cost and energy savings. Examples of where it would be acceptable to deliver a system that needs twice the resources to operate, are few and far between.

In this talk we explore where the inefficiencies crept in and discover how simple software engineering can help to reclaim those losses.

italicssurround text with
boldsurround text with
**two asterisks**
or just a bare URL
surround text with
strikethroughsurround text with
~~two tilde characters~~
prefix with

Score: 0 | 9 months ago | no reply
This post has been deleted by the author
Score: 1 | 9 months ago | 1 reply

Thanks for the talk Henk. The most important phrase for me --> Making small programs is hard... I fight with it all the time... FLASH or SRAM restrictions using FreeRTOS and TI-RTOS... And sometimes solve that is very complicated... and the time to market press on the developer... I always build generic C functions... however your advise to create specialization code version is more appropriate in many cases... interesting ideas to think about exceptions too.... Thanks

Score: 0 | 9 months ago | 1 reply

Building generic C functions is definitely the answer to fast time to market; but as you say it may blow your budget!

Score: 0 | 9 months ago | no reply

You're right... Thanks for all advises

Score: 2 | 9 months ago | 1 reply

Thanks for the insightful presentation.
Would you have any recommendations when it comes to quantifying the memory requirements for a system that is at an early stage of design? Would all the software dependencies and build tools have be known with relatively high accuracy at that point to ascertain a good enough estimate?

In the slide of specialisation as an answer to generic code, is the specialisation achieved solely by the compiler? Could you expand briefly on how the specialisation approach would look in practical terms, e.g. the library implementation leveraging a polymorphic interface (?).

Score: 2 | 9 months ago | no reply

Indeed, you will have to have a reasonable grasp of all the bits that you are going to need for the design. Indeed, I find this a valuable first stage of the design:what bits are there and what resources do they need? Accuracy is not an enormous issue typically, with the proviso that if you don't know how much data, for example, a filter needs that that unknown will persist all the way.

About specialisation: it is typically compiler and linker; I often, incorrectly, label the whole tool-chain a compiler, but you have to build a full call-graph before you can specialise efficiently. Some toolchains choose to only specialise if the number of specialisations created is small (eg, never more than 2), other toolchains can be more brutal.

Specialisation can help get rid of polymorphism, but polymorphism is not a requirement for specialisation.

Score: 1 | 9 months ago | 1 reply

Thanks for this very informative summary on the problems you have to deal with on emedded systems.
You mentioned that it's a good idea to deal with errors an not to pass the bug. But isn't this (especially for libraries) not always a problem to decide?
I think of a current problem I'm facing with a communication protocol implementation (written as a library) which is used on many differnt devices from very small embedded processors up to powerful processors running an embedded Linux. On a Linux machine the communication protocol runs as a user process which you can safely terminate and restart on an error without affecting the rest of the system. On the embedded component the only possible way to handle the same error could be to do a reset which will break all the other functionalities the component does beside communication.
I mean that in such cases it's up to the application that uses the library to know what the "correct" error handling would be and therefore the library must pass the bug to give the user the ability to decide?
Or did I misunderstood something?

Score: 0 | 9 months ago | no reply

Hi Erwin - you are absolutely right. It will matter very much in what sort of company you work, whether you got to pass the buck or whether the library can deal with the error.

If the company delivers Linux device drivers as a product, then there is no way that you can deal with the error other than reporting it to the caller; you cannot second guess what the caller is going to do.

However, if you work in a company where you are making a communication driver and one of your colleagues is writing the software that deals with the error (maybe in another building), then it may be worthwhile to shortcut the spec, and still create a generic library that is useful for different cars, but it is going to report a communication error at a low level in a more direct manner.