As I dove into my coding journey with Google Summer of Code (GSoC), my mentors and I opted for weekly text-based updates on Discord for progress tracking and doubt-solving, tailored to our project’s needs. This approach differed from the broader GSoC meetings, providing more focused one-on-one support.
However, I found myself on a family holiday trip within two weeks, which naturally limited my project time. Despite this, I made sure to make the most of whatever time I had available. It’s easy to feel a bit overwhelmed during such times, but I learned to focus on working smartly rather than stressing over hard work.
My current focus revolved around exploring ways to interface I/O operations with the processor, starting with Memory-mapped I/O. This method involves mapping each I/O device to a specific memory address, allowing the processor to interact with them directly through memory operations. Setting it up required writing an I/O controller in Verilog HDL to map I/O pins to designated memory addresses, making it simple to control GPIO pins through memory pointers.
I chose Memory-mapped I/O because of its compatibility with specifying memory locations through C. Here’s a basic syntax example:
#define GPIO1 (*(volatile bool *) 0x03000000)
#define GPIO2 (*(volatile bool *) 0x03000001)
#define GPIO3 (*(volatile bool *) 0x03000002)
In this setup, volatile ensures that the compiler doesn’t optimize these memory-mapped variables, crucial for direct hardware interaction. While this direct approach wouldn’t function on typical PCs due to access restrictions, it’s feasible when cross-compiling for a specific CPU with predefined memory mappings.
However, despite its simplicity, Memory-mapped I/O had notable drawbacks:
- Inefficient Data Handling: It writes only one bit at a time, underutilizing the processor’s 32-bit data bus and clock cycles.
- Performance Challenges: On CPUs where memory operations take longer than two clock cycles, this method could significantly impact overall system latency.
As a result, it became clear that this approach wouldn’t meet our goal of achieving low-latency processing. We experimented and decided to move away from Memory-mapped I/O for our project’s requirements.
To sum up, while Memory-mapped I/O provided a straightforward solution for hardware interfacing, its limitations in performance and efficiency led us to explore alternative methods more suitable for our needs.
References