Some of Brandon Jernigan's Projects

This project is a serial terminal that can be accessed from a terminal emulator (i.e., Windows Terminal). There are plenty of serial terminals out there, and this one doesn't try to replace any of them. It is simply a personal tool that I wrote while at Microchip, as I needed something light-weight and easily accessible. I also wasn't a big fan of the terminals integrated with MPLab X and Microchip Studio. I am primarily working in the terminal anyways, so it just made sense to put something together in my free-time that I would enjoy using more. I wrote it in Rust since I already used it as part of a day-to-day tech-stack.

While working at Microchip, my team supported a total of 210 serial devices, most of which were EEPROM and some Flash. When releasing the a new version of the Memory Xplorer product, a majority of those devices needed be tested individually. Different families of devices and sometimes, different devices within the same family (family being based on fabrication process) were equipped with different features, necessitating the testing of so many devices before a release. This project arose from the need to test so many hardware devices to release a peice of software and the accompanying firmware. I originally started developing it as a side project in my spare time. After presenting it to the team as a potential solution to this testing problem, I was granted permission to work on it as part of my day-to-day job.

It originally started out as a breadboard project, using an PIC32. There were other chips that I prototyped at the beginning, but the PIC32 (specifically the PIC32MX534F064H) was the best fit for my needs. All of the work to design the board was done in Altium Designer. This was my first time doing any type of hardware design/development (and the only time since) so I'm sure you can see issues in the layout, but I'm still proud of it. By the end of the project the board supported the following protocols: I2C, SPI, and SingleWire. I developed a custom interface to configure the device over UART since the device would not be able to distinguish transmissions over protocols mentioned above from configuration and emulation. Though I don't have the ability to share (nor the memory) of the specifics, the format was basically an encoded packet with headers that signified the type of change. As an example, swithing the protocol from SPI to I2C or simulating a memory array of a different size or event enabling a portion of the "memory array" to act as a special register, such as a security register. Finally, everything was written in C using a wrapped version of the GNU C compiler.

Many times I find myself digging through terminal output to identify something, whether it be trace statements for debugging, or specific portions of a stack trace. To aid me in this, I wrote a simple Python script that wraps an application, launching it and capturing its output. Prior to regurgitating this output, it parses it for specific patterns or key words to highlight that piece of text to my liking. I set it up to support multiple color formats (e.g., 8bit, 16bit, 24bit), as not all terminals are created equal. I also implemented logic that allows me to color a whole line of text or only a specific word. I found that I primarily used this to subdue output that I really didn't care about, such as the Spring Boot portions of a Java stack trace. So, I would just color the general output to a color that was closer to my terminal background, and highlight the portions that I was focused on, such as the portions of said stack trace that were from my source code.