So this sounds like a new stm32g4 subdirectory would be beneficial.
You would have to know how pervasive the differences between the chips
are. The STM32F0 cohabitates quite nicely with G0 and L0, for example.
If, for example, all of the peripherals are the same, but there is a
This helps clarify the families: https://en.wikipedia.org/wiki/STM32
"The STM32 F3-series is the second group of STM32 microcontrollers based
on the ARM Cortex-M4F core. The F3 is almost pin-to-pin compatible with
the STM32 F1-series. ...
"The STM32 F2-series of STM32 microcontrollers based
This document address migration from F1 to F3 and addresses all major
differences between F1 and F3: AN4228, Application note, Migrating from
STM32F1 Series to STM32F3 Series microcontrollers. Table 6 address every
peripheral.
On 4/15/2020 1:51 PM, Gregory Nutt wrote:
This helps clarify the families: https://en.wikipedia.org/wiki/STM32
"The STM32 F3-series is the second group of STM32 microcontrollers
based on the ARM Cortex-M4F core. The F3 is almost pin-to-pin
compatible with the STM32 F1-series. ...
"
Maybe I am just a simple soul .but the root concept is (seems to be) shared memory. Memory which is some
sort of "topic" where an MCU is a "subscriber" and where there is some sort of
"applicational" orchestration. A kafka bus on memory
I think I am getting it, but where I am
One thing you can do to keep prevent the runaway dependencies on
specific chips is to parameterized the features. For example, if
STM32abc, STM32def, and STM32ghi and have FEATURE_X, then instead of
conditioning the implementation of FEATURE_X on all of those MCUs, you
could minimize the
So what's the deciding factor? Should this be in 'stm32' directory
because most peripherals have compatibility? Or a different directory
because RCC is different?
The deciding factor should be maintainability.
I have not heard any reason why the support should not go under stm32/.
Mu only
The final tag should have a format similar to the old one: nuttx-9.0.0
(or nuttx-9.0.0-rc1 for an RC)
The version.sh script needs the "-" to parse the tag.
It would seem that if we wanted to make an April 30 release, we should
create the tarball now and ask for beta testers. Or do you have
Perhaps we could get Greg's input, as far as steps did you take when
making tarballs for earlier releases? It will, of course, be important
that we document what we do as well as possible.
Yes, I have a check list. it is a spreadsheet, so I cannot attach it
for distribution. I gave a copy
I wonder if there's a reason it has to be a spreadsheet?
You are welcome to do anything that you would like with the file.
Thanks. I haven't actually seen the file but we'll try to figure out as a
community what's the best way to document, or better yet, automate as many
steps as possible,
I wonder if there's a reason it has to be a spreadsheet?
You are welcome to do anything that you would like with the file.
In the past, we talked about not all changes being equal and that
changes within some directories are more sensitive than changes to
others. We discussed the notion of an "owner" of each top level
directory that needed to approve any changes to those directories.
Nathan was the primary
One thing we can do is automatically apply labels to pull requests via the
CI system. So if something changes in certain folder gets a multiple
reviewer label and a comment in the PR.
Still a social solution, but I think it would nudge people into the right
direction.
I like the idea.
Just to clarify:
I don't support that specific people should "own" a directory or
section of code,
Poor choice of words on my part. I seem to pick words that trigger the
wrong responses. We are in agreement int the concept. By "own", I
meant in the sense that businesses use the term:
The only project I know that does something similar (successfully) is
subversion and it's by social convention.
Social conventions would be the preferred way to handle this. But that
requires some education for all committers to understand and support
those conventions. That can be
Just to clarify:
I don't support that specific people should "own" a directory or
section of code,
Poor choice of words on my part. I seem to pick words that trigger
the wrong responses. We are in agreement int the concept. By "own",
I meant in the sense that businesses use the term:
I agree that we should not let trivial cosmetic things onto the release
branch. We should only permit showstopping, critical bugfixes onto the
release branch. It is probably a fair comment that we brought too much
unimportant stuff in and the confuses things. Let's add that to the
TIL:
For future 2-month releases, I think that on the branch date, we
should branch and immediately make -rc1 tarballs.
Then the community can test, report bugs/showstoppers, and those will
be fixed on master and backported to the branch.
When it seems there are no more showstoppers, make -rc2
Didn't quite understood what you mean by "crappy" driver interface.
My object is to support the core NuttX graphics system. Not user
kludges to get low level access to drivers. That is unimportant because
it is not on the OS roadmap. It was a mistake to create those userspace
drivers in
That would indeed work as well. I did not suggest it to avoid modifying
semantics of an existing call.
It should work on most but not all LCDs. It should work on LCDs where
the run is simply writing pixels into a graphics memory. But there are
other LCDs that have to do other,
When we do a release, the zipme script creates a proper version of the
.version file. This later becomes the version.h header file and is used
in several places:
1. NSH Greeting
2. libcurl (OS identity)
3. webserver (OS identity)
4. procfs version file
5. uname OS version number
The .version
I wouldn't hold up the release because of such issues. First, it is
getting better consideration than when I did the job all by myself.
It is already and improvemtn. And second, as you say, it is a
learning experience. Let's get the job done for better or worse,
create a TIL and get
But how we describe 9.0 release? Most people will ask two questiones:
1.When(or commit id) the release branch out from master
We know this from the branch creation
2.Which patch we cherry-pick from master after the branch is created
This we can get from the pose branch PRs
and then the
I think if everybody send it as SVG we couldn't have any issue. And
because SVG is a common standard all good graphic design software
supports it.
That is unnecessary. SVG will only be required for the single graphic
that is selected for the logo. It is not needed for any of the others.
Before we vote, how about we rebase the release/9.0 to the latest
master? There still have many difference between master and
release/9.0:
If we rebase, we would have to update the release notes and related
documentation again. You have to freeze the code somewhere; there will
always be
If we rebase, we would have to update the release notes and related
documentation again. You have to freeze the code somewhere; there
will always be things that are omitted from the release that will have
to wait until the next release. I would vote that we not rebase the
release branch.
when working with some LCDs (such as SSD1306 or Sharp Memory LCD) via the LCD
driver interface, the putrun() method greatly limits the speed at which you can
update the screen, since it imposes one I2C/SPI transfer per putrun(). This
type of graphical LCDs typically support sending a
On 4/20/2020 8:45 AM, Gregory Nutt wrote:
when working with some LCDs (such as SSD1306 or Sharp Memory LCD) via
the LCD driver interface, the putrun() method greatly limits the
speed at which you can update the screen, since it imposes one
I2C/SPI transfer per putrun(). This type
The difference between commit id or order make the user life even more harder.
The release tarballs have no GIT information in them. That information
is available on the branch, but AFAIK all users of releases use the
tarballs with no git information. Only the release notes describes
With this in mind and with the suggestion from Brennan, the branch
would be "releases/9.0.0"
There there would be tags on the branch to differentiate 9.0.1 from
9.0.2? and from release candidates?
So would the branch name releases/9.0 still be OK? The tags on the
branch would pick up
Yes, OpenAMP still here on NuttX and AFAIK everything is fine.
But I think OpenAMP is not feasible for this scenario where you have
two isolated boards, but Xiang could tell us, he and his team
integrated it on NuttX.
Assumed that the poster was referring to the many processors with
Yeah I thought about the too
But think of the can of worm on the commit history: Every PR touches the cfg
file.
I don't see that. Modifications to the white list file, whatever it is
called, would be very rare. Only when a new non-compliant name is added
which should be never.
We
How about we put this special treatment to another file(e.g.
nxstyle.cfg)? So we don't pollute the source code.
+1 I like it. I just suggested basically the same think in the PR. I
suggested the name .nxignore.
If a .nxignore file exists in the same directory as the file under test,
Sounds like it needs to call nxsig_wait_uninterruptible instead of
nxsig_wait somewhere in sched/pthread/
On 3/13/2020 3:59 PM, Nathan Hartman wrote:
According to the description of pthread_mutex_lock() (in the
function's comment block):
"If a signal is delivered to a thread waiting for a
On 3/13/2020 4:00 PM, Gregory Nutt wrote:
Sounds like it needs to call nxsig_wait_uninterruptible instead of
nxsig_wait somewhere in sched/pthread/
s/nxsig_wait/nxsem_wait/g
The calling sequence is:
libs/libc/phthread:pthread_mutex_lock() ->
sc
If pthread_mutex_timedlock() would call pthread_mutex_take() with a
intr value of false, instead of true as it is doing now, that would
cause pthread_sem_take() to call nxsem_wait_uninterruptible().
But, I am *not* rushing to change this, because I don't know what else
it might affect (and
.
- The timed wait will be awakened with a particular signal, but it could
also be awakened if an unrelated signal is received. Should there be a
signprocmask() to block other signals while waiting?
Greg
On 3/13/2020 4:34 PM, Nathan Hartman wrote:
On Fri, Mar 13, 2020 at 6:17 PM Gregory Nutt wrote
I did this manually when I ran the build tests myself: I just
kept the last good test log and diff'ed the current test log with that
known good log. Any new warnings would show up in the diffs. The
tricky part is that there is a lot of other kruft that shows up in the
diffs too
I would suggest you report this month otherwise you’ll be asked to report again
next month.
I imagine that if we report no progress this month, we would be asked to
report again next month too, right?
The hope and the plan is that we will be able to report the first
release and well as
I also took a look at the coding standard guide to make sure I was in
compliance, but I'm unsure of where I should put the 'do'
#define mpu_priv_stronglyordered(base, size) do \
{ \
/* The configure the region */ \
== OR ==
#define mpu_user_flash(base, size) \
do { \
/* The configure
Do we have a platform-independent way to detect whether the NuttX
distribution is a git clone or not?
Yes, just do a check if the directory at $TOPDIR/.git exists.
Also, doesn't 'make distclean' clean in apps as well as nuttx? Because
I think 'git cleanup' won't clean apps.
It will also
You should open an issue, or better, push a PR.
On 4/2/2020 5:50 PM, Nathan Hartman wrote:
Hi all,
I didn't catch this before the PR was merged, so apologies for being
slightly late...
Regarding commit 27142b2e3c4c6498dc198818ec9b260d812f, this means
that tools/testbuild.sh now depends on
I opened issue #698 -- https://github.com/apache/incubator-nuttx/issues/698.
Issues are good. Someday they will be fixed but it might be weeks or
months. If you really want a quick turnaround, a PR (or patch) is the
only way to do that.
1. For each chip, files that include mpu support need to add a
conditional to two included files
#ifdef CONFIG_ARM_MPU
# include "mpu.h"
# include "_mpuinit.h"
#endif
Wouldn't it make more sense to put #ifdef CONFIG_ARM_MPU inside of mpu.h
and _mpuinit.h. That way, the problem is fixed
I notice that TizenRT which uses an old, highly modified version of
NuttX, has added ARMv8-M support:
https://github.com/Samsung/TizenRT/tree/master/os/arch/arm/include/armv8-m
https://github.com/Samsung/TizenRT/tree/master/os/arch/arm/src/armv8-m
My recommendations (pending input from the community of course) are:
Do we plan to generate Release Notes? In my experience that is the most
difficult part of the release (the rest is fun). Abdelatif tells me that
there are 1051 commits. That is a much lower number that I expecteded,
The organization of the release notes is fine, it is just making the
level of effort needed to produce them manageable. This begs for some
kind of tooling
There is tools/logparser.c, but it was designed specifically to convert
the git log into the format used in the ChangeLog. It is
The release notes really want to be in source control,
That is the reason that I always kept the ReleaseNotes in the
repository. Then there is no possibility that the ReleaseNotes can ever
become decouple from the release even after years and changes in ISPs.
That is the same reason
I think we need to keep the release notes, they help people understand
why they would want to upgrade.
Let's make them succinct, however. I like the list of major parts,
maybe we can add "Boards" to "Architecture Support" and add another
part for other subsystems like, crypto, graphics, net,
these configs have the following default values:
CONFIG_SMP_IDLETHREAD_STACKSIZE=2048
CONFIG_IDLETHREAD_STACKSIZE=1024
is there any rationale of these values?
the kconfig help text seems to suggest the opposite; the SMP one
should be smaller.
Partially. Yes, there is a reason for
Hi, list,
This is something that I wanted to add to the incubator-nuttx-testing,
but it appears that no issues are supported in that repository. That is
a problem; issues should be enabled for the testing repository as well.
Anyway...
I was looking at some successful logs from recent
I was able to do this once before:
#if !defined(TODO)
# if !defined(NO_PRINT_TODOS)
# define DO_PRAGMA(x) _Pragma (#x)
# define TODO(x) DO_PRAGMA(message ("TODO - " #x))
# else
# define TODO(x)
# endif
#endif
IIRC it allowed me to print compiler output that was not treated as warnings
Almost warning come from #warning, we can:
1.Add -Wno-cpp to disable #warning for precheck/nightly build:
https://stackoverflow.com/questions/9793293/how-do-i-disable-warning-message-in-gcc
2.Fix the remaining real warnning
3.Enable -Werror for precheck/nightly build
The suggestion from
Bumping this up. It seems like we need a plan to tackle going through the
613 closed PRs and summarizing (only merged ones need to be summarized).
This would be easier with a team of people... anyone want to help?
One way we could do this is one group take bug fixes, and another take
On 4/2/2020 1:04 PM, Gregory Nutt wrote:
Bumping this up. It seems like we need a plan to tackle going through
the
613 closed PRs and summarizing (only merged ones need to be summarized).
This would be easier with a team of people... anyone want to help?
One way we could do this is one group
+1
Its been a long time coming!
On 4/28/2020 12:06 AM, Brennan Ashton wrote:
Hello all,
Apache NuttX (Incubating) 9.0.0 has been staged under [1] and it's time to
vote
on accepting it for release. If approved we will seek final release
approval
from the IPMC. Voting will be open for 72hr.
> The maintainer still can create a new branch and push to that branch
directly, only the master branch get the strict protection. The setting
must be done by INFRA team, I can raise a JIRA ticket if the community
agree that it's the right direction to go.
How would we perform development on
I am looking at this merge in the incubator master
https://github.com/apache/incubator-nuttx/commit/434086ff935a760d274518d79d2abcf99294fc6f
along with three additional commits.
These appear to have gone directly to incubator_nuttx/master without
going through a PR. Was this a mistake?
The PR come from Juha:
https://github.com/apache/incubator-nuttx/pull/892
Juha's PR looks clean to me.
But this PR just change the code under libs/libc/netdb, I don't know
why the commit log show:
arch/mips/src/pic32mz/pic32mz_oneshot-lowerhalf.c is deleted
Hi, Xiang,
I am look at this merge in the incubator master
https://github.com/apache/incubator-nuttx/commit/434086ff935a760d274518d79d2abcf99294fc6f
along with three additional commits.
These appear to have go directly to incubator_nuttx/master without going
through a PR. Was this a
Yes, here is the PR I sent from my openamp branch:
https://github.com/apache/incubator-nuttx/pull/894
But merged by you two hour ago.
Do you select "Create a merge commit" or "Rebase and merge"?
I always select rebase and merge, but it is hard to construct what
happened in the past from the
He can also see all of the merges made earlier in the day, include the
merge of Juha's PR. They did not cause the problem. This one direct
merge to incubator_nuttx caused the wild merge messages and the
duplicate commits:
On 4/27/2020 9:37 AM, Gregory Nutt wrote:
... it is hard
... it is hard to construct what happened in the past from the present.
I forget about the commit messages. This makes it clear exactly what
happened
(https://mail-archives.apache.org/mod_mbox/nuttx-commits/202004.mbox/browser):
From xiaoxi...@apache.org
Subject
Makes sense. Maybe we can create a test dat file for the windows builds
that only targets the sim configs we care about? Maybe another for a
set of
ARM targets? Thanks for helping me understand what's going on.
I think we should have wpcap working windows. It is an important
feature
Yes! Should I do the same workaround as Greg mentions there, namely to
add an additional "Included Files" section for the conditional
includes?
We have just been ignoring this style error in previous PRs.
If you want someone to ignore and nxstyle complaint, I think the the
etiquette is to
Makes sense. Maybe we can create a test dat file for the windows builds
that only targets the sim configs we care about? Maybe another for a set of
ARM targets? Thanks for helping me understand what's going on.
I think we should have wpcap working windows. It is an important
feature and
In arch/arm/src/stm32/Kconfig, config ARCH_CHIP_STM32F303RD and config
ARCH_CHIP_STM32F303RE each appear twice. I think this is an error?
I haven't looked, but once is certainly enough. A PR is probably in order.
I have a WIP CI run on my fork for Windows using Cygwin (it a bit ugly
right now), but it has a fair amount of sim builds failing. Could someone
take a look. I'll put a draft PR up tonight for CI but for now this is what
I have.
I recently started playing with the Core746I board from waveshare.
It is quite different from the stm32f746g-disco.
Seeveral IO are differently, the SDRAM is connected to bank 2, it
has a different xtal.
The stm32f746-ws looks like it could be for the waveshare board.
At least the PLL setup
Windows have many atlernative: Cygwin, MSYS2, WSL and Native. We need
select one(less setup, more stable and community favor) to avoid the
user lose the focus. It will be great if the selected platform can
build and test on Linux/macOS/WIndows.
Regarding Windows, I think Native is the best
In several places, the top-level README.txt mentions a specially
modified version of the kconfig-frontends tool that can be used on
Native Windows and provides a link:
http://uvc.de/posts/linux-kernel-configuration-tool-mconf-under-windows.html
There is a more recent port here:
nuttx$ cat .config | grep MKRD
CONFIG_BOARDCTL_MKRD=y
CONFIG_DRVR_MKRD=y
# CONFIG_NSH_DISABLE_MKRD is not set
NuttShell (NSH) NuttX-8.2.0
nsh> help
help usage: help [-v] []
[ cdecho help mkdir pwd sleep
unset
? cpexec hexdump
Given that we have been trying unsuccessfully to get an SGA from NXP
This I think in the issue why are they not willing to do this?
From my understanding, it is just the slow wheels of corporate legal
departments. In my experience, legal departments just see no win to
giving up rights.
I would love it if we could merge the code soon.
It does have a limited shelf life, if we don't get it in place to it
will be a waste of a real effort and probably the most major
contribution every made to Apache NuttX.
I, too, would like to hear from our mentors regarding the licensing.
Merge the SocketCAN branch onto master. I don't think any further
review or checks are required (but ARE certainly welcome). All of the
PRs used to create the SocketCAN branch were previously reviewed and
the merge is very low risk since it should, in principle, effect only
the SocketCAN
There is a LOT of third party code in the Mynewt repositories.
Having 3rd party code that is under a compatible license is OK, but the ASF
likes to go a step further and know that the owner is OK with this. The ASF
doesn’t take code without permission or make hostile forks of projects.
As most of you know, there is a branch called SocketCAN in the
incubator_nuttx repository. This branch holds a port of port of VW's
socket CAN plus NXP copyrighted files. All are BSD licensed (the VW
code is dual licensed) and compatible with the Apache 2.0 license.
The code is stuck on
From my understanding, it is just the slow wheels of corporate legal
departments. In my experience, legal departments just see no win to giving up
rights.
If they don’t want to give the rights to us to use it, do we actually have the
rights to use it? (Despite what the license may say)
wrote:
That's unfortunate. Hopefully he is still reachable at that email.
What options should I present to him if I do get in touch with him?
John
On 5/1/20 3:02 PM, Gregory Nutt wrote:
Since no new files are allowed to come into the repo without ASF
licenses, I need some direction on how I
Since no new files are allowed to come into the repo without ASF
licenses, I need some direction on how I should go about re-licensing
two of the files for this driver. The files in question are
arch/arm/src/stm32f7/stm32_can.h -- This is only copyrighted by Greg.
Greg, do I have your
I've followed a few of the conversations on here regarding licensing
and have been a confused as well. It seems like there are a few
options, so I want to make sure I do things right.
I'll wait for a mentor to chime in when they have a chance. I'm not
ready to merge yet anyways; I just
Commit a86884c615429f837285e214cbfb05a49a725336 adds file:
arch/arm/src/armv8-m/doit.sh
Was that intended to be added?
Nope it stuck in. I'll submit a PR to remove it. ...
PR 942 if you would be so kind to merge.
Previously at some point, we discussed optionally putting a short (one
line) description of a file's purpose somewhere in or near the Apache
header. Where did we decide to put that (if we decided)?
Thanks,
Nathan
No sure what happen, maybe I push the wrong remote git? Does github
have any configuration to enforce all merge must come from web UI?
In this case, AFAIK no harm was done. A little bit a odd history was
added but no file changes. So I think we are good. We do need to be
careful; all of
We are facing issue of hang when powering up board and target simultaneously.
We have debugged and observed that it is hanging at nxsem_wait(sem) during auto
ip configuration by dhcp where waiting for
offer repsonse corresponding to dhcp_request at lock nxsem_wait(sem). This lock
is not
This is linked in the Documentation under "Getting Started" here:
https://cwiki.apache.org/confluence/display/NUTTX/Documentation
Is there anything for OSX? It is mentioned as a supported platform. You may
have to do some more work on make the compilation process easier to get IPMC
votes
I took a look at the STM32F4DISCOVERY guide in the wiki and a lot of the
links are now wrong or broken.
https://cwiki.apache.org/confluence/display/NUTTX/STM32F4DISCOVERY+Unix
Yes, the wiki is not being well maintained.
./tools/configure.sh -m -a ../apps teensy-2.0:hello
make
sh: avr-nuttx-elf-gcc: command not found
ERROR: avr-nuttx-elf-gcc failed: 127
That is configured to use the NuttX buildroot toolchain . See
https://bitbucket.org/nuttx/buildroot/src/master/ You probably don't
want to use that.
No custom board, it's the tm4c1294-launchpad.
Seems no general problem with heap allocation, so I guess it's not in
the linker script, it's rather directly linked to the usage of the elf-
binary loader, and there are only two configs in the nuttx repo which
use the CONFIG_ELF stuff.
That
No custom board, it's the tm4c1294-launchpad.
Seems no general problem with heap allocation, so I guess it's not in
the linker script, it's rather directly linked to the usage of the elf-
binary loader, and there are only two configs in the nuttx repo which
use the CONFIG_ELF stuff.
That
+1
In case you are calling a self-VOTE too :). I would love to have you
one board! We could use the help.
Greg
On 5/11/2020 7:10 PM, Duo Zhang wrote:
Hi, NuttX community, I'm Duo Zhang, I would like to self nominate to be a
mentor of Apache Nuttx, since I'm the only person among 3
I had extensive discussions with Daniel Shahaf and Mark Thomas at
tradema...@apache.org. The emails should be available in the
tradema...@apache.org mail history for the data December 17-18, 2019.
The title of the thread is "NuttX Incubator Project". I don't have
access to that mail list,
I'm fixing styling errors on my PR and the first line of the license header
triggers a long line error:
* Copyright (C) 2018 Erle Robotics (Juan Flores Muñoz). All rights reserved.
* Author: Erle Robotics (Juan Flores Muñoz)
I usually do something like:
* Copyright (C) 2018 Erle Robotics
If all goes well, there will be a big pull request coming soon. Wish me luck!
I think we should consider getting a review team together. This will be
more than a single person can review (especially if that single person
is me since I am completely out of touch with with STM32 these
I just created incubator-nuttx-apps PR 255 that should restore the
correct behavior: https://github.com/apache/incubator-nuttx-apps/pull/255
On 5/17/2020 3:33 PM, Gregory Nutt wrote:
Mystery solved.
It does not even try to load the elf file from file-system, it
directly
goes to the built
However, got a new problem now which I've not figured out yet:
The binary loader does not load the elf if the program is a built-in
app... very strange..
It does not even try to load the elf file from file-system, it directly
goes to the built-in app.
That means that it failed to load the
Mystery solved.
It does not even try to load the elf file from file-system, it
directly
goes to the built-in app.
That means that it failed to load the app on the file system. It
should
check in this order"
- Load file from file system if possible
- If not, run built-in application if
I just created incubator-nuttx-apps PR 255 that should restore the
correct behavior: https://github.com/apache/incubator-nuttx-apps/pull/255
This is a major bug and, if we release do a bugfix release sometime,
this should be included.
I have no preference. At some point, I think we also have to say that
9.0.x "is what it is". Or do you see us continuing to maintain the
release forever? In the dark, pre-Apache past, I had about a two week
period after the release after which it "is what it is". I distrubuted
patches up
Hi, Brennan,
I just created incubator-nuttx-apps PR 255 that should restore the
correct behavior:
https://github.com/apache/incubator-nuttx-apps/pull/255
This is a major bug and, if we release do a bugfix release sometime,
this should be included.
I was thinking the same. I created a label
501 - 600 of 1580 matches
Mail list logo
