RE: Roadmap?

[Xiang Xiao]

I would see the automation test on the roadmap, thanks.

> -Original Message-
> From: Matias N. 
> Sent: Wednesday, August 5, 2020 4:59 AM
> To: dev@nuttx.apache.org
> Subject: Re: Roadmap?
> 
> Having a (public) roadmap is very good idea, it guides and organizes efforts 
> over time and also gives indication to existing or
potential
> users about which features which are not currently but might as well be there 
> soon.
> 
> I personally would like to see support for Bluetooth/WiFi on widely used 
> hardware platforms.
> I'm currently working on getting BLE on nRF working so it is a matter of 
> time. I hope that also Alan might steer Espressif into
add
> support for ESP32. LoRaWAN stack would also be interesting.
> I would also add the current documentation effort as part of the roadmap.
> 
> I think with a Roadmap laid out it would be possible to create GitHub 
> milestones (major and minor) and organize issues into each,
> depending on how disruptive the change is. This would help to have for 
> example a 10.x series more or less stable while holding
bigger
> changes towards 11.0 or even 12.0.
> 
> Just my two cents.
> 
> Best,
> Matias
> 
> On Tue, Aug 4, 2020, at 17:32, Gregory Nutt wrote:
> > One of the things that I think we are missing is a Roadmap to guide
> > and prioritize new feature development.  Other RTOS' (like Zephyr) do
> > have such published roadmaps and are responsive to needs and requests
> > of users and sponsors.  I have even seen web pages where the Zephyr
> > team has laid out what new features on the roadmap will be available
> > in future releases.
> >
> > While I think it would be essentially impossible for us to manage such
> > a thing with our loose organiation, I think we should have a roadmap
> > that identifies the important directions that operating system will take.
> >
> > For me, the important thing is to stay relevant and contemporary and
> > not get lost in some aging niche architecture or toolset.  I think
> > that the best way to predict where NuttX needs to be is to look at the
> > SoCs in use just above the upper end of the NuttX market.  I think
> > over time, those features will trickle down into embedded systems
> > (albeit with some twists and modifications for the embedded market).
> > The Cortex-M7 introduces I-Cache and L1 D-Cache, for example.  A few
> > years ago, those were higher end features not available on MCUs.
> >
> > I think that SMP and AMP are key technologies to get us a leg up on
> > future mutli-core MCUs.  KERNEL mode places us in a position to
> > support MCUs with MMUs.  A proper TrustZone model for all ARM parts is
> > needed too (the multi-core TrustZone model is pretty well in place,
> > but what do we do with TrustZone on a single CPU?).
> >
> > Security, especially IoT security is very important.  Some security
> > topics are addressed by PROTECTED mode.  So although PROTECTED and
> > KERNEL build modes are not commonly used,  I believe that they are
> > important parts of the roadmap.
> >
> > Other thoughts?  We should collaborate and  define a meaningful
> > roadmap that will keep the OS healthy well into the future.  We should
> > publish that roadmap somewhere so that anyone can see where we are
> > going and can offer insights for other directions.
> >
> >
> >

Re: Roadmap?

[Maciej Wójcik]

1) More opinionated documentation
  a) In particular clear instructions:
– where to get compilers for C/C++
– how to setup project with an application outside of nuttx, and clear
[apps], [libs], [board], [nuttx] structure
– how to set up your own board
These questions are recurring. They were asked on the mailing list recently
again. They are basic things and they should be the second page of
documentation.
  b) Typical policy for documentation is that when people ask, the answer
should be put to documentation and the link sent back as an answer.
  c) Table of supported features on different platforms and boards, as
discussed recently. For people who want to use NuttX to feel safe and know
how much they need to contribute to make their project work.

2) Package management
Database where people can submit whatever they want, as long as it works
and they are willing to maintain it.
Description on what such packages need to fulfill to work with NuttX. Some
simple command line tool to inject packages to NuttX projects.

