As an Embedded Software Engineering Intern at Skydio, I had the novel opportunity to work at the forefront of a product release cycle by contributing to the development of the new Skydio X10 enterprise drone. My primary focus was the design and implementation of the Factory Reset feature, a project which entailed a multitude of modifications to the drone's C and Python code. The core design of the feature centered around reliable, lightweight communication between the Linux userspace and boot-time C code, in order to safely wipe the filesystem of temporary changes as efficiently as possible. The feature was exposed to developers through a simple debug CLI, while the user-facing implementation required modifications to the Python code that interfaced the mobile app with the onboard NVidia and Qualcomm SoCs, initiating and synchronizing the shared reset behaviour of the processors, and reporting status updates back to the user's controller. The end result was a robust and intuitive method for users and developers alike to restore their drones to a clean, factory-like state.

Apart from working on the Factory Reset feature, I also had the opportunity to work on patching various bugs for release, improving the robustness of the X10's OTA update system, debugging various drone issues for other developers and testers in the office, and rewriting some of the charging driver code present on the STM32 microcontroller used in the Skydio Dock to implement I²C using purely asynchronous operations.

During my co-op term at Samsung Research America, I worked on a variety of multi-disciplinary projects as part of the Think Tank Team, with the bulk of my work revolving around the development and/or improvement of HW/SW prototypes. Some examples include flattening the frequency response and improving the SNR of an audio amplifier circuit, implementing real-time, context-based classification and reduction of sensor noise in C, and developing a compact, low-power rev1 prototype circuit for a potential new project idea.

Along the way, I was also able to broaden my personal range of experience and tools by getting familiar with using digital oscilloscopes (Picoscope, Digilent Analog Discovery 2) for ease of electrical signal monitoring and recording, as well as using Jupyter Notebook for improved data visualization, manipulation, and algorithm prototyping.

During my co-op term at onsemi, my main responsibility was the development and integration of GPIO-related libraries for the new, ARM Cortex-M33 based RSL20 platform. Specifically, I designed pushbutton and LED management libraries that were designed to be easy to integrate into our customers' existing hearing aid applications, while also providing a level of uniformity to our sample applications. The library design process involved determining project requirements and scope, figuring out how to integrate the SysTick and TIMER modules into the design in a flexible way, writing C code that was highly configurable and able to serve all possible customer needs, creating internal and customer-facing SDK documentation, developing self-testing applications to verify library behaviour, and integrating these libraries into our existing sample applications. These libraries will ultimately serve not only as an improvement to the uniformity and feature set of our existing sample code, but may also act as a template for similar designs on other projects in the future.

I also worked on some tasks related to automated application testing, working to improve our test infrastructure for future developers, and using the Python BEHAVE framework to write automated tests for some sample applications. These automated tests are part of the test suite that is run on a regular basis by our Jenkins server, and are also used during SDK release cycles to verify behaviour for customers.

During my co-op term at Ford, my main focus was to continue a previous co-op student's investigation into using Vector's MICROSAR Runtime Measurement (RTM) module in order to provide performance metrics for system debugging. Throughout my investigation, I became intimately familiar with the RTM module, eventually figuring out how I could scrap the module and its significant overhead entirely, and create a much more lightweight implementation using timestamps from our 1us free-running timer and OS context-switch hooks in order to record the execution time of all OS tasks and ISRs. This implementation has since been used to evaluate the performance of various shared memory implementations, as well as to debug an OS error that was causing system crashes.

I also assisted various testing teams by creating useful user console commands, such as a command to reset all Diagnostic Identifier values to default, and a command to toggle developer mode in a way that persists across system power cycles.