Re: oneshot or watchdog?

[raiden00pl]

> I'm following the BLE 4.0 spec and the most I could find about timing
requirements is on p.55.

Look at BLE spec vol 6, part B.4 - Air Interface protocol. If you look at
the spec for BLE 5.1, a little more is written there.
"The Inter Frame Space is designated “T_IFS” and shall be 150 μs."

> Which part of the BLE protocol requires capture?

TIMER capture + PPI enables you to get exact times of radio events. Without
this you probably cannot handle TIFS or window widening properly.
There is hardware support for TFIS but it is usable only for RX -> TX
transition.  For TX -> RX you have to use TIMER capture to know how long
you should wait in RX state.

> I looked a bit at Zephyr's stack, and in the process found this video
which cleared some questions about the code (which is quite complex):
https://www.youtube.com/watch?v=rIicvcriWR8

The code in Zephyr is complex and completely unreadable :)

sob., 18 lip 2020 o 03:56 Matias N.  napisał(a):

> I looked a bit at Zephyr's stack, and in the process found this video
> which cleared some questions about the code (which is quite complex):
> https://www.youtube.com/watch?v=rIicvcriWR8
>
> It seems that once you get into handle multiple connections, it requires
> some clever handling of communication intervals. This guy from Zephyr
> developed the "mayfly" system, which is a kind of RPC system that I
> understand helped him dealing with this. I think the use of the TIMER may
> be tied to that. Moreover, looking at the code I found about nRF52 PPI
> (Programmable Peripheral Interconnect) which lets you chain events to
> tasks, to avoid doing this in ISR (one cool use is to tie GPIO outputs to
> events and you can inspect low-level events of the protocol using a logic
> analyzer).
>
> I think that I'm still far at handling all that complexity, since I will
> probably just tackle the whole scanning/advertisement and connection of a
> single device.
>
> Best,
> Matias
>
> On Fri, Jul 17, 2020, at 16:27, raiden00pl wrote:
> > > I'm not sure why a TIMER would be needed. Do you mean because of the
> RTC
> > resolution?
> >
> > To meet the BLE timing specification, we need a timer resolution in
> > microseconds and support for BLE/RADIO events capture.
> > There is no capture interface for RTC and maximum counter resolution is
> > 30.5us which can be not sufficient.
> > As far as I know, the main problem with implementing a radio based BLE
> > stack is the time requirements.
> >
> > > Let's try to coordinate things since I'm actually working on the same
> > code and I was even about to start working on RTC peripheral interface
> >
> > So far I've done interfaces for TIMER and RTC peripherals. Tomorrow I'll
> > prepare a PR.
> >
> > pt., 17 lip 2020 o 16:09 Matias N.  napisał(a):
> >
> > > Hi,
> > >
> > > On Fri, Jul 17, 2020, at 03:30, raiden00pl wrote:
> > > >I think we should do it like in other BLE implementations for
> NRF52
> > > > (SoftDevice, Zephyr) and use a combination of RTC and TIMER
> peripherals.
> > > >There are quite a few places in the BLE protocol where we need to
> > > count
> > > > the time in various ranges from seconds to mili-seconds.
> > > >It is not possible to achieve this with just one timer device.
> > >
> > > I'm not sure why a TIMER would be needed. Do you mean because of the
> RTC
> > > resolution?
> > > The RTC is capable of us resolution with period of hundreds of seconds.
> > > The point is that RTC works
> > > while MCU is sleeping so not depending on other peripherals means
> > > low-power mode could be entered while waiting for things eventually. I
> > > would personally use one timer until there's a specific need for other.
> > >
> > > >There is only one watchdog instance and at least two RTC
> instances in
> > > > the NRF52 chips.
> > > >The watchdog timer should be left for user-specific applications.
> > >
> > > Note that "watchdog" in NuttX context means different things: there's a
> > > "watchdog" interface which basically allows you to set a callback to be
> > > invoked after some duration. This works using the underlying system
> timer.
> > > In other words, the "watchdog" interface in NuttX gives you access to
> the
> > > system timer, whereas the oneshot is a separate interface based on a
> > > separate harware resource.
> > >
> > > >The system timer (SysTick) is not low-power friendly, so it is not
> > > > suitable either.
> > > >Ultimately, we should use the TICK event from RTC as the system
> clock.
> > >
> > > Yes, RTC0 should be used for OS. My intention is to support what Xiang
> > > mentioned is the recommended approach for new boards, which would mean
> to
> > > implement an arch_timer.c compatible interface to RTC and then you get
> > > tick/tickless option automatically.
> > >
> > > >Another thing is that we probably don't want to use the oneshot
> > > > interface but instead work directly with the TIMER/RTC peripherals.
> > > >In a few days I'll add PR with TIMER and RTC suppor

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

