The Most Challenging Part of the Project
The Most challenging aspect of this project throughout all the deliverables, was surprisingly configuring different aspects of the embedded system such as the ADC, the GPIO interface, and the interrupt handlers rather than the actual logical problems themselves.
Examples
- During Lab 2, when switching from tight polling to interrupt synchronization, PB4 stopped working so we had to find a new pinout
- When working on D1, we used the UART to transmit a string indicating the theoretical direction of movement for a motor to see if a limit switch could reverse the motor direction… except sometimes the serial monitor didn’t print anything out? Adding a check on
HAL_UART_STATE_READYseemed to have resolved the issue since maybe the USART driver isn’t ready when the first transmission happens which is something that we expect to work initially.- When working on D2 We had trouble configuring one ADC since we never called
MX_ADC1_Init()because we thought it was called in some file outside of main.- When working on D3, we had issues configuring the second ADC (the outputs seemed coupled). We resolved this issue by enabling
DiscontinuousConvModeand callingHAL_ADC_Starttwice (once per potentiometer).
The majority of these issues were solved in collaboration with lab TA help. In my opinion, these issues weren’t logically challenging but rather things that we expected to just work, or things that required a nuanced understanding of the configurations for the F401RE chip.
The Part That Contributed the Most to My Learning
D1 contributed the most to my learning since it was the backbone for D3 and D4 and is where we first learned how to control the motors programatically.
D1 taught us how to:
- Interface with GPIO (something that we knew in theory but never tried in practice from MTE 241)
- Read a pre-existing code base and modify it to serve our needs
- Control DC motors programatically
- Search online for configuration settings
- Read chip schematics
- Form directed questions to communicate and resolve specific issues with the lab TAs
Personally…
As someone who is typically weak when it comes to applying theory to applications and who comes from a backend developer background, this deliverable made me much more comfortable working with our chip, and even more comfortable using breadboard to wire limit switches to GPIO.
What Would I Do Differently in My Next Embedded Project
In the future, I would try to write cleaner more functioned code since our main loop quickly became messy.
I would also like to look into methods of reducing the input lag between two sensors for a more effective controls system. That being said, I’d like to generally, be more aware of the different design choices that exist (e.g. reading ADC values from the DMA instead of directly) and when they should be used.
What Would I Not Change in Future Embedded Projects
I would keep my problem solving methodology in the future in terms of how I have approached each deliverables:
- Form questions based off of deliverables
- Find answers to those questions
- Write tests for my answers
- Write code / build hardware to pass the tests
- Evaluate qualitatively
Additionally, I wouldn’t change the iterative testing methodology that we adopted throughout this project which involved only making one change and testing for results when encountering an issue which allowed us to isolate issues in a systematic manner.
I would finally, maintain my clear and consistent lab documentation throughout my embedded projects which helped facilitate knowledge transfer between team members, track progress, maintain a record of hardware + software configurations, and maintain a record of problems and their solutions for posterity.