With the increasing use of microcontrollers and microprocessors, it’s likely that all but the very simplest of electronic products will require some degree of software development. We believe in keeping the hardware as simple as possible and making the software do the work – After all, once the development process is completed, software is essentially free.
Platforms
We have an extensive history of embedded programming & development, including experience with:
- Microchip PIC (particularly 16F & 18F families)
- Coldfire V2/V3/V4, including MAC and MMU extensions
- PowerPC/PowerQUICC/QorIQ
- 68k (68000/020/030/040/060, and embedded types – 68332 etc.)
- ARM
- 6800/6502
- Atmel AVR
- Smartphone “Apps” (Android)
- Lattice (CPLD/FPGA)
- Xilinx (CPLD/FPGA)
High Performance
When higher performance is required, our choice is the Coldfire range of 32-bit microcontrollers & microprocessors. These devices are available with a wide range of peripheral features, and are ideally suited to handling high speeds and volumes of data such as encountered with bulk processing, automotive, and multimedia applications.
Low power / Low cost
From years of experience, we’ve selected the PIC18F family of processor as the preferred choice for low power / low cost applications. There are numerous devices to choose from ranging from the minuscule DFN-packaged chips costing less than one pound, up to highly-featured microcontrollers with numerous peripherals and speeds up to 64MHz.
Software Libraries
For both of these platforms, we have written extensive software libraries so that for any given project, a large amount of the software is already written and tested. Normally, little more than the “top level” functionality would actually need to be written. Some of the code that we already have includes:
- Pre-emptive multitasking operating systems
- Bootloaders (RS232/USB). Including encryption
- Communications libraries for many common & obscure protocols
- Terminal software
- Debug / trace software
- Maths libraries
- Graphics libraries
- Video codecs
Programmable logic
When even more processing power is required, it is usually for repetitive “number crunching” applications. Our preferred approach is to add an FPGA device to offload this work from the main CPU. For a specific task, an FPGA can vastly outperform even the fastest CPU, for a fraction of the cost and power consumption, and also provide additional high-speed interfacing hardware.
Standards
All software is written to a high standard by experienced professionals, and conforms to our in-house quality-control program. Software is verified for
- Functionality, including with abnormal input parameters (black-box testing methodology)
- Efficiency, both for speed and memory usage.
- Repeatability to ensure that there are no unexpected delays or deadlock situations in code.
- Documentation, so that the source code can easily be followed by either the original programmer at a later date, or a different programmer.
- And optionally, Security. Whilst most modern microcontrollers include a facility to protect the code from unauthorised viewing, in this context, we’re referring to side-channel attacks on data passing through the software rather than the code itself. Writing in assembly language provides an additional benefit as it’s far easier, for example, to code against timing attacks by ensuring all paths through an algorithm take precisely the same length of time.
Except in very particular circumstances, we would not recommend using Linux as an embedded operating system. Linux is fine as an environment for a desktop PC – we use it exclusively for development – but it is slow and cumbersome in embedded applications where quick start-up and precise timing are critical. Our Coldfire OS boots from a cold start to running applications in a fraction of a second, whereas Linux may take many seconds, even as much as a minute
We use the “top-down/bottom-up” program design methodology. A program is first designed from the top down, meaning that we would start with the simplest description of what the code should do, then start to break this down into simpler and simpler modules until the level of easily-programmable routines is reached. Then it is actually written, from the bottom up – These simple routines are written, tested and de-bugged, and only once they are approved does work continue to the higher levels, although many of these “lowest level” routines are actually the library functions that we already have in place. This method ensures that:
- The final result is what was intended, and the software performs as expected.
- There are no obscure bugs in the lowest levels of the code.
- The whole project can be scheduled and priced accurately.
We do not outsource any programming to offshore companies. All software is written by SMR Electronics’ employees at our premises in the UK, and to our high standards. This ensures that the customer can always discuss their requirements directly with the programmer, and that there’s no opportunity for poor quality code, written by a “trainee”, to find its way into commercial software.
Languages
Today, much of the embedded software written is in high-level languages such as C/C++, Java or Python. We believe that the best performance can only be achieved by writing in a low-level language – Assembly language, and this is our preferred approach for many applications. Whilst compilers have progressed in recent years, they still act to (intentionally) shield the programmer from how the processor actually functions. Writing in assembly language, where each instruction written by the programmer directly translates to an instruction executed by the CPU has many benefits:
- Well written assembly language code will always run faster than anything generated by a compiler. This equates to better performance, or lower power consumption – often with the option to specify a lower cost processor to do the same job.
- Assembly language software is more compact, and generally requires less memory to do the same job as the equivalent software written in a high-level language. Again, this leads to the ability to reduce the specification of the hardware.
- Being “close to the hardware” allows an assembly language program to have more complete control over peripherals and timing, allowing very precise, high-speed code to be written.
But, if assembly language is so good, why isn’t everyone using it? Firstly, these arguments don’t really apply where most people consciously experience software – on a desktop PC or smartphone. These platforms have a complex operating system and a fixed, high-performance processor that is intended to run a wide variety of software. Making the software more efficient doesn’t save any money, because it doesn’t change the hardware costs. We specialise in embedded applications, where the hardware and software are developed hand-in-hand. Secondly, there’s the simple fact that programming in assembly language is more difficult – Not a problem if you have decades of experience in it, but something of a deterrent if you’re new to programming.