Who: Pearl Automation
Where: Scotts Valley, CA
Languages: C, C++, ARM assembly, Thrift, Python
Pearl's RearVision consists of two separate embedded devices - the camera system, mounted on the car's license plate, as well as an in-car OBD-II powered system.
Phillip was an early hire at Pearl - #12, hired right after series A closed. He was the primary developer for the camera system.
In the early stages of the company, Phillip performed initial bringup of the system and was responsible for:
- SOC Bringup
- RTOS Selection
- Setting up the build system
- Porting initial software from gcc to clang
- Software / source tree architecture
- Implementing the DFU framework to flash devices
- Creating a USB CDC shell and defining commands for various drivers
- Driver bringup for multiple devices
- Solar IC
- EHCI (ported u-boot EHCI stack to our system)
- Defining factory test methods and processes
After the bringup stage, focus shifted to firmware support for the camera sub-system. Responsibilities included:
- Implementing low-level C++ functionality in the RearVision frame firmware
- Converting early libraries and drivers to C++
- Conversion of C-based USB Host stack to C++
- Ported vendor host-side Camera USB/UVC APIs from Linux to an RTOS
- Managed interfaces for client software to initiate and configure video streams.
- Worked closely with our ISP vendor to:
- Identify and prioritize requirements and issues
- Assist in debugging ISP, video, and memory issues
- Optimize ISP pipeline performance to reduce latency and improve quality over BT/Wifi
- Optimized video system memory usage
- Created a buffer pool class to re-use large buffers in camera path
- Eliminated all copies from USB->Camera path when getting new frames.
- Converting malloc()/free() calls to use smart pointers
- Debugging memory stompers
Where: Cupertino, CA; Shenzhen, CN
Languages: C, Lua
After the iPhone 5C, I transitioned onto bringup for the iPhone 6/6+. A shortage of team members meant that I managed both the iPhone 6 and iPhone 6+. After EVT was completed, I transitioned to project management of the iPhone test line. I traveled to most builds for both programs during this product cycle.
During the prototype phase, I was responsible for rapid bringup of new parts for evaluation at prototype builds. I worked closely with the product development and reliability teams to make sure they had the ability to validate all the parts under consideration while at the proto builds. I also expanded our driver and factory test support to encompass other new design changes.
I spent significant time training and developing the CM software team. Unlike on the iPhone 5C, I managed to get the iPhone 6 CM team to help write software, allowing me to manage the immense workload by offloading tasks to the CM team. My strategy was to keep the hardest tasks for myself - once a task could be crystallized into a simple set of instructions, I would utilize the CM team. This allowed me to stay ahead of deadlines with an extremely challenging schedule, and helped me to expand my communication abilities. It is not simple to provide instructions across language barriers!
Current testing also expanded on the iPhone 6/6+ lines. Limits were able to be set for different phones while keeping the same core software (previously, duplicate software was required). Also, much of the current testing coverage was pushed up to SMT to catch failures before final assembly.
After transitioning to project management, my primary responsibility was the factory test and calibration lines. I was responsible for coordinating software and fixture readiness, ensuring that we had everything we needed for builds. I also frequently briefed executives on program status and readiness for hardware builds. I became well-versed in crisis management, as there are always new failures, missing coverage, late deliverables, and missing support. Prioritization and triage were important in making sure build goals were met without further delays.
I managed test plans, test coverage, and line flow for iPhone 6 and iPhone 6+ development, including these areas:
Who: Georgia Tech Research Institute (GTRI), Georgia Institute of Technology (GT)
Where: Atlanta, GA
Languages: C (pre-C99), i8085 assembly, VHDL
GTRI has multiple contracts to redesign existing systems and update them with modern electronics. The i8085 was nearing end-of-life, so GTRI requested that we implement the i8085 in VHDL and produce a development kit for prototyping new hardware. Our final product resulted in a Micro-C program (running on i8085 in VHDL) talking over a MIL-STD-1553B bus to blink a light on a receiving board.
The MIL-STD-1553B Embedded Development Kit consisted of a Xilinx Spartan FPGA and two MIL-STD-1553B capable daughter cards of our own design. The FPGA board interfaced with MIL-STD-1553B transcievers to prove that we could communicate over the bus with our software.
Our primary challenge was getting software running on our i8085 FPGA device. We revived an old ISO-C compiler (Micro-C) and managed to get software compiling in a virtual machine. Next, the vendor's 1553 driver needed to be back-ported for i8085 compilation. This was challening, as many modern conveniences and best practices are not valid in prior to C99. The compiler also had its own separate limitations, such as lack of support for float/double/long/enum/typedef.
After getting example code running on our i8085 design, we created a VHDL system architecture that allowed us to interface with our daughter board and run the i8085 demo program.
8085-HI6130-Port: Port of HI-6130 Driver and Demo Project to a MICRO-C Compiler for the 8085
SREC-to-COE: Converter to convert Motorola SREC hex files to Xilinx COE memory initialization files.
1553-Firmware: Contains VHDL implementing an 8085, Holt HI-6130 1553 IC, and Memory. Also includes firmware used to demo the system.
High Level Schedule / Waterfall
Who: Georgia Tech Research Institute (GTRI)
Where: Atlanta, GA; Charleston, SC; Aberdeen, MD
Languages: C, ASM
The I-BESS project was sponsored by the U.S. Army Rapid Equipping Force (REF). I-BESS was developed to collect data on the effect of IED blasts on a soldier. Many soldiers were coming back from Iraq and Afghanistan with traumatic brain injuries (TBI) and the Army needed data to understand how soldiers were being injured.
The I-BESS system consisted of four parts: a soldier body unit (SBU), a vehicle unit mounted to the back of each seat (VIA), a headset, and a black box recorder which stored the data inside each vehicle. The SBU and headset were designed to collect directionality, pressure, force, and head rotation that a soldier experienced during an IED event.
Phillip was the lead developer for the VIA system. The VIA system utilized bluetooth, wifi, RFID, and CAN to communicate with the other products in the ecosystem. It also included a high-g accelerometer to measure force during an IED event. When a soldier sat in a seat, the VIA would exchange wifi connection information over RFID, download the stored event data, and send the data to the black box computer. Both the VIA and black box recorder collected their own IMU data during IED events involving the vehicle.
In the early stages Phillip was responsible for bringup of the new design, working closely with the HW and RF teams to debug issues. One of the key parts - the RFID controller - had very poor documentation from TI, and the RF group was undergoing restructuring. Phillip reverse engineered the communication protocol using example binaries provided from TI and produced an Interface Control Document (ICD) for the part.
The project involved frequent travel to the SPAWAR facility in Charleston, SC to perform various tests: fit check, radio jamming, installation, in-vehicle performance. During later stages of the project, the travel shifted to the U.S. Army proving grounds in Aberdeen, MD, where live demolition tests were performed.
Who: Georgia Tech Research Institute (GTRI)
Where: Atlanta, GA
Skills Developed: Research, Documentation, API Design
The Future Airborne Capability Environment (FACE) project was started by the U.S. Navy. The stated goal was to produce a common software architecture that contractors would adhear to. Software projects would be decoupled from the hardware interfaces, allowing the U.S. government to accept competitive bids from multiple software developers. The status quo is/was to be locked into a single vendor due to complaints about opening up their own intellectual propery.
When the FACE was being formed, GTRI was tasked with working in parallel to the committee to come up with an alternative common architecture proposal. While working on this team, Phillip's role was to perform research on API design, military architecture challenges, military harware, and software architecture. These findings fed into a section of the original GTRI FACE proposal.
GTRI later worked with the FACE consortium to develop the final standard and proof-of-concept software implementations.
Who: Georgia Tech Research Institute (GTRI) When: 2009-2010 Where: Atlanta, GA Languages: C, Visual C++
Phillip's major software development experience was working on a MIL-STD-1553B bus analyzer. The software supported monitoring, recording, playback, and decoding messages sent to EW/avionics systems. This software had been written and maintained by GTRI for 10-20 years, leading to a large and unruly code base.
Phillip supported a major release cycle and was responsible for a variety of activities:
- Integrating support for decoding traffic on new systems
- Incorporating new interface updates for supported systems
- Fixing bugs identified in previous releases
- Reviewing formal software test plan, fixing errors, and incorporating requirements for new feature sets
- Running formal software tests prior to releasing the software to the customer
Who: Laboratory of Lymphatic Biology and Bioengineering (GT)
Where: Atlanta, GA
Languages: C, C++
Phillip volunteered with Georgia Tech's Laboratory of Lymphatic Biology and Bioengineering for a summer, working with their researchers to develop software to research mechanical stresses on lymphatic vessels. The device was controlled by a PIC32 microcontroller which interfaced with two motors. These motors were intended to actuate syringes, which controlled flow of fluid through the lymphatic vessel.
The main researcher had already designed a board to interface with an Arduino to control the motors via DACs. Work began on a DAC driver (interfacing to the motors) and basic controls for the device, but the desired output voltages never appeared. This issue was tracked to a hardware design problem: the CLR line on the DAC was left floating and prevented register settings from being applied. After reworking the boards, the DAC driver was completed and an initial feedback loop to output specific waveforms was implemented.
The remaining time on the project was spent improving the existing code base and applying professional software practices. The project was migrated to git, duplicated code was eliminated, and libraries for interfaces like SPI and I2C were written. A further hardware issue was identified (DAC overheating leading to part failure), but there was not sufficient time remaining to root-cause the issue.