> as NuttX does not support the function system()
Hmm, I don't think this is true. You just need to enable `system()` in
configuration
http://nuttx-config.nxtlabs.pl/#/?current=SYSTEM_SYSTEM
Am Do., 10. Juni 2021 um 17:52 Uhr schrieb Fotis Panagiotopoulos <
f.j.pa...@gmail.com>:
> Regarding
Regarding Lua.
I have been using Lua in MCU environment for many years now.
This is the first time to use it along with NuttX.
I am using Lua 5.2.4, for which I have ported the LTR patch, as described
here:
http://www.eluaproject.net/doc/v0.9/en_arch_ltr.html
The way I am using it, is to enable
On Thu, Jun 10, 2021 at 11:33 AM Sebastien Lorquet wrote:
>
>
> Le 10/06/2021 à 16:34, Nathan Hartman a écrit :
> > Second, we need a new Documentation page, "Migrating From Older
> > NuttX." In this documentation, every compatibility change should be
> > documented, going from the present to at
Le 10/06/2021 à 16:34, Nathan Hartman a écrit :
Second, we need a new Documentation page, "Migrating From Older
NuttX." In this documentation, every compatibility change should be
documented, going from the present to at least as far back as NuttX
7.31. We can get all of these from the
On Thu, Jun 10, 2021 at 11:01 AM Nathan Hartman
wrote:
>
> On Thu, Jun 10, 2021 at 10:34 AM Nathan Hartman
> wrote:
> > I was in the CWIKI just a few moments ago, to create the skeleton for
> > what will be our next ReleaseNotes, and I found out something
> > unfortunate: In the CWIKI copy of
On Thu, Jun 10, 2021 at 10:34 AM Nathan Hartman
wrote:
> I was in the CWIKI just a few moments ago, to create the skeleton for
> what will be our next ReleaseNotes, and I found out something
> unfortunate: In the CWIKI copy of the 9.1 ReleaseNotes [1], the
> EXTRADEFINES -> EXTRAFLAGS change is
On Thu, Jun 10, 2021 at 3:50 AM Sebastien Lorquet wrote:
> With that in mind, I am very worried of a supplemental dispersion of
> useful documentation.
>
> At what release/commit does the build system becomes cmake? before that,
> please refer to the make build system documentation. chances are
First, I would like to apologies to Matias for not being able to contribute
to the effort. We are working on the PX4 release, and a nuttx upgrade and I
just do not have the time to spare.
Ironically time is one of the things this discussion is all about. PR with
the current build system and CI
Thanks for everyone's help on this. All working now.
It transpires the msgram can be in SDRAM not just in ISRAM so the solution is
much more like the samV71 using cached memory, but it is handled a little
differently in a few places of course.
No thanks AT ALL to the Atmel datasheet which
Hello Guys,
In my specific situation, I use NuttX separately from the application,
deployed as a library.
And I use CMake to build my application. My reason to choose CMake was
tool integration and easier support to add other open source
libraries.
CMake can build fast, but make is not slow. In
Hi all
Thanks to the assistance given here I now have MCAN working on a sama5D27
processor. The changes need to apply to all sama5d2x processors. I have
forked and bracnched the master repository for this and will submit pull
requests once I completed the work and tested it more thorougly -
It would be great to put NuttX special build files to apps/interpreters
folder after you finish the port, so other people can benefit from your
work and improve it in the future. For the code change, I would
suggest that:
1. If the api called by 3rd party is very common in other Unix variants but
>
> We really ought to talk to the Lua team and see if we can upstream the
> changes. Unsupported ports in NuttX don't have good shelf life.
>
I believe that one of the reasons is that Lua's major use case is to
be embedded inside applications, isn't it?
I don't know if Lua is used so much as a
13 matches
Mail list logo
