On Fri, May 28, 2021 at 12:16 PM Sebastien Lorquet wrote:
> The documentation about NuttX is exploded all around. This is an issue
> that is often noticed by all of my colleagues that attempted to have a
> look at this project.
Documentation has moved from place to place over the years, but we
> Even if I dont get to vote in your committees I will
tell you if I find some problem.
You do get to vote, everyone can vote. It's actually helpful to have
more people voting and participating in the whole release process.
Voting for releases is done in the public dev list. PPMC members have
I will try to continue testing my custom board with upcoming releases to
detect such breaks. Even if I dont get to vote in your committees I will
tell you if I find some problem.
Yes I skipped two years of nuttx development, starting christmas holiday
2019, followed by covid lockdowns and a
> > 2. Split up the ReleaseNotes file? As it is now, it reads a bit more like a
> > ChangeLog rather than ReleaseNotes. In the past we talked about a
> > Documentation/ReleaseNotes directory that could hold a separate
> > ReleaseNotes for each major version?
> >
> They are broken out per release
On Fri, May 28, 2021 at 11:49 AM Nathan Hartman
wrote:
>
> On Fri, May 28, 2021 at 11:43 AM Brennan Ashton
> wrote:
> >
> > On Fri, May 28, 2021, 7:54 AM Nathan Hartman
> > > 3. Make a ReleaseNotes section of the website that will render those
> > > ReleaseNotes files and offer an easy to use
On Fri, May 28, 2021 at 11:43 AM Brennan Ashton
wrote:
>
> On Fri, May 28, 2021, 7:54 AM Nathan Hartman
> > 3. Make a ReleaseNotes section of the website that will render those
> > ReleaseNotes files and offer an easy to use index, so it's easier to find
> > this information. The newer ones are
On Fri, May 28, 2021, 7:54 AM Nathan Hartman
wrote:
> On Fri, May 28, 2021 at 9:12 AM Sebastien Lorquet
> wrote:
>
> > I'm not talking of renaming code symbols like up_anything to
> > arm_anything, which makes sense and can be noticed quite easily at link
> > stage.
> >
> > I'm talking about
On Fri, May 28, 2021 at 9:12 AM Sebastien Lorquet
wrote:
> I'm not talking of renaming code symbols like up_anything to
> arm_anything, which makes sense and can be noticed quite easily at link
> stage.
>
> I'm talking about renaming a shell/make variable from EXTRADEFINES to
> EXTRAFLAGS. This
I'm not talking of renaming code symbols like up_anything to
arm_anything, which makes sense and can be noticed quite easily at link
stage.
I'm talking about renaming a shell/make variable from EXTRADEFINES to
EXTRAFLAGS. This is hidden, and the build system has no way to complain
about
I think a benefit from renaming many of those "up_something" to
"stm32_something", "esp32_something", etc is now it is easy for
software find the right function.
I think many IDEs cannot handle functions search correctly for NuttX
because they don't have heuristics to know that IF I'm searching a
I sill wonder what is the purpose of this variable rename. Sorry to say,
but it just looks cosmetic while critically breaking everything that was
made before, and this kind of thing is a nightmare for migration when
you cant follow the project day to day. Boards can be external to the
project,
Boom, that was the extrastuff. The board now boots. We're going to run a
lot of functional tests to make sure everything is okay, but I dont have
this strange hardfault at boot.
Thank you.
I did not find this page despite searching through a lot of
documentation, mainly the "official"
: Sebastien Lorquet [mailto:sebast...@lorquet.fr]
Sent: Wednesday, May 26, 2021 9:22 AM
To: dev@nuttx.apache.org
Subject: Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
Hello,
Thanks for the remarks.
I am using the flat (monolithic build) and I see no place that define
this flag, at all
Hi Sebastien,
Stack crashing into heap?
Have you upped the stack sizes across the board?
David
-Original Message-
From: Sebastien Lorquet [mailto:sebast...@lorquet.fr]
Sent: Wednesday, May 26, 2021 9:22 AM
To: dev@nuttx.apache.org
Subject: Re: Port of project from NuttX 7.30 to 10.1
Maybe this one could help:
https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1#NuttX9.1-CompatibilityConcerns
> I am using the flat (monolithic build) and I see no place that define
>this flag, at all.
>I dont even see a place in the codebase that defines this flag.
__KERNEL__ is defined
Hello,
Thanks for the remarks.
I am using the flat (monolithic build) and I see no place that define
this flag, at all.
I dont even see a place in the codebase that defines this flag.
I see nothing related to mm, nor anything outdated in my Make.defs,
which is from my old setup, yes, but
If you use CONFIG_BUILD_FLAT=y, make sure that __KERNEL__ flag is set here:
https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/mm/mm.h#L85
I remember that at some point I had a similar hardfault in mm which doesn't
make sense and it was due to outdated board Make.defs.
śr., 26
Update: stack dump and register analysis are in fact pointing to a crash
in mm_alloc
I have enabled memory management debug:
mm_initialize: Heap: start=0x1000 size=65536
mm_addregion: Region 1: base=0x1154 size=65184
stm32_netinitialize: Enabling PHY power
stm32_netinitialize: PHY
On Tue, May 25, 2021 at 12:02 PM Sebastien Lorquet
wrote:
> Back to the business
> >> After this we managed to recompile our project using the latest NuttX
> >> sources, but it fails when trying to init the PHY irq on our STM32F427
> >> board: We get "unexpected IRQ".
> >>
> >> Yes I know that's
irq_unexpected_isr: ERROR irq: 3
...
My guess is that AN external IRQ is triggered (possibly not the PHY
IRQ) but the ISR handler for that one is not ready yet. I will add
debug messages.
IRQ 3 is a Hardfault, not an external IRQ or peripheral interrupt.
I would expect that situation to be
Back to the business
After this we managed to recompile our project using the latest NuttX
sources, but it fails when trying to init the PHY irq on our STM32F427
board: We get "unexpected IRQ".
Yes I know that's pretty vague :-)
Is there anything obvious I should have been careful with in this
On Tue, May 25, 2021 at 10:22 AM Sebastien Lorquet wrote:
>
> it will be easier next time.
Yes the workflow of git in general is a lot of steps to do a simple thing.
If you'd like to, you can still send patches to the mailing list. Just
please remember to name the file with ".txt" extension or
it will be easier next time.
Does any of the 21 queued test that I see waiting in github enable this
driver?
Because if they dont (which I suspect, hence this typo) these tests are
useless.
Sebastien
Le 25/05/2021 à 16:17, Sebastien Lorquet a écrit :
No, the workflow is very clear, the
No, the workflow is very clear, the pull request model is a defacto
standard that works everywhere.
But it is heavy for trivial changes. fork, mess with remotes, make a
branch, forget to change the git config --local user.name, push, deal
with github and my ssh agent messing with multiple ssh
On Tue, May 25, 2021 at 10:05 AM Sebastien Lorquet wrote:
>
> done, what a process for a 7-character change...
>
> The PHY and cable detection worked perfectly fine in our project.
>
> Sebastien
Thanks so much for doing that!
Regarding the process, did you have any difficulty, i.e., anything
done, what a process for a 7-character change...
The PHY and cable detection worked perfectly fine in our project.
Sebastien
Le 24/05/2021 à 23:04, Nathan Hartman a écrit :
On Mon, May 24, 2021 at 11:36 AM Sebastien Lorquet wrote:
Hello,
There is a typo in the PCA9555 driver at line 817:
On Mon, May 24, 2021 at 11:36 AM Sebastien Lorquet wrote:
>
> Hello,
>
> There is a typo in the PCA9555 driver at line 817:
> CONFIG_TCA64XX_INT_NCALLBACKS is a bad copy paste, should be
> CONFIG_PCA9555_INT_NCALLBACKS.
Good catch! Please feel free to open a PR.
> After this we managed to
https://github.com/apache/incubator-nuttx/issues/3769
Le 24/05/2021 à 17:36, Sebastien Lorquet a écrit :
Hello,
There is a typo in the PCA9555 driver at line 817:
CONFIG_TCA64XX_INT_NCALLBACKS is a bad copy paste, should be
CONFIG_PCA9555_INT_NCALLBACKS.
After this we managed to recompile
28 matches
Mail list logo
