I work with PLCs and industrial controls, so when this project started I was not coming into it as an embedded hardware designer.

My normal troubleshooting process is pretty straightforward: figure out what the machine is supposed to be doing, look at the logic and I/O, measure what is actually happening, and keep narrowing the problem down until something stops making sense.

That mindset ended up helping a lot, even though the tools were completely different.

This project started because I wanted to communicate with a MicroSquirt ECU from an iPhone. The ECU already talked over RS232, but that normally meant having a laptop and cable connected to it.

I wanted the connection to look more like:

ECU → RS232 → WiFi → iPhone

At first I thought the bridge would probably be the easy part.

Get an ESP32, connect it somehow to RS232, open a TCP connection, and move bytes back and forth.

That was about the level of detail I had in my head.

Then I started learning what was actually involved.

The ESP32 UART wasn't RS232 electrically. I needed a transceiver. Then I needed to understand the signal directions. Then power. Then the DB9 pinout. Then firmware. Then networking.

And eventually I reached the point where I didn't want a collection of development boards and jumper wires sitting in a box. I wanted an actual PCB.

That meant learning another completely new subject.

I started using AI heavily during this stage because I could ask questions while I was working instead of stopping every few minutes to search through unrelated forum posts and documentation.

Sometimes it explained something in a way that clicked immediately.

Other times it sent me down a path that sounded perfectly reasonable until a datasheet or a meter proved it wrong.

That became part of the learning process too.

One thing that carried over directly from PLC troubleshooting was that I never really cared whether an explanation sounded convincing. I cared whether I could prove it.

If the schematic said one thing and the voltage on the board said something else, the voltage won.

If AI said a signal should be on one pin and tracing the actual board showed otherwise, the board won.

That mentality probably saved this project more than once.

At this point I still had a long way to go. I hadn't learned EasyEDA yet, hadn't ordered a custom PCB, hadn't built the iPhone application, and definitely hadn't figured out how I was going to put any of this into an enclosure.

I was still basically a PLC guy trying to make an ECU talk to a phone.

I just didn't know yet how far that idea was going to take me.