Re: Undefined reference to longjmp/setjmp
> 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 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 the end user to provide their own logic > to the system. > Essentially they provide the end application that runs on my hardware. > Custom Lua libraries allow the Lua scripts to interface the board. > > "Porting" Lua to NuttX was a piece of cake*. > I just downloaded the source code, configured luaconf.h and built it. > The only modification that I did to the source code was to comment out the > os.execute function, as NuttX does not support the function system(). > I am not sure if this can be easily fixed in NuttX or Lua, or whether this > functionality is generally required in an MCU environment. > > (*Note however that this is a WIP for me, so it is not properly tested yet. > Issues may arise, but for the moment I don't see any reason for .) > > Στις Πέμ, 10 Ιουν 2021 στις 2:57 μ.μ., ο/η Xiang Xiao < > xiaoxiang781...@gmail.com> έγραψε: > > > 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 > > NuttX is not implemented or the implementation is wrong, it's better to > > improve NuttX instead of hacking the 3rd party code. > > 2. If the api is hard to implement in NuttX(e.g. fork), but there is a > more > > portable way to write the same functionality(e.g. > > posix_spawn/pthread_create), it's better to make a common change not > > specific to NuttX.(e.g. > > https://gitlab.com/libssh/libssh-mirror/-/merge_requests/174). > > 3.The last resort is to add __NuttX__ around the broken code. > > Last, it's better to upstream your change to NuttX and 3rd party > community, > > so both sides can maintain and improve your change in the long term. > > > > On Thu, Jun 10, 2021 at 5:58 PM Flavio Castro Alves Filho < > > flavio.al...@gmail.com> wrote: > > > > > > > > > > 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 replacement for bash, perl or > > > python .. > > > > > > In this case, maybe a document explaining how to add on a project > > > could be enough :-| > > > > > > Best regards, > > > > > > Flavio > > > > > >
Re: Undefined reference to longjmp/setjmp
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 the end user to provide their own logic to the system. Essentially they provide the end application that runs on my hardware. Custom Lua libraries allow the Lua scripts to interface the board. "Porting" Lua to NuttX was a piece of cake*. I just downloaded the source code, configured luaconf.h and built it. The only modification that I did to the source code was to comment out the os.execute function, as NuttX does not support the function system(). I am not sure if this can be easily fixed in NuttX or Lua, or whether this functionality is generally required in an MCU environment. (*Note however that this is a WIP for me, so it is not properly tested yet. Issues may arise, but for the moment I don't see any reason for .) Στις Πέμ, 10 Ιουν 2021 στις 2:57 μ.μ., ο/η Xiang Xiao < xiaoxiang781...@gmail.com> έγραψε: > 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 > NuttX is not implemented or the implementation is wrong, it's better to > improve NuttX instead of hacking the 3rd party code. > 2. If the api is hard to implement in NuttX(e.g. fork), but there is a more > portable way to write the same functionality(e.g. > posix_spawn/pthread_create), it's better to make a common change not > specific to NuttX.(e.g. > https://gitlab.com/libssh/libssh-mirror/-/merge_requests/174). > 3.The last resort is to add __NuttX__ around the broken code. > Last, it's better to upstream your change to NuttX and 3rd party community, > so both sides can maintain and improve your change in the long term. > > On Thu, Jun 10, 2021 at 5:58 PM Flavio Castro Alves Filho < > flavio.al...@gmail.com> wrote: > > > > > > > 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 replacement for bash, perl or > > python .. > > > > In this case, maybe a document explaining how to add on a project > > could be enough :-| > > > > Best regards, > > > > Flavio > > >
Re: [Discuss] Migrate the build system to CMake
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 least as far back as NuttX > > 7.31. We can get all of these from the ReleaseNotes, but they should > > be consolidated somewhere, so that someone like Sebastien who wants to > > upgrade from version X to version Y can just go step by step and make > > the necessary changes. > That would be an extremely good thing to have. It would ensure an > exhaustive migration path for legacy installations. > > That page should then explain how to migrate to cmake. > > If this doc is easy to find, I have less issues with cmake. > > Also thank you for fixing the release notes. This triplication is not > easy to manage. Agreed, and one of these days I'm sure we'll find a better solution! In the "Migrating From Older NuttX" document: The last section should document migrating from Latest Release to current master's HEAD. I think it should be the project's policy, from now on, that every time a breaking change is made, it should be documented in that section IN THE SAME PR. This way, everyone will always have documentation how to get from wherever they are to latest HEAD, and When we release, all we have to do is change the title of that section to the new release number, and add a new empty section for HEAD below that. Nathan
Re: [Discuss] Migrate the build system to CMake
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 ReleaseNotes, but they should be consolidated somewhere, so that someone like Sebastien who wants to upgrade from version X to version Y can just go step by step and make the necessary changes. That would be an extremely good thing to have. It would ensure an exhaustive migration path for legacy installations. That page should then explain how to migrate to cmake. If this doc is easy to find, I have less issues with cmake. Also thank you for fixing the release notes. This triplication is not easy to manage. Sebastien
Re: [Discuss] Migrate the build system to CMake
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 the 9.1 ReleaseNotes [1], the > > EXTRADEFINES -> EXTRAFLAGS change is documented. BUT... In the repo > > ReleaseNotes file [2], that section is COMPLETELY MISSING! It is also > > missing on the website [3]. In fact, all the compatibility docs are > > missing from both places, such as Rename WINTOOL to > > CONFIG_CYGWIN_WINTOOL, etc. > > > > First, I am going to send a PR to fix the ReleaseNotes in the repo. > > Ok that's done. See PR-3897: > https://github.com/apache/incubator-nuttx/pull/3897 Also PR-57 on the website repo: https://github.com/apache/incubator-nuttx-website/pull/57 Nathan
Re: [Discuss] Migrate the build system to CMake
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 documented. BUT... In the repo > ReleaseNotes file [2], that section is COMPLETELY MISSING! It is also > missing on the website [3]. In fact, all the compatibility docs are > missing from both places, such as Rename WINTOOL to > CONFIG_CYGWIN_WINTOOL, etc. > > First, I am going to send a PR to fix the ReleaseNotes in the repo. Ok that's done. See PR-3897: https://github.com/apache/incubator-nuttx/pull/3897 Nathan
Re: [Discuss] Migrate the build system to CMake
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 that > this doc quickly becomes 404, leaving all users of all versions in the > dark. for commits after that, please refer to this other documentation > on some personal blog, but only for release a.b.c later than this date. (snip) > So please. Keep NuttX interfaces STABLE for users that need it. It's not > a beta project anymore, it's "mature" as you advertise it, which means > it has some real industrial users that matter more than abstract > technical beauty. EXTRADEFINES now also need to include flags. hah, not > cool. I should rename that to EXTRAFLAGS, thats more cute. But how many > users will suffer from this apparently benign change? These questions > NEED to be asked by developers and contributors and reviewers. We screwed up. 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 documented. BUT... In the repo ReleaseNotes file [2], that section is COMPLETELY MISSING! It is also missing on the website [3]. In fact, all the compatibility docs are missing from both places, such as Rename WINTOOL to CONFIG_CYGWIN_WINTOOL, etc. First, I am going to send a PR to fix the ReleaseNotes in the repo. 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 ReleaseNotes, but they should be consolidated somewhere, so that someone like Sebastien who wants to upgrade from version X to version Y can just go step by step and make the necessary changes. [1] https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1#NuttX9.1-CompatibilityConcerns [2] https://github.com/apache/incubator-nuttx/blob/master/ReleaseNotes [3] http://nuttx.apache.org/releases/9.1.0/ Nathan
RE: [Discuss] Migrate the build system to CMake
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 take hours to complete. Yes hours! This may a not be an issue for the causal Nuttx contributor. For maintainers it is a waste of time and money from their companies or sponsors. It slows development progress down to a crawl. This is one of the key reasons why we need Cmake, Nijabuild, and ccache (and persistence). I am reminded by the 'if it ain't broke..." statement of the proud carpenter holding his hand saw, in hand, watching the guy cutting plywood sheeting with a Skill Saw. Saying if it ain't broke That is the level of improvement that we are talking about. Yes but now you need power on the job site…. Yes we have to overcome the barriers… There are a lot of changes happening in NuttX. The immediate value versus the level of effort to upgrade is difficult to see sometimes. For instance, in building PX4 with master I have a PR with 666 some odd files changes tracking the inttypes change and header file inclusion changes. While typing PRI... thousands of times it is hard to remember that catching the cause of a crash in the compiler, at build time is far superior to hours spent in the debugger. The include file changes add proper partitioning this is a code quality issue. Sometimes it seems like syntactical sugar or gratuitous renaming changes are just dumb. They are not. What is dumb is not sharing the sed script or a text file with the key was/is changes as part of the release. That is on us. Hats off to AlexanderVasiljev for his comments in [1]. We need to do this more! No Really we do. Sharing the reasons for the change and how to apply it to a derivative of NuttX will make NuttX more successful. Cmake is not in that class of gratuitous changes. The advantage of 22 second out of tree NuttX build will be an obvious. Yes it is a new tool, yes there is a learning curve, yes I hate cmake some times. The level of effort for adoption is very high for NuttX. Getting to a successful build is the first roadblock. Expecting contributors to find and use buried tooling as opposed to top level commands just digs the hole deeper. Is anyone getting tiered of telling contributors "just run ./tools/checkpatch.sh -g HEAD~...HEAD" yet? If the readme said: Installing the Tools Run tools/nuttxtools_install.sh Building the code make board-config make board-config menuconfig|newconfig|saveconfig Check formatting make format Getting to a successful build would be simple. Cmake will help with this goal on all OS platforms. We just need to invest in supporting Cmake. Rebasing it constantly is not an option it will eventually need to be on master. We can keep make and cmake side by side if we can find value in it. One other thing I would like to say is PX4 went from make to Cmake years ago now. It promoted adoption. I would never go back. Even hating cmake, sometimes the benefits far out way the hassles. >From that experience I can say it is important to do it right (refractor with good design reviews of the user experience) and document it well. But all the user has to type is `make board-config` Regards, David [1] https://github.com/apache/incubator-nuttx/pull/3836#issue-660639554 -Original Message- From: Matias N. [mailto:mat...@imap.cc] Sent: Wednesday, June 09, 2021 5:01 PM To: dev@nuttx.apache.org Subject: Re: [Discuss] Migrate the build system to CMake Hi, I'll answer a few question that came up several times about build systems co-existing. My previous answer was about co-existing them as a way to satisfy both set of users, which I don't think is the right approach. However, as a transition approach it does makes sense to me. This is technically feasible however it will require adapting the Make based system as there were some changes needed to be made to Kconfig files, specifically this one: https://github.com/apache/incubator-nuttx/pull/3704/files?file-filters%5B%5D=.dat%5B%5D=.pl%5B%5D=.sh%5B%5D=No+extension#diff-7c9693e9c5e61a1d80e09769377d47bb415ec39ca5aeaa85d13581b0105d6359 The main point is that CMake handles all steps related to build configuration (e.g. build flags based on optimization level) and platform detection. On master this is done via Kconfig (with settings which are stored in board defconfigs). One of these changes done to Kconfig is to pass the host-related variables as environment vars to Kconfig (so that it still possible to condition options based on platform). So, co-existing the build systems would require dealing with this, which I'm not sure how easy would be. With regards to comments about others requiring some hands-on time to become familiar with the system and
RE: Memory locations
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 says: "The MSBs [bits 31:16] of the CAN Message RAM for CAN0 and CAN1 are configured in 0x0020". I took "in" to mean "as". The statement makes even less sense anyway, as they are actually configured in a Special Function Register which is not referenced in the MCAN section at all...and default to 0x200020 in actual fact! So, much time was wasted :( But boy have I learned a lot these last few weeks LOL.
Re: [Discuss] Migrate the build system to CMake
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 fact, CMake is a makefile file generator. I use ninja in my builds, but could be make as well. Probably that's the reason that it works better in different environments. Adding another point for the discussion, maybe the build system for the operating system should not be the same for the application, just like Linux today. The build system challenge is more relevant if you have OS and apps together. Considering OS as, somehow, a BSP, then I don't know what would be the value for changing the build system. Best regards, Flavio Em qui., 10 de jun. de 2021 às 04:50, Sebastien Lorquet escreveu: > > Hello, > > Le 10/06/2021 à 02:00, Matias N. a écrit : > > With regards to comments about others requiring some hands-on time to become > > familiar with the system and try it for themselves: I agree with this point > > and was one > > of the reasons I actually started the migration. As I mentioned several > > weeks ago, > > the cmake branch can already be tested on the currently supported boards by > > everyone > > wishing to do so, but I don't think anyone really tried it as my offers > > about > > assistance in this were unanswered. > > I have no doubt that the new build system will work better. > > I understand that it builds faster than the existing and requires less > kludges, and permits out of tree builds. > > But it's a fundamental change about how to approach the NuttX OS globally. > > The track record of this OS in terms of user documentation is not very > good, to be honest, it requires a lot of time to dig in various source > files and different web sites to understand how to do something. > > This is not only my experience, it's the feeling of all of the ~10 > persons I have tried to introduce to Nuttx: This OS is hard, it does not > guide beginners and it's hard to do "WHAT I WANT" (which is usually not > configuring nsh on a stm32f4discovery, but hands-on use case on custom > hardware with custom apps). > > 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 that > this doc quickly becomes 404, leaving all users of all versions in the > dark. for commits after that, please refer to this other documentation > on some personal blog, but only for release a.b.c later than this date. > > I dont think cmake is technically wrong, but from a USER POINT OF VIEW, > it will become a nightmare and will drive new contributors away, because > of documentation problems. > > Not to mention old users who spend weeks just to migrate a few boards > from an old to a new nuttx, just because a makefile and a critical > variable were renamed but no migration documentation exists. Add more > changes, and a project may become unusable in the current state of the > project. > > So please. Keep NuttX interfaces STABLE for users that need it. It's not > a beta project anymore, it's "mature" as you advertise it, which means > it has some real industrial users that matter more than abstract > technical beauty. EXTRADEFINES now also need to include flags. hah, not > cool. I should rename that to EXTRAFLAGS, thats more cute. But how many > users will suffer from this apparently benign change? These questions > NEED to be asked by developers and contributors and reviewers. > > When you make a change, please ask yourselves: how many unknown users > will I f*k up with that? > > As a famous quote more or less goes, because it can be done does not > mean it should be done. > > And having a generator that derives cmake files from current makefiles > feels a bit like xkcd #927 > > Sebastien > -- Flavio de Castro Alves Filho flavio.al...@gmail.com Twitter: http://twitter.com/#!/fraviofii LinkedIn profile: www.linkedin.com/in/flaviocastroalves
sama5d2 mcan - procedure to fix
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 - and sorted the Kconfig files etc. The same will apply to flexcom ports as well (sama5d3 is not the same as sama5d2 in this area either) and possibly other things I'm yet to find of course This will all take a month or more (elapsed) but should I formally report these as issues via Github, along with some notes that may assist anyone else using this family in the mean time? Or just wait until it's all done and dusted and do my PRs in one hit with/without raising them as actual issues? Can't find guidance on this in the "Contributing" notes. TIA, Tim.
Re: Undefined reference to longjmp/setjmp
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 NuttX is not implemented or the implementation is wrong, it's better to improve NuttX instead of hacking the 3rd party code. 2. If the api is hard to implement in NuttX(e.g. fork), but there is a more portable way to write the same functionality(e.g. posix_spawn/pthread_create), it's better to make a common change not specific to NuttX.(e.g. https://gitlab.com/libssh/libssh-mirror/-/merge_requests/174). 3.The last resort is to add __NuttX__ around the broken code. Last, it's better to upstream your change to NuttX and 3rd party community, so both sides can maintain and improve your change in the long term. On Thu, Jun 10, 2021 at 5:58 PM Flavio Castro Alves Filho < flavio.al...@gmail.com> wrote: > > > > 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 replacement for bash, perl or > python .. > > In this case, maybe a document explaining how to add on a project > could be enough :-| > > Best regards, > > Flavio >
Re: Undefined reference to longjmp/setjmp
> > 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 replacement for bash, perl or python .. In this case, maybe a document explaining how to add on a project could be enough :-| Best regards, Flavio
