Re: [OT] WebAssembly Micro Runtime

On Sun, Jul 5, 2020 at 8:48 AM Alan Carvalho de Assis wrote: > Please let me know if someone here knows something about it: > > https://github.com/bytecodealliance/wasm-micro-runtime (snip) > Linux, Zephyr, MacOS, VxWorks, AliOS-Things, Intel Software Guard > Extention (Linux), Android > > >

Re: Help with Apache Github Invite

On Thu, Jul 2, 2020 at 1:16 PM Anthony Merlino wrote: > Is there an infra email address I should use to get help with this? Hi Anthony, It sounds to me like something fell through a crack somewhere. I think you should email us...@infra.apache.org. Sorry you're having all these issues... Hopefu

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC1 release

On Thu, Jul 2, 2020 at 1:12 PM Nathan Hartman wrote: > Summary: > +1 to release > > Development system: Linux > > Verified: > * Signatures (note GPG reports the key is expired) Correction, follow-up: I re-imported the key. GPG no longer reports the key as expired. My vot

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC1 release

On Tue, Jun 30, 2020 at 1:58 AM Brennan Ashton wrote: > Apache NuttX (Incubating) 9.1.0 has been staged under [1] and it's time > to vote on accepting it for release. If approved we will seek final > release approval from the IPMC. Voting will be open for 72hr. This RC > replaces RC0 which was ne

Re: Board report due by July 1st

On Wed, Jul 1, 2020 at 7:23 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > Hi, > > I filled in some blanks. The report is due today but we still have > some time for last minute changes. Thanks, the changes look good. I'm away from my computer today; could you submit the rep

Re: [DISCUSS] NuttX 9.1 RC1

On Mon, Jun 29, 2020 at 6:04 PM Brennan Ashton wrote: > I held off on cutting the release yesterday since not everything had > been backported yet and I had not heard of any other testing. > > There is one remaining PR for a backport which I just opened > https://github.com/apache/incubator-nuttx/

Fwd: Announcing ApacheCon @Home 2020

Perhaps this is an opportunity to present some of the materials that would have been presented at the NuttX conference that was canceled due to the virus? Forwarded message below... -- Forwarded message - From: Rich Bowen Date: Mon, Jun 29, 2020 at 11:19 AM Subject: Announcing Apa

Re: [DISCUSS] NuttX 9.1 RC1

On Fri, Jun 26, 2020 at 1:48 PM Brennan Ashton wrote: > Hey everyone, > There were several bugs found on the RC0 so we will not be moving forward > with that release candidate and will be creating RC1. I had suggested a > few days ago creating the release today, but as we merged some changes > y

Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release

On Fri, Jun 26, 2020 at 9:35 AM Jerpelea, Alin wrote: > Hi Justin, > > I can confirm that the latest branch looks good > We should create RC1 wih the fixes included to start the testing and > voting for RC1 What about the bug report about mm_realloc() reported by a user on 24 Jun: https://list

Re: Creating 9.1.0-RC0

On Mon, Jun 22, 2020 at 10:13 PM Brennan Ashton wrote: > On Mon, Jun 22, 2020, 5:38 PM Nathan Hartman > wrote: > > > On Mon, Jun 22, 2020 at 4:46 PM Abdelatif Guettouche > > wrote: > > > I created a PR copying the release notes from Confluence to ReleaseNote >

Re: Creating 9.1.0-RC0

On Mon, Jun 22, 2020 at 4:46 PM Abdelatif Guettouche wrote: > I created a PR copying the release notes from Confluence to ReleaseNote file. > I did not copy the "Compatibility Concerns" part, that's valuable > information but I don't think it belongs to that file, just because > there is a lot of

Board report due by July 1st

We are scheduled to submit our board report by July 1st. I have created a Confluence page [1] with some initial content. Please review and make any additions/changes/corrections. [1] https://cwiki.apache.org/confluence/display/NUTTX/July+2020 Cheers, Nathan

Re: Creating 9.1.0-RC0

