7.3.1 Application Development
The system implemented enables developers to write microcontroller applications without having any knowledge about the hardware. The base system can abstract the hardware in the functions stored in the jump table which can be called by developers, through a SDK, who do not have to care which pin a LED light is connected to. Since code can be loaded from an external source application developers do not need to learn or understand how the uploading via a programmer works. They can, for example, just transfer the finished code to a SD card. The abstraction of the hardware also open up for cross-platform applications. All the application code needs to do is call a function, via the jump table, and then the base system can implement the hardware specific logic.
7.3 Considerations
7.3.2 Security
As mentioned in the background theory, dynamic linking enables code to be linked first when it is to be executed. It blindly accepts any code that fits into the hole created by the linker. The loadable code compiled for the prototype, from this study, works the same way. It accepts an address to a jump table when it is first executed and then it uses the table for every external method call without any verification. This enables code pieces to be patched individually, which is a good thing, but it also enables maleficent attacks. Since the loaded code can not differentiate flashing a led light and getting stuck in an endless loop there exists an opportunity for harmful code to be injected. In a closed system this is not an issue but if code was to be received through wireless communication channels the system is vulnerable. The data received has to be verified before it is executed in order to ensure that the correct code has been received.
7.3.3 Reliability
Having dynamic parts in a system can make it more prone to failures. If an application expects an integer as input but receives a string it might fail if there is no error handling implemented. The same goes with loadable code. Microcontrollers are very useful since they have their code burnt into the memory circuits and always executes it the same way.
Introducing loadable code also introduces some weaknesses to the system that has to be taken into consideration. There has to be memory available to, temporarily, store the code. If something else is taking up all memory the system will fail the loading. The idea of loadable code was to split a large system into tiny pieces of code that each can perform a single task. This would allow a total size of code that is larger than the storage memory on the microcontroller, but there still need to be memory available for a small piece of code.
Reading the byte array representing the code might fail. A corrupted SD card or a bluetooth transfer that looses its connection introduces exceptions that the system must be able to handle in order to not crash. As with the security aspect of the system this is another reason to verify the code before loading it. Verification causes additional overhead but in some cases it might be required.
8 Summary
8.1 Conclusion
The research questions in this study was: ”What kind of overhead follows with a more storage efficient system? Is this system a viable alternative to the traditional way of run-ning code?” (RQ1) and ”How can a system be implemented, on low-end microcontrollers in native code, that uses storage more efficiently?” (RQ2). To answer RQ2 a system was hypothesised and then implemented using a jump table. This jump table enabled code loaded at runtime to execute functions located outside of itself. By being able to replace entire functions with a single function call the size of the loadable code was decreased.
The fact that it is loadable enables storage outside of the microcontroller which would lead it to only occupy storage memory inside the microcontroller when it is executing.
To answer RQ1 the system designed was tested in a controlled experiment. From the results gathered it could be deduced that the execution time overhead could become as little as 1% and still be decreasing. The memory usage overhead turned out to be stable around 8.5% or 400 bytes. Considering these results it is safe to say that the overhead is very small as long as the number of computations performed by the applications is high.
However, this only answers the first part of the question. The second part (whether the system is a viable alternative to conventional applications or not) is not as easy to answer.
More variables than just the overhead go into this. In the discussion chapter several considerations are brought up. All these come into play when answering whether the system is an alternate or not and there is still no definitive answer. It all depends on the purpose for which the system is developed for. Development requiring high reliability or security of the system might not benefit from a system that loads code during runtime.
However, for casual purposes there is often no need to have complete security or reliability.
By enabling the usage of cheaper microcontrollers, with low storage memory, in products, cheaper products can be produced. This could enable more people to be introduced to electronics otherwise unavailable to them. Learning to develop for microcontrollers also