Am Mi., 5. Aug. 2020 um 17:20 Uhr schrieb Xiang Xiao <
xiaoxiang781...@gmail.com>:

> I would see the automation test on the roadmap, thanks.
>
> > -Original Message-
> > From: Matias N. 
> > Sent: Wednesday, August 5, 2020 4:59 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: Roadmap?
> >
> > Having a (public) roadmap is very good idea, it guides and organizes
> efforts over time and also gives indication to existing or
> potential
> > users about which features which are not currently but might as well be
> there soon.
> >
> > I personally would like to see support for Bluetooth/WiFi on widely used
> hardware platforms.
> > I'm currently working on getting BLE on nRF working so it is a matter of
> time. I hope that also Alan might steer Espressif into
> add
> > support for ESP32. LoRaWAN stack would also be interesting.
> > I would also add the current documentation effort as part of the roadmap.
> >
> > I think with a Roadmap laid out it would be possible to create GitHub
> milestones (major and minor) and organize issues into each,
> > depending on how disruptive the change is. This would help to have for
> example a 10.x series more or less stable while holding
> bigger
> > changes towards 11.0 or even 12.0.
> >
> > Just my two cents.
> >
> > Best,
> > Matias
> >
> > On Tue, Aug 4, 2020, at 17:32, Gregory Nutt wrote:
> > > One of the things that I think we are missing is a Roadmap to guide
> > > and prioritize new feature development.  Other RTOS' (like Zephyr) do
> > > have such published roadmaps and are responsive to needs and requests
> > > of users and sponsors.  I have even seen web pages where the Zephyr
> > > team has laid out what new features on the roadmap will be available
> > > in future releases.
> > >
> > > While I think it would be essentially impossible for us to manage such
> > > a thing with our loose organiation, I think we should have a roadmap
> > > that identifies the important directions that operating system will
> take.
> > >
> > > For me, the important thing is to stay relevant and contemporary and
> > > not get lost in some aging niche architecture or toolset.  I think
> > > that the best way to predict where NuttX needs to be is to look at the
> > > SoCs in use just above the upper end of the NuttX market.  I think
> > > over time, those features will trickle down into embedded systems
> > > (albeit with some twists and modifications for the embedded market).
> > > The Cortex-M7 introduces I-Cache and L1 D-Cache, for example.  A few
> > > years ago, those were higher end features not available on MCUs.
> > >
> > > I think that SMP and AMP are key technologies to get us a leg up on
> > > future mutli-core MCUs.  KERNEL mode places us in a position to
> > > support MCUs with MMUs.  A proper TrustZone model for all ARM parts is
> > > needed too (the multi-core TrustZone model is pretty well in place,
> > > but what do we do with TrustZone on a single CPU?).
> > >
> > > Security, especially IoT security is very important.  Some security
> > > topics are addressed by PROTECTED mode.  So although PROTECTED and
> > > KERNEL build modes are not commonly used,  I believe that they are
> > > important parts of the roadmap.
> > >
> > > Other thoughts?  We should collaborate and  define a meaningful
> > > roadmap that will keep the OS healthy well into the future.  We should
> > > publish that roadmap somewhere so that anyone can see where we are
> > > going and can offer insights for other directions.
> > >
> > >
> > >
>
>

Re: Roadmap?

[Matias N.]

On Wed, Aug 5, 2020, at 13:35, Maciej Wójcik wrote:
> 1) More opinionated documentation
>   a) In particular clear instructions:
> – where to get compilers for C/C++
> – how to setup project with an application outside of nuttx, and clear
> [apps], [libs], [board], [nuttx] structure
> – how to set up your own board
> These questions are recurring. They were asked on the mailing list recently
> again. They are basic things and they should be the second page of
> documentation.
>   b) Typical policy for documentation is that when people ask, the answer
> should be put to documentation and the link sent back as an answer.
>   c) Table of supported features on different platforms and boards, as
> discussed recently. For people who want to use NuttX to feel safe and know
> how much they need to contribute to make their project work.

