15-Oct-2016, 11:15
(This post was last modified: 15-Oct-2016, 11:17 by thumb5.
Edit Reason: fixed typo
)
At the risk of being pedantic (not for the first time!), I think the discussion is going a bit off topic here: it seems to be veering towards differences in sound quality between different versions of firmware whereas gui's original post was about variation in sound quality over time with a given version of firmware.
Let me jot down a few quick notes about the typical process for building and updating embedded software. This will miss out lots of details which depend on the application/market, hardware, tools, etc. but hopefully could be a basis for discussion.
Embedded software is normally written either in assembly code or a (so-called) high-level language such as C or C++. Assembly code means that the programmer must write the program using the instructions defined and implemented by the processor itself - ARM, SHARC, Intel x86, etc. - and is completely in charge of how the processor registers and memory are used. By contrast programs written in C or C++ don't depend directly on the exact processor hardware and can be more easily made to run on different processors. For most general-purpose embedded systems, high-level languages are used wherever possible. But for an application like digital signal processing, especially on a processor like the SHARC, assembly language might be more often used since it can give higher performance or access to special features of the processor that can't be used from C/C++. In the case of the Devialet I'd expect all the DSP-type software (including SAM, tone controls, volume control, etc.) to be written in assembly language but the UI, configuration, etc. to be in C.
Once the program is written in source (that is, human-readable) form, it has to be translated into machine code -- that is, the binary code that the processor can actually execute. For assembly code, this is done by a software tool known as an assembler. For a high-level language this is normally a two-step process: the high-level code is first translated to assembly language (by a compiler) and then assembled. The compiler can be a very complex tool as it tries to optimise the assembly code it produces to give the best performance and/or smallest memory footprint (or more usually some compromise between the two).
Most embedded software will be built from more than one source file, which may include both assembly and high-level code. Once these have been translated to machine code, they can be linked together. At this point the programmer defines where in the processor's memory the program code and data will reside. This is done by a tool known as a linker. The linker produces a binary version of the program -- more or less an image of what needs to be loaded into memory so that the processor can run the program. This is just a (very!) long series of 0s and 1s, organised into units of (typically) 8, 16, or 32 at a time. For example each unit could represent a processor instruction or some data, both of which would be stored in memory.
Up to this point, the software has been built on a development system which is normally a PC -- that is, not the target embedded system. The output is an image of the program code and data, sitting in a file on the development system. The next part of the process is to load the program image into the memory of the target system.
The processor in the target system will automatically start reading instructions from a pre-defined place in memory when it is first powered up. That means the program code and data must be stored in some kind of non-volatile memory so that it's always there when the system starts up, without having to be loaded by hand each time.
These days, the program image is normally stored in "flash" memory -- more or less similar to what's inside a USB memory stick or an SD card, but either built into the processor itself or directly connected to it. The program image produced by the linker needs to be taken from the file on the development system where it was built, and somehow installed in the flash memory on the target system. One way to do this is to use a special hardware connection on the target system which allows the flash memory to be programmed using special tools running on the development system. This is often how the first firmware gets loaded during production on brand new hardware.
The program loaded on the target system might include code to update itself after production. That's the case for Devialet amplifiers, of course: the firmware can recognise when an SD card contains new binary files, and can re-program its own flash memory with the updated firmware. Then when it re-starts, it's running the new firmware.
[Wrote that in a bit of a rush, so might come back and edit or fill in detail later...]
Let me jot down a few quick notes about the typical process for building and updating embedded software. This will miss out lots of details which depend on the application/market, hardware, tools, etc. but hopefully could be a basis for discussion.
Embedded software is normally written either in assembly code or a (so-called) high-level language such as C or C++. Assembly code means that the programmer must write the program using the instructions defined and implemented by the processor itself - ARM, SHARC, Intel x86, etc. - and is completely in charge of how the processor registers and memory are used. By contrast programs written in C or C++ don't depend directly on the exact processor hardware and can be more easily made to run on different processors. For most general-purpose embedded systems, high-level languages are used wherever possible. But for an application like digital signal processing, especially on a processor like the SHARC, assembly language might be more often used since it can give higher performance or access to special features of the processor that can't be used from C/C++. In the case of the Devialet I'd expect all the DSP-type software (including SAM, tone controls, volume control, etc.) to be written in assembly language but the UI, configuration, etc. to be in C.
Once the program is written in source (that is, human-readable) form, it has to be translated into machine code -- that is, the binary code that the processor can actually execute. For assembly code, this is done by a software tool known as an assembler. For a high-level language this is normally a two-step process: the high-level code is first translated to assembly language (by a compiler) and then assembled. The compiler can be a very complex tool as it tries to optimise the assembly code it produces to give the best performance and/or smallest memory footprint (or more usually some compromise between the two).
Most embedded software will be built from more than one source file, which may include both assembly and high-level code. Once these have been translated to machine code, they can be linked together. At this point the programmer defines where in the processor's memory the program code and data will reside. This is done by a tool known as a linker. The linker produces a binary version of the program -- more or less an image of what needs to be loaded into memory so that the processor can run the program. This is just a (very!) long series of 0s and 1s, organised into units of (typically) 8, 16, or 32 at a time. For example each unit could represent a processor instruction or some data, both of which would be stored in memory.
Up to this point, the software has been built on a development system which is normally a PC -- that is, not the target embedded system. The output is an image of the program code and data, sitting in a file on the development system. The next part of the process is to load the program image into the memory of the target system.
The processor in the target system will automatically start reading instructions from a pre-defined place in memory when it is first powered up. That means the program code and data must be stored in some kind of non-volatile memory so that it's always there when the system starts up, without having to be loaded by hand each time.
These days, the program image is normally stored in "flash" memory -- more or less similar to what's inside a USB memory stick or an SD card, but either built into the processor itself or directly connected to it. The program image produced by the linker needs to be taken from the file on the development system where it was built, and somehow installed in the flash memory on the target system. One way to do this is to use a special hardware connection on the target system which allows the flash memory to be programmed using special tools running on the development system. This is often how the first firmware gets loaded during production on brand new hardware.
The program loaded on the target system might include code to update itself after production. That's the case for Devialet amplifiers, of course: the firmware can recognise when an SD card contains new binary files, and can re-program its own flash memory with the updated firmware. Then when it re-starts, it's running the new firmware.
[Wrote that in a bit of a rush, so might come back and edit or fill in detail later...]
Roon (Mac Mini), Wilson Benesch Full Circle, Expert 1000 Pro CI, Kaiser Chiara
Warwickshire, UK
