Eugene Hutorny

This post collects and organizes discussion theses posted on different forums.

MCU Models

Despite it is not explicitly spelled out, assemblers and C-compilers do use one or the other kind of MCU model, defined in terms of the programming language (assembly, C or preprocessor). These models are ‘flat’ (set of constants or static variables). These models are often incomplete and can be easily misused without any compilation error.
Linkers and simulators use another way of defining the same model and doing it in other, different languages with no or very little documentation support.
e# will give ability to define a formal, self-descriptive MCU model once and open it for use everywhere ??“ in compiler, application, and simulator. This indeed does not negate the need to learn the hardware. Instead e# will provide a formalized addendum to the device datasheet.
Defining MCU model in the same language as the program is written will open up possibilities hardly achievable in the current tools.

Cost of abstractions

All proposed abstractions are abstractions of the tool language. They will be constructed and executed on the host computer. There will be no abstraction one would have to use on the device. One still will be able to program in terms of instructions, and on top of that, may define abstractions for the device in extents of available device resources. For example, one would be able to define (and implement) an interface method call using whatever calling convention is appropriate and use it as if it were a HLL language.

Generic MCU

Many parts in an embedded application (such as state machine, math, conversion, etc.) can be written for a ‘more generic MCU’ and these parts can be transferred to other MCU that fit under the same ‘generality umbrella’. This will give developers freedom to make such choice – either writing with very limited very generic MCU and have highly portable code or writing for a given MCU and have more efficient and, of course, less portable code.