blog: add nuttx article for external static libraries

[fdcavalcanti]

Adds and article with instructions on how to use an externally built static library.

Description

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

Related

Testing

No issues on local 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.

[wmrsouza]

LGTM

[pedrominatel]

@fdcavalcanti, thanks for your contribution.

[fdcavalcanti]

@fdcavalcanti, thanks for your contribution.

Thanks! Updated and also changed the date.

[pedrominatel]

c.c @f-hollow

[f-hollow]

@fdcavalcanti Thank you for writing this article!

Please don't feel overwhelmed with the wall of text in my review comments. I basically ask a lot of questions to nudge you at some ideas on what information might be missing and how to possibly better structure the content.

I believe the current structure can be improved but not sure yet about details. My rough ideas for now:

• Add a section on comparing the usual approach of adding a software stack to the NuttX image vs. your simpler approach. Cover advantages and disadvantages if there are any. Make it more clear when each approach is more useful (if it applies).
• Using an example library describes the chosen library and shows how to use it on its own. I would remove the verb using as it sounds like we are already using it with our NuttX image. How about changing the title to External library?
• Testing on NuttX Simulation gives a self-contained guide on doing the proof of concept that adding a pre-compiled library works. By self-contained, I don't mean that you need to duplicate the steps from other sections, you can refer to the steps describes earlier, but there should be a quick explanation of what should be done and a reference to the steps provided earlier.
• Using the library on ESP32-C6 gives a self-contained guide on how to add the library to a NuttX image.

[f-hollow]

There is one problem with this paragraph though. It mentions three parts:

• The first part introduces and builds the sample library on x86.
• The second part describes how to add the library to the NuttX simulation environment.
• The last part cross-compiles to RISC-V and runs the example on the ESP32-C6.

The relevant part of TOC looks like this:

• ...
• Using an example library
• Testing on NuttX Simulation
• Using the library on ESP32C6
  • Cross-compilation
  • Test on target
• ...

The wording in the intro and the heading titles is quite different and involves some thinking to figure out how they correlate.

I suggest that you make the wording more consistent.

[fdcavalcanti]

I considered the second level heading (##) as a part (or a section if it makes more sense). The "Using the library on ESP32C6" part contains sub sections, which I don't mention. Do you think I should?

Suggested change

	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 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. The third part cross-compiles to RISC-V and runs the example on the ESP32-C6. Finally, the fourth part concludes the article.

[f-hollow]

I am not a software developer and might not understand certain things, but, after reading the intro, the process and the logic in this article seem a bit unclear to me.

I will share my questions and concerns with you and let's see if it is my lack of knowledge or the article structure can be indeed made more clear.

Here we go:

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.

• Application vs. NuttX application vs. external library:
  • When you talk about your application here, do you mean an external library that you mentioned in the summary?
  • I see that you also mention NuttX applications in the summary, but why you need to move your application to NuttX if it is already a NuttX application?
• Software stack, static libraries, and execution environments:
  • Why do you often need to add your existing software stack to the NuttX image? Should it be done so that the NuttX image can be easily compiled for different environments?
  • I see that This article shows how to build NuttX with your custom application without moving your entire stack to the NuttX directory. It is not clear at what price you achieve this simplicity. Do I understand it correctly, that you need to compile your external library for a certain architecture yourself and then add it to your NuttX appplication for each different architecture? Can you compile your eternal library for all popular architectures from the beginning and add all of them to your NuttX appplication?
• This software may run on a different RTOS: Not clear what this software refers to your application or NuttX image?

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.

• Why do we need to build the sample library for x86 first? Is it for testing only or it helps us better integrate a sample library into our NuttX image before we compile the binary for the target architecture?
• I see that there are two major parts in the article (1) doing a proof of concept that the approach of adding a pre-compiled library to NuttX image works in a simulation environment, and (2) it gives an actual how-to on adding a pre-compiled library to a NuttX image and flashing it to the ESP32-C6.
  • Is my understanding correct? If yes, should we clearly split these two parts and turn them into self-contained guides because now they seem somewhat entangled?
• The first part introduces and builds the sample library later turns into an example library

[fdcavalcanti]

• Application vs. NuttX application vs. external library

"Your application" means anything outside the NuttX environment. Take the hex to rgb example.

It is an external application that I can run anywhere, like in a Raspberry Pi which would be compiled natively. Now, I want to use it in a microcontroller and I choose NuttX as my operating system. When I move this application to NuttX, then I call it a Nuttx Application.

• "Why do you often need to add your existing software stack to the NuttX image?"

I changed to "you may need" as that makes more sense, since you only need to migrate once.

About compiling, you would only compile for your target architecture, not all of them. Compiling for all would be a mess of downloading many compilers and unnecessarily large build environments. There's no point in an end user building for ARM if the target is a ESP32.

• "Why do we need to build the sample library for x86 first? Is it for testing only or it helps us better integrate a sample library into our NuttX image before we compile the binary for the target architecture?"

Yes. That's essentially it. Because NuttX is POSIX compliant, we can code our app normally in a Linux machine and then simply add it to NuttX.

• "Is my understanding correct? If yes, should we clearly split these two parts and turn them into self-contained guides because now they seem somewhat entangled?"

They are the same. We only change the contents on the Make.defs once (3 or 4 lines) and then we can build the library externally to whatever architecture we want, as long as we copy the .a file to the proper place.

[f-hollow]

@fdcavalcanti As we agreed, I will merge your article now.

Please check my comments and create a follow-up PR with your updates once you have a chance.

Thank you very much for your article!