Understanding SOFIA

In this section, I'll describe project SOFIA in more details, including project organization, architecture and also showing some software metrics.

If you are only interested in how to use the simulator, the section Using SOFIA should be enough. Here, I'll present some technical information for developers.

pageUsing SOFIA

SOFIA's architecture

The figure 2.1 presents the SOFIA's architecture. Though it may be a little confusing, this architecture was developed based on the datasheet description of the ATmega328P. It was attempted to create the same modules and the same flow of communication between them.

Figure 2.1. SOFIA's architecture

Everything starts at the UCModule. This module is responsible to start all the others and synchronize them. It works as an scheduler, activating one module at a time. UCModule also holds information to be used by other modules (mainly the UCModule_View), related to the current board characteristics (although only Arduino UNO is supported so far), power suply, colors, etc.Notice that only the CPUModule and the UCModule_View are directed accessed by the UCModule. In fact, all the other modules are accessed using interfaces, so that it will be easier to add new boards support.

The CPUModule continually reads an instruction from the ProgramMemory and execute it. The instructions are already decoded in an embedded database in order to make the system faster. After each instruction, the CPUModule check for interruptions in the InterruptionModule before execute another instruction.

All I/O modules have access to write on the InterruptionModule, accessed statically in the UCModule. There, interruptions flags are stored in a vector according to it's priority, so that the CPU can execute the right interrupt routine.

The ProgramMemory contain the instructions to be executed, read from the hexadecimal file. This module also look for modifications in the hexadecimal file in the system, generating a reset signal if any modification is detected.

The DataMemory holds and synchronize all the registers and external memory. All modules can read and write to DataMemory directly (except for IOModule and UCModule_View, they access DataMemory through other modules). DataMemory also notifies the IOModule if a I/O register is changed and update the MemoryMap.

The UCModule_View manages all the user interface, together with IOModule. The IOModule gather informations from the InputFragment and the OutputFragment and check for short-circuit and other stuffs. It also manages the internal pull-ups.

Finally, there are the modules of Timer, ADC and USART. Each module works with direct memory access and they are independent. USART and Timers will overwrite the normal pin functionality when activated. The USART can communicates directly with the SerialMonitor and the ADC have access to the input value only for the allowed analog inputs.

Project Organization

The source code is organized as follows (see figure 2.2):

Figure 2.2. Project structure

• database: Contain the database manager class.

• extra: Contain classes not directly related to the simulator (like the Splash Screen, About Page and Memory Map).

• serial_monitor: Contains the implementation of the Serial Monitor Fragment.

• ucinterface: Contain all modules interfaces.

• atmega328P: Contain the specific implementation of all modules for the ATmega328P.

This project depends on JUnit4 and PowerMokito for tests and uses the SonarQube and Jacoco plugin for code quality and coverage respectively.

Tests

SOFIA is being tested with the use of JUnit4. So far, about 48% of the project have been tested with unit test, as shown in figure 2.3.

Figure 2.3. Code coverage for SOFIA (measured with jacoco)

Figure 2.4 shows the code coverage per module.

Figure 2.4. Code coverage per modules (measured with jacoco)

The SonarQube analysis produces the following result, shown in figure 2.5.

Figure 2.5. SonarQube analysis

Although it may not look that good, a manual inspect of the problems showed that there are many false positives or some problems found are not a problem at all (SonarQube is a tool for static analysis and this kind of problem is expected). All the main issues found (relevant to the project) are already fixed.

Some other informations

Lines of Code	10 k
Line Coverage	49%
Condition Coverage	46.1%
Classes	70
Files	41
Cyclomatic Complexity	1,969
Duplicated Lines	29.1%
Language	English / Portuguese

Conclusion

I guess that's all. Here I wanted to show you a little more about how this project is being developed, in case you are interested.

As I said before, SOFIA is a prototype and I'm still trying new stuffs to see what work and what doesn't. Many of the original project were already changed in order to improve performance, add new functionalities and so on.