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
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
> 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
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
> 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
> 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
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,
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
>
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
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
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
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
> 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
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
-
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
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:
+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
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,
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,
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
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
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
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
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,
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
25 matches
Mail list logo
