feat(lab03): report
This commit is contained in:
@@ -2,47 +2,40 @@
|
||||
|
||||
= Linux System Programming
|
||||
|
||||
== File system
|
||||
This laboratory is focused on the user space. We make an application to change the blinking frequency of a led with button.
|
||||
|
||||
=== Buttons
|
||||
|
||||
// TODO
|
||||
|
||||
It has some difficulties to locate the button on the GPIOs. Because this is not
|
||||
the same as we have done in the module in the precedent laboratory.
|
||||
-> explain
|
||||
|
||||
Discover the epoll to trigg on file modification
|
||||
|
||||
discover the timer_fd
|
||||
|
||||
all is file
|
||||
|
||||
all can be in the epoll to manage all event from files
|
||||
This laboratory implements a user-space application for the NanoPi NEO Plus2 that controls the blinking frequency of the status LED using three push buttons. The main goal was to replace a CPU-intensive busy loop with an event-driven design.
|
||||
|
||||
|
||||
=== timer
|
||||
- epoll
|
||||
- thread
|
||||
- 1 consumer, 1 provider, no need mutex
|
||||
== Design
|
||||
The application is based on multithreading: one thread handles the LED timing, while another handles button events. GPIOs are accessed through sysfs, which allows the LED and buttons to be managed as file descriptors. A key design choice was to centralize all events with a single epoll instance, so both timer events and button events can be processed efficiently.
|
||||
|
||||
- create timer empty
|
||||
- set timer with `timerfd_set_time`
|
||||
- definition of the initial time and not the repetition time, to use only one timer
|
||||
- link to epoll
|
||||
All logs are done using the syslog at info level:
|
||||
```c
|
||||
syslog(LOG_INFO, "Start logging silly led-controller"); // INFO level
|
||||
```
|
||||
|
||||
== Difficulties
|
||||
The most difficult part was understanding the GPIO mapping between the physical pins and the sysfs GPIO numbers. All can be found in the #link("https://linux-sunxi.org/GPIO", [*sunxi driver*]) which is the driver for GPIO.
|
||||
|
||||
=== syslog
|
||||
- one opening
|
||||
```c openlog("CSEL Logs", LOG_PID, LOG_USER);```
|
||||
LOG_PID is used to keep the PID of the process in the log, and LOG_USER is used to specify the facility of the log (what type of programme).
|
||||
== Results
|
||||
We can demonstracte that the application works in an efficient than the silly led controller given:
|
||||
|
||||
```c syslog(LOG_INFO, "Start logging silly led-controller"); // INFO level```
|
||||
#table(
|
||||
columns: (1fr, 1fr),
|
||||
align: center + horizon,
|
||||
stroke: none,
|
||||
[
|
||||
#figure(
|
||||
image("test-silly.png"),
|
||||
caption:[Run silly led controller on nanopi]
|
||||
)<fig-silly>
|
||||
|
||||
],[
|
||||
#figure(
|
||||
image("test-epoll.png"),
|
||||
caption:[Run epoll led controller on nanopi]
|
||||
)<fig-epoll>
|
||||
]
|
||||
)
|
||||
|
||||
We can see the difference between @fig-silly and @fig-epoll. One is using a core at 100% and the other one not.
|
||||
|
||||
=== Multithreading
|
||||
- one thread for the button, one for the led
|
||||
- button write time
|
||||
- led read time and sleep for this time
|
||||
- no mutex because we have only one provider
|
||||
BIN
doc/lab03-silly_led/test-epoll.png
Normal file
BIN
doc/lab03-silly_led/test-epoll.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 94 KiB |
BIN
doc/lab03-silly_led/test-silly.png
Normal file
BIN
doc/lab03-silly_led/test-silly.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 78 KiB |
Reference in New Issue
Block a user