Because many people frequently ask this question, I've compiled a summary document for your reference. It's important to clarify that the following steps are for Linux systems, not WinCE. You might notice that among embedded systems developers, far more people research Linux than WinCE, and many manufacturers' resources are primarily Linux-based. I've always found this hard to understand. WinCE's interface is much more visually appealing and user-friendly than Linux's. More importantly, WinCE development is essentially the same as Windows development, making it much easier to learn. Yet, far more people are learning Linux or using Linux for embedded systems than WinCE. In conversations with many working professionals, I've learned that their companies have never considered using WinCE due to its high cost; they all use Linux for development. Even in my graduate school lab, WinCE wasn't used; most research focused on Linux, with a few projects using VxWorks, but I never heard of anyone using WinCE—because it's open-source ! Of course, I've heard that WinCE 6.0 is now also open-source, but Linux has an unparalleled advantage in terms of cost and resources. Correspondingly, more and more electronics manufacturers are starting to use Linux for product development. For example, Google's recently developed smartphone operating system , Android, is actually an improvement on the Linux- 2.6.23 kernel.
First, learn basic bare-metal programming.
For those learning hardware, it's essential to first have a basic intuitive understanding of how to use the hardware, and even more importantly, a deep understanding of how it's controlled. Starting with Linux systems and porting will only lead to a deep and confusing learning curve. When I first started learning ARM, I chose ARM7 (the reason being that ARM9 was still very expensive at the time). While learning ARM7, I maintained the mindset I used when learning 51 microcontrollers, using ADS for programming. My first experiment was controlling an LED. Those who have studied ARM for a while might laugh at this approach as foolish, but it's not. I actually think this process is much better because no matter how complex the system, it ultimately comes down to these lowest-level hardware controls. Therefore, having an intuitive understanding of how to control this hardware is crucial.
While learning bare-metal programming, it's crucial to thoroughly understand the hardware architecture and control principles—what I call "hardware understanding." Hardware understanding means comprehending how the hardware organizes its resources and how these resources are controlled by the CPU and programming. For example, the S3C2410 has an AD converter, GPIO (general purpose I/O ports), and a NAND flash controller. These components are controlled by registers, each with an address. What do these addresses mean ? How are these registers used to control the operation of these peripheral devices ? Furthermore, each cell within the NOR flash memory has a corresponding address in the chip's memory. What is the relationship between these addresses and the register addresses mentioned earlier ? Are they the same ? The NAND flash memory's storage cells are not linearly arranged. How does the S3C2410 map NAND flash addresses to memory space for use ? Or, simply put, how should NAND flash be used ? Additionally, when programming the ARM9 using ADS, an initialization assembly file is required. What is the purpose of this file ? What does its code mean ? Can it be omitted ?
These are all aspects of understanding hardware. Understanding these concepts leads to a deep understanding of hardware, which will greatly help with further learning. If you skip this step, I believe you will feel increasingly confused and find these things unfathomable as you progress. This is because your foundation has not been solid.
However, let me state first that I have not used ADS to program ARM9. I learned ARM7 and then directly used ARM9 to learn the Linux system. Therefore, it is difficult for me to answer questions about using ADS to program ARM9. You should research it yourself.
A tutorial on this topic will be provided soon. The examples in this tutorial were not written by me for the boards we distribute, but were taken from our college lab. Impet wrote them for their own experimental kits, but they are still very useful and can serve as a valuable reference.
Second, conduct some basic experiments using the Linux system.
When you buy a board, it usually comes with some Linux example programs. Spend some time working through them; this process is very meaningful and helps you accumulate practical experience for further learning. Can you imagine someone who has never used a Linux system before learning Linux programming ? Follow the examples in the manual and do the experiments. It might seem a bit like a toddler learning to walk, but I think many experts go through this process.
DeepBlue Technology currently has no plans to provide corresponding sample programs in this regard. The main reason is that the development board providers offer a wealth of sample programs. We do not do duplicate work; we only provide the most valuable things that they do not have.
Third, study the complete operating process of a Linux system.
What components make up a complete Linux system ?
The three parts are: bootloader, linuxkernel (Linux kernel), and rootfile (root file system).
So how do these three parts work together to form this system ? What is the function of each part ? What is the relationship between them ? How are they connected ? What is the system's execution flow ? Understanding these questions will give you a clear understanding of how the entire system operates, laying another important foundation for the next step of creating this Linux system. Tons of information on this topic can be found online; study it carefully.
Fourth, begin system porting.
As mentioned above, a complete Linux distribution consists of three parts, and you now understand the relationship and function between them. Now, what you need to do is learn how to build these things yourself.
Of course, I can't ask you to write that code; that's not feasible. In fact, the source code for all three can be downloaded online, but it's impossible to simply download and compile it and expect it to run on your system. It requires a lot of modification until it runs on your board. This modification process is called porting. During the porting process, you'll learn a lot and understand a great deal of related knowledge. Once you complete this process, you'll find yourself a novice expert.
If you have a strong research spirit during this process, you will inevitably think of looking at the source code. Many books introduce how to read Linux source code, but I don't advocate looking at Linux source code aimlessly. In Xu Sanduo's words, it's meaningless. Only look for some good books when you feel you must look at the source code while doing porting. Here, I recommend a good book, Ni Jili's "Linux Kernel Analysis and Programming," which is a book specifically for the Linux- 2.6.11 kernel and goes into great depth. I suggest improving your C programming skills first before reading it.
As for the transplantation of each part, you can find tons of information online. Study it yourself. However, I should warn you that many people who share their experiences are more or less holding back. If you follow their advice, you will always encounter some problems, but they will not tell you how to solve them. At this time, you have to rely on yourself. If you can't even rely on yourself, then come to me to study it together. I can't guarantee that I can solve your problem because I may not have encountered your problem before, but I believe I can give you some advice that may help you solve the problem.
The ultimate goal of this step is to download the standard source code package from the official website of the source code (which is all foreign, sadly), modify it, and finally run it on the board.
To paraphrase Archimedes: "Give me a network cable and I can master Linux."
Fifth, study the writing of Linux drivers.
Porting the system is not the ultimate goal; the ultimate goal is to develop products and do projects, all of which require driver development.
Linux drivers are incredibly diverse. There are significant differences between writing drivers for Linux 2.4 and Linux 2.6 , and even within Linux 2.6 , drivers can vary between versions. Therefore, writing Linux drivers is never easy, and there isn't even enough reference material for writing drivers for the latest versions. My suggestion is to use and port a relatively recent kernel version, which will provide sufficient resources for learning driver programming later.
For book recommendations in this section, please refer to another article, "Recommended Books for Learning Embedded Linux".
Sixth, study application programming.
Besides writing drivers, the final step in creating projects is writing applications. The current trend is towards graphical application development, and the Qt/E library is the most widely used in graphical applications. I've always used this library to develop my own applications, but I hope you can use the domestically developed MiniGUI library. To borrow a line from Jay Chou's advertisement, "Support domestic products, support MiniGUI!" MiniGUI programming is similar to VC programming under Windows, relatively easy to learn, and the results are quite good. I've used it to develop programs for ARM7. However, MiniGUI's biggest drawback is the lack of a graphical operating platform like Qtopia, which greatly limits its adoption. I've dreamed of collaborating with Beijing Feiman Company (the copyright holder of MiniGUI) to develop a graphical operating platform like Qtopia using the MiniGUI library, but due to my limited skills, this remains just a dream, haha.
Once you complete this step, you've essentially learned all of embedded Linux.
Here's another small piece of experience I'd like to share. During my learning of embedded Linux, I rarely asked for help. The objective reason was that none of my teachers, classmates, or senior students were experts in this field. The subjective reason was that I didn't like asking others; I preferred to research and solve problems myself. This approach has an advantage: it improves your problem-solving skills. Because when working with these things, there are always many problems you don't understand, and others don't have that experience. Not everyone can provide the answer, so you have to solve problems yourself. This is where your problem-solving ability becomes crucial. Therefore, my advice is to search online for general questions. If you still can't find the answer, ask an expert. If that still doesn't work, research it yourself. Don't just wait for others to solve your problems.
Remember, questions are the best opportunity to learn.
For more information, please follow the Embedded Systems channel.
