Skip to content

Conversation

@fdcavalcanti
Copy link
Contributor

Description

This PR changes the article content with better introduction and fixes some inconsistencies.

Related

Applies changes suggested in #596.

Testing

Build ok with hugo server.


Checklist

Before submitting a Pull Request, please ensure the following:

  • 🚨 This PR does not introduce breaking changes.
  • All CI checks (GH Actions) pass.
  • Documentation is updated as needed.
  • Tests are updated or added as necessary.
  • Code is well-commented, especially in complex areas.
  • Git history is clean — commits are squashed to the minimum necessary.

Copy link
Collaborator

@f-hollow f-hollow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fdcavalcanti Thank you for implementing most of the comments and for your detailed explanations in the original PR.

Now that I better understand the background information, I have a few more suggestions on how to improve the content and it smoother.

One question:

Your article has a few code snippets. Do you want to create a small GitHub repo with a sample project available for cloning for those who want to save time instead of creating all code files and copying code snippets themselves?

@fdcavalcanti
Copy link
Contributor Author

@fdcavalcanti Thank you for implementing most of the comments and for your detailed explanations in the original PR.

Now that I better understand the background information, I have a few more suggestions on how to improve the content and it smoother.

One question:

Your article has a few code snippets. Do you want to create a small GitHub repo with a sample project available for cloning for those who want to save time instead of creating all code files and copying code snippets themselves?

I would say the example app repository is enough, the code that runs on main is also available there. Other than that, it is a minor change on Make.defs file.

@fdcavalcanti fdcavalcanti force-pushed the feature/nuttx-external-lib branch from 4f5cd7b to 11e5d92 Compare November 26, 2025 18:00
Apply some text changes for better reading.

Signed-off-by: Filipe Cavalcanti <[email protected]>
@fdcavalcanti fdcavalcanti force-pushed the feature/nuttx-external-lib branch from 11e5d92 to 0693793 Compare November 26, 2025 18:02
@fdcavalcanti
Copy link
Contributor Author

@f-hollow thanks for the deep review! Applied many changes, let's do another round of revision to be sure?

@github-actions
Copy link

🎉 A preview for this PR is available at: https://preview-developer.espressif.com/pr600/

Copy link
Collaborator

@f-hollow f-hollow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fdcavalcanti Thank you for implementing the comments so quickly.

A couple of final nitpicks, otherwise LGTM!

## Introduction

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.
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 contains mostly hardware-independent logic (such as data processing and analysis) that was originally developed on a POSIX compliant system. Those applications are usually tested on an x86 machine 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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the last sentence, we say applications are ... tested ... and adapted to run on an RTOS. Then we go on `in the case of NuttX, it [NuttX] should not need changes if the codebase is already POSIX compliant.

Do you want to say that NuttX is POSIX compliant, that is why there is no need to adapt the codebase? If yes, how about updating the last part?

Suggested change
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 contains mostly hardware-independent logic (such as data processing and analysis) that was originally developed on a POSIX compliant system. Those applications are usually tested on an x86 machine 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.
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 contains mostly hardware-independent logic (such as data processing and analysis) that was originally developed on a POSIX compliant system. Those applications are usually tested on an x86 machine and adapted to run on an RTOS. In the case of NuttX, which is POSIX compliant, there is no need for codebase adaptation.

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.
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.

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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you are not dropping the conclusion, it still consists of four parts.

Also, decribes > describes as suggested in #600 (comment).

Suggested change
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.
This article is divided into four parts. The first part introduces an example library and builds it on x86. Then, the second part describes 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.

Now that simulation works, we must look into a real use case that requires the same code to work on hardware.
For this, we must compile the library to be supported on our RISC-V target.
## Using the library on the ESP32C6
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As suggested in #600 (comment)

Suggested change
## Using the library on the ESP32C6
## Using the library on the ESP32-C6

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
add it entirely to the build system. That works but is complicated, not user-friendly, and causes a Makefile mess.

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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest simplifying the language a bit.

Suggested change
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.
If you are new to NuttX, you can read the [Getting Started with NuttX and ESP32](https://developer.espressif.com/blog/nuttx-getting-started/), which shows how to set up the NuttX development environment.

1. `make clean`
2. `make TARGET=riscv32`
In the hex-converter Makefile, the CC instruction changes to `riscv-none-elf-gcc` instead of `gcc` when you set the TARGET variable.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You change the existing value to a new value. Why switch the order?

Edit: changes to riscv-none-elf-gcc instead of gcc > changes from gcc to riscv-none-elf-gcc

Also, the edits slightly improve the flow:

Suggested change
In the hex-converter Makefile, the CC instruction changes to `riscv-none-elf-gcc` instead of `gcc` when you set the TARGET variable.
When you set the TARGET variable in the hex-converter Makefile, the CC instruction changes from `gcc` to `riscv-none-elf-gcc`.

## Using the library on the ESP32C6
### Cross-compilation
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
Copy link
Collaborator

@f-hollow f-hollow Nov 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You usually address it as Hello World example?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants