Hi all, I decided to start this hackaday account to document my journey of learning electronics. 

While I have some programming background in Java and C++ from high school courses and built Lego robotics in elementary school, I felt a bit self-conscious saying I wanted to pursue electrical engineering without hands-on microcontroller experience.

On social media, I see people creating cool but simple projects using materials such as a microcontroller, a few wires, motors, sensors, and some code. While that definitely glosses over the circuit design, debugging, and hardware constraints, it made me eager to explore.

Accompanying me on this journey is a W55MH32L_EVB board. Browsing the quick reference guide, the first thing that caught my eye was its support for MicroPython. Having standard Python syntax available on bare metal makes the learning curve much friendlier. The board also features an integrated Ethernet port, allowing it to interface directly with local networks or the internet.

Getting started physically was pretty straightforward: I plugged a USB-C cable into the DAP-LINK port to handle power and programming, opened Thonny IDE, pointed the interpreter to generic MicroPython, and had a working session right away. Something interesting I discovered was that MicroPython uses Read-Eval-Print Loop or REPL. It is an interactive programming environment that takes user inputs, executes them, and returns the result immediately.

Instead of writing a full program, saving it, compiling/running it, and checking the output, a REPL lets you run code one line or expression at a time.

Something cool I discovered is that I can write algebraic expressions in the shell and it will be evaluated.

Before diving into complex projects, I spent the past few days wrapping my head around the basic communication protocols and networking features exposed on the board’s pinout.

Hardware Communication Protocols

I spent some time looking at how microcontrollers actually talk to outside components. Technically, they are called Serial Communication Protocols. However we need to first, we need to start with learning about buses and clocks:

• A bus is a shared communication highway (traces or wires) that lets multiple devices exchange data without dedicated point-to-point connections turning the board into unmanageable copper spaghetti.
• A clock (SCLK) provides the electrical heartbeat, a square wave toggling between logic HIGH (3.3V) and LOW (0V), giving digital logic distinct, synchronized sampling points.

Now we can start looking at the some of those different communication protocols

• UART (Universal Asynchronous Receiver-Transmitter): UART only needs two data lines: a transmit line (TX) and a receive line (RX). You simply cross them over; TX on one side goes to RX on the other, and vice versa. Basically, one device can send its information to the second device whenever it wants, and the second device does the same. This is what makes it asynchronous. However both devices agree on something called a baud rate, which can be analogous to two people agreeing on a talking pace before the conversation starts.
• SPI: A faster, synchronous protocol that uses separate lines for sending data (MOSI), receiving data (MISO), and clocking, plus a chip-select pin for each connected device. One device is always the master and controls the clock, while the other devices are slaves/peripherals that respond to it. The chip-select lets the master tell any of the peripherals to “wake up” and receive/send data.
• I2C (Inter-Integrated Circuit): I2C is a two-wire bus (one wire, SDA, for data and another wire, SCL, for the clock) designed to connect multiple sensors or chips along the same two shared lines using individual device addresses. Again, one device is always the master; however, to talk to the other devices, each of the other connected devices have unique addresses that the master can use to identify each of them.

Networking Concepts & Ethernet

Having onboard Ethernet makes this board pretty unique compared to typical beginner boards. I learned about the foundational protocols and ideas that makes the network happen:

• IP Address: Every device connected to the internet such as phones, laptops, or smart TVs need a way to send and receive information. An IP address is a string of numbers assigned to your device (like 192.168.1.42 or 142.250.190.46). It tells data packets where they came from and where they need to go. Without one, a website would not know which device requested a webpage.
• DHCP: DHCP is the system that assigns IP addresses to devices. We can think of our home Wi-Fi router acting as a hotel clerk running DHCP. When your phone connects to Wi-Fi, it does not have an address yet. It asks the router, "Can I get an address?" The DHCP server automatically hands it an available IP address on a temporary "lease".
• DNS: Translates human-readable domain names into IP addresses so the board knows where web servers live.
• TCP vs. UDP: The two main ways to send data across a network. TCP establishes a reliable connection and confirms every packet arrives intact, whereas UDP just fires data off without handshakes, much faster, but packets can get dropped along the way.
• NTP: Network Time Protocol, which lets the board sync its internal real-time clock to precise atomic time over the internet.

So far, my progress has just been a bunch of background research. It's a small start, but understanding the difference between these buses and protocols makes the hardware world feel a lot less intimidating.