Introduction This article is dedicated to those who have just embarked on the embedded path. Here, I briefly document my learning experiences and some insights I have gained along the way, hoping to help beginners avoid unnecessary detours.
The image above shows a corner of the laboratory where I have worked and studied, looking quite cluttered with various electronic components and tools. My former work team consisted of four people, one of whom was a senior engineer with 11 years of experience and already had his own patents, another was a warm-hearted engineer with 5 years of experience, and the other two were experts in power supply and video. Being immersed in this environment gradually sparked my strong interest in hardware.Microcontroller Starting with microcontrollers, FPGA, SOPC hardware setup, and software programming, and now diligently studying ARM, I have approached these topics with boundless enthusiasm. The laboratory provided a convenient learning environment, equipped with ready-to-use Winbond 51 microcontrollers, a Weifeng emulator, an Advanced Labtool 48uxp universal programmer, and a 120,000 RMB oscilloscope. I bought a universal board myself, and during the learning phase, I could conduct experiments just by referring to a book. I began with simple LED blinking, later moving on to seven-segment displays, PWM, interrupts, serial communication (communication between microcontrollers and between microcontrollers and PCs), I2C EEPROM read/write, A/D conversion, temperature measurement, etc. Each experiment, from data searching, program writing, debugging to problem-solving, brought me immense satisfaction.FPGA When I first entered the laboratory, I received an Altera Nios EP1C20 Cyclone series development board, which was purchased under a university program for 5,000 RMB. Thus began my journey of learning FPGA. I had previously studied Verilog, but it was purely theoretical, writing a few small programs and simulating them with Quartus II’s built-in simulation software. Simulating with software often yields the desired results, but once downloaded to the chip, problems arise one after another. The beginning is always difficult; my first experiment was to light up an LED. I wrote a program (just a few lines), compiled it, assigned pins, simulated it, and then connected the development board to the PC with a JTAG download cable to download the .sof file to the chip. Looking back, these were such simple steps, but at that time, I spent considerable time and effort searching for information and repeatedly experimenting. Especially with pin assignments, the documentation only stated that it needed to be done this way, but why? At that time, I had no further thoughts; I just wanted to see the results of the experiment. Achieving results gave me immense satisfaction and enthusiasm, so when, after much effort, the LED in my first FPGA experiment finally worked as intended, the excitement was reminiscent of the time I achieved LED blinking while learning microcontrollers. A habit and experience I developed during experiments was to read books while experimenting, discovering problems during experiments, and looking up relevant documents for any unclear issues or principles. With this enthusiasm, I gradually delved deeper into FPGA, designing some conventional logic circuits, including logic gates, multiplexers, encoders, arithmetic units, shifters, and later more complex circuit designs such as FIFO, digital counters, frequency counters, state machines, traffic control, card phone billing systems, and UART. I implemented all these experiments using Verilog. Initially, I intended to learn VHDL, but since my classmates were using Verilog, I switched to it for easier discussion. Once I started learning, I gradually discovered that I deeply loved Verilog; it undoubtedly suited me better. This is also a recommendation I want to make: pay attention to the tools used by those around you. The tools they use may not be your favorite or the most popular, but if you want to communicate and discuss issues with them, it’s better to adapt and use the same tools for smoother communication. After arriving at the laboratory, since all the staff used Weifeng’s emulator, the software was naturally provided by Weifeng. I found Weifeng’s software not very good; it only supports assembly language and is significantly inferior to the renowned Keil C51. However, unless you want to wait until you encounter a problem and find no one around to help you, it’s still more convenient to choose Weifeng’s software for initial communication. Later, after exploring on my own and consulting with the engineers around me, I became very familiar with Weifeng and developed my own assembly language skills. At this point, I began embedding Keil into Weifeng to write programs in C. Eventually, I downloaded the Keil C51 software and officially started writing programs in the Keil development environment. Of course, during simulation, I could also use the Weifeng emulator in the Keil environment. I believe Weifeng considered this point when manufacturing their products; some of their products must be compatible with mainstream software like Keil. After using Keil C51, I no longer wanted to use Weifeng’s compilation software. Similarly, after writing programs in C, I no longer wanted to use assembly. However, assembly is essential for every hardware development engineer; it has irreplaceable advantages that C cannot match. Sometimes, assembly is necessary. Assembly language runs efficiently, though it can be tedious to write. However, in certain specific situations, assembly still plays an irreplaceable role. For example, when porting a USOC to a microcontroller, processor-related programs must indeed be completed in assembly.SOPC Later, I learned SOPC. From building the minimal system hardware platform to writing simple LED blinking programs, to running .sof files on the chip and watching the LED light up and down, my enthusiasm surged. Similar to my previous learning of microcontrollers and FPGAs, my first experiment was still LED blinking, gradually transitioning to more complex functional designs, which were merely implementations of functions I had previously realized in Verilog. The difference between the two is: one is entirely implemented using Verilog; the other requires first building the hardware system with SOPC Builder and then programming the software in Nios IDE. Both methods can achieve the required functionality, but the latter is more convenient and faster because, in this method, we use the principle of “borrowing,” where the IP cores have already implemented our functions, and all we need to do is utilize them. During this period, I particularly appreciated Altera’s introduction of the SOPC, which liberated us from the tediousness of building hardware systems. We only need to add our own IP cores and some necessary peripherals according to our needs. Altera or other third-party companies have provided us with well-performing and functional IP cores; all we need to do is integrate these IP cores into our system to complete the required functionality. After completing the hardware system, we need to program the software for the hardware system in the Nios IDE environment provided by Altera, where we can fully use C language to achieve the required functionality.UCOS Later, I learned the UCOS embedded operating system, mainly used in FPGA. Nios has already been ported for users, requiring no modification of any files. We can use it by making some corresponding settings in the Nios user interface. Altera provides several excellent examples in their templates, including task management, semaphores, mailbox passing, event flags, and time management. We need to read and study them carefully, and if necessary, modify the templates to achieve our own functionality. This is a higher level of imitation, transforming some of their elements into our own; I believe this is something hardware enthusiasts and beginners are very eager to do.Conclusion In fact, during my FPGA learning journey, I encountered times when experiments did not progress, and I felt frustrated. At that time, I knew nothing about low-level hardware and could barely understand basic schematics, let alone how programs ran on the development board. Days without any sense of progress felt long and torturous. Once, I chatted with a warm-hearted engineer in the office about my confusion, and he suggested that I first learn microcontrollers and build a hardware platform starting from the minimal system. He was always patient in helping me with learning issues, which benefited me greatly. I am very fortunate to be able to learn in such an environment. When encountering problems and feeling stuck, it might be worthwhile to try a different approach and talk to those around you; it may lead to a change.
Some Screenshots of Electronic Books
【Complete Set of Hardware Learning Materials Collection】
