Re: [DRUNX] Distributed Runtime and bUild for NuttX

[Sebastien Lorquet]

I would say testing as much as possible is always a benefit.
I have worked for more than 15 years as an embedded specialist managing 
mission critical code, and every bug we found later in the project was 
in a test gap.

As my boss usually say, "If it's not tested, it doesnt work" and this 
has been universally true.

The actual issue is that nuttx has very few resources, and that one is a 
real blocker.

So starting small and improving later is the only realistic way forward.


Please, dont add more tools to discuss more issues, the only result will 
be more dilution of the information. I have never seen any project where 
more communication channels has had benefit, quite the contrary.

Email is actually fine, its not perfect, but it has the merit to exist 
and be usable *today* without additional work.

This project is not even started yet :-)


What do you want to test? Do the minimum. ostest, hello world. Build a 
simple infra that can automatically build a board and run a hello world 
on it. Bonus if everyone can self host it by running very few code. 
avoid docker and modern heavy tools. This can be a simple python script 
using pyserial and openocd/esptool/whatever is required for a platform.

This is a very valid and useful first step, it will catch many bugs that 
cannot be seen by building only.

You will add SPI and I2C and all the desirable bell and whistles later.


But I maintain this: Having hello world run on an actual board 
automatically is 90% of the work. and it's already useful.


Sebastien


On 05/02/2025 08:22, raiden00pl wrote:
As mentioned earlier, testing all boards is pointless, especially since the
project
has very limited resources. Choosing a few boards that will allow us to
test as many
things as possible is the most optimal approach.

But first we should determine what things we want to test, not what boards.
Knowing what things we want to test, we can design test cases and possibly
use what is already available.

But e-mail and github don't seem to me to be a good tool for brainstorming
and ideas. Maybe Confluence pages would be better? I haven't used
Confluence
for a few years, I just hope it's not as slow as it used to be :)

I can create a Confluence page and describe my ideas about testing, I have
some
thoughts about NuttX testing written somewhere in my private notes. Others
can do
the same.

Email can be good for decision making and maybe gathering more feedback from
the community, but it's a shitty tool for more complex work. Or I'm too
young
to use it comfortably :P

wt., 4 lut 2025 o 12:03 Tomek CEDRO <to...@cedro.info> napisał(a):

On Tue, Feb 4, 2025 at 11:42 AM Luchian Mihai <luchiann.mi...@gmail.com>
wrote:
Hi!
First thing, I'm fairly new to nuttx so I might be off subject but here
is
my hot take on this subject.
Welcome and have fun Mihai! :-)


NuttX is offering support for a lot of boards, more than what DRUNX
should
require.

Eg. stm32f3 family, offering support for all the boards would benefit the
boards more than the NuttX codebase.
These boards share 80% of the code but each in its own files, so most
differences are due to lack of backporting.

My suggestion is to take a single board for each mcu family as mandatory
NuttX support, others as optional.
I'm not saying to drop support, or offer less support for those, just to
treat the mandatory as higher prio.
For the moment we can choose what is mandatory, and at a later time, when
DRUNX would be stable, move the optional ones to DRUNX repo (for
example).

The idea is that everyone can test what they have at hand and then
gather the results, that should sum up to full board list one day :-)
Also different people will use different build hosts, different
compilers, etc, so even if the same board is tested in different build
environment that can also reveal potential issues to be fixed :-)

Yes, for sure we need at least one board from each family for start,
then adding more boards, we all do release testing that way or
another, by hand or scripted, we now have to find a way to make it
distributed easy to setup fire-and-forget :-)


TLDR: I think less is more, less "official" support, more "official"
coverage.
More means more. Less means less. Lets keep thing simple in this
inverted world where word have no meaning anymore :D :D :D

Its a small project based on voluntary work with zero financial
support from big companies. We will define a testing architecture for
sure, but for now its a fresh concept and each one of us try different
area to create small building blocks that will give us the solution we
need, one day, hopefully ;-)

Please go ahead Mihai and try your boards, start with one that you
know best, use PyTest to create build and runtime automation, create
"selftest" board config that will run a script with `uname -a; help;
ostest, coremark`, gather the logs, parse the results, see how
nuttx-dashboard works based on gist, see what problems we have, see
how can we solve them hands-on :-) Maybe there is something better
than PyTest. Maybe there are other ways. You try it out and share the
feedback :-)

If this is too much, use smaller steps, think of it as automation tool
for release testing on different boards :-)

Thank you and take care :-)
Tomek

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info