On Mon, Jun 22, 2020 at 10:35 AM Gregory Nutt wrote: > I created PR 1277 to add that to documentation: > > > > https://github.com/apache/incubator-nuttx/pull/1277 > The Confluence landing page needs to be updated too (usually not more > than half dozen words). > Done. Thanks for the reminder.

Re: Creating 9.1.0-RC0

On Mon, Jun 22, 2020 at 7:01 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > > With regards to bringing the release notes to the repo, that needs to > go to master then backported to the release branch. Are we all on the > same page with this? +1 We also need to update a cou

Re: The new Apache NuttX Logo

On Fri, Jun 19, 2020 at 9:47 AM Nathan Hartman wrote: > On Fri, Jun 19, 2020 at 9:25 AM Gregory Nutt wrote: > > NuttX was created in Costa Rica so an animal from Costa Rica does not > > seem in appropriate. Here the most beloved animals are (1) the > > rainforest frog

Re: The new Apache NuttX Logo

On Fri, Jun 19, 2020 at 9:25 AM Gregory Nutt wrote: > NuttX was created in Costa Rica so an animal from Costa Rica does not > seem in appropriate. Here the most beloved animals are (1) the > rainforest frogs, the red-eyed rain forest frog in particular: In addition to real animals, we could con

Re: The new Apache NuttX Logo

On Thu, Jun 18, 2020 at 7:43 AM Erdem MEYDANLI wrote: > I wanted to revive this discussion. As I stated before, I and a friend of > mine (a graphical artist.) will start working on this. But, > > - What's the deadline for this? (A deadline is a powerful force for > motivation.) Feel free to pro

Re: SAMA5D27 SDMMC support branch

On Wed, Jun 17, 2020 at 5:49 PM Adam Feuer wrote: > SDMMC write is working now too. So the driver can do the following: > >- Non-DMA read and write >- DMA read and write in SDMA mode >- 1 bit bus >- 4 bit bus (widebus) >- up to 25Mhz > > I'm going to work on cleanup, documenta

Re: release branches/tags

On Mon, Jun 15, 2020 at 3:41 PM Matias N. wrote: > Functionally, yes. But git has troubles recognizing that the cherry-picked > commits are the same on master and generates conflicts. The merge would > solve this in theory, since the release branch tip would end up matching a > commit on master.

Re: Release 9.1

On Mon, Jun 15, 2020 at 8:58 AM Abdelatif Guettouche wrote: > Hi all, > > D-Day; I'll go ahead and create the branches. Thank you! I went ahead and created a blank release notes wiki for the *next* release, 9.2, here: https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.2 If there's anythi

Re: Hold off merging PRs

On Sun, Jun 14, 2020 at 11:04 PM spudaneco wrote: > I see a few new PRs coming in. I want to remind everyone that tomorrow we > plan the branch for release/9.1. If committers could hold off merging > until that branch is in place, the I think we have a chance for a good > release candidate!Than

Re: MSYS2 build slow

On Sun, May 31, 2020 at 12:41 PM Nathan Hartman wrote: > FWIW the build has become noticeably faster for me with latest master: > 1m21s now. Before, the build consistently took about 1m50s. So that's > 30 seconds saved. I build on Linux. I just wanted to follow up on this and say t

Re: SAMA5D27 SDMMC support branch

On Thu, Jun 11, 2020 at 5:26 PM Adam Feuer wrote: > This module does have a 50Mhz SDIO interface, so if it can use 4 bit mode, > it could work. However, the ATWIL3000 Linux driver on Github > does not appear to have an open > license– all the code is marked "

Re: New Wiki Page

On Thu, Jun 11, 2020 at 10:07 AM Gregory Nutt wrote: > Why Can't Kernel Threads Have pthreads? > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=158862687 Thank you! Nathan

Re: Organising Release Notes for 9.1

On Sun, Jun 7, 2020 at 9:42 PM Brennan Ashton wrote: > Just a quick update, all of the OS PRs have been gone through (352). > Thanks Abdelatif for helping out just now, it was nice to see that > this workflow seemed to actually work quite well even with both of us > editing the board and wiki doc

Re: [DISCUSS] requirements for commit messages and PRs

