Differences
This shows you the differences between two versions of the page.
|
pm:prj2025:iivasciuc:marius.zaharia2305 [2025/05/18 14:16] marius.zaharia2305 [Implementation details] |
pm:prj2025:iivasciuc:marius.zaharia2305 [2025/05/25 18:30] (current) marius.zaharia2305 [Results] |
||
|---|---|---|---|
| Line 186: | Line 186: | ||
| * The source file contains a static variable (private to the file) that represents the counter, offering an init and a getter method for outside modules. | * The source file contains a static variable (private to the file) that represents the counter, offering an init and a getter method for outside modules. | ||
| * The ISR is rather short and simple, by only incrementing the counter value. | * The ISR is rather short and simple, by only incrementing the counter value. | ||
| + | * The live value of the counter can be observed in the debug menu. | ||
| **debounce** | **debounce** | ||
| Line 207: | Line 208: | ||
| ===How it works=== | ===How it works=== | ||
| - | **General** | ||
| * The users are stored in a statically allocated array, each of them having a predefined name and UID. Initially, all of them are marked as not registered and have to go through the ''register'' menu to become active. | * The users are stored in a statically allocated array, each of them having a predefined name and UID. Initially, all of them are marked as not registered and have to go through the ''register'' menu to become active. | ||
| * The ''main loop'' is rather simple: at each iteration, it checks the value of the ''curr_menu'' global variable via a ''switch'' and launches the associated routine accordingly. Each such routine then displays its message and enters a ''while(true)'' loop, waiting for user input. | * The ''main loop'' is rather simple: at each iteration, it checks the value of the ''curr_menu'' global variable via a ''switch'' and launches the associated routine accordingly. Each such routine then displays its message and enters a ''while(true)'' loop, waiting for user input. | ||
| - | * The goal was to develop a device as realistic and error-less as possible, so extreme cases are always considered, such that: the user is forced to enter a 4-digit PIN code (is not allowed to submit it until it has 4 digits and cannot input more than 4 digits), the user is always allowed to cancel his current action if he changes his mind, error states are checked, sending the system to the ''ERROR'' menu if such a case occurs (i.e. if the current menu is the home page of a user, but there is no user logged in). | + | * The menus communicate with each other by altering the values of the global variables and of the static variables from the ''menus.cpp'' file. |
| + | * The goal was to develop a device as realistic and error-less as possible, so extreme cases are always considered, such that: the user is forced to enter a 4-digit PIN code (is not allowed to submit it until it has 4 digits and cannot input more than 4 digits), the user is always allowed to cancel his current action if he changes his mind, hypothetical error states are checked, sending the system to the ''ERROR'' menu if such a case occurs (i.e. if the current menu is the home page of a user, but there is no user logged in). | ||
| + | * ''enum class'' have been used for their own namespace feature and for their expressivity compared to numerical constants. | ||
| + | ===Correctness validation=== | ||
| + | * Each component was firstly tested alone to validate that the hardware was functional. | ||
| + | * The system as a whole was incrementally tested, after each new feature added. | ||
| + | ===Optimizations=== | ||
| + | * Because the maximum number of users is 6, their ''registered'' status was saved as a single 8-bit variable, using bitwise operations: user i is registered if the i-th bit (from the right) of the variable is 1. If each user had a boolean variable associated for this matter, 6 bytes would have been used in total, instead of 1. Thus, 5 bytes are saved. | ||
| + | * As the available RAM memory is limited, all the menu message strings were stored on the Flash rather than the RAM, via the ''F()'' macro. Also, variable types from ''<stdint.h>'' were used, for a better control. | ||
| + | * The notifications are encoded for memory efficiency: the ''Notification'' struct contains the type (''RecvFromFriend'', ''FriendReq'', ''ReqAccepted''), the index of the user who sent it and the sum of money sent (used when it is the case). | ||
| ===== Results ===== | ===== Results ===== | ||
| + | * The final result is a fully functional, robust device, that encompasses all the proposed features in an intuitive and efficient way, both hardware and software wise. | ||
| + | * [[https://youtu.be/4Y1_n8hq_Kc|Demo on YouTube]] | ||
| ===== Conclusions ===== | ===== Conclusions ===== | ||
| - | + | * To sum up, this project achieved its goal of getting hands-on experience with embedded design, from wiring up the components all the way to writing efficient and functional software. | |
| - | ===== Download ===== | + | * For me, it was a fun experience with satisfactory results, which I will surely cherish in the future! |
| - | + | ||
| - | + | ||
| - | + | ||
| - | ===== Timeline ===== | + | |