[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/jenkins8679329934701310590.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 H27 (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
4dc9c2fff018: Pulling fs layer
0a4ccbb24215: Pulling fs layer
c0f243bc6706: Pulling fs layer
5ff1eaecba77: Pulling fs layer
a5640de097a2: Pulling fs layer
652636454a5d: Pulling fs layer
ff9f9a216ea4: Pulling fs layer
86fb64809595: Pulling fs layer
4f4fb700ef54: Pulling fs layer
6ba0c3ec3b78: Pulling fs layer
cea874b12f7e: Pulling fs layer
5ff1eaecba77: Waiting
c12c44b835dc: Pulling fs layer
652636454a5d: Waiting
af65bd64ad36: Pulling fs layer
a5640de097a2: Waiting
68bbf8294e93: Pulling fs layer
ff9f9a216ea4: Waiting
fb9d57636f52: Pulling fs layer
6ba0c3ec3b78: Waiting
4f4fb700ef54: Waiting
86fb64809595: Waiting
292aef0780b6: Pulling fs layer
fc41b6481ee6: Pulling fs layer
c12c44b835dc: Waiting
cea874b12f7e: Waiting
c6288483c374: Pulling fs layer
af65bd64ad36: Waiting
68bbf8294e93: Waiting
fc41b6481ee6: Waiting
c6288483c374: Waiting
0a4ccbb24215: Verifying Checksum
0a4ccbb24215: Download complete
c0f243bc6706: Download complete
a5640de097a2: Verifying Checksum
a5640de097a2: Download complete
5ff1eaecba77: Verifying Checksum
5ff1eaecba77: Download complete
ff9f9a216ea4: Verifying Checksum
ff9f9a216ea4: Download complete
4dc9c2fff018: Verifying Checksum
4dc9c2fff018: Download complete
86fb64809595: Verifying Checksum
86fb64809595: Download complete
4f4fb700ef54: Download complete
6ba0c3ec3b78: Download complete
cea874b12f7e: Verifying Checksum
cea874b12f7e: Download complete
4dc9c2fff018: Pull complete
0a4ccbb24215: Pull complete
c0f243bc6706: Pull complete
5ff1eaecba77: Pull complete
a5640de097a2: Pull complete
af65bd64ad36: Verifying Checksum
af65bd64ad36: Download complete
652636454a5d: Verifying Checksum
652636454a5d: Download complete
c12c44b835dc: Verifying Checksum
c12c44b835dc: Download complete
292aef0780b6: Download complete
fc41b6481ee6: Verifying Checksum
fc41b6481ee6: Download complete
c6288483c374: Verifying Checksum
c6288483c374: Download complete
fb9d57636f52: Verifying Checksum
fb9d57636f52: Download complete
652636454a5d: Pull complete
68bbf8294e93: Verifying Checksum
68bbf8294e93: Download complete
ff9f9a216ea4: Pull complete
86fb64809595: Pull complete
4f4fb700ef54: Pull complete
6ba0c3ec3b78: Pull complete
cea874b12f7e: Pull complete
c12c44b835dc: Pull complete
af65bd64ad36: Pull complete
68bbf8294e93: Pull complete
fb9d57636f52: Pull complete
292aef0780b6: Pull complete
fc41b6481ee6: Pull complete
c6288483c374: Pull complete
Digest: sha256:2d978e178b9837ebec6ba3effb9359540c20d2a08429d969de09eb486a32a06f
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 --privileged --workdir 
 --volume 
/home/jenkins/jenkins-slave:/home/jenkins/jenkins-slave:rw --volume 

Re: oneshot or watchdog?

[Matias N.]

I looked a bit at Zephyr's stack, and in the process found this video which 
cleared some questions about the code (which is quite complex): 
https://www.youtube.com/watch?v=rIicvcriWR8

It seems that once you get into handle multiple connections, it requires some 
clever handling of communication intervals. This guy from Zephyr developed the 
"mayfly" system, which is a kind of RPC system that I understand helped him 
dealing with this. I think the use of the TIMER may be tied to that. Moreover, 
looking at the code I found about nRF52 PPI (Programmable Peripheral 
Interconnect) which lets you chain events to tasks, to avoid doing this in ISR 
(one cool use is to tie GPIO outputs to events and you can inspect low-level 
events of the protocol using a logic analyzer).

I think that I'm still far at handling all that complexity, since I will 
probably just tackle the whole scanning/advertisement and connection of a 
single device.

Best,
Matias

On Fri, Jul 17, 2020, at 16:27, raiden00pl wrote:
> > I'm not sure why a TIMER would be needed. Do you mean because of the RTC
> resolution?
> 
> To meet the BLE timing specification, we need a timer resolution in
> microseconds and support for BLE/RADIO events capture.
> There is no capture interface for RTC and maximum counter resolution is
> 30.5us which can be not sufficient.
> As far as I know, the main problem with implementing a radio based BLE
> stack is the time requirements.
> 
> > Let's try to coordinate things since I'm actually working on the same
> code and I was even about to start working on RTC peripheral interface
> 
> So far I've done interfaces for TIMER and RTC peripherals. Tomorrow I'll
> prepare a PR.
> 
> pt., 17 lip 2020 o 16:09 Matias N.  napisał(a):
> 
> > Hi,
> >
> > On Fri, Jul 17, 2020, at 03:30, raiden00pl wrote:
> > >I think we should do it like in other BLE implementations for NRF52
> > > (SoftDevice, Zephyr) and use a combination of RTC and TIMER peripherals.
> > >There are quite a few places in the BLE protocol where we need to
> > count
> > > the time in various ranges from seconds to mili-seconds.
> > >It is not possible to achieve this with just one timer device.
> >
> > I'm not sure why a TIMER would be needed. Do you mean because of the RTC
> > resolution?
> > The RTC is capable of us resolution with period of hundreds of seconds.
> > The point is that RTC works
> > while MCU is sleeping so not depending on other peripherals means
> > low-power mode could be entered while waiting for things eventually. I
> > would personally use one timer until there's a specific need for other.
> >
> > >There is only one watchdog instance and at least two RTC instances in
> > > the NRF52 chips.
> > >The watchdog timer should be left for user-specific applications.
> >
> > Note that "watchdog" in NuttX context means different things: there's a
> > "watchdog" interface which basically allows you to set a callback to be
> > invoked after some duration. This works using the underlying system timer.
> > In other words, the "watchdog" interface in NuttX gives you access to the
> > system timer, whereas the oneshot is a separate interface based on a
> > separate harware resource.
> >
> > >The system timer (SysTick) is not low-power friendly, so it is not
> > > suitable either.
> > >Ultimately, we should use the TICK event from RTC as the system clock.
> >
> > Yes, RTC0 should be used for OS. My intention is to support what Xiang
> > mentioned is the recommended approach for new boards, which would mean to
> > implement an arch_timer.c compatible interface to RTC and then you get
> > tick/tickless option automatically.
> >
> > >Another thing is that we probably don't want to use the oneshot
> > > interface but instead work directly with the TIMER/RTC peripherals.
> > >In a few days I'll add PR with TIMER and RTC support.
> >
> > Let's try to coordinate things since I'm actually working on the same code
> > and I was even about to start working on RTC peripheral interface. My
> > intention was to do the following:
> > - work on clockconfig to configure the LFCLK (wait for oscillator, etc)
> > - expose RTC peripheral with very basic interface
> >
> > The following step would be to either create a oneshot driver interface
> > for the RTC timer, so RTC1 could be used from Link-layer timeouts.
> > Otherwise I could simply use the system timer using NuttX watchdog
> > interface. That was my original question. Since you mention that maybe two
> > timers are needed, that enforces my idea that at least one oneshot timer is
> > needed (for the TIMER peripheral).
> >
> > And FYI, I'm slowly building up a Bluetooth link-layer by defining what
> > would be an upper-half part that implement most of the arch-independant
> > parts of the low-level BLE protocol handling, next to a lower-half
> > interface which allows the upper-half to communicate with the
> > arch-dependant part. This means that besides the arch-independant
> > li

Re: Markdown READMEs?

[Justin Mclean]

Hi,

> asciidoctor requires ruby

You can use it that way yes but it not required.

One other ways of doing so including javascript for displaying markdown content 
on a website.

Justin

Re: oneshot or watchdog?

[Matias N.]

> I hope that you are following the established NuttX Bluetooth 
> architecture per 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629397 
> or file:///C:/Users/spuda/AppData/Local/Temp/nuttx-4-WifiBt.pdf

I was unaware of that presentation. But yes, I'm following the expected 
architecture. Anyways, if something needs to be changed later, it is no problem.

Currently I have a Link-layer implementation, which does a bt_netdev_register() 
call. The LL receives HCI commands and speaks to a lower-half LL. This 
lower-half is expected to be implemented by each architecture. Since I'm on 
nRF52, this lower-half accesses the RADIO peripheral via the nrf52_radio.c arch 
interface. 

The upper-half of the LL should implement everything about the controller part 
of the BLE stack that is arch-independant. The lower-half does not carry much 
complexity as it is mostly a wrapper with a standardized interface.

If I sort out which timing system I should use to manage scan interval, window, 
and so on, and when I receive the nrf52832 eval board, I can open a draft PR so 
you can see the work in progress.

Best,
Matias

Re: oneshot or watchdog?

[Gregory Nutt]

On 7/17/2020 1:48 PM, Matias N. wrote:

To meet the BLE timing specification, we need a timer resolution in
microseconds and support for BLE/RADIO events capture.
There is no capture interface for RTC and maximum counter resolution is
30.5us which can be not sufficient.
As far as I know, the main problem with implementing a radio based BLE
stack is the time requirements.

I'm following the BLE 4.0 spec and the most I could find about timing 
requirements is on p.55. It states that two clock resolutions are acceptable, 
depending on the power consumption of the device, and mostly speaks about 
deviations in ppm. Regarding resolution, for now I saw timings in the order of 
ms (for example, some interval in units of 1.25ms), not us. It would seem the 
RTC timer meets this.

On the other hand, it is true it does not support capture. Which part of the 
BLE protocol requires capture? I'm learning the protocol as I go, so I'm not 
fully aware of the whole complexity of the system.


Let's try to coordinate things since I'm actually working on the same

code and I was even about to start working on RTC peripheral interface

So far I've done interfaces for TIMER and RTC peripherals. Tomorrow I'll
prepare a PR.

Great, I will have a look when you do and base my work on that.

PS: have you seen https://github.com/apache/incubator-nuttx/issues/1416 ?


pt., 17 lip 2020 o 16:09 Matias N.  napisał(a):


Hi,

On Fri, Jul 17, 2020, at 03:30, raiden00pl wrote:

I think we should do it like in other BLE implementations for NRF52
(SoftDevice, Zephyr) and use a combination of RTC and TIMER peripherals.
There are quite a few places in the BLE protocol where we need to

count

the time in various ranges from seconds to mili-seconds.
It is not possible to achieve this with just one timer device.

I'm not sure why a TIMER would be needed. Do you mean because of the RTC
resolution?
The RTC is capable of us resolution with period of hundreds of seconds.
The point is that RTC works
while MCU is sleeping so not depending on other peripherals means
low-power mode could be entered while waiting for things eventually. I
would personally use one timer until there's a specific need for other.


There is only one watchdog instance and at least two RTC instances in
the NRF52 chips.
The watchdog timer should be left for user-specific applications.

Note that "watchdog" in NuttX context means different things: there's a
"watchdog" interface which basically allows you to set a callback to be
invoked after some duration. This works using the underlying system timer.
In other words, the "watchdog" interface in NuttX gives you access to the
system timer, whereas the oneshot is a separate interface based on a
separate harware resource.


The system timer (SysTick) is not low-power friendly, so it is not
suitable either.
Ultimately, we should use the TICK event from RTC as the system clock.

Yes, RTC0 should be used for OS. My intention is to support what Xiang
mentioned is the recommended approach for new boards, which would mean to
implement an arch_timer.c compatible interface to RTC and then you get
tick/tickless option automatically.


Another thing is that we probably don't want to use the oneshot
interface but instead work directly with the TIMER/RTC peripherals.
In a few days I'll add PR with TIMER and RTC support.

Let's try to coordinate things since I'm actually working on the same code
and I was even about to start working on RTC peripheral interface. My
intention was to do the following:
- work on clockconfig to configure the LFCLK (wait for oscillator, etc)
- expose RTC peripheral with very basic interface

The following step would be to either create a oneshot driver interface
for the RTC timer, so RTC1 could be used from Link-layer timeouts.
Otherwise I could simply use the system timer using NuttX watchdog
interface. That was my original question. Since you mention that maybe two
timers are needed, that enforces my idea that at least one oneshot timer is
needed (for the TIMER peripheral).

And FYI, I'm slowly building up a Bluetooth link-layer by defining what
would be an upper-half part that implement most of the arch-independant
parts of the low-level BLE protocol handling, next to a lower-half
interface which allows the upper-half to communicate with the
arch-dependant part. This means that besides the arch-independant
link-layer, I'm writing an implementation for the lower-half which calls
into nrf52_radio.h functions.

I don't have this pushed anywhere yet since I don't even have the hardware
to test it, but I'm slowly advancing. I was just at the point of needing to
design how the timing part would work on the LL.

Best,
Matias


pt., 17 lip 2020 o 04:40 Matias N.  napisał(a):


Hi,
I'm working on a BLE Link Layer for NuttX, which sits between HCI layer
and low-level radio-layer. I'm starting with BLE scanning and I need

to set

a timer to periodically execute the radio reception to liste

Re: oneshot or watchdog?

[Matias N.]

> To meet the BLE timing specification, we need a timer resolution in
> microseconds and support for BLE/RADIO events capture.
> There is no capture interface for RTC and maximum counter resolution is
> 30.5us which can be not sufficient.
> As far as I know, the main problem with implementing a radio based BLE
> stack is the time requirements.

I'm following the BLE 4.0 spec and the most I could find about timing 
requirements is on p.55. It states that two clock resolutions are acceptable, 
depending on the power consumption of the device, and mostly speaks about 
deviations in ppm. Regarding resolution, for now I saw timings in the order of 
ms (for example, some interval in units of 1.25ms), not us. It would seem the 
RTC timer meets this.

On the other hand, it is true it does not support capture. Which part of the 
BLE protocol requires capture? I'm learning the protocol as I go, so I'm not 
fully aware of the whole complexity of the system.

> > Let's try to coordinate things since I'm actually working on the same
> code and I was even about to start working on RTC peripheral interface
> 
> So far I've done interfaces for TIMER and RTC peripherals. Tomorrow I'll
> prepare a PR.

Great, I will have a look when you do and base my work on that.

PS: have you seen https://github.com/apache/incubator-nuttx/issues/1416 ?

> 
> pt., 17 lip 2020 o 16:09 Matias N.  napisał(a):
> 
> > Hi,
> >
> > On Fri, Jul 17, 2020, at 03:30, raiden00pl wrote:
> > >I think we should do it like in other BLE implementations for NRF52
> > > (SoftDevice, Zephyr) and use a combination of RTC and TIMER peripherals.
> > >There are quite a few places in the BLE protocol where we need to
> > count
> > > the time in various ranges from seconds to mili-seconds.
> > >It is not possible to achieve this with just one timer device.
> >
> > I'm not sure why a TIMER would be needed. Do you mean because of the RTC
> > resolution?
> > The RTC is capable of us resolution with period of hundreds of seconds.
> > The point is that RTC works
> > while MCU is sleeping so not depending on other peripherals means
> > low-power mode could be entered while waiting for things eventually. I
> > would personally use one timer until there's a specific need for other.
> >
> > >There is only one watchdog instance and at least two RTC instances in
> > > the NRF52 chips.
> > >The watchdog timer should be left for user-specific applications.
> >
> > Note that "watchdog" in NuttX context means different things: there's a
> > "watchdog" interface which basically allows you to set a callback to be
> > invoked after some duration. This works using the underlying system timer.
> > In other words, the "watchdog" interface in NuttX gives you access to the
> > system timer, whereas the oneshot is a separate interface based on a
> > separate harware resource.
> >
> > >The system timer (SysTick) is not low-power friendly, so it is not
> > > suitable either.
> > >Ultimately, we should use the TICK event from RTC as the system clock.
> >
> > Yes, RTC0 should be used for OS. My intention is to support what Xiang
> > mentioned is the recommended approach for new boards, which would mean to
> > implement an arch_timer.c compatible interface to RTC and then you get
> > tick/tickless option automatically.
> >
> > >Another thing is that we probably don't want to use the oneshot
> > > interface but instead work directly with the TIMER/RTC peripherals.
> > >In a few days I'll add PR with TIMER and RTC support.
> >
> > Let's try to coordinate things since I'm actually working on the same code
> > and I was even about to start working on RTC peripheral interface. My
> > intention was to do the following:
> > - work on clockconfig to configure the LFCLK (wait for oscillator, etc)
> > - expose RTC peripheral with very basic interface
> >
> > The following step would be to either create a oneshot driver interface
> > for the RTC timer, so RTC1 could be used from Link-layer timeouts.
> > Otherwise I could simply use the system timer using NuttX watchdog
> > interface. That was my original question. Since you mention that maybe two
> > timers are needed, that enforces my idea that at least one oneshot timer is
> > needed (for the TIMER peripheral).
> >
> > And FYI, I'm slowly building up a Bluetooth link-layer by defining what
> > would be an upper-half part that implement most of the arch-independant
> > parts of the low-level BLE protocol handling, next to a lower-half
> > interface which allows the upper-half to communicate with the
> > arch-dependant part. This means that besides the arch-independant
> > link-layer, I'm writing an implementation for the lower-half which calls
> > into nrf52_radio.h functions.
> >
> > I don't have this pushed anywhere yet since I don't even have the hardware
> > to test it, but I'm slowly advancing. I was just at the point of needing to
> > design how the timing part would work on the LL.
> >
> > Best,
> > Matias
> 

Re: oneshot or watchdog?

[raiden00pl]

> I'm not sure why a TIMER would be needed. Do you mean because of the RTC
resolution?

To meet the BLE timing specification, we need a timer resolution in
microseconds and support for BLE/RADIO events capture.
There is no capture interface for RTC and maximum counter resolution is
30.5us which can be not sufficient.
As far as I know, the main problem with implementing a radio based BLE
stack is the time requirements.

> Let's try to coordinate things since I'm actually working on the same
code and I was even about to start working on RTC peripheral interface

So far I've done interfaces for TIMER and RTC peripherals. Tomorrow I'll
prepare a PR.

pt., 17 lip 2020 o 16:09 Matias N.  napisał(a):

> Hi,
>
> On Fri, Jul 17, 2020, at 03:30, raiden00pl wrote:
> >I think we should do it like in other BLE implementations for NRF52
> > (SoftDevice, Zephyr) and use a combination of RTC and TIMER peripherals.
> >There are quite a few places in the BLE protocol where we need to
> count
> > the time in various ranges from seconds to mili-seconds.
> >It is not possible to achieve this with just one timer device.
>
> I'm not sure why a TIMER would be needed. Do you mean because of the RTC
> resolution?
> The RTC is capable of us resolution with period of hundreds of seconds.
> The point is that RTC works
> while MCU is sleeping so not depending on other peripherals means
> low-power mode could be entered while waiting for things eventually. I
> would personally use one timer until there's a specific need for other.
>
> >There is only one watchdog instance and at least two RTC instances in
> > the NRF52 chips.
> >The watchdog timer should be left for user-specific applications.
>
> Note that "watchdog" in NuttX context means different things: there's a
> "watchdog" interface which basically allows you to set a callback to be
> invoked after some duration. This works using the underlying system timer.
> In other words, the "watchdog" interface in NuttX gives you access to the
> system timer, whereas the oneshot is a separate interface based on a
> separate harware resource.
>
> >The system timer (SysTick) is not low-power friendly, so it is not
> > suitable either.
> >Ultimately, we should use the TICK event from RTC as the system clock.
>
> Yes, RTC0 should be used for OS. My intention is to support what Xiang
> mentioned is the recommended approach for new boards, which would mean to
> implement an arch_timer.c compatible interface to RTC and then you get
> tick/tickless option automatically.
>
> >Another thing is that we probably don't want to use the oneshot
> > interface but instead work directly with the TIMER/RTC peripherals.
> >In a few days I'll add PR with TIMER and RTC support.
>
> Let's try to coordinate things since I'm actually working on the same code
> and I was even about to start working on RTC peripheral interface. My
> intention was to do the following:
> - work on clockconfig to configure the LFCLK (wait for oscillator, etc)
> - expose RTC peripheral with very basic interface
>
> The following step would be to either create a oneshot driver interface
> for the RTC timer, so RTC1 could be used from Link-layer timeouts.
> Otherwise I could simply use the system timer using NuttX watchdog
> interface. That was my original question. Since you mention that maybe two
> timers are needed, that enforces my idea that at least one oneshot timer is
> needed (for the TIMER peripheral).
>
> And FYI, I'm slowly building up a Bluetooth link-layer by defining what
> would be an upper-half part that implement most of the arch-independant
> parts of the low-level BLE protocol handling, next to a lower-half
> interface which allows the upper-half to communicate with the
> arch-dependant part. This means that besides the arch-independant
> link-layer, I'm writing an implementation for the lower-half which calls
> into nrf52_radio.h functions.
>
> I don't have this pushed anywhere yet since I don't even have the hardware
> to test it, but I'm slowly advancing. I was just at the point of needing to
> design how the timing part would work on the LL.
>
> Best,
> Matias
>
> > pt., 17 lip 2020 o 04:40 Matias N.  napisał(a):
> >
> > > Hi,
> > > I'm working on a BLE Link Layer for NuttX, which sits between HCI layer
> > > and low-level radio-layer. I'm starting with BLE scanning and I need
> to set
> > > a timer to periodically execute the radio reception to listen for
> > > advertisements. I'm trying to see which interface should this layer
> use:
> > > oneshot or watchdog? From what I understand, the oneshot would use a
> > > separate timer that of the system timer. I can only think of that
> > > difference, is there other?
> > > In any case, I'm not sure what would be desireable to use for this. I
> like
> > > the simplicity of the watchdog (nothing to implement) but maybe it is
> > > better to use a separate timer?
> > >
> > > At the hardware level, the NRF52832 is already designed to have 

Re: Markdown READMEs?

[Adam Feuer]

Version documentation is quite useful, specially for such a dynamic project
> as NuttX. I'm not sure it would require to have everything in a single
> repo, since it is not really necessary to tie every single code commit to a
> doc commit. I think a doc for master, updated as the code evolves, while
> having doc tagged with the same version numbers as the codebase, could be
> already enough and simple enough.


That works– what I was trying to say was that the docs need to have the
same version as the release numbers, so you can know you're reading
accurate docs for that version. As long as we have process to keep them in
sync, we're good.

Having separate repos will also simplify dealing with doc PRs vs code PRs,
> can have different maintainers, requirements, CI system, etc. (imagine
> having a doc update triggering a full CI rebuild).
>

To me, it's a preference– with most CI systems you can set it to watch
certain directories or types of files.

Again, I would encourage you to think in a scenario where you have a
> specific repo holding all documentation which describes how to use and work
> with NuttX, starting from simple "quickstart", to advanced technical
> information and even an API reference.


Agreed. This is also my vision.


> In that case, READMEs throughout the repo would not need to have a lot of
> the information that today exists there, sprinkled in all of the READMEs.
> For that reason, I don't think it is worth it using something richer than
> Markdown for READMEs.
>

As long as we can mix Markdown and RST (or whatever we use for the richer
documentation) then Markdown is ok with me. Where this would come in handy
is something like the Supported Boards tree you've been describing. In
Zephyr each board doc is a seamless part of the main docs.


> Anyways, if it comes down to "use the same for everything, or leave it as
> is" I would indeed vote for the first option


Likewise. But if we use Sphinx we can mix Markdown and RST. However, Zephyr
went with "everything the same"  and just uses RST (Zephyr supported boards
; example board
Nitrogen
;
example board nitrogen RST on github

).

-adam
-- 
Adam Feuer 

Re: Markdown READMEs?

[Matias N.]

On Fri, Jul 17, 2020, at 13:39, Adam Feuer wrote:
> A few comments:
> 
>- It would be great to have the documentation in the same repository, to
>make synchronizing a particular documentation version with the code.
>- Or if we don't do that, have some other explicit versioning that
>   matches the code, and do simultaneous releases. Code and docs
> synchronized
>   will make peoples' lives a lot easier.

Version documentation is quite useful, specially for such a dynamic project as 
NuttX. I'm not sure it would require to have everything in a single repo, since 
it is not really necessary to tie every single code commit to a doc commit. I 
think a doc for master, updated as the code evolves, while having doc tagged 
with the same version numbers as the codebase, could be already enough and 
simple enough. Having separate repos will also simplify dealing with doc PRs vs 
code PRs, can have different maintainers, requirements, CI system, etc. 
(imagine having a doc update triggering a full CI rebuild).

>- RST is as readable in plain text format as Markdown, and is also
>rendered automatically by Github (example rendered by Github
>
> ;
>raw version
>
> 
>).
>- The main difference between RST and Markdown formatting is the way
>links are handled. RST has a different link format and also has support for
>internal linking– in my opinion that's what makes RST really good for
>technical documentation.
>- Converting READMEs to RST or Markdown can be done manually or
>semi-manually, it's not that hard. We could design a system that included
>both text and RST or Markdown to support the transition.
>- Sphinx supports generating documentation using both RST and Markdown
>(recommonmark) so
>you can mix them.
> 
> I think getting our docs and READMEs into a single system using RST or
> RST/Markdown would be great.

IMHO, each format has its benefits: 
- Markdown, simple, very readable
- Rest: richer syntax, not that nice to read as Markdown

Again, I would encourage you to think in a scenario where you have a specific 
repo holding all documentation which describes how to use and work with NuttX, 
starting from simple "quickstart", to advanced technical information and even 
an API reference. In that case, READMEs throughout the repo would not need to 
have a lot of the information that today exists there, sprinkled in all of the 
READMEs. For that reason, I don't think it is worth it using something richer 
than Markdown for READMEs. 
Anyways, if it comes down to "use the same for everything, or leave it as is" I 
would indeed vote for the first option.

Best,
Matias

> 
> -adam
> 
> On Fri, Jul 17, 2020 at 9:23 AM Abdelatif Guettouche <
> abdelatif.guettou...@gmail.com> wrote:
> 
> > It would be great to have READMEs in Markdown, as said before, it's
> > still plain text and can be rendered by other tools/websites.  Because
> > it was brought out, VIM also has plugins for syntax highlighting,
> > instant rendering, etc.
> > It was also suggested to use Markdown for release notes.
> >
> > On Fri, Jul 17, 2020 at 5:12 PM Matias N.  wrote:
> > >
> > > No problem, just wanted to clear any possible confusion when considering
> > the idea.
> > >
> > > On Fri, Jul 17, 2020, at 13:09, Maciej Wójcik wrote:
> > > > Sure, Matias. I was not addressing your proposition in any way. I was
> > just
> > > > commenting on existing format of READMEs.
> > > >
> > > > I am neutral regarding separate repository with documentation. At
> > least at
> > > > the moment, I need to sleep with the idea (more).
> > > >
> > > > Some if not all READMES will stay in the repository and I was
> > suggesting
> > > > reformatting them.
> > > >
> > > > Am Fr., 17. Juli 2020 um 17:59 Uhr schrieb Matias N. :
> > > >
> > > > >
> > > > > > What I think would be great, is to pick any of this two standards.
> > > > >
> > > > > What I was trying to convey in my previous e-mail is that we can
> > choose
> > > > > Markdown for READMEs (the prefered choice, IMHO) and either
> > Markdown, RST,
> > > > > or anything else for the eventual doc-repo. These are independent
> > choices,
> > > > > one does not have to affect the other. In fact, maybe RST is better
> > for the
> > > > > doc-repo, since it supports richer syntax more apropriate for
> > building
> > > > > documentation.
> > > > >
> > > > > Best,
> > > > > Matias
> > > >
> >
> 
> 
> -- 
> Adam Feuer 
> 

Re: Markdown READMEs?

[Adam Feuer]

A few comments:

   - It would be great to have the documentation in the same repository, to
   make synchronizing a particular documentation version with the code.
   - Or if we don't do that, have some other explicit versioning that
  matches the code, and do simultaneous releases. Code and docs
synchronized
  will make peoples' lives a lot easier.
   - RST is as readable in plain text format as Markdown, and is also
   rendered automatically by Github (example rendered by Github
   
;
   raw version
   

   ).
   - The main difference between RST and Markdown formatting is the way
   links are handled. RST has a different link format and also has support for
   internal linking– in my opinion that's what makes RST really good for
   technical documentation.
   - Converting READMEs to RST or Markdown can be done manually or
   semi-manually, it's not that hard. We could design a system that included
   both text and RST or Markdown to support the transition.
   - Sphinx supports generating documentation using both RST and Markdown
   (recommonmark) so
   you can mix them.

I think getting our docs and READMEs into a single system using RST or
RST/Markdown would be great.

-adam

On Fri, Jul 17, 2020 at 9:23 AM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:

> It would be great to have READMEs in Markdown, as said before, it's
> still plain text and can be rendered by other tools/websites.  Because
> it was brought out, VIM also has plugins for syntax highlighting,
> instant rendering, etc.
> It was also suggested to use Markdown for release notes.
>
> On Fri, Jul 17, 2020 at 5:12 PM Matias N.  wrote:
> >
> > No problem, just wanted to clear any possible confusion when considering
> the idea.
> >
> > On Fri, Jul 17, 2020, at 13:09, Maciej Wójcik wrote:
> > > Sure, Matias. I was not addressing your proposition in any way. I was
> just
> > > commenting on existing format of READMEs.
> > >
> > > I am neutral regarding separate repository with documentation. At
> least at
> > > the moment, I need to sleep with the idea (more).
> > >
> > > Some if not all READMES will stay in the repository and I was
> suggesting
> > > reformatting them.
> > >
> > > Am Fr., 17. Juli 2020 um 17:59 Uhr schrieb Matias N. :
> > >
> > > >
> > > > > What I think would be great, is to pick any of this two standards.
> > > >
> > > > What I was trying to convey in my previous e-mail is that we can
> choose
> > > > Markdown for READMEs (the prefered choice, IMHO) and either
> Markdown, RST,
> > > > or anything else for the eventual doc-repo. These are independent
> choices,
> > > > one does not have to affect the other. In fact, maybe RST is better
> for the
> > > > doc-repo, since it supports richer syntax more apropriate for
> building
> > > > documentation.
> > > >
> > > > Best,
> > > > Matias
> > >
>


-- 
Adam Feuer 

Re: Markdown READMEs?

[Abdelatif Guettouche]

It would be great to have READMEs in Markdown, as said before, it's
still plain text and can be rendered by other tools/websites.  Because
it was brought out, VIM also has plugins for syntax highlighting,
instant rendering, etc.
It was also suggested to use Markdown for release notes.

On Fri, Jul 17, 2020 at 5:12 PM Matias N.  wrote:
>
> No problem, just wanted to clear any possible confusion when considering the 
> idea.
>
> On Fri, Jul 17, 2020, at 13:09, Maciej Wójcik wrote:
> > Sure, Matias. I was not addressing your proposition in any way. I was just
> > commenting on existing format of READMEs.
> >
> > I am neutral regarding separate repository with documentation. At least at
> > the moment, I need to sleep with the idea (more).
> >
> > Some if not all READMES will stay in the repository and I was suggesting
> > reformatting them.
> >
> > Am Fr., 17. Juli 2020 um 17:59 Uhr schrieb Matias N. :
> >
> > >
> > > > What I think would be great, is to pick any of this two standards.
> > >
> > > What I was trying to convey in my previous e-mail is that we can choose
> > > Markdown for READMEs (the prefered choice, IMHO) and either Markdown, RST,
> > > or anything else for the eventual doc-repo. These are independent choices,
> > > one does not have to affect the other. In fact, maybe RST is better for 
> > > the
> > > doc-repo, since it supports richer syntax more apropriate for building
> > > documentation.
> > >
> > > Best,
> > > Matias
> >

Re: Markdown READMEs?

[Matias N.]

No problem, just wanted to clear any possible confusion when considering the 
idea.

On Fri, Jul 17, 2020, at 13:09, Maciej Wójcik wrote:
> Sure, Matias. I was not addressing your proposition in any way. I was just
> commenting on existing format of READMEs.
> 
> I am neutral regarding separate repository with documentation. At least at
> the moment, I need to sleep with the idea (more).
> 
> Some if not all READMES will stay in the repository and I was suggesting
> reformatting them.
> 
> Am Fr., 17. Juli 2020 um 17:59 Uhr schrieb Matias N. :
> 
> >
> > > What I think would be great, is to pick any of this two standards.
> >
> > What I was trying to convey in my previous e-mail is that we can choose
> > Markdown for READMEs (the prefered choice, IMHO) and either Markdown, RST,
> > or anything else for the eventual doc-repo. These are independent choices,
> > one does not have to affect the other. In fact, maybe RST is better for the
> > doc-repo, since it supports richer syntax more apropriate for building
> > documentation.
> >
> > Best,
> > Matias
> 

Re: Markdown READMEs?

[Maciej Wójcik]

Sure, Matias. I was not addressing your proposition in any way. I was just
commenting on existing format of READMEs.

I am neutral regarding separate repository with documentation. At least at
the moment, I need to sleep with the idea (more).

Some if not all READMES will stay in the repository and I was suggesting
reformatting them.

Am Fr., 17. Juli 2020 um 17:59 Uhr schrieb Matias N. :

>
> > What I think would be great, is to pick any of this two standards.
>
> What I was trying to convey in my previous e-mail is that we can choose
> Markdown for READMEs (the prefered choice, IMHO) and either Markdown, RST,
> or anything else for the eventual doc-repo. These are independent choices,
> one does not have to affect the other. In fact, maybe RST is better for the
> doc-repo, since it supports richer syntax more apropriate for building
> documentation.
>
> Best,
> Matias

Re: Markdown READMEs?

[Matias N.]

> What I think would be great, is to pick any of this two standards.

What I was trying to convey in my previous e-mail is that we can choose 
Markdown for READMEs (the prefered choice, IMHO) and either Markdown, RST, or 
anything else for the eventual doc-repo. These are independent choices, one 
does not have to affect the other. In fact, maybe RST is better for the 
doc-repo, since it supports richer syntax more apropriate for building 
documentation.

Best,
Matias

Re: Markdown READMEs?

[Maciej Wójcik]

Regarding Markdown:

I don't feel like I contribute here enough to have meaningful vote, but:

Readmes in Markdown are present in almost every GitHub, GitLab project. In
particular in almost every Python, Node.js, React/Angular/Vue project.

Also quiclky looking at some C projects
- https://github.com/lvgl/lvgl/blob/master/README.md
- https://github.com/ARMmbed/littlefs/blob/master/README.md
- https://github.com/warmcat/libwebsockets/blob/master/README.md

`.md` extension stands for Markdown.

It seems to be the de-facto standard.

> Plain text is the best on cmd line environments (ssh/putty)

Markdown is still a plain text.

> I would second that: (1) plain text with no embedded tags, and (2) no new
tools.

No new tools are required. The only difference is that some editors and
GitHub will display it in more readable way.

It is almost like the previous text format that is already in the repo, it
is just standardized and widely adopted.

Syntax is non intrusive. It clearly separates code fragments with
backticks. Renders headers and lists in a more readable way. Allows for a
table, image and clickable link from time to time.

It also allows separating code fragments and then it enables
syntax-highlighting. This improves readability greatly.

The format is actually simpler than the current one.


Regarding RST format:

It is a similar concept. It just seems to be a little bit more complex
to help writing documentation of code in larger projects. I am seeing it
for the first time, but I am also happy to help
with Adam Feuer effort if you would decide to use this one.


What I think would be great, is to pick any of this two standards. I was
trying to parse existing documentation how it is now and it is problematic.
The conventions
are not always followed and fragments of code randomly glue to text when I
am trying to retrieve paragraphs from it. My parsing issue is not relevant,
but standardization is important.
And Markdown is more readable, thanks to support from modern tools like
VSCode or GitHub/Lab. While still being readable in Vim through SSH.


Am Fr., 17. Juli 2020 um 16:49 Uhr schrieb Matias N. :

> Markdown is designed to be readable in plain-text.
> I think the only thing you could consider a special tag is how links are
> handled:
> [link text](url)
> linking to images is the same, with a prefix "!".
> Everything else is actually intuitive from looking at the text itself.
> Look here:
> https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet
>
> Regarding using READMEs as the backend for the main NuttX documentation,
> as I mentioned this is not the best idea because it would indeed require
> adding extra tags (like links to images, etc). READMEs should be used for
> technical information to be read when entering a subdirectory.
>
> On the other hand, Markdown or any other more complete format (like
> ReStructuredText) is a very good format for maintaining documentation
> outside of the main nuttx repo. In this case, a doc-repo with CI could be
> maintained, exactly the same as the nuttx website repo (in fact, it could
> be the same one). The website already requires ruby (jekyll) to be built.
>
> So, in summation:
> - I would use Markdown (without unnecessary tags) on the READMEs
> - I would start a doc repo (or reuse the website repo) and create a nice
> looking documentation (accessible as subdirectory or subdomain of nuttx
> website) based on Markdown or any other useful format and some website
> generator like readthedocs or whatever works best.
>
> Best,
> Matias
>
> On Fri, Jul 17, 2020, at 11:38, Alin Jerpelea wrote:
> > +1
> >
> > Plain text is the best on cmd line environments (ssh/putty)
> >
> > On Fri, Jul 17, 2020, 16:28 Gregory Nutt  wrote:
> >
> > >
> > > > Please make sure the readmes are still easily readable in vim and
> > > > other plain text editors.
> > > >
> > > > Plain text is good.
> > > >
> > > > underlined plain text interpreted by github is still readable
> (markdown?)
> > > >
> > > > anything that requires writing explicit tag in the readme text files
> > > > should be avoided imho.
> > > >
> > > >
> > > > also, anything that requires non-trivial tools for reading is to be
> > > > excluded.
> > > >
> > > > asciidoctor requires ruby
> > > >
> > > > Not sure that throwing more tools in the mix is even useful...
> > > >
> > > >
> > > > Sebastien
> > > I would second that:  (1) plain text with no embedded tags, and (2) no
> > > new tools.
> > >
> >
>

Re: Out of tree board definition

[Pavel Ionut]

Thank you. It works now.

Added.
CONFIG_ARCH_BOARD_CUSTOM=y
CONFIG_ARCH_BOARD_CUSTOM_NAME="xxx"
CONFIG_ARCH_BOARD_CUSTOM_DIR="../board"
CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y

Are these documented somewhere? I couldn't find anything searching
throughout the documentation. Maybe my search terms were wrong.
Also, this feature seems to be missing from ./configure.sh -h

Regards


On Fri, Jul 17, 2020 at 5:07 PM Gregory Nutt  wrote:

> On 7/17/2020 7:52 AM, Pavel Ionut wrote:
> > Hello,
> >
> > As i read in some posts and scrolled through configure.sh, it should be
> > possible to have a board definition outside the nuttx/boards/** location.
> >
> > My current setup is:
> > apps - (submodule)
> > nuttx - (submodule)
> > board - Makefile
> >- Make.defs
> >- defconfig
> >
> > However, if I do
> > cd nuttx
> > ./tools/configure.sh ../board
> > I get some errors, as it seems it still tries to get some files from
> > boards//**
> >
> > LN: include/arch/board to
> > //nuttx/boards//include
> > No directory at //nuttx/boards//include
> > tools/Makefile.unix:267: recipe for target 'include/arch/board' failed
> >
> > Regards
> >
> You did not define CONFIG_ARCH_BOARD_CUSTOM or CONFIG_ARCH_BOARD_CUSTOM_DIR
>
> This causes the wrong definition of BOARD_DIR in tools/Config.mk
>
> 140 ifeq ($(CONFIG_ARCH_BOARD_CUSTOM),y)<-- This was not defined
> 141 ifeq ($(CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH),y)
> 142   BOARD_DIR ?=
>
> $(TOPDIR)$(DELIM)$(CONFIG_ARCH_BOARD_CUSTOM_DIR)$(DELIM)$(CONFIG_ARCH_BOARD)
> 143 else
> 144   BOARD_DIR ?=
> $(CONFIG_ARCH_BOARD_CUSTOM_DIR)$(DELIM)$(CONFIG_ARCH_BOARD)
> 145 endif
> 146 else
> 147   BOARD_DIR ?=
> $(TOPDIR)$(DELIM)boards$(DELIM)$(CONFIG_ARCH)$(DELIM)$(CONFIG_ARCH_CHIP)$(DELIM)$(CONFIG_ARCH_BOARD)<--
>
> This was used
> 148 endif
>
> which, in turn causes the link to fail tools/Makefile.unix:
>
> 266 include/arch/board: include/arch
> 267 @echo "LN: include/arch/board to $(BOARD_DIR)/include"
> 268 $(Q) $(DIRLINK) $(BOARD_DIR)/include include/arch/board <--
> This fails
>
>

Re: Markdown READMEs?

[Matias N.]

Markdown is designed to be readable in plain-text.
I think the only thing you could consider a special tag is how links are 
handled:
[link text](url)
linking to images is the same, with a prefix "!".
Everything else is actually intuitive from looking at the text itself.
Look here: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet

Regarding using READMEs as the backend for the main NuttX documentation, as I 
mentioned this is not the best idea because it would indeed require adding 
extra tags (like links to images, etc). READMEs should be used for technical 
information to be read when entering a subdirectory.

On the other hand, Markdown or any other more complete format (like 
ReStructuredText) is a very good format for maintaining documentation outside 
of the main nuttx repo. In this case, a doc-repo with CI could be maintained, 
exactly the same as the nuttx website repo (in fact, it could be the same one). 
The website already requires ruby (jekyll) to be built.

So, in summation:
- I would use Markdown (without unnecessary tags) on the READMEs
- I would start a doc repo (or reuse the website repo) and create a nice 
looking documentation (accessible as subdirectory or subdomain of nuttx 
website) based on Markdown or any other useful format and some website 
generator like readthedocs or whatever works best.

Best,
Matias

On Fri, Jul 17, 2020, at 11:38, Alin Jerpelea wrote:
> +1
> 
> Plain text is the best on cmd line environments (ssh/putty)
> 
> On Fri, Jul 17, 2020, 16:28 Gregory Nutt  wrote:
> 
> >
> > > Please make sure the readmes are still easily readable in vim and
> > > other plain text editors.
> > >
> > > Plain text is good.
> > >
> > > underlined plain text interpreted by github is still readable (markdown?)
> > >
> > > anything that requires writing explicit tag in the readme text files
> > > should be avoided imho.
> > >
> > >
> > > also, anything that requires non-trivial tools for reading is to be
> > > excluded.
> > >
> > > asciidoctor requires ruby
> > >
> > > Not sure that throwing more tools in the mix is even useful...
> > >
> > >
> > > Sebastien
> > I would second that:  (1) plain text with no embedded tags, and (2) no
> > new tools.
> >
> 

Re: Markdown READMEs?

[Alin Jerpelea]

+1

Plain text is the best on cmd line environments (ssh/putty)

On Fri, Jul 17, 2020, 16:28 Gregory Nutt  wrote:

>
> > Please make sure the readmes are still easily readable in vim and
> > other plain text editors.
> >
> > Plain text is good.
> >
> > underlined plain text interpreted by github is still readable (markdown?)
> >
> > anything that requires writing explicit tag in the readme text files
> > should be avoided imho.
> >
> >
> > also, anything that requires non-trivial tools for reading is to be
> > excluded.
> >
> > asciidoctor requires ruby
> >
> > Not sure that throwing more tools in the mix is even useful...
> >
> >
> > Sebastien
> I would second that:  (1) plain text with no embedded tags, and (2) no
> new tools.
>

Re: Markdown READMEs?

[Gregory Nutt]

Please make sure the readmes are still easily readable in vim and 
other plain text editors.


Plain text is good.

underlined plain text interpreted by github is still readable (markdown?)

anything that requires writing explicit tag in the readme text files 
should be avoided imho.



also, anything that requires non-trivial tools for reading is to be 
excluded.


asciidoctor requires ruby

Not sure that throwing more tools in the mix is even useful...


Sebastien 
I would second that:  (1) plain text with no embedded tags, and (2) no 
new tools.

Re: Markdown READMEs?

[Sebastien Lorquet]

Please make sure the readmes are still easily readable in vim and other 
plain text editors.


Plain text is good.

underlined plain text interpreted by github is still readable (markdown?)

anything that requires writing explicit tag in the readme text files 
should be avoided imho.



also, anything that requires non-trivial tools for reading is to be 
excluded.


asciidoctor requires ruby

Not sure that throwing more tools in the mix is even useful...


Sebastien

Le 16/07/2020 à 17:56, Adam Feuer a écrit :

I like the idea of doing a ReStructured Text build in CI. I'd help convert
READMEs and other docs to RST. And I'd be willing to contribute the RST
docs I have already as a starting place if people are interested. They are
already Apache 2.0 Licensed.

-adam

On Thu, Jul 16, 2020 at 6:45 AM Matias N.  wrote:


Documenting boards using the README's in each subdirectory (by converting
them to Markdown and having them rendered somewhere) is indeed to most
direct approach. Although I would say it is an intermediate solution.

I think having an explicit repo holding documentation written in something
more powerful (ReStructured text, or whatever) would probably allow to get
better results. In this repo a CI system could use python or whatever
dependency necessary. No need to add build-dependencies to NuttX codebase
for that.

In that scenario, I would try to move most of the user-friendly
documentation towards that repo away from the board READMEs, leaving them
only with technical details that are better described there. I would still
use Markdown in that case, due to how GitHub renders them.

So, until something like that is done I think it would be appropriate to
move all READMEs to Markdown and have them available somewhere, but as I
mentioned, I think having a doc.nuttx.org site or something similar to
Zephyr's would really increase the user-friendliness of NuttX.

That said, I can help in both efforts, this is something I've been meaning
to work on for sometime and there was simply no infrastructure available at
the moment (that is why I worked on the NuttX GitBook but such effort is
definitely not for just one person).

Best,
Matias

On Thu, Jul 16, 2020, at 01:20, Adam Feuer wrote:

Zephyr uses Sphinx  and

ReStructured

Text (RST) for their docs.

I'm a

fan obviously, it's great for writing hyperlinked technical

documentation.

Sphinx requires Python, though.

The board list with pictures is a great idea, and I'd be willing to help
with it.

-adam

On Wed, Jul 15, 2020 at 9:11 PM Maciej Wójcik  wrote:


what do you think about using Markdown for README files?

Since the project was very conservative so far, I used regular

expression

to parse some existing files into Markdown. Although it is not

completely

reliable. I also think that markdown in repository would be great.

Even trying to sneak in some first Markdown file already :D



https://github.com/apache/incubator-nuttx-apps/blob/2fdd7529251919315bce62ceb0b130d7f135c506/graphics/lvgl/README.md

One of the reasons I really like the Zephyr docs...

Yes, it is also my impression. This is why I am trying to create
interactive documentation right now.

Kconfig NuttX data is extracted using the same library as Zephyr does.

Here are some existing READMES parsed into markdown
http://nuttx-config.nxtlabs.pl/#/apps. To be more specific
apps/*/README.txt files.

I would like to add boards section as well in form of tiles with

pictures

and board configuration support comparison inspired by this
https://node.green.

Complete tree of READMEs with a search is also in my mind
https://gitlab.com/nuttx-upm/kconfig-browser/web-ui/-/issues/25

How it works: currently there is a pipeline which runs for multiple
tags/branches (master, releases/9.1, releases/9.0, ...) and extracts

data

into static JSON. Then Vue.js application is trying to render it.

Pipeline

triggers automatically weekly to keep the master fresh.


Am Do., 16. Juli 2020 um 03:55 Uhr schrieb Matias N. :


On Wed, Jul 15, 2020, at 22:45, Brennan Ashton wrote:

I would be huge fan of this.  It makes it a lot more approachable,

I

had

started converting the main readme in particular but I did not get

very

far. It's a lot of work.

I can help with that if you want


Did you see Adams work here
https://nuttx-companion.readthedocs.io/en/latest/

I thought it would be really nice to integrate the board list with

the

readme content into it. (While keeping the content readable in the

source

control).

Yes, I was actually imagining some sort of CI command on the website

(not

sure the wiki handles that) that could build a list with all boards
containing a README, link to it and display it there nicely

formatted.

Something like readthedocs could possibly do it already, not sure.

One of the reasons I really like the Zephyr docs is because of this,

you

can see how they present their supported boards there

Re: oneshot or watchdog?

[Matias N.]

Hi,

On Fri, Jul 17, 2020, at 03:30, raiden00pl wrote:
>I think we should do it like in other BLE implementations for NRF52
> (SoftDevice, Zephyr) and use a combination of RTC and TIMER peripherals.
>There are quite a few places in the BLE protocol where we need to count
> the time in various ranges from seconds to mili-seconds.
>It is not possible to achieve this with just one timer device.

I'm not sure why a TIMER would be needed. Do you mean because of the RTC 
resolution?
The RTC is capable of us resolution with period of hundreds of seconds. The 
point is that RTC works
while MCU is sleeping so not depending on other peripherals means low-power 
mode could be entered while waiting for things eventually. I would personally 
use one timer until there's a specific need for other.

>There is only one watchdog instance and at least two RTC instances in
> the NRF52 chips.
>The watchdog timer should be left for user-specific applications.

Note that "watchdog" in NuttX context means different things: there's a 
"watchdog" interface which basically allows you to set a callback to be invoked 
after some duration. This works using the underlying system timer.
In other words, the "watchdog" interface in NuttX gives you access to the 
system timer, whereas the oneshot is a separate interface based on a separate 
harware resource.

>The system timer (SysTick) is not low-power friendly, so it is not
> suitable either.
>Ultimately, we should use the TICK event from RTC as the system clock.

Yes, RTC0 should be used for OS. My intention is to support what Xiang 
mentioned is the recommended approach for new boards, which would mean to 
implement an arch_timer.c compatible interface to RTC and then you get 
tick/tickless option automatically.

>Another thing is that we probably don't want to use the oneshot
> interface but instead work directly with the TIMER/RTC peripherals.
>In a few days I'll add PR with TIMER and RTC support.

Let's try to coordinate things since I'm actually working on the same code and 
I was even about to start working on RTC peripheral interface. My intention was 
to do the following:
- work on clockconfig to configure the LFCLK (wait for oscillator, etc)
- expose RTC peripheral with very basic interface

The following step would be to either create a oneshot driver interface for the 
RTC timer, so RTC1 could be used from Link-layer timeouts. Otherwise I could 
simply use the system timer using NuttX watchdog interface. That was my 
original question. Since you mention that maybe two timers are needed, that 
enforces my idea that at least one oneshot timer is needed (for the TIMER 
peripheral).

And FYI, I'm slowly building up a Bluetooth link-layer by defining what would 
be an upper-half part that implement most of the arch-independant parts of the 
low-level BLE protocol handling, next to a lower-half interface which allows 
the upper-half to communicate with the arch-dependant part. This means that 
besides the arch-independant link-layer, I'm writing an implementation for the 
lower-half which calls into nrf52_radio.h functions.

I don't have this pushed anywhere yet since I don't even have the hardware to 
test it, but I'm slowly advancing. I was just at the point of needing to design 
how the timing part would work on the LL.

Best,
Matias

> pt., 17 lip 2020 o 04:40 Matias N.  napisał(a):
> 
> > Hi,
> > I'm working on a BLE Link Layer for NuttX, which sits between HCI layer
> > and low-level radio-layer. I'm starting with BLE scanning and I need to set
> > a timer to periodically execute the radio reception to listen for
> > advertisements. I'm trying to see which interface should this layer use:
> > oneshot or watchdog? From what I understand, the oneshot would use a
> > separate timer that of the system timer. I can only think of that
> > difference, is there other?
> > In any case, I'm not sure what would be desireable to use for this. I like
> > the simplicity of the watchdog (nothing to implement) but maybe it is
> > better to use a separate timer?
> >
> > At the hardware level, the NRF52832 is already designed to have two
> > identical hardware timers, one usually used for the OS and the other for
> > handling BLE timeouts, so maybe using a oneshot on the second timer is most
> > apropriate.
> >
> > What do you think?
> >
> > Best,
> > Matias
> 

Re: Out of tree board definition

[Gregory Nutt]

On 7/17/2020 7:52 AM, Pavel Ionut wrote:

Hello,

As i read in some posts and scrolled through configure.sh, it should be
possible to have a board definition outside the nuttx/boards/** location.

My current setup is:
apps - (submodule)
nuttx - (submodule)
board - Makefile
   - Make.defs
   - defconfig

However, if I do
cd nuttx
./tools/configure.sh ../board
I get some errors, as it seems it still tries to get some files from
boards//**

LN: include/arch/board to
//nuttx/boards//include
No directory at //nuttx/boards//include
tools/Makefile.unix:267: recipe for target 'include/arch/board' failed

Regards


You did not define CONFIG_ARCH_BOARD_CUSTOM or CONFIG_ARCH_BOARD_CUSTOM_DIR

This causes the wrong definition of BOARD_DIR in tools/Config.mk

140 ifeq ($(CONFIG_ARCH_BOARD_CUSTOM),y)<-- This was not defined
141 ifeq ($(CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH),y)
142   BOARD_DIR ?= 
$(TOPDIR)$(DELIM)$(CONFIG_ARCH_BOARD_CUSTOM_DIR)$(DELIM)$(CONFIG_ARCH_BOARD)

143 else
144   BOARD_DIR ?= 
$(CONFIG_ARCH_BOARD_CUSTOM_DIR)$(DELIM)$(CONFIG_ARCH_BOARD)

145 endif
146 else
147   BOARD_DIR ?= 
$(TOPDIR)$(DELIM)boards$(DELIM)$(CONFIG_ARCH)$(DELIM)$(CONFIG_ARCH_CHIP)$(DELIM)$(CONFIG_ARCH_BOARD)<-- 
This was used

148 endif

which, in turn causes the link to fail tools/Makefile.unix:

266 include/arch/board: include/arch
267 @echo "LN: include/arch/board to $(BOARD_DIR)/include"
268 $(Q) $(DIRLINK) $(BOARD_DIR)/include include/arch/board <-- 
This fails

Out of tree board definition

[Pavel Ionut]

Hello,

As i read in some posts and scrolled through configure.sh, it should be
possible to have a board definition outside the nuttx/boards/** location.

My current setup is:
apps - (submodule)
nuttx - (submodule)
board - Makefile
  - Make.defs
  - defconfig

However, if I do
cd nuttx
./tools/configure.sh ../board
I get some errors, as it seems it still tries to get some files from
boards//**

LN: include/arch/board to
//nuttx/boards//include
No directory at //nuttx/boards//include
tools/Makefile.unix:267: recipe for target 'include/arch/board' failed

Regards

Re: [nuttx][avr] Issues while building avr (atmega) board example.

[Pavel Ionut]

Asked Microchip if they will/already provide these without a wall (like ARM
does).
Waiting for a response before going further.

BR

On Fri, Jul 17, 2020 at 10:06 AM Xiang Xiao 
wrote:

> Traditionally, the 3rd party tool put here:
> https://bitbucket.org/nuttx/
> Since the code base is moved to github after NuttX join Apache Foundation,
> there are a discussion to put the 3rd party tool here:
> https://github.com/NuttX
>
> > -Original Message-
> > From: Adam Feuer 
> > Sent: Friday, July 17, 2020 3:35 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: [nuttx][avr] Issues while building avr (atmega) board
> example.
> >
> > Could we put the compilers in a private repository or web server? Maybe
> Apache has solved this problem before.
> >
> > -adam
> >
> > On Thu, Jul 16, 2020 at 12:21 PM Pavel Ionut <
> pavel.ionut.catalin...@gmail.com> wrote:
> >
> > > Also, regarding the CI stuff.
> > >
> > > Seems like Microchip has the official compiler(s) download links under
> > > a
> > > (login) wall.
> > > What would be the approach in this case (so that the compilers could
> > > be downloaded by the CI scripts)?
> > > There are various binaries scattered across the internet, but I guess
> > > the official releases would be desirable.
> > >
> > > Regards.
> > >
> > > On Thu, Jul 16, 2020 at 8:15 PM Pavel Ionut <
> > > pavel.ionut.catalin...@gmail.com> wrote:
> > >
> > > > Hello,
> > > >
> > > > I created a PR for the build issue.
> > > > Will have a go at the CI stuff.
> > > >
> > > > Regards.
> > > >
> > > > On Thu, Jul 16, 2020 at 5:48 PM Xiang Xiao
> > > > 
> > > > wrote:
> > > >
> > > >>
> > > >>
> > > >> > -Original Message-
> > > >> > From: Pavel Ionut 
> > > >> > Sent: Wednesday, July 15, 2020 6:48 PM
> > > >> > To: dev@nuttx.apache.org
> > > >> > Subject: [nuttx][avr] Issues while building avr (atmega) board
> > > example.
> > > >> >
> > > >> > Hello,
> > > >> >
> > > >> > Basically I'm trying to build the moteino-mega board example and
> > > >> > I
> > > >> found some issues.
> > > >> > I have prepared a fix for all of these issues, but first of all I
> > > >> > want
> > > >> your opinion on one of the issues.
> > > >> >
> > > >>
> > > >> It will be great if you can take some time to enable the build
> > > >> check for AVR, so we can avoid the build break in the feature. Only
> > > >> three files
> > > need
> > > >> to change:
> > > >>
> > > >>
> > > https://github.com/apache/incubator-nuttx-testing/blob/master/testlist
> > > /all.dat
> > > >>
> > > https://github.com/apache/incubator-nuttx-testing/blob/master/cibuild.
> > > sh
> > > >>
> > > >>
> > > https://github.com/apache/incubator-nuttx-testing/blob/master/docker/l
> > > inux/Dockerfile
> > > >>
> > > >> > Seems like the linux avr-gcc does not include double_t as a type
> > > inside
> > > >> the compiler provided , and double_t is used inside
> > > >> > the libs and the build fails.
> > > >> >
> > > >> Yes, the change Is made in the recent commit:
> > > >> commit d17b963bcab98e2d2f641623547837a8d3fe94cd
> > > >> Author: Xiang Xiao 
> > > >> Date:   Sun Jun 28 14:04:30 2020 +0800
> > > >>
> > > >> libc: Move double_t typedef from sys/types.h to math.h
> > > >>
> > > >> specified here:
> > > >>
> > > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/math.h.html
> > > >>
> > > >> Signed-off-by: Xiang Xiao 
> > > >> Change-Id: I3497a73908301d999cf1cfc4a66552a7ca4868c6
> > > >> Before this commit, double_t is defined in include/sys/types.h, but
> > > >> we found that this definition may different from the toolchain's
> > > >> one, so
> > > this
> > > >> patch move the definition into include/nuttx/lib/math.h. Both case
> > > >> work correctly(no mismatch) until your case:
> > > >> 1.double_t come from include/nuttx/lib/math.h when we enable
> > > >> NuttX's
> > > libm
> > > >> 2.double_t come from toolchain's math.h when we enable toolchain's
> > > >> libm
> > > >>
> > > >> > One possible fix (currently using) is to typedef it inside
> > > >> > compiler.h
> > > >> (for the AVR compiler), however, I don't know if this would be
> > > >> > correct since I see no other typedefs inside that file.
> > > >> >
> > > >>
> > > >> Another place is arch/avr/include/types.h, all arch specific types
> > > >> definition come from here.
> > > >>
> > > >> > Regards
> > > >>
> > > >>
> > >
> >
> >
> > --
> > Adam Feuer 
>
>

RE: [nuttx][avr] Issues while building avr (atmega) board example.

[Xiang Xiao]

Traditionally, the 3rd party tool put here:
https://bitbucket.org/nuttx/
Since the code base is moved to github after NuttX join Apache Foundation, 
there are a discussion to put the 3rd party tool here:
https://github.com/NuttX

> -Original Message-
> From: Adam Feuer 
> Sent: Friday, July 17, 2020 3:35 AM
> To: dev@nuttx.apache.org
> Subject: Re: [nuttx][avr] Issues while building avr (atmega) board example.
> 
> Could we put the compilers in a private repository or web server? Maybe 
> Apache has solved this problem before.
> 
> -adam
> 
> On Thu, Jul 16, 2020 at 12:21 PM Pavel Ionut < 
> pavel.ionut.catalin...@gmail.com> wrote:
> 
> > Also, regarding the CI stuff.
> >
> > Seems like Microchip has the official compiler(s) download links under
> > a
> > (login) wall.
> > What would be the approach in this case (so that the compilers could
> > be downloaded by the CI scripts)?
> > There are various binaries scattered across the internet, but I guess
> > the official releases would be desirable.
> >
> > Regards.
> >
> > On Thu, Jul 16, 2020 at 8:15 PM Pavel Ionut <
> > pavel.ionut.catalin...@gmail.com> wrote:
> >
> > > Hello,
> > >
> > > I created a PR for the build issue.
> > > Will have a go at the CI stuff.
> > >
> > > Regards.
> > >
> > > On Thu, Jul 16, 2020 at 5:48 PM Xiang Xiao
> > > 
> > > wrote:
> > >
> > >>
> > >>
> > >> > -Original Message-
> > >> > From: Pavel Ionut 
> > >> > Sent: Wednesday, July 15, 2020 6:48 PM
> > >> > To: dev@nuttx.apache.org
> > >> > Subject: [nuttx][avr] Issues while building avr (atmega) board
> > example.
> > >> >
> > >> > Hello,
> > >> >
> > >> > Basically I'm trying to build the moteino-mega board example and
> > >> > I
> > >> found some issues.
> > >> > I have prepared a fix for all of these issues, but first of all I
> > >> > want
> > >> your opinion on one of the issues.
> > >> >
> > >>
> > >> It will be great if you can take some time to enable the build
> > >> check for AVR, so we can avoid the build break in the feature. Only
> > >> three files
> > need
> > >> to change:
> > >>
> > >>
> > https://github.com/apache/incubator-nuttx-testing/blob/master/testlist
> > /all.dat
> > >>
> > https://github.com/apache/incubator-nuttx-testing/blob/master/cibuild.
> > sh
> > >>
> > >>
> > https://github.com/apache/incubator-nuttx-testing/blob/master/docker/l
> > inux/Dockerfile
> > >>
> > >> > Seems like the linux avr-gcc does not include double_t as a type
> > inside
> > >> the compiler provided , and double_t is used inside
> > >> > the libs and the build fails.
> > >> >
> > >> Yes, the change Is made in the recent commit:
> > >> commit d17b963bcab98e2d2f641623547837a8d3fe94cd
> > >> Author: Xiang Xiao 
> > >> Date:   Sun Jun 28 14:04:30 2020 +0800
> > >>
> > >> libc: Move double_t typedef from sys/types.h to math.h
> > >>
> > >> specified here:
> > >>
> > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/math.h.html
> > >>
> > >> Signed-off-by: Xiang Xiao 
> > >> Change-Id: I3497a73908301d999cf1cfc4a66552a7ca4868c6
> > >> Before this commit, double_t is defined in include/sys/types.h, but
> > >> we found that this definition may different from the toolchain's
> > >> one, so
> > this
> > >> patch move the definition into include/nuttx/lib/math.h. Both case
> > >> work correctly(no mismatch) until your case:
> > >> 1.double_t come from include/nuttx/lib/math.h when we enable
> > >> NuttX's
> > libm
> > >> 2.double_t come from toolchain's math.h when we enable toolchain's
> > >> libm
> > >>
> > >> > One possible fix (currently using) is to typedef it inside
> > >> > compiler.h
> > >> (for the AVR compiler), however, I don't know if this would be
> > >> > correct since I see no other typedefs inside that file.
> > >> >
> > >>
> > >> Another place is arch/avr/include/types.h, all arch specific types
> > >> definition come from here.
> > >>
> > >> > Regards
> > >>
> > >>
> >
> 
> 
> --
> Adam Feuer