On Thu, Jun 4, 2020 at 7:19 PM Jukka Laitinen wrote: > But the template in the commit... please, no. I have had enough of those > in big companies and in the end they are just harmful. I agree with that!! We should not be too rigid and complicated. The more I think about it, the more I like Gr

Re: [DISCUSS] requirements for commit messages and PRs

On Thu, Jun 4, 2020 at 1:19 PM Gregory Nutt wrote: > Why don't we require that the reviewer fill in those sections. The main > reason that they are not filled in now is language barrier issues, not > willingness to contribute. Forcing someone who has marginal English > skills to write prose to yo

Re: [DISCUSS] requirements for commit messages and PRs

On Thu, Jun 4, 2020 at 12:32 PM Gregory Nutt wrote: > Yes. Simplicity is single most important thing. The entire template > should fit entirely within the PR comment window. It should not be a > punishment to contributors to the project. We will get a better > response if it is simple and usab

Re: [DISCUSS] requirements for commit messages and PRs

On Thu, Jun 4, 2020 at 11:54 AM Gregory Nutt wrote: > >> See > >> https://github.com/nuttx-to-asf/incubator-nuttx/commit/b496ee7ff9adeaa9020e7b07efed8198d4e8e623 > >> > > > > The is HORRIBLE!!! God help us. > Full disclosure: I am the guy with the "lack of working project > experience an

Re: Organising Release Notes for 9.1

On Thu, Jun 4, 2020 at 10:07 AM David Sidrane wrote: > I had this in the original PR I submitted for the templates. That got > changed due to lack of working project experience and vision. The Apache way > is not being followed here: the PMC is not voting on things we should be. > > Can we work on

Re: Release 9.1

On Wed, Jun 3, 2020 at 5:36 PM Adam Feuer wrote: > I got stuck, and switched to Linux. But I will give macOS a try again in > the next few days, and update the instructions if I succeed. I built a recent master on macOS and it worked. All I had to do was: * Install gcc-arm-none-eabi using inst

Re: Organising Release Notes for 9.1

On Thu, Jun 4, 2020 at 7:58 AM David Sidrane wrote: > I think _Every PR_ needs a description do begin to be a responsible and > professional contribution. The small extra level of effort will keep the > team informed and provide the documentation for the release process. We > should not have to re

Re: Organising Release Notes for 9.1

On Thu, Jun 4, 2020 at 2:07 AM Brennan Ashton wrote: > So Nathan has done an awesome job getting a start on the release notes for > 9.1, but so far he has done all of the work and it is a little hard to see > where we have left off and to work together adding the content. > https://cwiki.apache.or

Re: MSYS2 build slow

On Sun, May 31, 2020 at 12:44 PM Gregory Nutt wrote: > > > FWIW the build has become noticeably faster for me with latest master: > > 1m21s now. Before, the build consistently took about 1m50s. So that's > > 30 seconds saved. I build on Linux. > yes I have seen improvements of 25-30% on all platf

Re: MSYS2 build slow

On Wed, May 27, 2020 at 8:06 PM Nathan Hartman wrote: > I build on Linux and those build times seem fast to me (20-30 seconds, 45-60 > seconds). I don't know if I've ever had builds that fast, but it might be my > configurations, or my machine. I'll build one now... &

Re: The new Apache NuttX Logo

On Thu, May 28, 2020 at 1:14 PM Brennan Ashton wrote: > > On Thu, May 28, 2020, 10:06 AM Gregory Nutt wrote: > > We should complicate that. Justin said that Apache services could do > > any image conversions that we need. We should not restrict people if we > > don't need to > > Long as it is a

Re: The new Apache NuttX Logo

