You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
summary: "This guide demonstrates how to integrate external libraries into NuttX applications using static libraries and cross-compilation. Learn how to build a library on x86, integrate it into the NuttX simulation environment, and cross-compile for RISC-V targets like the ESP32-C6, all without moving your codebase into the NuttX directory structure."
9
+
summary: "This guide demonstrates how to integrate external libraries into NuttX applications using static libraries and cross-compilation. Learn how to build a library on x86, integrate it into the NuttX simulation environment, and cross-compile for RISC-V targets like the ESP32-C6, all without moving your entire codebase into the NuttX directory structure."
9
10
---
10
11
11
12
## Introduction
12
13
13
-
When moving your application to NuttX, you often need to add your existing software stack to the NuttX image. This software may run on a different RTOS or even on an x86 environment, but sometimes it must run on multiple target devices. This article shows how to build NuttX with your custom application without moving your entire stack to the NuttX directory. You use a static library and cross-compilation to achieve this.
14
+
When moving your application to NuttX, you may need to add your existing codebase to the NuttX build environment. That is a common scenario where the user application does not interact with hardware (such as data processing and analysis) but must run on the target devices. Those applications are usually tested on an x86 computer and adapted to run on an RTOS, or, in the case of NuttX, it should not need changes if the codebase is already POSIX compliant.
14
15
15
-
This article is divided into three parts. The first part introduces and builds the sample library on x86. Then, a second part decribes how to add the library to the NuttX simulation environment and finally, the last part cross-compiles to RISC-V and runs the example on the ESP32-C6.
16
+
This article shows how to build NuttX with your custom application without moving your entire stack to the NuttX directory. You use a static library and cross-compilation to achieve this.
17
+
18
+
This article is divided into three parts. The first part introduces an example library and builds it on x86. Then, the second part decribes how to add the library to the NuttX simulation environment. The third part cross-compiles to RISC-V and runs the example on the ESP32-C6. Finally, the fourth part concludes the article.
16
19
17
20
## Using an example library
18
21
19
-
As an example, we will use an example application library that converts a hexadecimal color string to RGB with the following structure:
22
+
For demonstration purposes, we will use an example application library that converts a hexadecimal color string to RGB with the following structure:
20
23
21
24
```
22
25
hex-converter/
@@ -34,27 +37,34 @@ The reference project is available in [this repository](https://github.com/fdcav
34
37
The `hex-converter` library exposes one single function called `hex_to_rgb`. The user provides a pointer to a string representing the hex color and a pointer
35
38
to an array where the R, G, and B values are copied. It is a simple application but very useful as an example.
36
39
37
-
Clone the repository and build it according to the steps in the README file to produce the static library. To confirm that everything works, run the provided `main` example program. This program accepts a hexadecimal color string as input.
40
+
Now, let's use the library on our x86 machine and see how it operates.
41
+
42
+
1. Clone the repository
43
+
2. Build the library according to the steps in the README file
44
+
3. Execute the provided `main` example program:
38
45
39
46
```bash
40
47
$ ./main "#1A2B3C"
41
48
Input: #1A2B3C
42
49
RGB: (26, 43, 60)
43
50
```
44
51
45
-
At this point, the directory should contain a static library called `libhex_to_rgb.a` that will be added to the NuttX build system.
52
+
At this point, the directory should contain a static library called `libhex_to_rgb.a`.
46
53
47
54
## Testing on NuttX Simulation
48
55
49
-
As an user, you might want to use this library in an application. The first solution might be to copy the entire hex-converter repository to the NuttX application directory and
56
+
As a user, you might want to use this library in an application. The first solution might be to copy the entire hex-converter repository to the NuttX application directory and
50
57
add it entirely to the build system. That works but is complicated, not user-friendly, and causes a Makefile mess.
51
58
59
+
Before proceeding, if you are new to NuttX please read the [Getting Started with NuttX and ESP32](https://developer.espressif.com/blog/nuttx-getting-started/) which contains an introduction setting up NuttX.
60
+
52
61
The simplest way to test this library on NuttX is to modify the ready-to-use Hello World example in the NuttX Apps repository, which could in fact be any application.
53
62
54
63
With your NuttX environment ready, follow these steps:
55
64
56
-
1. Copy `libhex_to_rgb.a` from the hex-converter repository to `apps/examples/hello` (the Hello World example directory).
57
-
2. In `apps/hello/Make.defs`, add the hex library, library path, and include path.
65
+
1. Clone the example repository and build `libhex_to_rgb.a` as discussed in [Using an example library](#using-an-example-library)
66
+
2. Copy `libhex_to_rgb.a` to `apps/examples/hello` (the Hello World example directory)
67
+
3. In `apps/hello/Make.defs`, add the hex library, library path, and include path
58
68
59
69
The Make.defs file should look like this:
60
70
```
@@ -131,19 +141,22 @@ nsh>
131
141
132
142
Success! We can compile our library externally, link it to a NuttX application, and use it.
133
143
134
-
## Using the library on ESP32C6
144
+
Now that simulation works, let's look into a real use case that requires the same code to work on hardware.
135
145
136
-
Now that simulation works, we must look into a real use case that requires the same code to work on hardware.
137
-
For this, we must compile the library to be supported on our RISC-V target.
146
+
## Using the library on the ESP32C6
138
147
139
-
### Cross-compilation
148
+
This section shows how to prepare the library for an actual target device—in this case, the ESP32-C6. To do this, we first cross-compile the example library for the RISC-V architecture and then integrate the resulting static library into the "Hello Example" that will be executed on
149
+
our target.
140
150
141
-
In the hex-converter Makefile, the CC instruction changes to `riscv-none-elf-gcc` instead of `gcc` when you set the TARGET variable.
151
+
### Cross-compilation
142
152
143
153
Clear the environment to delete the x86 build and rebuild for RISC-V:
154
+
144
155
1. `make clean`
145
156
2. `make TARGET=riscv32`
146
157
158
+
In the hex-converter Makefile, the CC instruction changes to `riscv-none-elf-gcc` instead of `gcc` when you set the TARGET variable.
159
+
147
160
The same `libhex_to_rgb.a` library is ready, but now it can be used on RISC-V devices. This can be verified easily:
148
161
149
162
```
@@ -190,7 +203,7 @@ This article demonstrates how to integrate external libraries into NuttX applica
190
203
191
204
The static library approach offers several advantages. You can develop and test your code on an x86 machine without flashing the target device. The same library works across different architectures with minimal changes, requiring only a recompilation step. This workflow saves development time and simplifies the porting process.
192
205
193
-
By following these steps, you can add existing software stacks to NuttX without moving your entire codebase into the NuttX directory structure. This approach maintains separation between your application code and the RTOS, making maintenance and updates easier.
206
+
By following these steps, you can add existing applications to NuttX without moving your entire codebase into the NuttX directory structure. This approach maintains separation between your application code and the RTOS, making maintenance and updates easier.
0 commit comments