Klagarge/MSE-CSEL
1
0
Fork 0
Code Activity

docs(MP): proofread languagetool

Browse Source
This commit is contained in:
Rémi Heredero
2026-06-06 22:45:56 +02:00
parent 6ef9b6a244
commit 361b6eae4d
1 changed files with 16 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
doc/mini-project.typ
View File

@@ -42,7 +42,7 @@
#v(5em)
#infobox()[
The repository for this labs can be found at the following address:
The repository for these lab can be found at the following address:
#align(center)[https://github.com/Klagarge/MSE-MA-CSEL]
]
@@ -67,7 +67,7 @@ The @fig:general-architecture shows the general architecture of the project.
This @led and the measure of the temperature is managed by a kernel module. This module support an automatic and manual mode. In the automatic mode, the blinking frequency is automatically adjusted according to the temperature. We can switch this mode by a @sysfs entry. In the manual mode, we can set the blinking frequency by writing in another @sysfs entry. The @sysfs also provide an entry to read the current temperature and blinking frequency.
Another part in this mini-project is to create a daemon in user-space to control manually the fan. The buttons are read by the daemon to increase and decrease the blinking frequency in manual mode. The daemon also display the current temperature and blinking frequency on an @oled screen. The daemon can also be controlled by a @ipc interface.
Another part in this mini-project is to create a daemon in user-space to control manually the fan. The buttons are read by the daemon to increase and decrease the blinking frequency in manual mode. The daemon also displays the current temperature and blinking frequency on an @oled screen. The daemon can also be controlled by an @ipc interface.
Finally, a tiny @cli is implemented to control the daemon through the @ipc interface.
@@ -75,30 +75,30 @@ Finally, a tiny @cli is implemented to control the daemon through the @ipc inter
== Architecture
In our architecture, we manage to separate with callback our functionalities. Then, we use threads for multiprocessing which involve to implements some atomic operations, signals and mutex. We add socketpair and @sysfs for communication. Finally, we get some information through registers.
In our architecture, we manage to separate with callback our functionalities. Then, we use threads for multiprocessing which involve to implement some atomic operations, signals and mutex. We add socket pair and @sysfs for communication. Finally, we get some information through registers.
== Kernel
The kernel part is separated in three main part: the blink, the temperature and the @sysfs. All this part are initialize in the main but handle in a regulator that build the logic of the auto/man mode. In auto mode, the regulator sets the frequency according to the temperature. The regulator also handle the @sysfs for setting the mode and the frequency in case of the manual mode.
The kernel part is separated in three main parts: the blink, the temperature, and the @sysfs. All this part are initialized in the main but handle in a regulator that build the logic of the auto/man mode. In auto mode, the regulator sets the frequency according to the temperature. The regulator also handles the @sysfs for setting the mode and the frequency in case of the manual mode.
=== blink
The `blink.c` and `blink.h` files implement the part that control the status @led. It's a kernel module, so we have an init and an exit function. The init function create a kernel thread that blink to a specific frequency. The exit function stop this thread. The period is stored in a global `atomic_t` variable, so it can be safely set with the `adjust_period` function.
=== temperature
The read of temperature is done through register. It implements the function to calculate the temperature from the register. It changes the formula when the temperature is over 70°C as specified in the datasheet.
The read of temperature is done through the register. It implements the function to calculate the temperature from the register. It changes the formula when the temperature is over 70 °C, as specified in the datasheet.
=== #gls("sysfs", long: false)
It uses some callbacks for every actions in the module:
It uses some callbacks for every action in the module:
- read temperature
- set and get mode
- set period
- get period
We separates the setter and the getter of the period to avoid some issue. Because if we set a wrong value or in automatic mode, the value would be wrong for getting it. In the way we did it, the read value will be the current.
We separate the setter and the getter of the period to avoid some issue. Because if we set a wrong value or in automatic mode, the value would be wrong for getting it. In the way we did it, the read value will be the current.
== Daemon
The deamon has the core in `app`. It handles the `sysfs` functions needed by the different features. It provides them for the @oled screen, buttons, @led:pl and @ipc server.
The daemon has the core in `app`. It handles the `sysfs` functions needed by the different features. It provides them for the @oled screen, buttons, @led:pl and @ipc server.
=== #gls("gpio", long: false)
We develop the @gpio part as near as possible with a pseudo class for the @led and a pseudo class for the button. The @led class is quite simple and help to have a good understanding of this principle. As shown in @fig:led-class-header, we create a structure for the @led. A `LED_init` function is used to create a @led object by returning a pointer to this structure. Function to this class start with the same prefix `LED_` and take a pointer to the structure as parameter.
@@ -122,7 +122,7 @@ We develop the @gpio part as near as possible with a pseudo class for the @led a
caption: "Led class header"
) <fig:led-class-header>
We develop the button in the same way, with class spirit. But a button have no function to control it, but only a callback that need to be set as shown in @fig:button-class-header. So this pseudo class abstract the complexity of a button and we provide a simple @api with a nice callback system. Behind the scene, we have a thread that look the button file with an `@epoll` and call the callback when the button is pushed. The first button to be initialized create this static thread. All new button are added on the event list of this thread.
We develop the button in the same way, with class spirit. But a button has no function to control it, but only a callback that need to be set as shown in @fig:button-class-header. So this pseudo class abstract the complexity of a button, and we provide a simple @api with a nice callback system. Behind the scene, we have a thread that looks the button file with an `@epoll` and call the callback when the button is pushed. The first button to be initialized create this static thread. All new buttons are added on the event list of this thread.
#figure(
[```c
@@ -139,7 +139,7 @@ We develop the button in the same way, with class spirit. But a button have no f
The @ipc provides a server to handle messages from other processes with a socket pair. All is defined in a common file: `src/06-mini-project/common/common_ipc.h`. This file implements the action and the format of the message through the socket.
=== #gls("oled", long: false)
The @oled part have nothing special, we basically use the provided example. But we had to modify the devicetree to add the @i2c that control the screen. It was the first time we had to modify the buildroot part. We forgot a bit how it's absolutely not enough to modify in `/config/board/.../nanopi-neo-plus2.dts`. In the `get-buildroot.sh` script, there is a rsync command that was done only at the full beginning of the semester when we initialize everything. To effectively modify the devicetree, we had to copy our modification, then rebuild (it's short because most parts are already built):
The @oled part has nothing special, we basically use the provided example. But we had to modify the devicetree to add the @i2c that control the screen. It was the first time we had to modify the buildroot part. We forgot a bit how it's absolutely not enough to modify in `/config/board/.../nanopi-neo-plus2.dts`. In the `get-buildroot.sh` script, there is a rsync command that was done only at the full beginning of the semester when we initialize everything. To effectively modify the devicetree, we had to copy our modification, then rebuild (it's short because most parts are already built):
```bash
rsync -a /workspace/config/board/ /buildroot/board/
@@ -154,11 +154,11 @@ Then, if we boot with @tftp, we can simply reboot. Otherwise, we have to reflash
=== application
This part is the core of the daemon and provides @api for the @oled screen, the buttons and the @ipc to set and get values from the module. It uses @sysfs technology to communicate with the kernel.
This part is the core of the daemon and provides @api for the @oled screen, the buttons, and the @ipc to set and get values from the module. It uses @sysfs technology to communicate with the kernel.
It implements some specific action like increase and decrease the period of the @led. It provides too specifics functions for the buttons, because it has to signal with the power @led when it is pushed. We called that an animation.
It implements some specific action like increase and decrease the period of the @led. It provides too specifics functions for the buttons because it has to signal with the power @led when it is pushed. We called that an animation.
This animation is managed by a signal and a condition. The function increase and decrease for the buttons increment a counter and send a signal to the animation thread. It handles it and make the animation until the counter reach 0. Then it waits with the `pthread_cond_wait`.
This animation is managed by a signal and a condition. The function increase and decrease for the buttons increment a counter and send a signal to the animation thread. It handles it and makes the animation until the counter reach 0. Then it waits with the `pthread_cond_wait`.
@@ -166,11 +166,11 @@ This animation is managed by a signal and a condition. The function increase and
The @cli is connected to the daemon through the socketpair define in the `common` as the @ipc. It uses the same struct and actions for changing mode or set, increase, decrease a period.
It is installed in the `/usr/bin` by the `justfile`. It allows to use it from everywhere in the terminal. It can be use as a tool.
It is installed in the `/usr/bin` by the `justfile`. It allows using it from everywhere in the terminal. It can be used as a tool.
= Future work
#let link-github-project = "https://github.com/users/Klagarge/projects/3/views/1?filterQuery=is%3Aopen"
C.f.: #link(link-github-project)[Github project] #footnote(link-github-project)
C.f.: #link(link-github-project)[GitHub project] #footnote(link-github-project)
= Conclusion