On Thu, May 28, 2020 at 10:28 AM Alan Carvalho de Assis wrote: > Before we start the pool we need to find a better site to put it, > confluence will not allow external user to update file to it. A GitHub repository? incubator-nuttx-logo? People could open pull requests. We should prefer SVG (or

Re: The new Apache NuttX Logo

On Thu, May 28, 2020 at 9:32 AM Abdelatif Guettouche wrote: > > I think David is referring to the ideas given in the attached document, > where NuttX is spelled all upper case (NUTTX) Well I think it should be spelled NuttX. Because as Greg points out: On Thu, May 28, 2020 at 8:40 AM Gregory Nu

Re: The new Apache NuttX Logo

On Thu, May 28, 2020 at 2:20 AM David Alessio wrote: > Before it's too late, I'd like to pose the question: > Is there no-one who prefers NuttX be spelled with lower-case "utt"? I'm confused by your question: Haven't we been spelling it NuttX? Nathan

Re: MSYS2 build slow

On Wed, May 27, 2020 at 3:39 PM Gregory Nutt wrote: > > >> it seems because ARCHINCLUDES try to figure out the search path by > >> invoking shell script: > > > > But wouldn't that affect all platforms proportionally? Why would that > > cause such a huge increase on MSYS2. > > > > I saw a 7 minut

Re: The new Apache NuttX Logo

On Wed, May 27, 2020 at 5:15 PM Gregory Nutt wrote: > > > Well, it could be a gift certificate of some kind. Seems like it must > > be embedded RTOS themed in some way, however. > > > > Or maybe a trophy? > > Better... a T-shirt or hoody with the selected logo on it. That's a neat idea! Natha

Re: The new Apache NuttX Logo

On Wed, May 27, 2020 at 11:45 AM Gregory Nutt wrote: > A contest is fine, maybe we could even create a pool to purchase a > prize... like a nice, high end NuttX board? I would contribute. That would provide more incentive to participate. Let's find out if we can do this. Mentors? Is it allowed?

Re: The new Apache NuttX Logo

On Wed, May 27, 2020 at 10:45 AM Gregory Nutt wrote: > > The new logo could be viewed online here: > > https://cwiki.apache.org/confluence/display/NUTTX/New+Apache+Nuttx+Logo > > Please give your feedback and suggestoion. > > Are there any updates on the proposed new NuttX logos? We stopped > dis

Re: kconfig (Re: mbedtls)

On Mon, May 25, 2020 at 8:41 PM Takashi Yamamoto wrote: > On Tue, May 26, 2020 at 12:48 AM Gregory Nutt wrote: > > > > We should all be using a consistent, common version of > > kconfig-frontends. A snapshot was taken and has never disappeared from > > internet contrary to other statements it i

Re: kconfig (Re: mbedtls)

On Mon, May 25, 2020 at 12:28 PM Gregory Nutt wrote: > Most projects that use kconfig-frontends use a snapshot version that is > built into the codebase. We cannot do that because kconfig-frontends is > GPL. However, I still argue that we should use a fixed, common version > of kconfig-frontends

Re: kconfig (Re: mbedtls)

On Mon, May 25, 2020 at 11:48 AM Gregory Nutt wrote: > A snapshot was taken and has never disappeared from > internet contrary to other statements it is always been here and will > always be here: https://bitbucket.org/nuttx/tools/src/master/ Correct. I meant that the original (from Yann Morin) d

Re: kconfig (Re: mbedtls)

On Mon, May 25, 2020 at 12:36 AM Takashi Yamamoto wrote: > On Mon, May 25, 2020 at 1:00 AM Nathan Hartman > wrote: > > We do have to solve the issue of Kconfig. That has disappeared from > > the Internet and we depend on it. We were told, before we joined > > do we

Re: Correct call sequence to initialize the heap in CONFIG_BUILD_FLAT?

On Mon, May 25, 2020 at 1:25 AM Laitinen, Jukka wrote: > > Hi, > > Right now, looking at the file nx_start.c, all calls to up_allocate_heap are > being done when one of these flags are defined: > > #if defined(MM_KERNEL_USRHEAP_INIT) || defined(CONFIG_MM_KERNEL_HEAP) || \ > defined(CONFIG_MM

Re: mbedtls

On Mon, May 25, 2020 at 10:51 AM Gregory Nutt wrote: > I would say that it is an absolute requirement that nothing depend on > GIT in anyway from the standpoint of the end user. I agree Nathan

Re: mbedtls

On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis wrote: > Some months ago I suggested that NuttX could focus only in the kernel > and we could create an external distribution using some build system > like buildroot, yocto, etc. But as some people pointed, maybe a great > strength of NuttX i

Re: Don't need use $(DELIM) in include statement

On Sun, May 24, 2020 at 11:35 AM Gregory Nutt wrote: > Some time back we actually voted to keep the Windows native build in > place, even though it is not fully functional or ready for prime time. > We did mark it as EXPERIMENTAL. The idea is that some champion for this > build would emerge and p

Re: Don't need use $(DELIM) in include statement

On Sun, May 24, 2020 at 11:27 AM Gregory Nutt wrote: > > I'm confused about commit edb0ce2d5afa8a0905bd4536ac39eaf1819dfc56: > > "build: Don't need use $(DELIM) in include statement" > > > > This changes various lines in Make.defs from this: > > include wireless$(DELIM)spirit$(DELIM)drivers$(

Don't need use $(DELIM) in include statement

I'm confused about commit edb0ce2d5afa8a0905bd4536ac39eaf1819dfc56: "build: Don't need use $(DELIM) in include statement" This changes various lines in Make.defs from this: include wireless$(DELIM)spirit$(DELIM)drivers$(DELIM)Make.defs to this: include wireless/spirit/lib/Make.defs Don't

Re: Release Notes for the NEXT version of NuttX

gt; log.txt That log file contains: [[[ commit 4476a16a1a2d68c930f2d1c2476b7f1d53162cb6 Author: Nathan Hartman <59230071+hartmannat...@users.noreply.github.com> Date: Fri Apr 24 10:17:36 2020 -0400 README.txt: Address issues raised in -RC0 review * Add INTRODUCTION section with a brief summary of Apache

Re: Release Notes for the NEXT version of NuttX

On Fri, May 22, 2020 at 4:54 PM Brennan Ashton wrote: > Nevermind I see what you were asking for. There is no great way to do this > with git directly, usually you track this by using labels (or similar) on > issues or PRs to aggregate it. At least that is that is how I have always > run releases

Re: Release Notes for the NEXT version of NuttX

In preparation for the 9.1 release notes... What git incantation will get the log, excluding all commits present in the 9.0 release? Specifically, I want to include commits after 9.0 was branched, but exclude commits that were cherry-picked to 9.0. Thanks, Nathan

Re: mbedtls

On Fri, May 22, 2020 at 9:18 AM Alan Carvalho de Assis wrote: > Hi Daniel, > > Yes, I think an option is to create an apps/thirdparty folder to > follow with Xiang idea. I like the idea of glue code. There are many libraries out there which people may want to use with NuttX, and we can't/shoul

Re: Jenkins build is back to normal : NuttX-Nightly-Build #159

On Wed, May 20, 2020 at 9:17 AM Xiang Xiao wrote: > Hi all, > We finally get the stable parallel build! Thanks the hard work from > Haitao Liu, Takashi Yamamoto and Masayuki Ishikawa to make this > happen. Thank you so much!

Re: nxstyle warnings: Fail precheck?

On Tue, May 19, 2020 at 4:27 PM Gregory Nutt wrote: > > It does print "error" for some and "warnings" for others. So I thought > > there was a difference. >> > Yes, that was added. But I don't know what it means. I guess that some > stylistic violations are not as bad as others? None are tolera

Re: nxstyle warnings: Fail precheck?

On Tue, May 19, 2020 at 4:01 PM Gregory Nutt wrote: > > Are nxstyle warnings supposed to make precheck fail at GitHub PR? I > > thought only errors constitute fails. > > In the build checks C warnings are also converted to warnings via > -Werror and any warnings in the builds will fail the check.

nxstyle warnings: Fail precheck?

Are nxstyle warnings supposed to make precheck fail at GitHub PR? I thought only errors constitute fails.

Re: Automated Testing

On Tue, May 19, 2020 at 1:20 PM Gregory Nutt wrote: > Or don't develop custom hardware. Use COTS (Commerical Off-The-Shelf) only. That's the easiest (and possibly best) option. Custom boards, if we ever get there, would serve multiple purposes, one being testing, another being a reference platf

Re: Automated Testing

On Tue, May 19, 2020 at 1:10 PM Gregory Nutt wrote: > However, that when no where beyond Dave's personal use because there was > no way for regular people to get the board. The design was open so you > get everything you need to make your own, but that was it. So, from my > point of view, that w

Re: Automated Testing

On Tue, May 19, 2020 at 1:06 PM Gregory Nutt wrote: > On Tue, May 19, 2020 at 12:57 PM Alan Carvalho de Assis > wrote: > > During the NuttX Workshop a friend (Thiago Costa Paiva) suggested > > about the idea of creating a FPGA solution to validate NuttX hardware, > > but his idea didn't take pla

Re: INCDIROPT changes

On Tue, May 19, 2020 at 11:05 AM Xiang Xiao wrote: > > Yes, the document is reflect the implementation accurately. Thank you for reviewing it. Nathan

Re: INCDIROPT changes

On Tue, May 19, 2020 at 10:08 AM Xiang Xiao wrote: > > Config.mk, bundled in INCDIR: > > ifeq ($(CONFIG_WINDOWS_NATIVE),y) > DEFINE ?= "$(TOPDIR)\tools\define.bat" > INCDIR ?= "$(TOPDIR)\tools\incdir.bat" > else ifeq ($(CONFIG_CYGWIN_WINTOOL),y) > DEFINE ?= "$(TOPDIR)/tools/define.sh" -w >

Re: INCDIROPT changes

On Tue, May 19, 2020 at 10:08 AM Xiang Xiao wrote: > > Config.mk, bundled in INCDIR: > > ifeq ($(CONFIG_WINDOWS_NATIVE),y) > DEFINE ?= "$(TOPDIR)\tools\define.bat" > INCDIR ?= "$(TOPDIR)\tools\incdir.bat" > else ifeq ($(CONFIG_CYGWIN_WINTOOL),y) > DEFINE ?= "$(TOPDIR)/tools/define.sh" -w >

INCDIROPT changes

Commit 5eae32577e5d5226e5d3027c169eeb369f83f77d says: "build: Move INCDIROPT to common place" Where is the common place? Thanks, Nathan

Re: nxstyle weird indentations

On Mon, May 18, 2020 at 9:20 PM Gregory Nutt wrote: > > > ... Either way, the left edge of the comment will not line up > > with the "define" or "undef." > > This is the perfect illustration of the problem of mixing the > incompatible C and pre-processor indentation. Visually, you eye is > drawn

Re: nxstyle weird indentations

On Mon, May 18, 2020 at 8:08 PM Gregory Nutt wrote: > > > Actually, I just ran into another nxstyle-related conundrum and I > > don't see anything about this in the coding standard. > > > > Regarding indentations, the coding standard says that everything is > > indented by units of 2, so that all

nxstyle weird indentations

Actually, I just ran into another nxstyle-related conundrum and I don't see anything about this in the coding standard. Regarding indentations, the coding standard says that everything is indented by units of 2, so that all C code begins at column 4n + 2. But preprocessor statements begin with a '

Re: nxstyle mixed case identifiers

On Mon, May 18, 2020 at 7:48 PM Gregory Nutt wrote: > >> I started out life a a tiny, ad hoc program to help me review code and > >> then became indispensable. It was never designed; it just evolved. > > Some programs just "happen" that way, and work fine, and there's no > > need to replace them.

Re: nxstyle mixed case identifiers

On Mon, May 18, 2020 at 7:39 PM Gregory Nutt wrote: > You should feel free to just modify nxstyle at any time you like. :-) > I started out life a a tiny, ad hoc program to help me review code and > then became indispensable. It was never designed; it just evolved. Some programs just "happen"

Re: nxstyle mixed case identifiers

Submitted PR1067. Cheers, Nathan

Re: nxstyle mixed case identifiers

On Mon, May 18, 2020 at 7:20 PM Gregory Nutt wrote: > LGTM. I can't come up with any credible case where that would fail > badly. I suppose if someone wanted SHMOOZHz that would be okay albeit > weird. One would normally expect a limited number of things before the > H, but I don't think we nee

Re: nxstyle mixed case identifiers

On Mon, May 18, 2020 at 6:29 PM Gregory Nutt wrote: > > Are abbreviations like MHz, KHz, Hz, intended to be exceptions to the > > mixed case rules? > > Yes, the coding standard is here: snip > If that is not working, then please consider a PR. I see logic that > picks off and ignores MHz but no

nxstyle mixed case identifiers

nxstyle produces errors about mixed case identifiers like the following, which are found throughout the system: GPIO_SPEED_100MHz GPIO_SPEED_10MHz GPIO_SPEED_120MHz GPIO_SPEED_25MHz GPIO_SPEED_2MHz GPIO_SPEED_400KHz GPIO_SPEED_40MHz GPIO_SPEED_50MHz GPIO_SPEED_5MHz Are abbreviations like MHz, KHz

Re: Backporting Fixes [was: heap malloc when executing binary/elf file]

On Mon, May 18, 2020 at 12:12 PM Gregory Nutt wrote: > I think we need to assure that these two "tiers" are compatible and use > the same test infrastructure. The should have these things in common: I'd like to move this discussion to a new thread, titled "Automated Testing" without several leve

Automated Testing

Moving this discussion from a 2020/05/17 thread titled: "Backporting Fixes [was: heap malloc when executing binary/elf file]" The discussion about automated testing begins at [1] where Greg asks whether we want to invest in an exhaustive functional test suite to qualify releases. I suggested that

Re: Backporting Fixes [was: heap malloc when executing binary/elf file]

On Mon, May 18, 2020 at 12:03 AM Gregory Nutt wrote: > Build testing is important but does not address functionality. Things > can be completely broken and still build perfectly. Correct. > Currently our functional testing strategy is simply to ask people to > check releases. But no problems ha

Re: 答复: [External Mail]Re: heap malloc when executing binary/elf file

On Mon, May 18, 2020 at 10:38 AM Gregory Nutt wrote: > >> Yes, the best solution is to extend ELF with stack and priority info. > >> But before that happen, gathering this info from the built-in app > >> table is workable alternative: > >> 1.Keep the trying order(file system, built-in and nsh comm

Re: Backporting Fixes [was: heap malloc when executing binary/elf file]

On Sun, May 17, 2020 at 7:11 PM Brennan Ashton wrote: > On Sun, May 17, 2020, 3:59 PM Gregory Nutt wrote: > > > Hi, Brennan, > > >>> I just created incubator-nuttx-apps PR 255 that should restore the > > >>> correct behavior: > > >> https://github.com/apache/incubator-nuttx-apps/pull/255 > > >>

Re: "No Podling Name Search on file"

On Sun, May 17, 2020 at 2:46 PM Brennan Ashton wrote: > FYI it was just approved. > > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-182 Thanks for taking care of that! Nathan

Re: Adding support for STM32G474RET6

On Thu, May 14, 2020 at 5:21 PM Nathan Hartman wrote: > It is now time to open a PR and start the review process. The PR is #1051: https://github.com/apache/incubator-nuttx/pull/1051 Alan and David, whenever you get the chance, I'll be standing by to address any issues you find...

Re: Release Notes for the NEXT version of NuttX

On Thu, May 14, 2020 at 11:07 PM Abdelatif Guettouche wrote: > > That looks good. > Just one small thing: Is your board in-tree with other STM32s? > I'm asking because the referenced commit didn't make the change to the > build system, it re-organized the STM32 boards. The "real" change to > the

Re: Release Notes for the NEXT version of NuttX

On Thu, May 14, 2020 at 6:40 PM Abdelatif Guettouche wrote: > I noted one thing: > "Rename src/Makefile to src/Make.defs" > I'm not sure about this one, this applies only if the board family > uses a common directory (like CXD56 does and recently STM32). > The "Makefile" way still works and is sti

Release Notes for the NEXT version of NuttX

After the release of NuttX-9.0, there have been some build system changes that starting with NuttX-9.1 will likely break custom board configurations that people might have. While the information is fresh in my head, I went ahead and created on Confluence a page to start working on our next Release

Re: Adding support for STM32G474RET6

BIG UPDATE: The board boots NuttX to a working NSH prompt! This means that a whole lot of things went right. It is now time to open a PR and start the review process. I'm going to title the PR [DO NOT MERGE] until we go through it... Greg, thanks for your help. David and Alan, thanks for volunt

Re: Adding support for STM32G474RET6

On Wed, May 13, 2020 at 12:26 PM Gregory Nutt wrote: > > > If all goes well, there will be a big pull request coming soon. Wish me > luck! > > I think we should consider getting a review team together. This will be > more than a single person can review (especially if that single person > is me

Re: Adding support for STM32G474RET6

Update: It builds! It links! After much work, it's time to begin testing... https://github.com/hartmannathan/incubator-nuttx/tree/stm32g474 If all goes well, there will be a big pull request coming soon. Wish me luck! Nathan

Re: "No Podling Name Search on file"

On Wed, May 13, 2020 at 12:54 AM Brennan Ashton wrote: > I created the ticket > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-182 following the > same template as another pre-existing project that recently was approved. > > While I do not have access to the email thread that Greg refere

Re: "No Podling Name Search on file"

On Tue, May 12, 2020 at 12:25 PM Gregory Nutt wrote: > I had extensive discussions with Daniel Shahaf and Mark Thomas at > tradema...@apache.org. The emails should be available in the > tradema...@apache.org mail history for the data December 17-18, 2019. > The title of the thread is "NuttX Incu

"No Podling Name Search on file"

I noticed that our Whimsy page [1] has this to say about a podling name search: "No Podling Name Search on file" What do we need to do to check this off our TODO list? [1] https://whimsy.apache.org/roster/ppmc/nuttx Thanks, Nathan

Re: [NOMINATION] Self nominate to be a mentor of Apache NuttX

On 5/11/20, Duo Zhang wrote: > Hi, NuttX community, I'm Duo Zhang, I would like to self nominate to be a > mentor of Apache Nuttx, since I'm the only person among 3 binding votes who > have successfully built NuttX in the 9.0.0 vote thread. Just joking :) > > Last year when Greg and David came to

Re: heap malloc when executing binary/elf file

On Mon, May 11, 2020 at 5:01 PM Gregory Nutt wrote: > That part has 256Kb of SRAM. That is more that many, but it could be > that you are using too much SRAM and just cannot run ELF reliably. It > does want a lot of SRAM. If there isn't enough memory, I wonder why malloc doesn't return NULL? Ha

Re: heap malloc when executing binary/elf file

On Mon, May 11, 2020 at 2:05 PM Florian Wehmeyer wrote: > OK I already saw that simply increasing the heap is no solution, > because it's already maximum size: > mm_initialize: Heap: start=0x20008924 > size=227036 > mm_addregion: Region 1: base=0x20008924 size=227024 Tricky problem. Is this for

NuttX website: Adding a News & Announcements section

I propose that the homepage of nuttx.apache.org should have a new section called News and Announcements, that over time would contain a list of the three or four most recent project-related news items. Currently we have one news-worthy item: The release of 9.0. I am opening a pull request on the

Re: [ANNOUNCE] Apache NuttX 9.0.0-incubating released

On Mon, May 11, 2020 at 3:01 PM Brennan Ashton wrote: > The Apache NuttX (incubating) project team is proud to announce > Apache NuttX 9.0.0-incubating has been released. > This is the 1st Apache release as an Apache Incubator project. > > https://nuttx.apache.org/download/ > https://nuttx.apache

Re: Adding support for STM32G474RET6

Progress report on this port: I'm getting closer... Not quite compiling yet, still some errors with a few undefined register definitions here and there. But I'm definitely getting closer... As before, my work is in my fork under stm32g474 branch [1], if anyone wants a sneak preview. :-) [1] https

NuttX: More than just code

Greg and I were discussing offlist the role of the project management committee and ways that interested people can become part of it. Right now, we have technical people in the PPMC, which is valuable because the PPMC needs to deal with technical matters. But! We are lacking in people (who may o

<    1   2   3   4   5   6   7   8   9   >