Completely agree on the above. I would add that when people add a new board 
they document it
following a set of guidelines (maybe based on a template). Also, new features 
or breaking changes
should be accompanied by documentation changes. Distributing the load on 
maintaining the documentation
IMHO is the way to keep it updated.

> 2) Package management
> Database where people can submit whatever they want, as long as it works
> and they are willing to maintain it.
> Description on what such packages need to fulfill to work with NuttX. Some
> simple command line tool to inject packages to NuttX projects.

On my "NuttX workspace manager" 
(https://gitlab.com/nuttx_projects/nuttx_workspace_manager) I have this
mechanism that allows you to simply drop a directory containing an app inside 
an "extra_apps" directory. This works
by having a symlink from apps/external point to this directory, where NuttX 
looks for external apps. The trick is to
have a Make.defs recursively including Make.defs from subdirectories and a 
Makefile including "Directory.mk". This are the files that are placed inside 
extra_apps/: 
https://gitlab.com/nuttx_projects/nuttx_workspace_manager/-/tree/master/files/extra_apps.
 If external/ would already have this set up, it would indeed be a matter of 
dropping an app there.

Furthermore, I personally like to use submodules but even if you simply clone 
or download a git repo containing just the app, you wouldn't need a central 
database of apps, just a git repo for each app. If some sort of "central 
repository" is desired, a special github organization could be used to collect 
contributed apps.

I have a similar mechanism for OS level code, which is compiled as if it were a 
subdirectory of nuttx/.

Best,
Matias

> Am Mi., 5. Aug. 2020 um 17:20 Uhr schrieb Xiang Xiao <
> xiaoxiang781...@gmail.com>:
> 
> > I would see the automation test on the roadmap, thanks.
> >
> > > -Original Message-
> > > From: Matias N. 
> > > Sent: Wednesday, August 5, 2020 4:59 AM
> > > To: dev@nuttx.apache.org
> > > Subject: Re: Roadmap?
> > >
> > > Having a (public) roadmap is very good idea, it guides and organizes
> > efforts over time and also gives indication to existing or
> > potential
> > > users about which features which are not currently but might as well be
> > there soon.
> > >
> > > I personally would like to see support for Bluetooth/WiFi on widely used
> > hardware platforms.
> > > I'm currently working on getting BLE on nRF working so it is a matter of
> > time. I hope that also Alan might steer Espressif into
> > add
> > > support for ESP32. LoRaWAN stack would also be interesting.
> > > I would also add the current documentation effort as part of the roadmap.
> > >
> > > I think with a Roadmap laid out it would be possible to create GitHub
> > milestones (major and minor) and organize issues into each,
> > > depending on how disruptive the change is. This would help to have for
> > example a 10.x series more or less stable while holding
> > bigger
> > > changes towards 11.0 or even 12.0.
> > >
> > > Just my two cents.
> > >
> > > Best,
> > > Matias
> > >
> > > On Tue, Aug 4, 2020, at 17:32, Gregory Nutt wrote:
> > > > One of the things that I think we are missing is a Roadmap to guide
> > > > and prioritize new feature development.  Other RTOS' (like Zephyr) do
> > > > have such published roadmaps and are responsive to needs and requests
> > > > of users and sponsors.  I have even seen web pages where the Zephyr
> > > > team has laid out what new features on the roadmap will be available
> > > > in future releases.
> > > >
> > > > While I think it would be essentially impossible for us to manage such
> > > > a thing with our loose organiation, I think we should have a roadmap
> > > > that identifies the important directions that operating system will
> > take.
> > > >
> > > > For me, the important thing is to stay relevant and contemporary and
> > > > not get lost in some aging niche architecture or toolset.  I think
> > > > that the best way to predict where NuttX needs to be is to look at the
> > > > SoCs in use just above the upper end of the 

Build failed in Jenkins: NuttX-Nightly-Build #243

[Apache Jenkins Server]

See 

Changes:


--
Started by timer
Running as SYSTEM
[EnvInject] - Loading node environment variables.
[EnvInject] - Preparing an environment for the build.
[EnvInject] - Keeping Jenkins system variables.
[EnvInject] - Keeping Jenkins build variables.
[EnvInject] - Executing and processing the following script content: 
# This is a read-only credential and not explicitly a secret.  There does not 
seem to be a way to do this with the Jenkins docker plugin...
# This docker env plugin also manages to mess up pulling from docker hub...
# see JENKINS-54021
rm -rf ~/.docker/config.json
docker pull alpine:3.6

set +x
docker login https://docker.pkg.github.com -u btashton -p $GITHUB_RO_TOKEN
set -x

[jenkins-slave] $ /bin/bash -xe /tmp/jenkins4158951424401743235.sh
+ rm -rf /home/jenkins/.docker/config.json
+ docker pull alpine:3.6
3.6: Pulling from library/alpine
5a3ea8efae5d: Pulling fs layer
5a3ea8efae5d: Verifying Checksum
5a3ea8efae5d: Download complete
5a3ea8efae5d: Pull complete
Digest: sha256:66790a2b79e1ea3e1dabac43990c54aca5d1ddf268d9a5a0285e4167c8b24475
Status: Downloaded newer image for alpine:3.6
docker.io/library/alpine:3.6
+ set +x
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
WARNING! Your password will be stored unencrypted in 
/home/jenkins/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded
[EnvInject] - Script executed successfully.
[EnvInject] - Injecting contributions.
Building remotely on H24 (ubuntu) in workspace 

Pull Docker image 
docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest from 
repository ...
$ docker pull 
docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest
latest: Pulling from apache/incubator-nuttx-testing/nuttx-ci-linux
3f2411103a12: Pulling fs layer
4da04088b2c2: Pulling fs layer
ab1184837b6f: Pulling fs layer
354c6da61dcc: Pulling fs layer
fa5f246b8f10: Pulling fs layer
80ee4de2b95f: Pulling fs layer
cc1a7e2c6aab: Pulling fs layer
25b592c98129: Pulling fs layer
4f4fb700ef54: Pulling fs layer
8128befeadd3: Pulling fs layer
265fb5ec3c8e: Pulling fs layer
4c6c50c6f6e9: Pulling fs layer
fa5f246b8f10: Waiting
f65ddf0c0d7b: Pulling fs layer
354c6da61dcc: Waiting
456037525708: Pulling fs layer
cc1a7e2c6aab: Waiting
8128befeadd3: Waiting
80ee4de2b95f: Waiting
265fb5ec3c8e: Waiting
8ce796614c51: Pulling fs layer
4f4fb700ef54: Waiting
4c1d3e1bc344: Pulling fs layer
25b592c98129: Waiting
f65ddf0c0d7b: Waiting
8ce796614c51: Waiting
2f8510a006ec: Pulling fs layer
456037525708: Waiting
fac8ae7c9273: Pulling fs layer
2f8510a006ec: Waiting
ba00d8fbca38: Pulling fs layer
ba00d8fbca38: Waiting
ab1184837b6f: Verifying Checksum
ab1184837b6f: Download complete
4da04088b2c2: Verifying Checksum
4da04088b2c2: Download complete
fa5f246b8f10: Verifying Checksum
fa5f246b8f10: Download complete
354c6da61dcc: Verifying Checksum
354c6da61dcc: Download complete
3f2411103a12: Verifying Checksum
3f2411103a12: Download complete
cc1a7e2c6aab: Verifying Checksum
cc1a7e2c6aab: Download complete
25b592c98129: Download complete
4f4fb700ef54: Verifying Checksum
4f4fb700ef54: Download complete
8128befeadd3: Download complete
3f2411103a12: Pull complete
265fb5ec3c8e: Verifying Checksum
265fb5ec3c8e: Download complete
4da04088b2c2: Pull complete
ab1184837b6f: Pull complete
354c6da61dcc: Pull complete
fa5f246b8f10: Pull complete
f65ddf0c0d7b: Verifying Checksum
f65ddf0c0d7b: Download complete
4c6c50c6f6e9: Verifying Checksum
4c6c50c6f6e9: Download complete
8ce796614c51: Verifying Checksum
8ce796614c51: Download complete
80ee4de2b95f: Verifying Checksum
80ee4de2b95f: Download complete
2f8510a006ec: Download complete
fac8ae7c9273: Verifying Checksum
fac8ae7c9273: Download complete
ba00d8fbca38: Verifying Checksum
ba00d8fbca38: Download complete
4c1d3e1bc344: Verifying Checksum
4c1d3e1bc344: Download complete
80ee4de2b95f: Pull complete
cc1a7e2c6aab: Pull complete
25b592c98129: Pull complete
4f4fb700ef54: Pull complete
8128befeadd3: Pull complete
265fb5ec3c8e: Pull complete
456037525708: Verifying Checksum
456037525708: Download complete
4c6c50c6f6e9: Pull complete
f65ddf0c0d7b: Pull complete
456037525708: Pull complete
8ce796614c51: Pull complete
4c1d3e1bc344: Pull complete
2f8510a006ec: Pull complete
fac8ae7c9273: Pull complete
ba00d8fbca38: Pull complete
Digest: sha256:a950168cffbc7c41c0189286dfb4410377b4aecf04ace48b22723d99470a0bb8
Status: Downloaded newer image for 
docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest
docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest
$ docker run --rm --entrypoint /bin/true alpine:3.6
$ docker run --tty --rm --entrypoint /sbin/ip alpine:3.6 route
$ docker run --tty --detach -

Re: Build failed in Jenkins: NuttX-Nightly-Build #243

[Brennan Ashton]

I'm fixing this and restarting the job.  There was a change in the
Docker file and the Jenkins job needed to get updated to match.

--Brennan

On Wed, Aug 5, 2020 at 5:39 PM Apache Jenkins Server
 wrote:
>
> See 
>
> Changes:
>
>
> --
> Started by timer
> Running as SYSTEM
> [EnvInject] - Loading node environment variables.
> [EnvInject] - Preparing an environment for the build.
> [EnvInject] - Keeping Jenkins system variables.
> [EnvInject] - Keeping Jenkins build variables.
> [EnvInject] - Executing and processing the following script content:
> # This is a read-only credential and not explicitly a secret.  There does not 
> seem to be a way to do this with the Jenkins docker plugin...
> # This docker env plugin also manages to mess up pulling from docker hub...
> # see JENKINS-54021
> rm -rf ~/.docker/config.json
> docker pull alpine:3.6
>
> set +x
> docker login https://docker.pkg.github.com -u btashton -p $GITHUB_RO_TOKEN
> set -x
>
> [jenkins-slave] $ /bin/bash -xe /tmp/jenkins4158951424401743235.sh
> + rm -rf /home/jenkins/.docker/config.json
> + docker pull alpine:3.6
> 3.6: Pulling from library/alpine
> 5a3ea8efae5d: Pulling fs layer
> 5a3ea8efae5d: Verifying Checksum
> 5a3ea8efae5d: Download complete
> 5a3ea8efae5d: Pull complete
> Digest: 
> sha256:66790a2b79e1ea3e1dabac43990c54aca5d1ddf268d9a5a0285e4167c8b24475
> Status: Downloaded newer image for alpine:3.6
> docker.io/library/alpine:3.6
> + set +x
> WARNING! Using --password via the CLI is insecure. Use --password-stdin.
> WARNING! Your password will be stored unencrypted in 
> /home/jenkins/.docker/config.json.
> Configure a credential helper to remove this warning. See
> https://docs.docker.com/engine/reference/commandline/login/#credentials-store
>
> Login Succeeded
> [EnvInject] - Script executed successfully.
> [EnvInject] - Injecting contributions.
> Building remotely on H24 (ubuntu) in workspace 
> 
> Pull Docker image 
> docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest 
> from repository ...
> $ docker pull 
> docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest
> latest: Pulling from apache/incubator-nuttx-testing/nuttx-ci-linux
> 3f2411103a12: Pulling fs layer
> 4da04088b2c2: Pulling fs layer
> ab1184837b6f: Pulling fs layer
> 354c6da61dcc: Pulling fs layer
> fa5f246b8f10: Pulling fs layer
> 80ee4de2b95f: Pulling fs layer
> cc1a7e2c6aab: Pulling fs layer
> 25b592c98129: Pulling fs layer
> 4f4fb700ef54: Pulling fs layer
> 8128befeadd3: Pulling fs layer
> 265fb5ec3c8e: Pulling fs layer
> 4c6c50c6f6e9: Pulling fs layer
> fa5f246b8f10: Waiting
> f65ddf0c0d7b: Pulling fs layer
> 354c6da61dcc: Waiting
> 456037525708: Pulling fs layer
> cc1a7e2c6aab: Waiting
> 8128befeadd3: Waiting
> 80ee4de2b95f: Waiting
> 265fb5ec3c8e: Waiting
> 8ce796614c51: Pulling fs layer
> 4f4fb700ef54: Waiting
> 4c1d3e1bc344: Pulling fs layer
> 25b592c98129: Waiting
> f65ddf0c0d7b: Waiting
> 8ce796614c51: Waiting
> 2f8510a006ec: Pulling fs layer
> 456037525708: Waiting
> fac8ae7c9273: Pulling fs layer
> 2f8510a006ec: Waiting
> ba00d8fbca38: Pulling fs layer
> ba00d8fbca38: Waiting
> ab1184837b6f: Verifying Checksum
> ab1184837b6f: Download complete
> 4da04088b2c2: Verifying Checksum
> 4da04088b2c2: Download complete
> fa5f246b8f10: Verifying Checksum
> fa5f246b8f10: Download complete
> 354c6da61dcc: Verifying Checksum
> 354c6da61dcc: Download complete
> 3f2411103a12: Verifying Checksum
> 3f2411103a12: Download complete
> cc1a7e2c6aab: Verifying Checksum
> cc1a7e2c6aab: Download complete
> 25b592c98129: Download complete
> 4f4fb700ef54: Verifying Checksum
> 4f4fb700ef54: Download complete
> 8128befeadd3: Download complete
> 3f2411103a12: Pull complete
> 265fb5ec3c8e: Verifying Checksum
> 265fb5ec3c8e: Download complete
> 4da04088b2c2: Pull complete
> ab1184837b6f: Pull complete
> 354c6da61dcc: Pull complete
> fa5f246b8f10: Pull complete
> f65ddf0c0d7b: Verifying Checksum
> f65ddf0c0d7b: Download complete
> 4c6c50c6f6e9: Verifying Checksum
> 4c6c50c6f6e9: Download complete
> 8ce796614c51: Verifying Checksum
> 8ce796614c51: Download complete
> 80ee4de2b95f: Verifying Checksum
> 80ee4de2b95f: Download complete
> 2f8510a006ec: Download complete
> fac8ae7c9273: Verifying Checksum
> fac8ae7c9273: Download complete
> ba00d8fbca38: Verifying Checksum
> ba00d8fbca38: Download complete
> 4c1d3e1bc344: Verifying Checksum
> 4c1d3e1bc344: Download complete
> 80ee4de2b95f: Pull complete
> cc1a7e2c6aab: Pull complete
> 25b592c98129: Pull complete
> 4f4fb700ef54: Pull complete
> 8128befeadd3: Pull complete
> 265fb5ec3c8e: Pull complete
> 456037525708: Verifying Checksum
> 456037525708: Download complete
> 4c6c50c6f6e9: Pull complete
> f65ddf0c0d7b: Pull complete
> 456037525708: Pull complete
> 8ce796614c51: Pull complete
> 4c1d3e1bc344: Pull complete
> 2f8510a006ec: Pull

Jenkins build is back to normal : NuttX-Nightly-Build #244

[Apache Jenkins Server]

See 

Re: Nuttx was found to be a strange error compiling on Macos

[Nii Jyeni]

Thanks Alan, I re-downloaded the source code and the problem was solved.It's a 
bit strange.

> 2020年8月3日 下午10:04，Nii Jyeni  写道：
> 
> OS:MacOS
> Nuttx:nightly
> Arm-none-eabi-gcc:7.3.1
> 
> …
> arning: /Library/Developer/CommandLineTools/usr/bin/ranlib: warning for 
> library: libbinfmt.a the table of contents is empty (no object file members 
> in the library define global symbols)
> IN: binfmt/libbinfmt.a -> staging/libbinfmt.a
> CC:  board/stm32_boot.c
> CC:  board/stm32_bringup.c
> CC:  board/stm32_spi.c
> CC:  board/stm32_userleds.c
> CC:  board/stm32_appinit.c
> CC:  board/stm32_extmem.c
> CC:  board/stm32_lcd.c
> CC:  board/stm32_adc.c
> ar rcs  libboard.a   stm32_boot.o stm32_bringup.o stm32_spi.o 
> stm32_userleds.o stm32_appinit.o stm32_extmem.o stm32_lcd.o stm32_adc.o
> warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: warning for 
> library: libboard.a the table of contents is empty (no object file members in 
> the library define global symbols)
> LD: nuttx
> arm-none-eabi-ld: warning: cannot find entry symbol __start; defaulting to 
> 0800
> 
> Does anybody know what's going on?
> 
> 
> Enjoy your life!
> -
> Nii Jyeni
> 
> 13880639629
> niijy...@hotmail.com
> www.niijyeni.org
> [https://a.gfx.ms/emoji_1F680.png]Sent from Outlook.com

ADC Examples error?

[Nii Jyeni]

I found a strange problem when using the latest source code to test the ADC 
example. The analog value can be obtained when the ADC example is run for the 
first time. When the ADC example is run again, it is blocked and it looks like 
it is dead. But send Ctrl+C to the console can terminate it.

OS:MacOS
Nuttx:nightly
MCU:stm32f429iit6
Board:customize

NuttShell (NSH) NuttX-9.1.0
nsh> adc -n 2
adc_main: g_adcstate.count: 2
adc_main: Hardware initialized. Opening the ADC device: /dev/adc0
Sample:
1: channel: 4 value: 3091
2: channel: 5 value: 3782
Sample:
1: channel: 4 value: 3192
2: channel: 5 value: 3612
nsh> adc -n 2
adc_main: g_adcstate.count: 2
adc_main: Hardware initialized. Opening the ADC device: /dev/adc0 <— terminated 
by send ctrl + c
nsh> adc -n 2
adc_main: g_adcstate.count: 2
adc_main: Hardware initialized. Opening the ADC device: /dev/adc0 <— terminated 
by send ctrl + c
nsh>

This is the configuration information about ADC that I am using:
CONFIG_STM32_ADC1=y
CONFIG_STM32_ADC1_DMA=y
CONFIG_STM32_TIM1=y
CONFIG_STM32_TIM1_ADC=y
CONFIG_EXAMPLES_ADC=y
CONFIG_EXAMPLES_ADC_GROUPSIZE=3
CONFIG_ADC=y

Does anyone know what is going on? and how to solve this problem.