The past and the future of the hardware – Part 1

In the following, I will overview the past and the future of the hardware we use in the project!

At the post “What this project was all about”, zsoltmazlo described the application of Arduino boards. The choice was based on the experience of easy usage of the libraries, but later during the development of the models it turned out that they hit their limitations.

As you may know, the Arduinos are basically microcontrollers. They are really an all in one package. But with microcontrollers, the programmer is facing very serious limitations. The Atmel ATmega328P has 32 Kbytes of program memory, and 2 Kbytes of data memory, with a 20 MHz operating frequency. This is the processor on the well famous Arduino Uno, and we also had Ethernet capable board. But the memory limitations are serious.


Comparing this with even your smartphone: just lack of performance. However, we have to mention, that although they look quite weak, they are very usable. 98 percent of the computers are used in embedded systems, and most of them utilizes microcontrollers like the one I mentioned.

Well, than what was the problem? We develop in a model-based fashion. With a safety critical system, you can’t just write code, and hope it just works, or test it to a level where the developer thinks it’s safe enough. You need mathematical proofs of the correctness of your solution, and you can do it with model based developement. You create some abstract representation of your application with statecharts, flow diagrams, or other abstract representations (read the post “Statecharts are everywhere!” if you are interested). These are mathematically more representable objects, therefore we can analyze this.

So what is the bottom line? When you are ready with analyzing the correctness of your model, you somehow need to make this model runnable. From a model, you can generate code (e.g C, C++, Java, etc.), so you can compile and run it. The problem with these code generators is that they are not prepared for the limitations of an embedded system: generated code is used to use dynamic memory handling, and trash a little. So little, you wouldn’t notice this in a PC, but with 2K RAM, you will, and the application will crash because it can’t allocate more memory for itself.

It turned out that to overcome these difficulties might be much harder than upgrading our hardware to the next level, so we chose the latter, and started developing the new hardware to suit our needs. Sure, we could work out how we could generate code to fit inside, but the MoDeS3 project isn’t about just us. It’s a tool to develop safe and smart applications, and the hardware needs may be varying between projects, so it is just better to fit the future needs.

Coming up: the new hardware and the horizon is opened for us!


Leave a Reply

Your email address will not be published. Required fields are marked *