Re: Integrating Nuttx to a firmware project.
Thanks everyone for the help. I managed to have everything set up to my liking. As a reference for others trying to manage multiple builds, here is what I did: I created scripts for every build, using the following format: # Example contents of DEBUG.sh kconfig-tweak --enable CONFIG_DEBUG_FEATURES make oldconfig The build type is defined as an environment variable in my system (e.g. BUILD = DEBUG). The top-level Makefile contains: ifeq ($(BUILD), DEBUG) BUILD_DEP = DEBUG.build BUILD_SCRIPT = DEBUG.sh endif ifeq ($(BUILD), RELEASE) BUILD_DEP = RELEASE.build BUILD_SCRIPT = RELEASE.sh endif I changed target all to: all: $(BUILD_PATH)/$(BUILD_DEP) @make -C nuttx and I added the target: $(BUILD_PATH)/$(BUILD_DEP): @make clean @mkdir -p $(BUILD_PATH) @./boards/config/$(BUILD_SCRIPT) @touch $(BUILD_PATH)/$(BUILD_DEP) This way every time I build NuttX, the build configuration is checked by the Makefile dependency. If needed (i.e. every time I change the build type), the project is cleaned and the changes are applied automatically. Now I can have as many configurations as I like, the changes are applied automatically, and the tracked files of my repository are not touched. Στις Κυρ, 26 Ιουλ 2020 στις 1:30 π.μ., ο/η Brennan Ashton < bash...@brennanashton.com> έγραψε: > On Sat, Jul 25, 2020 at 4:09 AM Fotis Panagiotopoulos > wrote: > > > > Perfect! kconfig-tweak is what I was looking for. I will give it a try > > later today. > > > > However at this point I would like to ask. How is a debug build defined > for > > NuttX? > > Surely there are configs that can be changed. But is there any > system-wide > > debug option? > > Is NDEBUG defined in any case? > > > > For example I see CONFIG_STM32_DISABLE_IDLE_SLEEP_DURING_DEBUG which is > > active when CONFIG_DEBUG_SYMBOLS is also active. > > So, I guess CONFIG_DEBUG_SYMBOLS is our general "debug" macro? > > > > My application will most probably need to know whether this is a debug > > build or not. > > Just about all the explicitly debug functionality, it is all behind > CONFIG_DEBUG_FEATURES > so if you wanted to indicate if the build had debug functionality > enabled that would probably be > the variable to use. That said there are a few exceptions including > these which may also be > of interest to you. > CONFIG_STACK_COLORATION > CONFIG_DEBUG_NOOPT > > Debug is a very broad word depending on what you are doing, for > instance I frequently include the nsh when I am developing along with > things like procfs, but I might not have that enabled in the "final" > build. > > --Brennan >
Re: Integrating Nuttx to a firmware project.
On Sat, Jul 25, 2020 at 4:09 AM Fotis Panagiotopoulos wrote: > > Perfect! kconfig-tweak is what I was looking for. I will give it a try > later today. > > However at this point I would like to ask. How is a debug build defined for > NuttX? > Surely there are configs that can be changed. But is there any system-wide > debug option? > Is NDEBUG defined in any case? > > For example I see CONFIG_STM32_DISABLE_IDLE_SLEEP_DURING_DEBUG which is > active when CONFIG_DEBUG_SYMBOLS is also active. > So, I guess CONFIG_DEBUG_SYMBOLS is our general "debug" macro? > > My application will most probably need to know whether this is a debug > build or not. Just about all the explicitly debug functionality, it is all behind CONFIG_DEBUG_FEATURES so if you wanted to indicate if the build had debug functionality enabled that would probably be the variable to use. That said there are a few exceptions including these which may also be of interest to you. CONFIG_STACK_COLORATION CONFIG_DEBUG_NOOPT Debug is a very broad word depending on what you are doing, for instance I frequently include the nsh when I am developing along with things like procfs, but I might not have that enabled in the "final" build. --Brennan
Re: Integrating Nuttx to a firmware project.
Fotis,
The debug.h file defines a lot of debug log settings that can be set or
unset to see debug logging for different functional areas within NuttX. To
use the settings, you first need to set the level you are interested in,
one or more of:
CONFIG_DEBUG_ERROR=yCONFIG_DEBUG_WARN=yCONFIG_DEBUG_INFO=y
The debug.h file has documentation in it explaining how to use the
functions. If I'm working in an area, I search the files I'm working
in for log messages. Typically you'll see something like mcerr("Some
message\n"); Then you know that's what that area is using for logging.
Then look in debug.h to find the CONFIG_DEBUG_ variable that you need
to set to turn on this logging. For the memory card area it's
CONFIG_DEBUG_MEMCARD_ERROR.
You can also define your own custom logging statements
if you want information that doesn't come along with that area's
logging.
You'll need to turn on both switches: the general one (for instance
CONFIG_DEBUG_ERROR) and the one for the area you're interested in
(CONFIG_DEBUG_MEMCARD_ERROR). I had to search the code of the area I'm
working in to understand its particular debug settings.
Does that help?
cheers
adam
On Sat, Jul 25, 2020 at 4:09 AM Fotis Panagiotopoulos
wrote:
> Perfect! kconfig-tweak is what I was looking for. I will give it a try
> later today.
>
> However at this point I would like to ask. How is a debug build defined for
> NuttX?
> Surely there are configs that can be changed. But is there any system-wide
> debug option?
> Is NDEBUG defined in any case?
>
> For example I see CONFIG_STM32_DISABLE_IDLE_SLEEP_DURING_DEBUG which is
> active when CONFIG_DEBUG_SYMBOLS is also active.
> So, I guess CONFIG_DEBUG_SYMBOLS is our general "debug" macro?
>
> My application will most probably need to know whether this is a debug
> build or not.
>
>
>
> Στις Σάβ, 25 Ιουλ 2020 στις 7:44 π.μ., ο/η Adam Feuer
> έγραψε:
>
> > I wrote up the kconfig-tweak usage here:
> >
> >
> >
> https://nuttx-companion.readthedocs.io/en/latest/user/debugging.html#changing-debug-settings-quickly
> >
> > -adam
> >
> > On Fri, Jul 24, 2020 at 3:24 PM Matias N. wrote:
> >
> > > I'm thinking in implementing it in my nuttx workspace manager as well
> =)
> > >
> > > On Fri, Jul 24, 2020, at 17:32, Nathan Hartman wrote:
> > > > On Fri, Jul 24, 2020 at 3:49 PM Adam Feuer wrote:
> > > > >
> > > > > On Fri, Jul 24, 2020 at 12:40 PM Gregory Nutt >
> > > wrote:
> > > > >
> > > > > > a dumb script like that one Abdelatif demonstrated
> > > > > > will multiple calls to kconfig-tweak can be used to turn on all
> of
> > > the
> > > > > > configuration options that you need.
> > > > > >
> > > > >
> > > > > Cool!
> > > >
> > > > I didn't know I could do this. Now that I know, I think I'll convert
> > > > my configs to work this way. It will be much more convenient to have
> > > > just one config for "release" builds and then a script to add or
> > > > remove debugging.
> > > >
> > > > Glad we had this conversation. :-)
> > > >
> > > > Nathan
> > > >
> > >
> >
> >
> > --
> > Adam Feuer
> >
>
--
Adam Feuer
Re: Integrating Nuttx to a firmware project.
Perfect! kconfig-tweak is what I was looking for. I will give it a try later today. However at this point I would like to ask. How is a debug build defined for NuttX? Surely there are configs that can be changed. But is there any system-wide debug option? Is NDEBUG defined in any case? For example I see CONFIG_STM32_DISABLE_IDLE_SLEEP_DURING_DEBUG which is active when CONFIG_DEBUG_SYMBOLS is also active. So, I guess CONFIG_DEBUG_SYMBOLS is our general "debug" macro? My application will most probably need to know whether this is a debug build or not. Στις Σάβ, 25 Ιουλ 2020 στις 7:44 π.μ., ο/η Adam Feuer έγραψε: > I wrote up the kconfig-tweak usage here: > > > https://nuttx-companion.readthedocs.io/en/latest/user/debugging.html#changing-debug-settings-quickly > > -adam > > On Fri, Jul 24, 2020 at 3:24 PM Matias N. wrote: > > > I'm thinking in implementing it in my nuttx workspace manager as well =) > > > > On Fri, Jul 24, 2020, at 17:32, Nathan Hartman wrote: > > > On Fri, Jul 24, 2020 at 3:49 PM Adam Feuer wrote: > > > > > > > > On Fri, Jul 24, 2020 at 12:40 PM Gregory Nutt > > wrote: > > > > > > > > > a dumb script like that one Abdelatif demonstrated > > > > > will multiple calls to kconfig-tweak can be used to turn on all of > > the > > > > > configuration options that you need. > > > > > > > > > > > > > Cool! > > > > > > I didn't know I could do this. Now that I know, I think I'll convert > > > my configs to work this way. It will be much more convenient to have > > > just one config for "release" builds and then a script to add or > > > remove debugging. > > > > > > Glad we had this conversation. :-) > > > > > > Nathan > > > > > > > > -- > Adam Feuer >
Re: Integrating Nuttx to a firmware project.
I wrote up the kconfig-tweak usage here: https://nuttx-companion.readthedocs.io/en/latest/user/debugging.html#changing-debug-settings-quickly -adam On Fri, Jul 24, 2020 at 3:24 PM Matias N. wrote: > I'm thinking in implementing it in my nuttx workspace manager as well =) > > On Fri, Jul 24, 2020, at 17:32, Nathan Hartman wrote: > > On Fri, Jul 24, 2020 at 3:49 PM Adam Feuer wrote: > > > > > > On Fri, Jul 24, 2020 at 12:40 PM Gregory Nutt > wrote: > > > > > > > a dumb script like that one Abdelatif demonstrated > > > > will multiple calls to kconfig-tweak can be used to turn on all of > the > > > > configuration options that you need. > > > > > > > > > > Cool! > > > > I didn't know I could do this. Now that I know, I think I'll convert > > my configs to work this way. It will be much more convenient to have > > just one config for "release" builds and then a script to add or > > remove debugging. > > > > Glad we had this conversation. :-) > > > > Nathan > > > -- Adam Feuer
Re: Integrating Nuttx to a firmware project.
I'm thinking in implementing it in my nuttx workspace manager as well =) On Fri, Jul 24, 2020, at 17:32, Nathan Hartman wrote: > On Fri, Jul 24, 2020 at 3:49 PM Adam Feuer wrote: > > > > On Fri, Jul 24, 2020 at 12:40 PM Gregory Nutt wrote: > > > > > a dumb script like that one Abdelatif demonstrated > > > will multiple calls to kconfig-tweak can be used to turn on all of the > > > configuration options that you need. > > > > > > > Cool! > > I didn't know I could do this. Now that I know, I think I'll convert > my configs to work this way. It will be much more convenient to have > just one config for "release" builds and then a script to add or > remove debugging. > > Glad we had this conversation. :-) > > Nathan >
Re: Integrating Nuttx to a firmware project.
a dumb script like that one Abdelatif demonstrated will multiple calls to kconfig-tweak can be used to turn on all of the configuration options that you need. Cool! I didn't know I could do this. Now that I know, I think I'll convert my configs to work this way. It will be much more convenient to have just one config for "release" builds and then a script to add or remove debugging. tools/sethost.sh already does this kind of thing: https://github.com/apache/incubator-nuttx/blob/master/tools/sethost.sh#L130 sed has been used to do this job in the past, but there are some subtle difference. kconfig-tweak is the safest bet.
Re: Integrating Nuttx to a firmware project.
On Fri, Jul 24, 2020 at 3:49 PM Adam Feuer wrote: > > On Fri, Jul 24, 2020 at 12:40 PM Gregory Nutt wrote: > > > a dumb script like that one Abdelatif demonstrated > > will multiple calls to kconfig-tweak can be used to turn on all of the > > configuration options that you need. > > > > Cool! I didn't know I could do this. Now that I know, I think I'll convert my configs to work this way. It will be much more convenient to have just one config for "release" builds and then a script to add or remove debugging. Glad we had this conversation. :-) Nathan
Re: Integrating Nuttx to a firmware project.
On Fri, Jul 24, 2020 at 12:40 PM Gregory Nutt wrote: > a dumb script like that one Abdelatif demonstrated > will multiple calls to kconfig-tweak can be used to turn on all of the > configuration options that you need. > Cool! -adam -- Adam Feuer
Re: Integrating Nuttx to a firmware project.
If no tool exists for this, Yes, kconfig-tweak. kconfig-tweak will enable or disable any setting configuration setting. The full set of debug options to enable is project-specific, but a dumb script like that one Abdelatif demonstrated will multiple calls to kconfig-tweak can be used to turn on all of the configuration options that you need. I don't think a single such script should be supported however. The options needed are project-specfic. For example, should network error debug output be enabled? Depends on the project.
Re: Integrating Nuttx to a firmware project.
If no tool exists for this, we could easily write one– it could look through a file with the debug settings, and turn them on or off in a config. It would help me too. I often want to quickly turn on or off particular debug settings while doing testing. Is this something that's wanted? -adam On Fri, Jul 24, 2020 at 12:18 PM Fotis Panagiotopoulos wrote: > > I keep two config files, one for debug, one for release. Very similar > > except for the kinds of debugging options you mentioned. > > This is exactly what I want to avoid. I will have to support 3 different > boards, with maybe 3 different build types. Thus 9 configurations. > > This will be very difficult to maintain. > If I want to make a change unrelated to the build or the boards (say for > example something in the network system), I will have to manually apply the > change to all these configurations! > And the worst is that there will be no guarantee that all configurations > are in sync (apart from manually checking the diffs between them). > > Στις Παρ, 24 Ιουλ 2020 στις 9:47 μ.μ., ο/η Nathan Hartman < > hartman.nat...@gmail.com> έγραψε: > > > On Fri, Jul 24, 2020 at 12:26 PM Fotis Panagiotopoulos < > > f.j.pa...@gmail.com> > > wrote: > > > > > Hello, > > > > > > So, I have set up my workspace now, and I have NuttX running properly > on > > my > > > custom board. > > > I have another question though, regarding how to set things up for > > > development. > > > > > > Usually I have at least 2 build configurations: one for debugging, one > > for > > > releases etc. > > > > > > Debug builds have assertions enabled, optimizations disabled, various > > > checks enabled etc etc, while release builds the do the opposite. > > > > > > How is this best to be handled by NuttX? Should I have various > > > configuration files to load each time, or is there a better way? > > > > > > I keep two config files, one for debug, one for release. Very similar > > except for the kinds of debugging options you mentioned. > > > > Nathan > > > -- Adam Feuer
Re: Integrating Nuttx to a firmware project.
> I keep two config files, one for debug, one for release. Very similar > except for the kinds of debugging options you mentioned. This is exactly what I want to avoid. I will have to support 3 different boards, with maybe 3 different build types. Thus 9 configurations. This will be very difficult to maintain. If I want to make a change unrelated to the build or the boards (say for example something in the network system), I will have to manually apply the change to all these configurations! And the worst is that there will be no guarantee that all configurations are in sync (apart from manually checking the diffs between them). Στις Παρ, 24 Ιουλ 2020 στις 9:47 μ.μ., ο/η Nathan Hartman < hartman.nat...@gmail.com> έγραψε: > On Fri, Jul 24, 2020 at 12:26 PM Fotis Panagiotopoulos < > f.j.pa...@gmail.com> > wrote: > > > Hello, > > > > So, I have set up my workspace now, and I have NuttX running properly on > my > > custom board. > > I have another question though, regarding how to set things up for > > development. > > > > Usually I have at least 2 build configurations: one for debugging, one > for > > releases etc. > > > > Debug builds have assertions enabled, optimizations disabled, various > > checks enabled etc etc, while release builds the do the opposite. > > > > How is this best to be handled by NuttX? Should I have various > > configuration files to load each time, or is there a better way? > > > I keep two config files, one for debug, one for release. Very similar > except for the kinds of debugging options you mentioned. > > Nathan >
Re: Integrating Nuttx to a firmware project.
> Can kconfig-tweak be used to quickly turn on and off these kind of settings > (such as debugging)? Maybe something like: kconfig-tweak --disable (or --enable) CONFIG_DEBUG_FEATURES make oldconfig On Fri, Jul 24, 2020 at 7:57 PM Matias N. wrote: > > Can kconfig-tweak be used to quickly turn on and off these kind of settings > (such as debugging)? > > > I keep two config files, one for debug, one for release. Very similar > > except for the kinds of debugging options you mentioned. > > > > Nathan > >
Re: Integrating Nuttx to a firmware project.
Can kconfig-tweak be used to quickly turn on and off these kind of settings (such as debugging)? > I keep two config files, one for debug, one for release. Very similar > except for the kinds of debugging options you mentioned. > > Nathan >
Re: Integrating Nuttx to a firmware project.
On Fri, Jul 24, 2020 at 12:26 PM Fotis Panagiotopoulos wrote: > Hello, > > So, I have set up my workspace now, and I have NuttX running properly on my > custom board. > I have another question though, regarding how to set things up for > development. > > Usually I have at least 2 build configurations: one for debugging, one for > releases etc. > > Debug builds have assertions enabled, optimizations disabled, various > checks enabled etc etc, while release builds the do the opposite. > > How is this best to be handled by NuttX? Should I have various > configuration files to load each time, or is there a better way? I keep two config files, one for debug, one for release. Very similar except for the kinds of debugging options you mentioned. Nathan
Re: Integrating Nuttx to a firmware project.
Hello,
So, I have set up my workspace now, and I have NuttX running properly on my
custom board.
I have another question though, regarding how to set things up for
development.
Usually I have at least 2 build configurations: one for debugging, one for
releases etc.
Debug builds have assertions enabled, optimizations disabled, various
checks enabled etc etc, while release builds the do the opposite.
How is this best to be handled by NuttX? Should I have various
configuration files to load each time, or is there a better way?
Στις Τετ, 15 Ιουλ 2020 στις 12:51 π.μ., ο/η Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> έγραψε:
> > Then I tried:
> > cd nuttx
> > ./tools/configure.sh ../boards/stm32f4discovery:nsh
>
> This does not work with out-of-tree boards, you need the path to the board.
>
> > In other words, it looks like it expects a different structure for
> > externally defined boards, than the provided ones. Correct?
>
> It doesn't expect a different structure but it doesn't support all the
> structures of in-tree boards.
> With an external custom board the Make.defs file needs to be located
> at the same level as the defconfig.
> Example:
> ls ../boards/custom_board/nsh
> defconfig
> Make.defs
>
> You also need to set the CUSTOM* configs as said earlier.
>
>
> On Tue, Jul 14, 2020 at 10:17 PM Fotis Panagiotopoulos
> wrote:
> >
> > Hi,
> >
> > I am trying to configure NuttX with an external board, following your
> > advice, but I just can't make it work...
> >
> > My current workspace structure is the following:
> > ├── apps
> > ├── boards
> > ├── Makefile
> > └── nuttx
> >
> > I copied the directory ${TOPDIR}/nuttx/boards/arm/stm32/stm32f4discovery
> > into ${TOPDIR}/boards/stm32f4discovery, to use it as an example.
> >
> > Then I tried:
> > cd nuttx
> > ./tools/configure.sh ../boards/stm32f4discovery:nsh
> > But it fails with:
> > Directory for ../boards/stm32f4discovery:nsh does not exist.
> > Options are: ...
> >
> > I then tried:
> > cd nuttx
> > ./tools/configure.sh ../boards/stm32f4discovery/configs/nsh
> > But again:
> > File Make.defs could not be found
> >
> > I started looking into the code of configure.sh script.
> > As I see, when it detects that an external board configuration is to be
> > used, it does:
> > configpath=${TOPDIR}/${boardconfig}
> > and generally it uses the dir ${TOPDIR}/${boardconfig}, assuming that
> every
> > needed file will be in this specific directory.
> >
> > In other words, it looks like it expects a different structure for
> > externally defined boards, than the provided ones. Correct?
> >
> >
> > Στις Τρί, 14 Ιουλ 2020 στις 6:42 μ.μ., ο/η Gregory Nutt <
> spudan...@gmail.com>
> > έγραψε:
> >
> > >
> > > > When not yet creating a custom board, I simply copy the config file
> and
> > > put it somewhere inside the workspace. If you eventually create a
> custom
> > > board, you can then place it in the proper directory
> > > (board/configs/*/defconfig). Doing it this way also allows you to
> configure
> > > nuttx with my framework using the "make configure" command.
> > >
> > > configure.sh works with board directories that are outside of the
> source
> > > tree as well. You never have to put a custom board configuration in
> the
> > > repository's boards/ sub-directory. Instead of
> > >
> > > tools/configure.sh :
> > >
> > > Use
> > >
> > > tools/configures.sh
> > >
> > >
>
Re: Integrating Nuttx to a firmware project.
> Then I tried:
> cd nuttx
> ./tools/configure.sh ../boards/stm32f4discovery:nsh
This does not work with out-of-tree boards, you need the path to the board.
> In other words, it looks like it expects a different structure for
> externally defined boards, than the provided ones. Correct?
It doesn't expect a different structure but it doesn't support all the
structures of in-tree boards.
With an external custom board the Make.defs file needs to be located
at the same level as the defconfig.
Example:
ls ../boards/custom_board/nsh
defconfig
Make.defs
You also need to set the CUSTOM* configs as said earlier.
On Tue, Jul 14, 2020 at 10:17 PM Fotis Panagiotopoulos
wrote:
>
> Hi,
>
> I am trying to configure NuttX with an external board, following your
> advice, but I just can't make it work...
>
> My current workspace structure is the following:
> ├── apps
> ├── boards
> ├── Makefile
> └── nuttx
>
> I copied the directory ${TOPDIR}/nuttx/boards/arm/stm32/stm32f4discovery
> into ${TOPDIR}/boards/stm32f4discovery, to use it as an example.
>
> Then I tried:
> cd nuttx
> ./tools/configure.sh ../boards/stm32f4discovery:nsh
> But it fails with:
> Directory for ../boards/stm32f4discovery:nsh does not exist.
> Options are: ...
>
> I then tried:
> cd nuttx
> ./tools/configure.sh ../boards/stm32f4discovery/configs/nsh
> But again:
> File Make.defs could not be found
>
> I started looking into the code of configure.sh script.
> As I see, when it detects that an external board configuration is to be
> used, it does:
> configpath=${TOPDIR}/${boardconfig}
> and generally it uses the dir ${TOPDIR}/${boardconfig}, assuming that every
> needed file will be in this specific directory.
>
> In other words, it looks like it expects a different structure for
> externally defined boards, than the provided ones. Correct?
>
>
> Στις Τρί, 14 Ιουλ 2020 στις 6:42 μ.μ., ο/η Gregory Nutt
> έγραψε:
>
> >
> > > When not yet creating a custom board, I simply copy the config file and
> > put it somewhere inside the workspace. If you eventually create a custom
> > board, you can then place it in the proper directory
> > (board/configs/*/defconfig). Doing it this way also allows you to configure
> > nuttx with my framework using the "make configure" command.
> >
> > configure.sh works with board directories that are outside of the source
> > tree as well. You never have to put a custom board configuration in the
> > repository's boards/ sub-directory. Instead of
> >
> > tools/configure.sh :
> >
> > Use
> >
> > tools/configures.sh
> >
> >
Re: Integrating Nuttx to a firmware project.
Hi,
I am trying to configure NuttX with an external board, following your
advice, but I just can't make it work...
My current workspace structure is the following:
├── apps
├── boards
├── Makefile
└── nuttx
I copied the directory ${TOPDIR}/nuttx/boards/arm/stm32/stm32f4discovery
into ${TOPDIR}/boards/stm32f4discovery, to use it as an example.
Then I tried:
cd nuttx
./tools/configure.sh ../boards/stm32f4discovery:nsh
But it fails with:
Directory for ../boards/stm32f4discovery:nsh does not exist.
Options are: ...
I then tried:
cd nuttx
./tools/configure.sh ../boards/stm32f4discovery/configs/nsh
But again:
File Make.defs could not be found
I started looking into the code of configure.sh script.
As I see, when it detects that an external board configuration is to be
used, it does:
configpath=${TOPDIR}/${boardconfig}
and generally it uses the dir ${TOPDIR}/${boardconfig}, assuming that every
needed file will be in this specific directory.
In other words, it looks like it expects a different structure for
externally defined boards, than the provided ones. Correct?
Στις Τρί, 14 Ιουλ 2020 στις 6:42 μ.μ., ο/η Gregory Nutt
έγραψε:
>
> > When not yet creating a custom board, I simply copy the config file and
> put it somewhere inside the workspace. If you eventually create a custom
> board, you can then place it in the proper directory
> (board/configs/*/defconfig). Doing it this way also allows you to configure
> nuttx with my framework using the "make configure" command.
>
> configure.sh works with board directories that are outside of the source
> tree as well. You never have to put a custom board configuration in the
> repository's boards/ sub-directory. Instead of
>
> tools/configure.sh :
>
> Use
>
> tools/configures.sh
>
>
Re: Integrating Nuttx to a firmware project.
When not yet creating a custom board, I simply copy the config file and put it somewhere inside the workspace. If you eventually create a custom board, you can then place it in the proper directory (board/configs/*/defconfig). Doing it this way also allows you to configure nuttx with my framework using the "make configure" command. configure.sh works with board directories that are outside of the source tree as well. You never have to put a custom board configuration in the repository's boards/ sub-directory. Instead of tools/configure.sh : Use tools/configures.sh
Re: Integrating Nuttx to a firmware project.
When not yet creating a custom board, I simply copy the config file and put it somewhere inside the workspace. If you eventually create a custom board, you can then place it in the proper directory (board/configs/*/defconfig). Doing it this way also allows you to configure nuttx with my framework using the "make configure" command. On Tue, Jul 14, 2020, at 08:48, Fotis Panagiotopoulos wrote: > Hi, > > Thanks everyone for your suggestions! > > I have read the Wikis, and they are very helpful indeed. > However as I see there is no officiaL way of having an out-of-tree boards > directory, and this is my main problem. > If I understand correctly, there is no "proper" way of using NuttX on > custom hardware, without touching its source code. > > Matias, nice work with that framework! > In fact it is very close to what I was thinking of finally doing. It seems > that a top-level Makefile is needed, that will handle everything else. It > will have to "inject" my custom board to the build system, so as not to > modify the sources. > I may use your framework as an example for setting up my workflow. > > Another thing that I was thinking is about NuttX configuration. The file > .config is included in the .gitignore file. So the actual NuttX > configuration is not tracked. > How do you usually handle this? Maybe also symlink my actual config to > NuttX dir? Also handled by the top-level Makefile? > > Στις Τρί, 14 Ιουλ 2020 στις 12:39 π.μ., ο/η Gregory Nutt < > spudan...@gmail.com> έγραψε: > > > On 7/13/2020 3:00 PM, Fotis Panagiotopoulos wrote: > > > Hi everyone! > > > > > > I am new to Nuttx but I would like to use it for my next projects. > > > For the moment I am porting one of my big projects to Nuttx (that was > > > previously working with another RTOS). However, I am a bit confused on > > how > > > I should set up our development workflow. > > > > > > I will have to create my own apps dir, containing the actual firmware. I > > > will have to create a new board config for our custom hardware. Of course > > > Nuttx shall be configured specifically for the needs of the project. Our > > > projects use git for version control. > > > > > > But what is the recommended way of integrating Nuttx code to my project? > > > I can think of the following cases: > > > > > > 1. Copy the whole Nuttx source code in the project. > > > This workflow seems to be encouraged, but IMO it's not correct. This way > > my > > > copy of Nuttx becomes "detached" to the original repo. It would be very > > > difficult to change versions, update the kernel, or contribute back. > > > Everything would have to be merged manually. > > > > > > 2. Use the export target, and use Nuttx as a library. > > > This seems better, but it is still problematic. Nuttx becomes a "black > > > box". It is not easy to debug it, change configuration, or generally tell > > > what the library contains. Knowledge on what is built and how is lost in > > > our version control and the rest of the developers will not be able to > > > follow any changes. > > > > > > 3. Add Nuttx as a submodule to our git repository. > > > This ticks most of the boxes, but this also means that I will have to > > also > > > fork Nuttx to our git server. I am afraid that this will lead up to > > having > > > lots of forks, each for every one of our projects, and that it will > > become > > > very difficult to manage. > > > > > > So what do others do? How do you integrate Nuttx to your projects? > > > Or is there anything that I am missing or any other solution? > > > > > > -- > > > Fotis Panagiotopoulos > > > > > Perhaps these Wiki pages would be useful to you: > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/Building+NuttX+with+Applications+Outside+of+the+Source+Tree > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/Custom+Application+Directories > > > > > > >
Re: Integrating Nuttx to a firmware project.
On Tue, Jul 14, 2020 at 7:48 AM Fotis Panagiotopoulos wrote: > Another thing that I was thinking is about NuttX configuration. The file > .config is included in the .gitignore file. So the actual NuttX > configuration is not tracked. > How do you usually handle this? I manually save that file in my board's configs directory. I do 'make savedefconfig' to save a file that can be used with tools/configure.sh but I also save the .config, giving it the name fullconfig. That's because the file saved by 'make savedefconfig' only contains options that differ from the default. Nathan
Re: Integrating Nuttx to a firmware project.
> However as I see there is no officiaL way of having an out-of-tree boards > directory, and this is my main problem. > If I understand correctly, there is no "proper" way of using NuttX on > custom hardware, without touching its source code. There is an official way to have out-of-tree boards, and they are configured (almost) the same way as a "normal" in-tree board. Here is an example I use with a relative path: ./tools/configure.sh ../relative_path_to_board/name_of_config. My defconfig has these three configurations set. CONFIG_ARCH_BOARD_CUSTOM_DIR="../boards/boards_name" CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y CONFIG_ARCH_BOARD_CUSTOM_NAME="boards_name" I've got a structure as the following: NuttX -- nuttx/ apps/ custom_boards/ custom_apps/ (this is symlinked to apps/external) The custom boards and apps are completely independent of nuttx/ and apps/, both with their own version control system. > Another thing that I was thinking is about NuttX configuration. The file > .config is included in the .gitignore file. So the actual NuttX > configuration is not tracked. > How do you usually handle this? The .config file is used to generate a complete config.h NuttX configuration file (which is also ignored). The configurations that are tracked are found in boards/*/*/*/configs. On Tue, Jul 14, 2020 at 12:48 PM Fotis Panagiotopoulos wrote: > > Hi, > > Thanks everyone for your suggestions! > > I have read the Wikis, and they are very helpful indeed. > However as I see there is no officiaL way of having an out-of-tree boards > directory, and this is my main problem. > If I understand correctly, there is no "proper" way of using NuttX on > custom hardware, without touching its source code. > > Matias, nice work with that framework! > In fact it is very close to what I was thinking of finally doing. It seems > that a top-level Makefile is needed, that will handle everything else. It > will have to "inject" my custom board to the build system, so as not to > modify the sources. > I may use your framework as an example for setting up my workflow. > > Another thing that I was thinking is about NuttX configuration. The file > .config is included in the .gitignore file. So the actual NuttX > configuration is not tracked. > How do you usually handle this? Maybe also symlink my actual config to > NuttX dir? Also handled by the top-level Makefile? > > Στις Τρί, 14 Ιουλ 2020 στις 12:39 π.μ., ο/η Gregory Nutt < > spudan...@gmail.com> έγραψε: > > > On 7/13/2020 3:00 PM, Fotis Panagiotopoulos wrote: > > > Hi everyone! > > > > > > I am new to Nuttx but I would like to use it for my next projects. > > > For the moment I am porting one of my big projects to Nuttx (that was > > > previously working with another RTOS). However, I am a bit confused on > > how > > > I should set up our development workflow. > > > > > > I will have to create my own apps dir, containing the actual firmware. I > > > will have to create a new board config for our custom hardware. Of course > > > Nuttx shall be configured specifically for the needs of the project. Our > > > projects use git for version control. > > > > > > But what is the recommended way of integrating Nuttx code to my project? > > > I can think of the following cases: > > > > > > 1. Copy the whole Nuttx source code in the project. > > > This workflow seems to be encouraged, but IMO it's not correct. This way > > my > > > copy of Nuttx becomes "detached" to the original repo. It would be very > > > difficult to change versions, update the kernel, or contribute back. > > > Everything would have to be merged manually. > > > > > > 2. Use the export target, and use Nuttx as a library. > > > This seems better, but it is still problematic. Nuttx becomes a "black > > > box". It is not easy to debug it, change configuration, or generally tell > > > what the library contains. Knowledge on what is built and how is lost in > > > our version control and the rest of the developers will not be able to > > > follow any changes. > > > > > > 3. Add Nuttx as a submodule to our git repository. > > > This ticks most of the boxes, but this also means that I will have to > > also > > > fork Nuttx to our git server. I am afraid that this will lead up to > > having > > > lots of forks, each for every one of our projects, and that it will > > become > > > very difficult to manage. > > > > > > So what do others do? How do you integrate Nuttx to your projects? > > > Or is there anything that I am missing or any other solution? > > > > > > -- > > > Fotis Panagiotopoulos > > > > > Perhaps these Wiki pages would be useful to you: > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/Building+NuttX+with+Applications+Outside+of+the+Source+Tree > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/Custom+Application+Directories > > > > > >
Re: Integrating Nuttx to a firmware project.
Hi, Thanks everyone for your suggestions! I have read the Wikis, and they are very helpful indeed. However as I see there is no officiaL way of having an out-of-tree boards directory, and this is my main problem. If I understand correctly, there is no "proper" way of using NuttX on custom hardware, without touching its source code. Matias, nice work with that framework! In fact it is very close to what I was thinking of finally doing. It seems that a top-level Makefile is needed, that will handle everything else. It will have to "inject" my custom board to the build system, so as not to modify the sources. I may use your framework as an example for setting up my workflow. Another thing that I was thinking is about NuttX configuration. The file .config is included in the .gitignore file. So the actual NuttX configuration is not tracked. How do you usually handle this? Maybe also symlink my actual config to NuttX dir? Also handled by the top-level Makefile? Στις Τρί, 14 Ιουλ 2020 στις 12:39 π.μ., ο/η Gregory Nutt < spudan...@gmail.com> έγραψε: > On 7/13/2020 3:00 PM, Fotis Panagiotopoulos wrote: > > Hi everyone! > > > > I am new to Nuttx but I would like to use it for my next projects. > > For the moment I am porting one of my big projects to Nuttx (that was > > previously working with another RTOS). However, I am a bit confused on > how > > I should set up our development workflow. > > > > I will have to create my own apps dir, containing the actual firmware. I > > will have to create a new board config for our custom hardware. Of course > > Nuttx shall be configured specifically for the needs of the project. Our > > projects use git for version control. > > > > But what is the recommended way of integrating Nuttx code to my project? > > I can think of the following cases: > > > > 1. Copy the whole Nuttx source code in the project. > > This workflow seems to be encouraged, but IMO it's not correct. This way > my > > copy of Nuttx becomes "detached" to the original repo. It would be very > > difficult to change versions, update the kernel, or contribute back. > > Everything would have to be merged manually. > > > > 2. Use the export target, and use Nuttx as a library. > > This seems better, but it is still problematic. Nuttx becomes a "black > > box". It is not easy to debug it, change configuration, or generally tell > > what the library contains. Knowledge on what is built and how is lost in > > our version control and the rest of the developers will not be able to > > follow any changes. > > > > 3. Add Nuttx as a submodule to our git repository. > > This ticks most of the boxes, but this also means that I will have to > also > > fork Nuttx to our git server. I am afraid that this will lead up to > having > > lots of forks, each for every one of our projects, and that it will > become > > very difficult to manage. > > > > So what do others do? How do you integrate Nuttx to your projects? > > Or is there anything that I am missing or any other solution? > > > > -- > > Fotis Panagiotopoulos > > > Perhaps these Wiki pages would be useful to you: > > > https://cwiki.apache.org/confluence/display/NUTTX/Building+NuttX+with+Applications+Outside+of+the+Source+Tree > > > https://cwiki.apache.org/confluence/display/NUTTX/Custom+Application+Directories > > >
Re: Integrating Nuttx to a firmware project.
On 7/13/2020 3:00 PM, Fotis Panagiotopoulos wrote: Hi everyone! I am new to Nuttx but I would like to use it for my next projects. For the moment I am porting one of my big projects to Nuttx (that was previously working with another RTOS). However, I am a bit confused on how I should set up our development workflow. I will have to create my own apps dir, containing the actual firmware. I will have to create a new board config for our custom hardware. Of course Nuttx shall be configured specifically for the needs of the project. Our projects use git for version control. But what is the recommended way of integrating Nuttx code to my project? I can think of the following cases: 1. Copy the whole Nuttx source code in the project. This workflow seems to be encouraged, but IMO it's not correct. This way my copy of Nuttx becomes "detached" to the original repo. It would be very difficult to change versions, update the kernel, or contribute back. Everything would have to be merged manually. 2. Use the export target, and use Nuttx as a library. This seems better, but it is still problematic. Nuttx becomes a "black box". It is not easy to debug it, change configuration, or generally tell what the library contains. Knowledge on what is built and how is lost in our version control and the rest of the developers will not be able to follow any changes. 3. Add Nuttx as a submodule to our git repository. This ticks most of the boxes, but this also means that I will have to also fork Nuttx to our git server. I am afraid that this will lead up to having lots of forks, each for every one of our projects, and that it will become very difficult to manage. So what do others do? How do you integrate Nuttx to your projects? Or is there anything that I am missing or any other solution? -- Fotis Panagiotopoulos Perhaps these Wiki pages would be useful to you: https://cwiki.apache.org/confluence/display/NUTTX/Building+NuttX+with+Applications+Outside+of+the+Source+Tree https://cwiki.apache.org/confluence/display/NUTTX/Custom+Application+Directories
Re: Integrating Nuttx to a firmware project.
Hello, I personally like to create a git repository where the apps and nuttx repos are added as submodules. Unless you are going to use a pre-existing board which has everything you need, you will also eventually need to modify content inside nuttx/. An alternative is to configure nuttx to use an out-of-tree custom board, which avoids this. For the apps there's a similar mechanism for out-of-tree inclusion of application code. Since I do this very often, I created myself a small framework based on Makefile which allows you to easily initialize a project and handle nuttx make commands from the top-level directory. Also, you can easily add out-of-tree applications and even OS-level code (for example, a driver) without having to fork nuttx repo. This framework is here: https://gitlab.com/nuttx_projects/nuttx_workspace_manager In case you want another option, there's is also https://gitlab.com/nuttx-upm/upm which is python based and works similarly. Best, Matias On Mon, Jul 13, 2020, at 18:00, Fotis Panagiotopoulos wrote: > Hi everyone! > > I am new to Nuttx but I would like to use it for my next projects. > For the moment I am porting one of my big projects to Nuttx (that was > previously working with another RTOS). However, I am a bit confused on how > I should set up our development workflow. > > I will have to create my own apps dir, containing the actual firmware. I > will have to create a new board config for our custom hardware. Of course > Nuttx shall be configured specifically for the needs of the project. Our > projects use git for version control. > > But what is the recommended way of integrating Nuttx code to my project? > I can think of the following cases: > > 1. Copy the whole Nuttx source code in the project. > This workflow seems to be encouraged, but IMO it's not correct. This way my > copy of Nuttx becomes "detached" to the original repo. It would be very > difficult to change versions, update the kernel, or contribute back. > Everything would have to be merged manually. > > 2. Use the export target, and use Nuttx as a library. > This seems better, but it is still problematic. Nuttx becomes a "black > box". It is not easy to debug it, change configuration, or generally tell > what the library contains. Knowledge on what is built and how is lost in > our version control and the rest of the developers will not be able to > follow any changes. > > 3. Add Nuttx as a submodule to our git repository. > This ticks most of the boxes, but this also means that I will have to also > fork Nuttx to our git server. I am afraid that this will lead up to having > lots of forks, each for every one of our projects, and that it will become > very difficult to manage. > > So what do others do? How do you integrate Nuttx to your projects? > Or is there anything that I am missing or any other solution? > > -- > Fotis Panagiotopoulos >
Re: Integrating Nuttx to a firmware project.
Hi Fotis, There are other options: Create a branch on nuttx and apps repositoris and add your project there. This way you can keep it working and from time to time rebase it with the master. Other option is creating an apps/external directory and inside it create a link for your application, but unfortunately there is not an equivalent for boards/external, so it is not an orthogonal solution. Maybe other people have other solution. BR, Alan On 7/13/20, Fotis Panagiotopoulos wrote: > Hi everyone! > > I am new to Nuttx but I would like to use it for my next projects. > For the moment I am porting one of my big projects to Nuttx (that was > previously working with another RTOS). However, I am a bit confused on how > I should set up our development workflow. > > I will have to create my own apps dir, containing the actual firmware. I > will have to create a new board config for our custom hardware. Of course > Nuttx shall be configured specifically for the needs of the project. Our > projects use git for version control. > > But what is the recommended way of integrating Nuttx code to my project? > I can think of the following cases: > > 1. Copy the whole Nuttx source code in the project. > This workflow seems to be encouraged, but IMO it's not correct. This way my > copy of Nuttx becomes "detached" to the original repo. It would be very > difficult to change versions, update the kernel, or contribute back. > Everything would have to be merged manually. > > 2. Use the export target, and use Nuttx as a library. > This seems better, but it is still problematic. Nuttx becomes a "black > box". It is not easy to debug it, change configuration, or generally tell > what the library contains. Knowledge on what is built and how is lost in > our version control and the rest of the developers will not be able to > follow any changes. > > 3. Add Nuttx as a submodule to our git repository. > This ticks most of the boxes, but this also means that I will have to also > fork Nuttx to our git server. I am afraid that this will lead up to having > lots of forks, each for every one of our projects, and that it will become > very difficult to manage. > > So what do others do? How do you integrate Nuttx to your projects? > Or is there anything that I am missing or any other solution? > > -- > Fotis Panagiotopoulos >
Integrating Nuttx to a firmware project.
Hi everyone! I am new to Nuttx but I would like to use it for my next projects. For the moment I am porting one of my big projects to Nuttx (that was previously working with another RTOS). However, I am a bit confused on how I should set up our development workflow. I will have to create my own apps dir, containing the actual firmware. I will have to create a new board config for our custom hardware. Of course Nuttx shall be configured specifically for the needs of the project. Our projects use git for version control. But what is the recommended way of integrating Nuttx code to my project? I can think of the following cases: 1. Copy the whole Nuttx source code in the project. This workflow seems to be encouraged, but IMO it's not correct. This way my copy of Nuttx becomes "detached" to the original repo. It would be very difficult to change versions, update the kernel, or contribute back. Everything would have to be merged manually. 2. Use the export target, and use Nuttx as a library. This seems better, but it is still problematic. Nuttx becomes a "black box". It is not easy to debug it, change configuration, or generally tell what the library contains. Knowledge on what is built and how is lost in our version control and the rest of the developers will not be able to follow any changes. 3. Add Nuttx as a submodule to our git repository. This ticks most of the boxes, but this also means that I will have to also fork Nuttx to our git server. I am afraid that this will lead up to having lots of forks, each for every one of our projects, and that it will become very difficult to manage. So what do others do? How do you integrate Nuttx to your projects? Or is there anything that I am missing or any other solution? -- Fotis Panagiotopoulos
