Re: Help us to create a distributed board testing farm
Most of us have some spare PC around, such PC can have fresh Linux with a gitlab-runner service and this gitlab-runner can build, flash and run tests, a pipeline that gives positive or negative results. With binaries already built it could just download instead. I know that with GitLab this is more or less trivial. With GitHub probably also, although I have no experience with it. Configuration of such a solution is not very difficult, but requires some expertise. We could create a repository with description and some configuration files allowing easy setup of such a solution. Even if NuttX has only a limited amount of automated tests, automated tests can be expanded and developed separately from such automated testing solution. Finally there could be a very simple website that board maintainers could automatically upload results of tests using some previously received tokens. Am Do., 18. Juli 2024 um 22:12 Uhr schrieb Alan C. Assis : > Hi Gábor, > > Our idea is to do it automatically: the CI will build the binary and notify > the users to start the flashing process, test it and return the result. > > We will need a board to do the flashing process (i.e. an ESP32 with > SWD/JTAG flashing emulation). > > Does LVGL have farm board testing? > > BR, > > Alan > > On Thu, Jul 18, 2024 at 5:03 PM Gábor Kiss-Vámosi > wrote: > > > Hi, > > > > In practice will it be manual testing by humans, or can you run some > tests > > automatically and remotely? > > > > On Thu, Jul 18, 2024, 21:50 Alan C. Assis wrote: > > > > > Actually I shared it publicly with modify permissions (danger mode, > maybe > > > it is better to use Comment option, so people can ask for invitation) > > > > > > BR, > > > > > > Alan > > > > > > On Thu, Jul 18, 2024 at 4:39 PM Kenneth Pettit > > wrote: > > > > > > > Hi Alan, > > > > > > > > I guess you need to be invited to view that Google Doc? > > > > > > > > Ken > > > > > > > > On 7/18/24 12:14 PM, Alan C. Assis wrote: > > > > > Hi Everyone, > > > > > > > > > > We are creating a testing farm for NuttX to be integrated on our > CI. > > > > > > > > > > As you know, NuttX supports more than 300 boards and we need to > test > > > all > > > > > boards everytime someone modifies our code base. > > > > > > > > > > So, let's to map each person have each board, please include your > > name > > > in > > > > > the front of each board you have (case there is already some else > > name > > > > > there, put your name in the next column) > > > > > > > > > > > > > > > > > > > > https://docs.google.com/spreadsheets/d/1nDMquG-gjfQ0c9jIfv_HztGeq1ysfCeJzOEts3X3Eks/edit?gid=0#gid=0 > > > > > > > > > > Thank you very much! > > > > > > > > > > BR, > > > > > > > > > > Alan > > > > > > > > > > > > > > >
Re: Custom apps outside the tree
There is an inexistent, ignored entry in apps called external. By creating a symlink called external you should end up with no, as you called "poop". I assume that you mean no extra files or modifications in NuttX repositories. On Tue, 12 Sep 2023, 19:58 Mike Moretti, wrote: > Hi, > > Is there any way to do custom apps outside the tree without "pooping" in > the apps directory? The docs show 3 ways to do custom apps, but they > all require modifying the apps directory in some way, either by putting > your custom apps in the apps directory, or making a symlink there. I'd > prefer not to modify the apps directory at all, to make it easier to > update from the official apps git repo when new versions come out. This > also gets in the way of us using the apps directory as a git submodule. > > Thanks, > -m >
Re: Touchscreen scaling/LVGL
Maybe additional IOCTL in touch display drivers, for example here https://github.com/apache/nuttx/blob/master/drivers/input/ads7843e.c#L943 Two calls, one accepting calibration matrix, and another to remove it and come back to raw readings. In typical Linux there is an `xinput` command to do it https://wiki.archlinux.org/title/Calibrating_Touchscreen#Apply_the_Matrix. Am Di., 23. Mai 2023 um 20:37 Uhr schrieb Alan C. Assis : > The LVGL 7.x that was integrated on NuttX had a calibration before > initialize the demo, I think it was from LVGL itself. > > There is also TS calibration that Greg created for TWM4NX: > apps/graphics/twm4nx/apps/ccalibration.cxx > > BR, > > Alan > > On 5/23/23, Maciej Wójcik wrote: > > It would be great if NuttX would offer calibration of touch screens out > of > > the box. > > > > I am not sure where it should go, but I think it could be a wrapper that > is > > used by many drivers. > > > > I think we have a similar situation with flash filesystems. There are > > multiple layers that stack on each other. > > > > For example here there is `ftl_initialize` (flash translation layer) and > > then `smart_initialize` (filesystem) > > > https://github.com/apache/nuttx/blob/master/boards/arm/stm32/stm32f103-minimum/src/stm32_w25.c#L266 > > > > Regarding the calibration itself, you probably know how to implement it, > > but otherwise you might find this useful > > https://gitlab.com/nxtlabs/shared-libs/touch-calib-lib/-/wikis/home > > (explanation and implementation) > > > > Coming back to your question, how do other people do it? For me it was > just > > user-space code, part of the application. > > > > Am Di., 23. Mai 2023 um 20:12 Uhr schrieb Tim Hardisty > > : > > > >> Hi, > >> > >> This is perhaps more a POSIX/general programming question than NuttX but > >> you are all, so often, so very helpful :) > >> > >> A touchscreen peripheral (SAMA5D2 as it happens) delivers X and Y > >> coordinates scaled 0-4095. > >> > >> LVGL wants them scaled to the actual size of the display (800x480 in my > >> case). > >> > >> I'm not 100% sure that the chip’s TSD driver is the place to scale it? > >> > >> The TSD driver creates a generic /dev/input0 character driver, which is > >> what LVGL (set via Kconfig) opens. Scaling within the LVGL code isn’t > >> right > >> either, I don’t think? > >> > >> I can only think of either: > >> > >> 1) creating a new character driver that does a translation – registered > >> as > >> /dev/input1 (or whatever) that LVGL uses, and this driver reads input0 > >> when > >> required and returns translated values. > >> > >> 2) Enhance the chip's TSD driver after all, using a Kconfig setting to > >> enable X/Y scaling to the display's size (set in board-specific files > >> already). > >> > >> Both seem a little messy though so perhaps I’m missing something > obvious? > >> Can't be the first to need to do this? > >> > >> Thanks, > >> > >> TimH > >> > >> > > >
Re: Touchscreen scaling/LVGL
It would be great if NuttX would offer calibration of touch screens out of the box. I am not sure where it should go, but I think it could be a wrapper that is used by many drivers. I think we have a similar situation with flash filesystems. There are multiple layers that stack on each other. For example here there is `ftl_initialize` (flash translation layer) and then `smart_initialize` (filesystem) https://github.com/apache/nuttx/blob/master/boards/arm/stm32/stm32f103-minimum/src/stm32_w25.c#L266 Regarding the calibration itself, you probably know how to implement it, but otherwise you might find this useful https://gitlab.com/nxtlabs/shared-libs/touch-calib-lib/-/wikis/home (explanation and implementation) Coming back to your question, how do other people do it? For me it was just user-space code, part of the application. Am Di., 23. Mai 2023 um 20:12 Uhr schrieb Tim Hardisty : > Hi, > > This is perhaps more a POSIX/general programming question than NuttX but > you are all, so often, so very helpful :) > > A touchscreen peripheral (SAMA5D2 as it happens) delivers X and Y > coordinates scaled 0-4095. > > LVGL wants them scaled to the actual size of the display (800x480 in my > case). > > I'm not 100% sure that the chip’s TSD driver is the place to scale it? > > The TSD driver creates a generic /dev/input0 character driver, which is > what LVGL (set via Kconfig) opens. Scaling within the LVGL code isn’t right > either, I don’t think? > > I can only think of either: > > 1) creating a new character driver that does a translation – registered as > /dev/input1 (or whatever) that LVGL uses, and this driver reads input0 when > required and returns translated values. > > 2) Enhance the chip's TSD driver after all, using a Kconfig setting to > enable X/Y scaling to the display's size (set in board-specific files > already). > > Both seem a little messy though so perhaps I’m missing something obvious? > Can't be the first to need to do this? > > Thanks, > > TimH > >
Re: CI tests (was: Re: [OT] Learning Makefiles)
Checking different configurations is an academic problem, I think they call it configuration sampling and it is part of variability modelling. There were some papers about sampling of Linux configurations. The simplest approach is to enable all possible, disable all possible, but it is not trivial. Each selection multiplies the number of configurations by the number of available options. That has very bad complexity. They use SAT solvers to generate many configurations instead of brute force. The goal is to sample configuration space in a uniform way. Am Mo., 22. Mai 2023 um 21:14 Uhr schrieb Nathan Hartman < hartman.nat...@gmail.com>: > On Mon, May 22, 2023 at 9:29 AM Sebastien Lorquet > wrote: > > > > > If the untold reason is to speed up github tests, then run less tests. > > Do we really need to test build on 13 or 20 arm platforms when only one > > config of the other architectures is tested, and the actual value of > > these build test is dubious? > > > > This is an interesting point. It reminds me that (at least in the old days, > I don't know now) FreeBSD had a build config that basically enabled all > options, even if that's impossible for actually running, for build testing. > I don't know if we can do that but maybe we need one ARM config that > enables as many options as possible and then use other archs for other > tests. > > Just a thought > > Nathan >
Re: [OT] Learning Makefiles
I see the following advantages of having CMake: - Everything is way more readable then the current Make files. - Easier on-boarding. - Less build-related bugs. - Less boiler-plate code. - Faster builds. - Great IDE integration. Adding CMake as an optional feature seems to be a great solution. Maintaining two systems for a while requires more work, but it would be a backward-compatible way to polish the solution. For trivial problems it is still just adding files to lists, right? For more complex issues, I am pretty sure that parties attached to Make will maintain it just fine and people who want CMake will fix it for themselves. The discussion so far was that: - Replacing Make breaks existing workflows. - CMake is less flexible. - Duplicated maintenance effort. By just adding CMake no workflows are broken If the new solution is able to recreate the previous build system, then it is flexible enough. I guess that overlapping maintenance effort is the only way to offer backward compatibility. I would like to point out that offering CMake is what people expect to have from a modern project and NuttX is currently not offering it. Am Fr., 19. Mai 2023 um 19:26 Uhr schrieb Tomek CEDRO : > On Fri, May 19, 2023 at 7:17 PM Xiang Xiao wrote: > > The change doesn't replace Makefile with CMake, both can work. So I would > > suggest the vote is "Enable CMake support". > > Isn't the goal of CMake to generate Makefiles? > > What is the chance of keeping both makefiles and cmakefiles out of sync? > > Wouldn't that double the work? > > Wouldn't that imply switch to CMake anyways? > > From what I understand CMake can offer faster builds using different > build methods / systems, it could eliminate GNU Make vs BSD Make > problem, but also it will change whole build process, changes > frequently, etc..? > > Such a big change needs good description.. risks.. clear list of > advantages and disadvantages :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
Re: New names of repositories
If some toolchain has an issue with hyphen separated name, then it should be solved in scope of that toolchain. In particular, instructions for that particular toolchain should suggest different clone name as a workaround. One broken toolchain should not lead to violating of URL naming standards. On Sat, 19 Nov 2022, 15:53 Thiago Costa de Paiva, wrote: > From these, the valid argument is that it would be non-standard (not a top > level name) related to Appache rules, which I think is indeed not > acceptable. It would not imply any source code organization change nor > submodules: > > git clone /nuttx/core nuttx > git clone /nuttx/apps apps > > Anyway, from all the discussion, since hyphens should not be used > according to what Greg said previously, I think we have only two options: > > nuttx > nuttx_apps > > and > > nuttx > nuttxapps > > Thiago > > > 2022/11/19 15:37:21, Tomek CEDRO: > > Short answer: NO :-) > > > > Long answer: > > 1. This is not how current source code is organized. Implies > > additional work and will break compatibility. > > 2. There will be a problem with git repository. This may not be > > accepted by Apache or will require additional non-standard work that > > will not align with how other projects are organized. Top level names > > should be used. Using nuttx.git is fine but having apps.git among > > other projects will be confusing (what apps are these?). Also might > > imply using git submodules. There was a discussion about that and this > > seems unnecessary complication. > > > > Best regadrs :-) > > Tomek > > > > > > On Sat, Nov 19, 2022 at 3:28 PM Thiago Costa de Paiva > wrote: > > > > > > I am not attached to the name itself, I was just trying to solve the > problem with special characters. Would the following work? > > > > > > nuttx/core > > > nuttx/apps > > > > > > > > > 2022/11/19 08:21:43, Gregory Nutt: > > > > On 11/19/2022 8:12 AM, Gregory Nutt wrote: > > > > > We need to verify, but I do not think that the Apache github > repository > > > > > supports directories > > > > > > > > > > Technically, NuttX is NOT a kernel in most build modes. A kernel > is a > > > > > very specific architectural implementation involving protected > > > > > resources: https://en.wikipedia.org/wiki/Kernel_(operating_system) > . > > > > > The Linux kernel is a kernel. NuttX can be a kernel in the > protected > > > > > and kernel build modes, but in general, NuttX is not a kernel so > any use > > > > > of kernel in the naming would be wrong in most cases. > > > > > > > > > > https://en.wikipedia.org/wiki/Kernel_(operating_system) > > > > > > > > > > More correctly Linux (and NuttX in protected and kernel modes) is a > > > > > monolithic kernel. > > > > > > > > > > Even worse usage is when NuttX is occasionally called a micro > kernel > > > > > which is most certainly is not. A microkernel is an architectural > > > > > alternative to a monolithic kernel: > > > > > > > > > > https://en.wikipedia.org/wiki/Microkernel > > > > > > > > According to > > > > > https://en.wikipedia.org/wiki/Operating_system#Types_of_operating_systems > , > > > > NuttX in the flat build mode could be called a "library operating > system" > > > > with regard to memory organization. It is also a real-time, > multi-tasking, > > > > embedded operating system using those definitions. > > > > > > > > > > > > > > -- > > > Thiago Costa de Paiva > > > FSF member: 11963 > > > Linux User: 565327 > > > > > > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > -- > Thiago Costa de Paiva > FSF member: 11963 > Linux User: 565327 > >
Re: New names of repositories
Isn't it possible to have a nuttx namespace with two repositories inside? This would also open a possibility to host other projects related to NuttX in the same place in the future. On Fri, 18 Nov 2022, 17:30 Gregory Nutt, wrote: > > > why can’t we just have : > > > > nuttx, apps > > > > as it has been for a long time (before Apache) … > > Ultimately, the repository names would appear here: > https://github.com/orgs/apache/repositories > > nuttx/ would probably be fine, but apps/ probably would not be > appropriate at that level. > > >
Re: New names of repositories
It is of course subjective, but dashes are typically used for URLs, not underscores. Just to quote a Google recommendation https://developers.google.com/search/docs/crawling-indexing/url-structure?hl=en_id=638043215091036715-3041335353=1 [image: image.png] In case some tools have an issue with such a trivial thing, then maybe their quality is not the best and they shouldn't be used :) Am Do., 17. Nov. 2022 um 23:07 Uhr schrieb Brennan Ashton < bash...@brennanashton.com>: > My vote without too much care is to leave it be minus the incubation bit. > We have already been dealing with the hyphens. > > --Brennan > > On Thu, Nov 17, 2022, 1:47 PM Nathan Hartman > wrote: > > > Hi all, > > > > As mentioned in the other thread, the repos need to be renamed to > > remove "incubating". > > > > In the discussion from a few months ago [1] several reasons were given > > why not to use hyphens in the names (they confuse some tools and > > underscores are safer). > > > > Two possibilities for repo names were given: > > > > 1) nuttx and nuttx_apps > > > > or > > > > 2) nuttx_rtos and nuttx_apps > > > > Which do we want? > > > > Cheers, > > Nathan > > > > [1] https://lists.apache.org/thread/8fn2m2v8qd3sl9r8jg4bs2f9xq7mwg85 > > >
Re: Can 2 UARTs coexist in nuttx?
- Enable another UART in blue configuration menu, section called Device drivers - It will appear in /dev in NSH as ttySX - Open it in your code and write to it. For examples search in NuttX apps. It is not documented because it is POSIX. On Wed, 11 Aug 2021, 04:59 Sathish Touch energy, wrote: > Hi, > > I am using nuttx, with an S32K144 eval board. > > For debug messages and nsh, uart1 is being used now. > > I need to use another uart for communicating with a host application. > > I want to use UART0 for this purpose. > > Can both UART0 and UART1 be used simultaneously? > > If so, how to enable both of them in nuttx code? > > Thanks and Regards, > Sathish. >
Re: ./tools/configure.sh | find -L | to follow symlinks
Regarding my advice from a few minutes ago. Somebody in
https://github.com/apache/incubator-nuttx/issues/2206#issuecomment-721138548
complains that
the process is not working.
Just to be sure I will test it today and maybe finish that documentation.
If I won't, still just try what is described there. I am sorry for the
inconvenience. It looks a bit complicated, but it is quite simple in the
end.
Am Di., 3. Aug. 2021 um 10:10 Uhr schrieb Maciej Wójcik :
> In general, you probably don't want to change files in the OS repository
> just to attach your board.
>
> I was supposed to document how to do this correctly, more than a half year
> ago. I didn't, but what you need is described in this issue
> https://github.com/apache/incubator-nuttx/issues/2206#issuecomment-721138548
>
> The whole idea is to call `./config.sh` with a relative path. Other than
> this you need to nest your board configuration in particular folder
> structure. I don't remember exactly, but what is in that issue is correct
> and supported.
>
> Am Di., 3. Aug. 2021 um 09:57 Uhr schrieb Simon Filgis <
> si...@ingenieurbuero-filgis.de>:
>
>> Dear all,
>>
>> I have my own board assembled with Atmel SAME70 and I would like to work
>> on
>> the board files "outside" the nuttix structure in a separate folder
>> (custom_board). Now I symlinked my custom_board folder into nuttx:
>>
>> cd ../nuttx/boards/arm/samv7
>> > ln -s ../../../../custom_board/ custom_board
>>
>>
>> This only works if the find command gets a -L (follow symlinks) in
>>
>> function dumpcfgs
>> > {
>> > configlist=`find -L ${TOPDIR}/boards -name defconfig`
>> > for defconfig in ${configlist}; do
>> > config=`dirname ${defconfig} | sed -e "s,${TOPDIR}/boards/,,g"`
>> > boardname=`echo ${config} | cut -d'/' -f3`
>> > configname=`echo ${config} | cut -d'/' -f5`
>> > echo " ${boardname}:${configname}"
>> > done
>> > }
>>
>>
>> Has anybody any concern in adding -L to the find or in general with my
>> approach?
>>
>> Regards,
>>
>> Simon
>>
>> Ingenieurbüro-Filgis
>> USt-IdNr.: DE305343278
>>
>
Re: ./tools/configure.sh | find -L | to follow symlinks
In general, you probably don't want to change files in the OS repository
just to attach your board.
I was supposed to document how to do this correctly, more than a half year
ago. I didn't, but what you need is described in this issue
https://github.com/apache/incubator-nuttx/issues/2206#issuecomment-721138548
The whole idea is to call `./config.sh` with a relative path. Other than
this you need to nest your board configuration in particular folder
structure. I don't remember exactly, but what is in that issue is correct
and supported.
Am Di., 3. Aug. 2021 um 09:57 Uhr schrieb Simon Filgis <
si...@ingenieurbuero-filgis.de>:
> Dear all,
>
> I have my own board assembled with Atmel SAME70 and I would like to work on
> the board files "outside" the nuttix structure in a separate folder
> (custom_board). Now I symlinked my custom_board folder into nuttx:
>
> cd ../nuttx/boards/arm/samv7
> > ln -s ../../../../custom_board/ custom_board
>
>
> This only works if the find command gets a -L (follow symlinks) in
>
> function dumpcfgs
> > {
> > configlist=`find -L ${TOPDIR}/boards -name defconfig`
> > for defconfig in ${configlist}; do
> > config=`dirname ${defconfig} | sed -e "s,${TOPDIR}/boards/,,g"`
> > boardname=`echo ${config} | cut -d'/' -f3`
> > configname=`echo ${config} | cut -d'/' -f5`
> > echo " ${boardname}:${configname}"
> > done
> > }
>
>
> Has anybody any concern in adding -L to the find or in general with my
> approach?
>
> Regards,
>
> Simon
>
> Ingenieurbüro-Filgis
> USt-IdNr.: DE305343278
>
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: [Discuss] Migrate the build system to CMake
Quoting Sebastien: > It it's not broken, dont fix it. > - it works for its intended purposes > - it is pretty complex > - ALL USERS have become used to it Sebastien, what tools are you using for development? Make has such poor support for any tooling. Some IDE's understand it partially, some not at all. By using Make we are rejecting all the help that IDE's offer. NuttX code base is too large to work efficiently without it. Complex is not a feature I think. Yes, people are used to it, because they have to. The same way one can get used to winter or to walk in uncomfortable shoes. > No one will understand the build system anymore I have been looking at the current Make solution for the last few years and I wouldn't say I understand or control it either. Quoting Alin: > I like the cmake idea but we should also consider that cmake will have implications on all projects > that use the NuttX as a base for the SDK or custom projects. I am still stuck with NuttX 7.31 because of changes in the Make build system, so I understand what you are saying. My projects are small and I still don't have resources to migrate applications. I cannot even imagine how big of a burden it is, for developers of larger frameworks, but it shouldn't block progress. I think CMake will pay off over time. Quoting Nathan > Can't a CMake build be an OPTIONAL component for people who want to use it? Quoting Matias > Maintaining two build systems in parallel does not really make sense to me. Matias, just a question, does your work so far collide much with the current Make build system. I could take your branch and put the previous solution back next to your changes. It is hard to convince people to switch until they see that something works well. Quoting Juha > There is no problem to solve here but potential for massive breakage and extra burden > on companies using NuttX to develop real products. This is suggesting that everyone who considers CMake a good idea is an amateur. Yes, every change is a burden, but when projects don't develop, the look... well, like a Make build system. Quoting Ken > CMake is horrible. Don't do it. It's hard to use for beginners, and > hard to use for anyone who isn't just a strong advocate for it. Yea I don't like it either, I don't like either Make or CMake. I don't think that anyone likes them because they are just building systems, they are boring and unrewarding. But regarding beginners, I think you are wrong. One opens a project that uses CMake in an IDE and it works. Open a project that uses Make and it doesn't. After spending a lot of time trying to make it work, it is fine, but it is never perfect. Everyone who starts using NuttX needs to go through this. This is an unnecessary steep learning curve. We could say that this way, we filter out inexperienced people from producing noise in GitHub issues and the Internet in general, but with such an attitude it would be not right to call it an open source project anymore. Quoting Alexander > We cannot get rid of the make in one commit. If we want CMake, it should > grow alongside the make. I agree. Quoting Fotis > For me, cmake would be a no. > The reasons are greatly outlined by Sebastien. > However, I am not very experienced with it. (I just never liked it...) If I don't have experience with something I usually don't express my opinion. Don't feel that I am attacking you much, I just don't understand how this is a valid argument. Maybe you are just modest. It is hard to claim to be experienced with something even after many years of working with it. Yes, I also don't like CMake :) but I know what it brings, so I am fully in favor of it. Quoting Matias > I find it particularly striking > that the original e-mail from Xiang was sent two months ago > requesting others to express any concern and no one responded until > today. This is exactly what I thought when I read it. If some people didn't like it why did they wait for so long? I have a feeling that they didn't believe that you would actually manage to do it :) >From my side, I am trying to not express my opinion if I don't have time to make any real contribution. In this case I didn't have time to help, so I kept silent. > I will therefore will not continue working on this > (you can delete the branch) Come on Matias, no need to behave like this. Also you should wait for the Earth to rotate a bit, so all people involved can wake up, think about it, finally argue a bit with each other. But I understand your disappointment when reading this. I would help you with CMake if I wouldn't be working 14 hours a day trying to finish delayed projects. Yet I was looking forward to a day when I could finally use it. In general I feel like you have a good hunch about good solutions and I am using a lot of them, either trying to update NuttX to a version where you already added something or cherry-picking like crazy. I think that you are doing a good job with CMake here. You definitely
Re: Handling of newbie-oriented fixes
Just fork again from main nuttx repository, to satisfy github. Then a) manually put yout changes back and commit, or b) add your current fork as additional remote, and get your commits from there. If fork doesn't have changes, you can pull it. Otherwise you might try to cherry pick. On Tue, 5 Jan 2021, 22:14 Grr, wrote: > I have several commits with fixes related to newbie issues > > -Avoid compilation crash due to enabling CONFIG_NET without board > networking support > > -Avoid compilation crash due to CONFIG_NET_ICMP_SOCKET missing > NET_READAHEAD > > and so on > > Problem is I can't make a PR on incubator-nuttx because my fork is not from > it but from Peter van der Perk's fork > > What would be the best way to handle this without bothering Peter to > process every one of my fixes? > > TIA > > Grr >
Re: Basic Documentation Update
Hello, I would suggest making merge request to the documentation inside repository. Confluence document could be copied there and then ascii art added. But it is my personal opinion. Not sure what was decided about confluence wiki. Yet, I had an impression that documentation should be gradually moved to the repository. Regarding ascii art itself, why not make a normal diagram. I think there is simple graphing syntax available called mermaid or you could attach svg. -- Maciej On Thu, 31 Dec 2020, 15:48 Grr, wrote: > Hello to all. > > I'm new into NuttX development and I made an ASCII-art function map of > NuttX initialization to hep update and improve > > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+Initialization+Sequence > and I'd like to know of Brennan Ashton thinks it can be incorporated into > his document > > My map is based on startup for stm32f4discovery board and doesn't have > _all_ the functions but covers pretty much all the most important to give a > very good idea of initialization in a graphic manner > > I'd also like to know what's the best practice to update text of the > aforementioned document since there are some parts to be updated according > to this up-to-date map > > I read somewhere I cannot attach file here so please tell me how to share > it > > Thanks in advance >
Re: UPD send delay
In case of board I was working with, the network traffic was handled by low priority work queue. It is probably the same with your network driver. Such work queue has configuration. Maybe you need to change some parameters of it. It might help if you send here your configuration file, or part of it. On Mon, 9 Nov 2020, 13:55 Andrey Shetov, wrote: > Hi, Jukka. > > I'm working with the thread author on a low latency audio processor based > on the STM32H7 chip and can provide some technical details about the issue. > We've used Ethernet config from your repo bitbucket.org/jlaitin/nuttx/ and > integrated it to master branch of Nuttx OS. After that, we've ported > CONFIG_SCHED_CRITMONITOR functionality into H7 platform and have > measured sending and receiving time of UDP packets by inserting bunch of > tracepoints into the driver. Results are little strange - packet receiving > is OK, but actual time of packet _sending_ at 100Mbit/s is about 200 usec. > By "actual time" I mean delay between sendto() and stm32_txdone() > functions. > > For now we are looking the reasons of such delay and ways to reduce it, any > help will be much appreciated. > PS We've already tried to use raw (packet) socket, it reduces the delay a > little, but not significant. > > -> sendto_start_time: 0 usec > stm32_dopoll: 58 usec > stm32_transmit: 93 usec > -> sendto_done_time: 120 usec > stm32_interrupt: 186 usec > ETH_DMACSR_TI: 187 usec > stm32_interrupt_work: 205 usec > stm32_txdone: 207 usec > > > On Sat, Nov 7, 2020 at 8:29 AM Jukka Laitinen > wrote: > > > Hi, > > > > I am not quite sure about from where you measured (and what is your phy > > config), but sending out 1000 bytes will take in theory about 800+ us at > > 10Mbps and 80+ us at 100Mbps, so you probably wouldn't want it to be > > synchronous (you'd like to be able to receive in full duplex at the same > > time when transmit happens). The ethernet driver uses the stm32h7 eth > > block's internal dma for sending. Other ethernet traffic, hubs, switches, > > the network cards.. may cause additional delays. > > > > Handling the interrupt should be fast, but the actual completion happens > > in your thread (waking up from mutex), so this can be delayed by some > > higher priority thread running in your system. > > > > - Jukka > > > > > > S D kirjoitti tiistai 3. marraskuuta 2020: > > > Hello! > > > could you please help a nuttx newbie. > > > I'm using a stm32h7 for my project > > > I'm trying to communicate with "big" Linux machine via direct ethernet > > (UDP), and I see relatively big delays for outgoing packets (with a 1000 > > bytes payload). > > > I see that sendto is executed in about 120usecs, but the actual > transmit > > is seems to be executed much later, and I see the actual transmit > > completion (interrupt) in about 100 more usecs later after return from > > sendto call. > > > > > > I spent a few days reading stm32_ethernet.c driver (and all the other > > stuff it works with) and it seems the system is heavily asynchronous. > > > Could you please tell, Is there a way to send/receive data > > immediately/synchronous if all I need a direct Ethernet connection to > > another device (may be even with raw ethernet frames) ? > > > > > > Thanks! > > > >
Re: sim target failures 10.0 branch
Hi Brennan, I would gladly join you with checking some of the boards in this table. For example I have some nostalgic relation with `hymini-stm32v` my first board :D Just removed the dust from it and flashed with NuttX 10. It is almost working :) (it was hanging on the missing SD card for a minute, what it shouldn't be doing, but started afterwards and displayed the NuttX logo) Maybe we could come up with a concept of board maintainers (people who check few boards of choice before release). There would be a table in documentation with a list of boards and maintainers on the side. It would be visible which are the orphans and maybe people would pick them over time. Am So., 25. Okt. 2020 um 01:35 Uhr schrieb Brennan Ashton < bash...@brennanashton.com>: > In preparation for cutting the release I started running all of the > simulation targets before digging into more hardware testing. There > were quite a few failures, it is possible that some are environment > related, in which case we should document them better, but some look > like clear bugs. I would like to see these addressed or at the very > least acknowledged before we cut the release. > > > https://github.com/apache/incubator-nuttx/issues?q=is%3Aissue+is%3Aopen+label%3Areleases%2F10.0.0++label%3Ablocker > > You can also see my testing sheet here: > > https://docs.google.com/spreadsheets/d/1qMQV_CSN5Ka13_wr73QNo2Uh-NiSumjcwINuc0BkyIs/edit?usp=sharing > > I commit for the 10.1 release wiring up actual integration testing for > these so we have better automation validation beyond just "it > compiles" > > --Brennan >
Re: Color ANSI support in nsh
There is a debug menu of NuttX configuration in which you can enable different levels of logging. You could add an option to differentiate colours based on debug level. I think this would be both great and doable. Then if it would be accepted, expose colorful logs to applications somehow. I wasn't using application level logging recently, just `printf|s. Don't know how it works now, but it should also be doable. On Mon, 17 Aug 2020, 13:34 Christian Catchpole, wrote: > Thanks everyone. There's obviously different levels of how far you take > it. And not just colour, but simple things like "clear screen on NSH > start", which I found useful for one use case at least. Having commands > colour aware as they are in linux is perhaps overkill at this stage. As a > minimum I found coloring the prompt and then returning to regular print was > a small but useful trick. > > As I'm new to NuttX and returning to serious C/systems development perhaps > this is something I'll look into as a trial for getting to know Kconfig and > the NuttX build system. > > Perhaps we could have a prompt color option in Kconfig which defaults to > none. > And clear screen on start which defaults to no. > > CC > > On Mon, 17 Aug 2020 at 21:24, Dave Marples wrote: > > > Guys, chill, it was a joke :-) of course colour has utility for improved > > cognition. Back in the day I remember discussions about if colour > terminals > > would ever take off cos folks couldn't see the point of them. That > argument > > got resolved. > > > > Colour certainly has utility. Small size does too. If we can accommodate > > both (KConfig) then everyone is a winner. > > > > Dave > > > > On Mon, 17 Aug 2020, 07:50 Maciej Wójcik, wrote: > > > > > I am confused a bit. Are you all guys talking about the same thing? If > I > > > understand correctly Christian just wanted to introduce colors to NSH. > > > > > > Colours in the terminal are not about looking good. Colours improve > > > readability. The same text on the screen carries more information. This > > is > > > why everyone is using syntax highlighting in the editor when > programming. > > > > > > It is easier to spot red error and yellow warning than just all black > > text > > > in terminal log. It would be great if there would be native option to > > > enable this, without pdcurses. > > > > > > > > > On Mon, 17 Aug 2020, 08:32 , wrote: > > > > > > > Please do not make technology about looks in functionality it has > > to > > > > work and be solid and has to address its purposes. If all is finished > > and > > > > value is there, one could bring a nice color too it Color is > > throwing > > > > money where functionality died > > > > > > > > Ben > > > > > > > > -Oorspronkelijk bericht- > > > > Van: Alan Carvalho de Assis > > > > Verzonden: zondag 16 augustus 2020 17:02 > > > > Aan: dev@nuttx.apache.org > > > > Onderwerp: Re: Color ANSI support in nsh > > > > > > > > Christian, > > > > > > > > If I'm not wrong NuttX already has this feature to fancy interface if > > you > > > > use of pdcurses library. > > > > > > > > Greg added pdcurses some time ago and Ken Petit added support to use > it > > > > over telnet > > > > > > > > BR, > > > > > > > > Alan > > > > > > > > On 8/16/20, Christian Catchpole wrote: > > > > > Yeah i should have had a poke around before posting on the group. I > > > > > keep finding NuttX has so many features in the Kconfig :) I also > > > > > suggested command history then found my Spresence NSH has history, > so > > > > > obviously i was not the first to think of it. > > > > > I don't want to go TOO crazy with ANSI colours. I'll experiment > with > > a > > > > > few things and then loop back around and see what others think. > > > > > > > > > > Thanks, > > > > > Christian > > > > > > > > > > > > > > > On Sun, 16 Aug 2020 at 22:11, Dave Marples > wrote: > > > > > > > > > >> Hiya, > > > > >> > > > > >> Yes, there's some cheesy simple stuff in there already (mainly to > > > > >> stop the zephyr folks throwing shade cos their terminal is > > prettier). > &g
Re: Color ANSI support in nsh
I am confused a bit. Are you all guys talking about the same thing? If I understand correctly Christian just wanted to introduce colors to NSH. Colours in the terminal are not about looking good. Colours improve readability. The same text on the screen carries more information. This is why everyone is using syntax highlighting in the editor when programming. It is easier to spot red error and yellow warning than just all black text in terminal log. It would be great if there would be native option to enable this, without pdcurses. On Mon, 17 Aug 2020, 08:32 , wrote: > Please do not make technology about looks in functionality it has to > work and be solid and has to address its purposes. If all is finished and > value is there, one could bring a nice color too it Color is throwing > money where functionality died > > Ben > > -Oorspronkelijk bericht- > Van: Alan Carvalho de Assis > Verzonden: zondag 16 augustus 2020 17:02 > Aan: dev@nuttx.apache.org > Onderwerp: Re: Color ANSI support in nsh > > Christian, > > If I'm not wrong NuttX already has this feature to fancy interface if you > use of pdcurses library. > > Greg added pdcurses some time ago and Ken Petit added support to use it > over telnet > > BR, > > Alan > > On 8/16/20, Christian Catchpole wrote: > > Yeah i should have had a poke around before posting on the group. I > > keep finding NuttX has so many features in the Kconfig :) I also > > suggested command history then found my Spresence NSH has history, so > > obviously i was not the first to think of it. > > I don't want to go TOO crazy with ANSI colours. I'll experiment with a > > few things and then loop back around and see what others think. > > > > Thanks, > > Christian > > > > > > On Sun, 16 Aug 2020 at 22:11, Dave Marples wrote: > > > >> Hiya, > >> > >> Yes, there's some cheesy simple stuff in there already (mainly to > >> stop the zephyr folks throwing shade cos their terminal is prettier). > >> At the moment it only highlights commands, responses and errors iirc, > >> but making it more context aware would certainly be niceit's > >> already switched on/off by kconfig option. > >> > >> Regards > >> > >> Dave > >> > >> On Sun, 16 Aug 2020, 12:24 David Sidrane, > >> wrote: > >> > >> > Hi Christian, > >> > > >> > As long as there is a Knob in Kconfig to enable / disable each > >> > feature (that defaults to disable) the impact is 0. > >> > > >> > IIRC there is a history, and some fancy-ness that was added by Dave > >> > a > >> while > >> > ago. Good docs and an example defconfig would will keep it > >> > maintained > >> (and > >> > built). Once we have scripted test running against the sim (or real > >> > HW) test cases will keep it from breaking. > >> > > >> > David > >> > > >> > -Original Message- > >> > From: Christian Catchpole [mailto:christ...@catchpole.net] > >> > Sent: Saturday, August 15, 2020 5:52 PM > >> > To: dev@nuttx.apache.org > >> > Subject: Color ANSI support in nsh > >> > > >> > Hi everyone, > >> > > >> > I have been adding ANSI escape codes for colour support to my app’s > >> console > >> > output and have been experimenting with adding it to nsh itself. At > >> > a minimum to colour the prompt. > >> > > >> > I had been thinking this is something i could develop and propose > >> > to come back into the mainline as a nsh kconfig option. > >> > > >> > But before i do, the obvious question is, has this been proposed > >> > before > >> and > >> > are there reasons we wouldn’t want this in NuttX? > >> > > >> > I’m also thinking it would be good to have a single line of command > >> > history. Other configurable options could be clear screen on nsh > >> > entry (I added this as my app was using ANSI line positioning and > >> > resets back into nsh looked messy). There are all sorts of fun > >> > things which could be done with ANSI terminal emulation. > >> > > >> > Thanks, > >> > See you all tonight. Where you’ll see my demo going crazy with ANSI > >> colour > >> > codes. > >> > > >> > Christian > >> > > >> > > > >
Re: Markdown READMEs?
This PR changes all READMEs in `apps` repository into Markdown https://github.com/apache/incubator-nuttx-apps/pull/337 More in the description. Am Di., 21. Juli 2020 um 20:37 Uhr schrieb Adam Feuer : > Matias, > > Yes, I have the NuttX.html file partially converted. I'll see if I can get > that a little close today and submit a PR to your branch. > > -adam > > On Tue, Jul 21, 2020 at 11:23 AM Matias N. wrote: > > > Ok, got it sooner than expected. The docs are published to: > > https://v01d.github.io/incubator-nuttx/ < > > https://v01d.github.io/incubator-nuttx/docs/index.html> > > Right now as we're working on a "docs" branch in this fork, you can see > it > > generated here: > > https://v01d.github.io/incubator-nuttx/docs/index.html > > On pull-requests it only does the build and not the publish (not tested > > this yet). Would be cool to have PRs viewable somewhere but that is more > > complex. > > > > Now we could work a bit on the content. I would iterate on a proposed > > structure and put some placeholders. > > Adam, you mentioned you wanted to convert on HTML file for demonstration > > purposes. Do you want to do that? > > > > Best, > > Matias > > > > On Tue, Jul 21, 2020, at 15:11, Matias N. wrote: > > > Hi, > > > yes, we have CI building sphinx already. I'm now trying to get this be > > published via GitHub pages using a subdirectory per version (version > would > > be "master" or the tip of each release or the tag name). Anyways, this is > > not how it would work exactly in the end since the website repo would > take > > care of this. But probably some components of the CI system would be > > similar. Also, this allows to have something to show when by put a bit of > > content there for demonstration purposes. > > > > > > Will let you know when I get something to show. > > > > > > Best, > > > Matias > > > > > > On Tue, Jul 21, 2020, at 15:02, Adam Feuer wrote: > > >> Brennan, > > >> > > >> Cool, that's awesome. I didn't know that discussion was going on in > the > > PR. > > >> :) > > >> > > >> -adam > > >> > > >> On Tue, Jul 21, 2020 at 10:55 AM Brennan Ashton < > > bash...@brennanashton.com> > > >> wrote: > > >> > > >> > On Tue, Jul 21, 2020, 10:51 AM Adam Feuer wrote: > > >> > > > >> > > Matias, Maciej, > > >> > > > > >> > > Ok, I looked into doing a Sphinx build of RST and Markdown via > > Github and > > >> > > publishing to Github pages automatically. People have done it, but > > it's a > > >> > > bit more complicated than I thought. I'll see if I can get it > > worked out > > >> > in > > >> > > my repo first and then we can go from there. It will take me a few > > days > > >> > > because I have other stuff going on too. > > >> > > > > >> > > -adam > > >> > > > > >> > > > >> > Hey Adam yesterday I submitted the PR for doing the build via GitHub > > >> > Actions and it generates the artifacts. I would not worry too much > > about > > >> > GitHub pages since we need to get it attached to the Apache system. > > >> > > > >> > You can see some of the discussion here > > >> > > https://github.com/v01d/incubator-nuttx/pull/1#issuecomment-661952429 > > >> > > > >> > --Brennan > > >> > > > >> > > >> > > >> -- > > >> Adam Feuer > > >> > > > > > > > > -- > Adam Feuer >
Re: Markdown READMEs?
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 and I was suggesting reformatting them. Am Fr., 17. Juli 2020 um 17:59 Uhr schrieb Matias N. : > > > 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 does not have to affect the other. In fact, maybe RST is better for the > doc-repo, since it supports richer syntax more apropriate for building > documentation. > > Best, > Matias
Re: Markdown READMEs?
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 - https://github.com/lvgl/lvgl/blob/master/README.md - https://github.com/ARMmbed/littlefs/blob/master/README.md - https://github.com/warmcat/libwebsockets/blob/master/README.md `.md` extension stands for Markdown. It seems to be the de-facto standard. > Plain text is the best on cmd line environments (ssh/putty) Markdown is still a plain text. > I would second that: (1) plain text with no embedded tags, and (2) no new tools. No new tools are required. The only difference is that some editors and GitHub will display it in more readable way. It is almost like the previous text format that is already in the repo, it is just standardized and widely adopted. Syntax is non intrusive. It clearly separates code fragments with backticks. Renders headers and lists in a more readable way. Allows for a table, image and clickable link from time to time. It also allows separating code fragments and then it enables syntax-highlighting. This improves readability greatly. The format is actually simpler than the current one. Regarding RST format: It is a similar concept. It just seems to be a little bit more complex to help writing documentation of code in larger projects. I am seeing it for the first time, but I am also happy to help with Adam Feuer effort if you would decide to use this one. What I think would be great, is to pick any of this two standards. I was trying to parse existing documentation how it is now and it is problematic. The conventions are not always followed and fragments of code randomly glue to text when I am trying to retrieve paragraphs from it. My parsing issue is not relevant, but standardization is important. And Markdown is more readable, thanks to support from modern tools like VSCode or GitHub/Lab. While still being readable in Vim through SSH. Am Fr., 17. Juli 2020 um 16:49 Uhr schrieb Matias N. : > 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: > https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet > > Regarding using READMEs as the backend for the main NuttX documentation, > as I mentioned this is not the best idea because it would indeed require > adding extra tags (like links to images, etc). READMEs should be used for > technical information to be read when entering a subdirectory. > > On the other hand, Markdown or any other more complete format (like > ReStructuredText) is a very good format for maintaining documentation > outside of the main nuttx repo. In this case, a doc-repo with CI could be > maintained, exactly the same as the nuttx website repo (in fact, it could > be the same one). The website already requires ruby (jekyll) to be built. > > So, in summation: > - I would use Markdown (without unnecessary tags) on the READMEs > - I would start a doc repo (or reuse the website repo) and create a nice > looking documentation (accessible as subdirectory or subdomain of nuttx > website) based on Markdown or any other useful format and some website > generator like readthedocs or whatever works best. > > Best, > Matias > > On Fri, Jul 17, 2020, at 11:38, Alin Jerpelea wrote: > > +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 is still readable > (markdown?) > > > > > > > > anything that requires writing explicit tag in the readme text files > > > > should be avoided imho. > > > > > > > > > > > > also, anything that requires non-trivial tools for reading is to be > > > > excluded. > > > > > > > > asciidoctor requires ruby > > > > > > > > Not sure that throwing more tools in the mix is even useful... > > > > > > > > > > > > Sebastien > > > I would second that: (1) plain text with no embedded tags, and (2) no > > > new tools. > > > > > >
Re: Markdown READMEs?
> what do you think about using Markdown for README files? Since the project was very conservative so far, I used regular expression to parse some existing files into Markdown. Although it is not completely reliable. I also think that markdown in repository would be great. Even trying to sneak in some first Markdown file already :D https://github.com/apache/incubator-nuttx-apps/blob/2fdd7529251919315bce62ceb0b130d7f135c506/graphics/lvgl/README.md > One of the reasons I really like the Zephyr docs... Yes, it is also my impression. This is why I am trying to create interactive documentation right now. Kconfig NuttX data is extracted using the same library as Zephyr does. Here are some existing READMES parsed into markdown http://nuttx-config.nxtlabs.pl/#/apps. To be more specific apps/*/README.txt files. I would like to add boards section as well in form of tiles with pictures and board configuration support comparison inspired by this https://node.green. Complete tree of READMEs with a search is also in my mind https://gitlab.com/nuttx-upm/kconfig-browser/web-ui/-/issues/25 How it works: currently there is a pipeline which runs for multiple tags/branches (master, releases/9.1, releases/9.0, ...) and extracts data into static JSON. Then Vue.js application is trying to render it. Pipeline triggers automatically weekly to keep the master fresh. Am Do., 16. Juli 2020 um 03:55 Uhr schrieb Matias N. : > On Wed, Jul 15, 2020, at 22:45, Brennan Ashton wrote: > > I would be huge fan of this. It makes it a lot more approachable, I had > > started converting the main readme in particular but I did not get very > > far. It's a lot of work. > > I can help with that if you want > > > Did you see Adams work here > > https://nuttx-companion.readthedocs.io/en/latest/ > > > > I thought it would be really nice to integrate the board list with the > > readme content into it. (While keeping the content readable in the source > > control). > > Yes, I was actually imagining some sort of CI command on the website (not > sure the wiki handles that) that could build a list with all boards > containing a README, link to it and display it there nicely formatted. > Something like readthedocs could possibly do it already, not sure. > > One of the reasons I really like the Zephyr docs is because of this, you > can see how they present their supported boards there: > https://docs.zephyrproject.org/latest/boards/index.html > Even further, each board description has a nice picture, specification > list, etc. I thank that would be really useful and easy to do (the picture > could be stored in some stable location and the README simply link to it). > > Best, > Matias
Re: NuttX 9.X C++11 Support
Right, newlib is C library. I feel dumb right now, because it seems I didn't know what I was using. But it is still something that C++ library provided by ARM GCC distribution was only working for me with both main package of ARM GCC and additional ARM newlib package installed. I was not digging into it because it was working. Maybe C++ library which they provide doesn't work without newlib. As Greg said, don't use it. I will also explore other options now. On Sat, 20 Jun 2020, 19:08 Peter van der Perk, wrote: > Okay to clarify newlib is only the C library right? I'm using the > gcc-arm-none-eabi-9-2019-q4 toolchain which it seems it comes with > newlib libc but as far as I know I'm not linking to it. Furthermore > I'm interesting in std C++11 functionality for portability not just > the the C++11 dialect. > > About libcxx it seems to be only working partially with my current > toolchain (gcc-arm-none-eabi-9-2019-q4): > With minimal testing I'm already getting these problems: > - iostream gives linker errors with locale e.g. "multiple definition > of `duplocale'" > - optional.cxx doesn't compile, although disabling it can compile further > - linking with libsupc++ gives linker errors e.g. > "std::set_unexpected(void (*)())'" > - GCC9 requires to enable fpermissive CXX flags > > Do I have to use another toolchain? (Although NuttX getting started > guide is reffering to gcc-arm-none-eabi-9) or do I have to downgrade > my NuttX kernel (libcxx hasn't seen any update in 2-3 years maybe that > has to do with?) > > > Quoting Gregory Nutt : > > > Use of newlib with NuttX should be avoid. It is not binary > > compatible with NuttX. See > > > https://cwiki.apache.org/confluence/display/NUTTX/Integrating+with+Newlib > > > > This should be used instead: > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629545 > > > > On 6/19/2020 3:54 PM, Maciej Wójcik wrote: > >> I was using newlib. It is bundled with ARM GCC toolchain, at least on > >> Ubuntu and Arch. Worked out of the box, except I remember having minor > >> build issues from time to time, when adding additional headers. This > >> question was appearing here in the past. I am also not sure what is the > >> official answer. > >> > >> If I remember correctly many libraries work, but none of them is > supported > >> by NuttX. By not supported, I mean people are still trying to help with > >> issues, but there is no official recommendation nor guarantee. > >> > >> C++ STL implementations are big projects, constantly changing and > >> toolchains are not always sane in terms which headers they are trying to > >> use. For example they may take a bit of NuttX libc, and mix it with a > bit > >> of its own headers. Then feed it to C++ STL giving unpredictable result > in > >> the end. > >> > >> I am not sure if anything that I am writing above makes sense :D In > >> practice newlib was working, but probably not good for critical > >> applications. I would also be happy to hear what is the official > statement > >> on it now. > >> > >> By the way, such GCC with newlib offers all higher C++ standards, not > just > >> C++11. > >> > >> On Fri, 19 Jun 2020, 23:13 , wrote: > >> > >>> For a personal project I want to use C++11, however which C++ library > >>> works best for that? Looking at the NuttX documentation it refers me > >>> to a "Contemporary port of the C++11 LLVM libcxx", but this guide > >>> ( > >>> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629545 > ) > >>> > >>> is based on a older NuttX fork. > >>> > >>> Nevertheless I've tried to follow the steps on NuttX Master, which > >>> works partially works with some extra modifications (had to enable > >>> fpermissive), after basic testing it seems C++11 threads () is > >>> working. But when I use std::cout () compiling gives me the > >>> following linker error: > >>> > >>> arm-none-eabi-ld: > >>> /home/peter/brickpoweredugv/nuttx/staging/libxx.a(ios.o): in function > >>> `std::char_traits::eof()': > >>> > /home/peter/brickpoweredugv/nuttx/include/libcxx/support/xlocale/__nop_locale_mgmt.h:20: > >>> multiple definition of `duplocale'; > >>> > /home/peter/brickpoweredugv/nuttx/staging/libapps.a(connector.home.peter.brickpoweredugv.apps.brickpoweredugv.o):/home/peter/brickpoweredugv/nuttx/include/libcxx/support/xlocale/__nop_locale_mgmt.h:20: > >>> first defined > >>> here > >>> arm-none-eabi-ld: > >>> /home/peter/brickpoweredugv/nuttx/staging/libxx.a(ios.o): in function > >>> `freelocale': > >>> > >>> Thus my question is, is someone actively using libcxx with C++11 in > >>> upstream NuttX and does it work well? Or do I have to use another > >>> libc++ implementation > >>> > >>> Yours sincerely, > >>> > >>> Peter van der Perk > >>> > >>> > > > >
Re: NuttX 9.X C++11 Support
I was using newlib. It is bundled with ARM GCC toolchain, at least on Ubuntu and Arch. Worked out of the box, except I remember having minor build issues from time to time, when adding additional headers. This question was appearing here in the past. I am also not sure what is the official answer. If I remember correctly many libraries work, but none of them is supported by NuttX. By not supported, I mean people are still trying to help with issues, but there is no official recommendation nor guarantee. C++ STL implementations are big projects, constantly changing and toolchains are not always sane in terms which headers they are trying to use. For example they may take a bit of NuttX libc, and mix it with a bit of its own headers. Then feed it to C++ STL giving unpredictable result in the end. I am not sure if anything that I am writing above makes sense :D In practice newlib was working, but probably not good for critical applications. I would also be happy to hear what is the official statement on it now. By the way, such GCC with newlib offers all higher C++ standards, not just C++11. On Fri, 19 Jun 2020, 23:13 , wrote: > For a personal project I want to use C++11, however which C++ library > works best for that? Looking at the NuttX documentation it refers me > to a "Contemporary port of the C++11 LLVM libcxx", but this guide > ( > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629545) > > is based on a older NuttX fork. > > Nevertheless I've tried to follow the steps on NuttX Master, which > works partially works with some extra modifications (had to enable > fpermissive), after basic testing it seems C++11 threads () is > working. But when I use std::cout () compiling gives me the > following linker error: > > arm-none-eabi-ld: > /home/peter/brickpoweredugv/nuttx/staging/libxx.a(ios.o): in function > `std::char_traits::eof()': > /home/peter/brickpoweredugv/nuttx/include/libcxx/support/xlocale/__nop_locale_mgmt.h:20: > multiple definition of `duplocale'; > /home/peter/brickpoweredugv/nuttx/staging/libapps.a(connector.home.peter.brickpoweredugv.apps.brickpoweredugv.o):/home/peter/brickpoweredugv/nuttx/include/libcxx/support/xlocale/__nop_locale_mgmt.h:20: > first defined > here > arm-none-eabi-ld: > /home/peter/brickpoweredugv/nuttx/staging/libxx.a(ios.o): in function > `freelocale': > > Thus my question is, is someone actively using libcxx with C++11 in > upstream NuttX and does it work well? Or do I have to use another > libc++ implementation > > Yours sincerely, > > Peter van der Perk > >
Re: NuttX config browser
They released today mentioned IDE https://os.mbed.com/blog/entry/mbed-studio-1-release It is literally vscode with few plugins. We could go the same way and do NuttX Studio :) For the beginning I could just provide instructions on how to use vscode with NuttX both for local and remote development. I was already using vscode for NuttX development, for some time, and it has good C/C++ support in comparison to other IDEs. With such instructions, we can identify what are the main issues and try to address them. Also PlatformIO and Mbed Studio plugins might be open-source, then we could just recommend them if they work or try to fork. Am Mo., 1. Juni 2020 um 13:46 Uhr schrieb Xiang Xiao < xiaoxiang781...@gmail.com>: > vscode may a good choice here: > https://code.visualstudio.com/ > It is totally free, open source and run on macOS/Linux/Windows > Many 3rd party tool build around vscode(e.g. PlatformIO): > https://platformio.org/platformio-ide > And github announce a new IDE base on vscode recently: > > https://github.com/features/codespaces/?utm_source=announcement_medium=blog_campaign=satellite-product-recap > The best thing is that online version has the full feature as the local > version because vscode is built from JS, CSS, and HTML. > > > -Original Message- > > From: Maciej Wójcik > > Sent: Monday, June 1, 2020 11:23 AM > > To: dev@nuttx.apache.org > > Subject: Re: NuttX config browser > > > > Hello Alan, > > > > A suggestion: when the user click on the option it should be nice to > > > see the Help for that option. > > > > > > Sure, I will add a side pane. > > > > Regarding online IDE. I was trying few times to switch to online > development. The problem is that to debug or even to connect to nsh, > > one still needs local software and local copy of entire project. Which > is against the basic reason why we would like to develop online. It > > is also a bit difficult to come up with own, custom online IDE. It is > simply a lot of work, for a team of people. > > > > That being said I can easily imagine using existing online IDE to > develop NuttX project. It could be just described how to do it efficiently. > > For example git repository can be cloned to GitLab and opened with their > IDE. > > Then binary comes from pipeline which can be flashed to the > microcontroller. Some simple client can be created which automates > > flashing. Still the issue of debugging remains. > > > > I will take a look at MBED and see how did they solve the issue. > > > > Am So., 31. Mai 2020 um 22:09 Uhr schrieb Alan Carvalho de Assis < > > acas...@gmail.com>: > > > > > Hi Maciej, > > > > > > A suggestion: when the user click on the option it should be nice to > > > see the Help for that option. > > > > > > Do you think it could be possible to do it? > > > > > > Did you test MBED platform in the browser ever? They have an online > > > IDE where people can create an application, compile it and load the > > > firmware in the board. > > > > > > It should be nice if we could have a way to compile NuttX in the > > > browser, like MBED is doing for a long time (more than 8 years at > > > least). > > > > > > BR, > > > > > > Alan > > > > > > On 5/31/20, Maciej Wójcik wrote: > > > >> > > > >> Maciej's tool is much easier to use. Maciej has several other cool > > > >> NuttX tools. > > > > > > > > > > > > Thank you Greg for a good word. I will work on this configuration > > > > browser more and I am glad to contribute it if the community will > find it useful. > > > > Regarding the other tools, I had one more project but I > > > > overcomplicated > > > it > > > > and it ended up nowhere. I am still working on it from time to time, > > > > but > > > I > > > > can't promise it will ever be production ready. > > > > > > > > Am So., 31. Mai 2020 um 19:18 Uhr schrieb spudaneco > > > > > > >: > > > > > > > >> The configuration document he is referring to is not in the > repository. > > > >> I > > > >> used to create it only for releases using a custom tool at > > > >> tools/mkconfigvars.shMaciej's tool is much easier to use.Maciej has > > > >> several other cool NuttX tools. In a meritocracy, I think > > > >> contributing these to the project would score pretty high (hint, > > &g
Re: NuttX config browser
Hello Alan, A suggestion: when the user click on the option it should be nice to > see the Help for that option. Sure, I will add a side pane. Regarding online IDE. I was trying few times to switch to online development. The problem is that to debug or even to connect to nsh, one still needs local software and local copy of entire project. Which is against the basic reason why we would like to develop online. It is also a bit difficult to come up with own, custom online IDE. It is simply a lot of work, for a team of people. That being said I can easily imagine using existing online IDE to develop NuttX project. It could be just described how to do it efficiently. For example git repository can be cloned to GitLab and opened with their IDE. Then binary comes from pipeline which can be flashed to the microcontroller. Some simple client can be created which automates flashing. Still the issue of debugging remains. I will take a look at MBED and see how did they solve the issue. Am So., 31. Mai 2020 um 22:09 Uhr schrieb Alan Carvalho de Assis < acas...@gmail.com>: > Hi Maciej, > > A suggestion: when the user click on the option it should be nice to > see the Help for that option. > > Do you think it could be possible to do it? > > Did you test MBED platform in the browser ever? They have an online > IDE where people can create an application, compile it and load the > firmware in the board. > > It should be nice if we could have a way to compile NuttX in the > browser, like MBED is doing for a long time (more than 8 years at > least). > > BR, > > Alan > > On 5/31/20, Maciej Wójcik wrote: > >> > >> Maciej's tool is much easier to use. Maciej has several other cool NuttX > >> tools. > > > > > > Thank you Greg for a good word. I will work on this configuration browser > > more and I am glad to contribute it if the community will find it useful. > > Regarding the other tools, I had one more project but I overcomplicated > it > > and it ended up nowhere. I am still working on it from time to time, but > I > > can't promise it will ever be production ready. > > > > Am So., 31. Mai 2020 um 19:18 Uhr schrieb spudaneco >: > > > >> The configuration document he is referring to is not in the repository. > >> I > >> used to create it only for releases using a custom tool at > >> tools/mkconfigvars.shMaciej's tool is much easier to use.Maciej has > >> several > >> other cool NuttX tools. In a meritocracy, I think contributing these to > >> the project would score pretty high (hint, hint, hint)Sent from Samsung > >> tablet. > >> Original message From: Brennan Ashton < > >> bash...@brennanashton.com> Date: 5/31/20 11:04 AM (GMT-06:00) To: > >> dev@nuttx.apache.org Subject: Re: NuttX config browser On Sun, May 31, > >> 2020, 9:17 AM Maciej Wójcik wrote:> That document is > >> old, from NuttX 8.2 and needs to be updated.>>> Yes, now I remember that > >> there was some page with configuration options. I> think it serves the > >> purpose. It could be auto generated using CI, then it> wouldn't be > >> outdated. Still I thought it could be a bit more interactive>It is built > >> via CI on every build, but only hosts the latest releaseversion not > >> master.Maybe there is a regeneration step that's actually missing... I > >> will > >> needto look at that, right now we just issue the inlining in the docs > >> build.--Brennan> > > >
Re: NuttX config browser
> > Maciej's tool is much easier to use. Maciej has several other cool NuttX > tools. Thank you Greg for a good word. I will work on this configuration browser more and I am glad to contribute it if the community will find it useful. Regarding the other tools, I had one more project but I overcomplicated it and it ended up nowhere. I am still working on it from time to time, but I can't promise it will ever be production ready. Am So., 31. Mai 2020 um 19:18 Uhr schrieb spudaneco : > The configuration document he is referring to is not in the repository. I > used to create it only for releases using a custom tool at > tools/mkconfigvars.shMaciej's tool is much easier to use.Maciej has several > other cool NuttX tools. In a meritocracy, I think contributing these to > the project would score pretty high (hint, hint, hint)Sent from Samsung > tablet. > Original message From: Brennan Ashton < > bash...@brennanashton.com> Date: 5/31/20 11:04 AM (GMT-06:00) To: > dev@nuttx.apache.org Subject: Re: NuttX config browser On Sun, May 31, > 2020, 9:17 AM Maciej Wójcik wrote:> That document is > old, from NuttX 8.2 and needs to be updated.>>> Yes, now I remember that > there was some page with configuration options. I> think it serves the > purpose. It could be auto generated using CI, then it> wouldn't be > outdated. Still I thought it could be a bit more interactive>It is built > via CI on every build, but only hosts the latest releaseversion not > master.Maybe there is a regeneration step that's actually missing... I will > needto look at that, right now we just issue the inlining in the docs > build.--Brennan>
Re: MSYS2 build slow
Thanks for explanation. I went through that PR right now. I was just reporting as a good citizen :) I will check Issue pane next time before spamming.
NuttX config browser
Hello, On many occasions I want to lookup configuration options in NuttX and I found it inconvenient to run `menuconfig` for this. So I quickly created a small web interface and deployed it here http://nuttx-config.nxtlabs.pl It allows browsing and simple filtering of configuration entries. It searches in keys, titles and descriptions. Shows only keys and titles, for performance reasons. I would also like to add a side pane which shows more details about selected entry and allows jumping between related entries. Right now something is missing to make it human friendly. Am I not reinventing a wheel here? How do you handle this? Would community benefit from such UI?
Re: MSYS2 build slow
> > PR 1149 has been merged. That means that the incdir.c program has now > been incorporated into the build system. There might be some regression within this solution. When I simply clone and configure NuttX, I get a repeated error. It might be related to recent change mkdir test cd test git clone https://bitbucket.org/nuttx/nuttx.git git clone https://bitbucket.org/nuttx/apps.git cd nuttx $ ./tools/configure.sh stm32f4discovery:nsh Copy files Select CONFIG_HOST_LINUX=y Refreshing... /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found Am Sa., 30. Mai 2020 um 04:25 Uhr schrieb Gregory Nutt : > Johannes, > > PR 1149 has been merged. That means that the incdir.c program has now > been incorporated into the build system. It all checks out: I have > pretty thoroughly verified it on Cygwin and Abdelatif and Alan Carvalho > de Assis have checked it out well on Linux. The PR also passes all of > the PR build checks which verifies that it works correctly with Linux > and macOS. > > The only untested platform is MSYS and there could very well be issues > there. I have MSYS2 installed on two systems. I tried testing on my > laptop tonight but there is something screwed up in the MSYS2 > installation. I have both MSYS2 and Cygwin installed and I am thinking > that when I build with Cygwin , it messes up the MSYS2 configuration > (and vice versa). They share the same repository files. I am not sure > what is going on but I was not able to verify on MSYS2. I will try > again on my desktop in the morning. > > If you find problems, you can be pretty much assured that the problem is > in tools/incdir.c and I will work with you to resolve any issues that > you run across. If you do have problems, try using 'make V=1'. That > will show us the arguments to and the output from incdir.exe. > > Greg > >
Re: Should we relax precheck a little bit?
Are you sure that clang-format cannot indent macros? What about IndentPPDirectives: PPDIS_AfterHash It also treats the outmost macro in headers in a special way. On Sat, 14 Mar 2020, 01:03 Adam Feuer, wrote: > David, > > Re: whatstyle, I ran it overnight on the c files in sched/ and came up with > a clang-format that does somewhat ok. Thanks for pointing that program out. > > By looking at the output of the diff, I learned a lot about how hard it is > to manually format programs. :) > > Anyway, the biggest problem with clang-format seems to be the way it > handles C-macros. In NuttX, they are often indented like this: > > #ifdef ... > # define ... > # ifdef ... > #define > # endif > #endif > > Peter Van Der Perk also mentioned this. There's no stock way to make > clang-format do that. Maybe a post-processing script that only looked at > these macros would work. Or a contribution to clang-format. I'll think > about it some more. > > -adam > > On Sun, Mar 8, 2020 at 3:40 AM David Sidrane > wrote: > > > Hi Adam, > > > > Have a look at https://github.com/mikr/whatstyle > > > > I got furthest with clang-format and it. It may be we get a 95% of the > way > > there with it and we can add a backend secondary scripts. > > > > I was unable to convince Greg to create a master template so my approach > > was > > to combine all the files and run it on the set so it would get all the > > constructs at once. > > > > David > > > > -- > Adam Feuer >
