Do we have the enough resource to develop a full test suite from
scratch? Before we get the resource commitment, the realistic step is
integrate the test suite from other project. This isn't a bad idea
because NuttX is a ANSI/POSIX compliant OS, there is many test suite
to cover POSIX, C/C++ librar
> -Original Message-
> From: Gregory Nutt
> Sent: Wednesday, May 20, 2020 1:20 AM
> To: dev@nuttx.apache.org
> Subject: Re: Automated Testing
>
> >> Adding hardware raises complexities or design, manufacturing,
> >> distribution, and support. Not insumountble, but not simple either.
>
What to do about lines of code like this:
...
# define GPIO_CNF_INPULLDWN (2 << GPIO_CNF_SHIFT) /* Input
pull-down */
# define GPIO_CNF_INPULLUP ((2 << GPIO_CNF_SHIFT) | GPIO_OUTPUT_SET)
/* Input pull-up */
...
I would probably fix that like:
# define GPIO_CNF_INP
I created PR https://github.com/apache/incubator-nuttx/pull/1079 to
eliminate any distinction between C source file and header files in
reporting long lines. Both are equally errors.
No, that was never a rule. We did use -m so that we didn't have to do
so much work. But that was just cutting corners; we (meaning us
individually) allowed a little slop in line length just because we
didn't want to do the work. There has never been a policy that said
long lines were okay
The rule use to be: long lines were ok in arch header files.
No, that was never a rule. We did use -m so that we didn't have to do
so much work. But that was just cutting corners; we (meaning us
individually) allowed a little slop in line length just because we
didn't want to do the work
The rule use to be: long lines were ok in arch header files.
When I made nxstyle output error parsable output, that was a warning not an
error.
Then we got to make it fit below the ruler.
Then we got to it better conform. So now I guess they are all errors.
David
-Original Message-
F
arch/arm/src/stm32/stm32_gpio.h:131:79: warning: Wrong column position
of comment right of code
Yes, the comments to the right of the definitions must be vertically
aligned.
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
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 tolerated, at
least not without some extenuating circumstance.
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.
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.
Don't know about nxstyle, but there really is no such thin
Are nxstyle warnings supposed to make precheck fail at GitHub PR? I
thought only errors constitute fails.
Before we select any tools, I think we should first enumerate some
general requirements of the automated test. Here are a few things that
occur to me.
I think it should be pretty simple from the standpoint of features;
* Execute a sequence of test cases, broken out as test stops.
* It m
...; it would be better for hardware developers if they could run the
automated tests on the hardware that they have a vested interest in.
This deserves a few more words because I am contradicting myself: The
object of the automated test is to verify the OS (pure software). In
this case,
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 was just wasted enthusiasm on my part.
Why? That effort c
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
I don't think we need a rigid sequence of steps. I see nothing wrong
with skipping directly to 3, skipping 1 and 2. I see nothing wrong
with some people doing 3 while others are doing 4 concurrent. These
sequence is not useful.
What would be useful would be:
1. Selection of a common tool
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
Adding hardware raises complexities or design, manufacturing,
distribution, and support. Not insumountble, but not simple either.
This is why I suggested that we "grow" into it.
Or don't develop custom hardware. Use COTS (Commerical Off-The-Shelf) only.
(1) Perfect the current coding standar
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
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 place.
Adding hardware raises complexities or design, manufacturing,
distribution, and support. Not insumountble, but not simple
On Tue, May 19, 2020, 9:57 AM Alan Carvalho de Assis
wrote:
> Hi Nathan,
>
> 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 place.
>
> I think using a software simulator is a goo
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 place.
Adding hardware raises complexities or design, manufacturing,
distribution, and support. Not insumountble, but not simple
Hi Nathan,
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 place.
I think using a software simulator is a good starting point, but some
features need to be validated on real hardware.
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
Yes, the document is reflect the implementation accurately.
> -Original Message-
> From: Nathan Hartman
> Sent: Tuesday, May 19, 2020 10:17 PM
> To: dev@nuttx.apache.org
> Subject: Re: INCDIROPT changes
>
> On Tue, May 19, 2020 at 10:08 AM Xiang Xiao wrote:
> >
> > Config.mk, bundled i
* The next tier could be an automated test suite that runs in a
simulator.
This would be accessible to the greatest numbers of developers and
contributors, because there's nothing to buy.
* The highest tier could be testing on a reference hardware board.
I think we need to assure th
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
>
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
>
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
INCDIR ?= "$(TOPDIR)/tools/incdir.sh" -w
else
DEFINE ?= "$(TOPDIR)
Commit 5eae32577e5d5226e5d3027c169eeb369f83f77d says:
"build: Move INCDIROPT to common place"
Where is the common place?
Thanks,
Nathan
Hello,
I've been playing with the IMX1060-EVK board for some time. I wanted to
test it by running NuttX on it with networking support enabled.
./tools/configure.sh -l imxrt1060-evk/netnsh
The configurations below have been enabled, referring to the explanation in
the README file.
CONFIG_IMXRT_E
2020年5月18日(月) 14:47 Brennan Ashton :
>
> On Sun, May 17, 2020, 10:36 PM Takashi Yamamoto
> wrote:
>
> > hi,
> >
> > this is just a curious question.
> > why do we use the name "intel64" for qemu things?
> > i thought it was from qemu, but qemu seems to use x86_64 or amd64.
> > i think "amd64" is m
34 matches
Mail list logo
