Project 2 - Implement the Code for controlling the retraction and extension of Airplane’s landing gear

Dear sir/madam,

Please find attached the files for my final project of Embedded C Essentials. As was the case with all of my other recent submissions, I have used a custom directory structure and Makefile:

project_2/Makefile

project_2/src/fsm_practical.c

project_2/src/fsm_practical.h

project_2/misc_funcs/get_input.c

project_2/misc_funcs/print_state.c

project_2/craft_states/craft_grounded.c

project_2/craft_states/craft_takeoff.c

project_2/craft_states/craft_ascend.c

project_2/craft_states/craft_cruise.c

project_2/craft_states/craft_descend.c

project_2/craft_states/craft_landing.

A few notes about this specific project:

1. Initially I had referenced the video on FSMs heavily and implemented it as a series of if/else statements without using any loops. However, I had also booked 2 O3 sessions to understand what exactly was required for this project and it seems that all of the TSEs have conflicting ideas on what constitutes a state machine. One TSE recommended I use an array of function pointers while another said that a struct "state table" was apparently mandatory, even though this is not explicitly mentioned anywhere in the problem description and during the class videos, professor Jegan A implemented a state machine using an array of function pointers as well as a switch case statement in addition to a struct state table. No where have I come across the mandate that a struct state table is necessary, even after reconfirming with a third TSE after the O3 session. As such, I have implemented this project using an array of function pointers.
2. I have used an array of function pointers and #define macros for the states because I also attempted to keep the binary size as small as I possible could given the mindset that such a program has to be implemented on an aircraft's embedded system, which I believe is restricted in space and is safety-critical. My understanding is that #define macros as states simplify program complexity and also reduce fileseize compared to using enum types. If this is inaccurate, please let me know!
3. In the spirit of getting familiar with hardware interrupts and because I am using an Arch Linux system, I have implemented epoll() as the user input facility. This has allowed me to simulate an appropriate squat switch/pilot's lever/emergency landing check timelimit quite satisfactorily, and it was really interesting for me to learn how it works.

If I might also share a few closing thoughts on my Embedded C Essentials journey: it has been absolutely phenomenal engaging with Skill-Lync and the TSEs, and I would like to sincerely thank professor Jegan A for his time spent teaching. I'm quite excited to proceed onto the Linux driver and AVR sessions because I thoroughly enjoy such topics!

Thank you for your time as always,

Best regards,

Rahul Singh