Re: Does Nuttx support hard real time?

[Nathan Hartman]

On Fri, May 17, 2024 at 1:42 AM 吳岱儒  wrote:

> Hi community,
>
> Is Nuttx a hard real time RTOS or software RTOS?
> If Nuttx support hard real time, is there any documentation about this
> feature and design ?
>
> BRs,
> TaiJuWu
>

Hello,

It depends on the CPU architecture:

For example, on ARM Cortex M architecture, the hardware provides an
interrupt vector table which supports multiple interrupt vectors, and
multiple interrupt priority levels, and there is an
interrupt base priority register which allows to keep certain interrupts
enabled while most interrupts are disabled. This hardware support makes it
possible to implement what we call a "Zero Latency Interrupt" (sometimes
called a Raw Interrupt or Unmanaged Interrupt by other RTOSes).

To get a hard real time performance, you would identify the time-critical part
of your software that needs zero latency handling (usually a tiny part of
the whole software) and then design your software to run that part in a
Zero Latency Interrupt. Everything else goes in regular code.

There is a page in the NuttX documentation that explains Zero Latency
Interrupts. See [1].

It may be possible to implement Zero Latency Interrupts for other CPU
architectures besides ARM Cortex M, if the hardware provides mechanisms
that make it possible, such as a way to define a high priority interrupt
that is never disabled.

For the best possible performance, you need to choose your microcontroller
hardware carefully. Look for features like the ability to put your zero
latency interrupt handler and its variables in RAM for faster execution
(because code in FLASH may take longer to fetch). Some microcontrollers
even have a special section of RAM that is faster than the rest for this
exact purpose. For example the STmicro STM32G series has this feature and
calls it CCM SRAM. Other microcontroller vendors might have a similar thing
but call it a different name.

Fortunately NuttX supports many CPU architectures and many microcontroller
models from many hardware vendors, so you have lots of choices. Also if the
microcontroller you want to use isn't currently supported by NuttX, it is
usually not too difficult to add support, especially if there is already
support for something similar.

References:
[1]
https://nuttx.apache.org/docs/12.5.0/guides/zerolatencyinterrupts.html

Hope this helps,
Nathan

Re: Missing bytes on serial port

[Nathan Hartman]

When writing to the port, write() should indicate number of bytes written.
Are you checking the return value and is it less than expected?

Note that write() enqueues the bytes but returns before write complete. If
port is closed before hardware finishes shifting all the bits out, message
will be truncated.

Note that most MCUs have errata related to UART completion: usually the
"busy" bit (or whatever a particular micro calls it) indicates transmission
done before it actually shifts out the last bits.

On Thu, May 9, 2024 at 12:41 PM Mark Stevens
 wrote:

> This is a direct connection between the two chips on a PCB.
>
> Regards,
> Mark
> —
> Mark Stevens
> mark.stev...@wildernesslabs.co
>
>
>
>
>
>
> > On 9 May 2024, at 17:38, Bill Rees 
> wrote:
> >
> >
> > I've seen this problem before which revolved around flow control;
> essentially soft versus hard flow control (xmit off/ xmit on)
> >
> > Are you using a null modem cable? If not that may give you the accuracy
> you're looking for, else hardware flow control is the only other
> possibility if it is flow control.
> >
> > Bill
> >
> > On 5/9/2024 9:24 AM, Tomek CEDRO wrote:
> >> On Thu, May 9, 2024 at 6:15 PM Mark Stevens
> >>  wrote:
> >>> Yes, I am sure both side are configured correctly.
> >>> If I run the kernel code only then all works as expected.
> >>> If I run user space code alone all works as expected.
> >>> The problems happen when I transition from kernel use of the UART to
> user space use of the UART.
> >>> I have also connected a logic analyser to the system and all looks
> good.
> >>> Also, my current problem is NuttX reading data not sending it.
> Sending may also be a problem but I have not got that far at the moment.
> >> Which UART do you use? What happens when you use different UART? Are
> >> you sure it does not interfere with console?
> >>
> >> --
> >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> >
>
>

Re: Missing bytes on serial port

[Nathan Hartman]

On Thu, May 9, 2024 at 3:31 AM Mark Stevens
 wrote:

> So we have a two chip board:
>
> * STM32 running NuttX (v7.5 I believe)
> * ESP32 acting as a coprocessor running custom firmware
>
> The STM32 runs the show and the ESP32 provides services to the STM32 code.
>
> In normal run mode, NuttX has a kernel thread that reads data from the
> ESP32 over UART (/dev/ttyS2) and then processes the data.  This is working
> fine as is.
>
> The UART is configured to use a 512 byte buffer.
>
> Every now and then we want to upload new firmware to the ESP32.  This is
> done by a user mode thread and it goes through the following steps:
>
> * Signals to the kernel thread that it should close the UART and exit.
> * Opens the serial port
> * Starts the programming sequence
>
> If we try to do this then the user mode thread misses bytes in the byte
> stream.
>
> Kernel mode thread only:
> When the system starts then this thread works fine, no bytes are lost.
>
> User mode thread only:
> If we do not start the kernel mode thread then the programming works fine,
> no bytes are lost.
>
> Both threads:
> Starting the kernel works fine, we do not miss any bytes.  The kernel
> thread can be stopped, the UART is closed correctly.
>
> The user thread can open the serial port correctly after the kernel thread
> has stopped but now it misses bytes.
>
> So we know the individual threads work as expected when used on their own
> but not together.
>
> How anyone seen this or have any advice on how we can resolve the issue?
>
> Regards,
> Mark
> __
> mark.stev...@wildernesslabs.co
>
>
>
>

Which bytes are missing? Are they the ones at the beginning of the message,
or the end?

Nathan

Re: Beginner questions

[Nathan Hartman]

On Sun, Apr 28, 2024 at 1:45 AM M. Edward (Ed) Borasky <
zn...@algocompsynth.com> wrote:

> I've just run across NuttX, and I think it's a good fit for my project.
> What I'm trying to do is develop some computer music applications on
> microcontrollers. I'm mostly interested in the Raspberry Pi Pico, but I
> also have some ESP32 S3, ESP 32 C3/C6, and Teensy 4.1 boards aand would
> like the applications to run on 64-bit Linux machines as well.
>
> My first target is the Pimoroni PicoVision. This has a Raspberry Pi Pico W
> as the main processor and a second highly overclocked RP2040 to drive the
> HDMI signal generation. It also has an I2S audio including a DAC and stereo
> output jack. I won't be using the HDMI at the beginning.
>
> The existing raspberrypi-pico-w:audiopack does much of what I want except
> for a couple of exceptions:
>
> - It doesn't seem to use the wireless on the Pico W. I'd like to be able
> to access the system via wireless, for example, to broadcast to a Bluetooth
> speaker.
> - I couldn't find a library in NuttX for MIDI or audio over USB. That
> isn't critical; those exist in TinyUSB.
>
> Which brings me to my main question: how do I use NuttX as a build system
> for my own code without integrating my code into a fork of NuttX
> repositories as I would for a formal contribution to the NuttX project?
>
> It's not a licensing issue; everything I do is open source for code and
> Creative Commons for documentation. It's mainly logistics; I don't want an
> end user to have to download NuttX and learn how to add a board or an
> application in order to use my code.
>
> Getting the PicoVision audio working with raspberrypi-pico-w:audiopack
> looks easy; I think all I have to do is make sure the I2S GPIO pin numbers
> are correct in the configuration. But is there documentation on how to use
> the media player? I couldn't find any. And how do I go about adding WiFi
> and Bluetooth to the configuration? I didn't see them in the existing one.
>
> I guess what I'm looking for is a guide for how to compose the pieces -
> board definitions, libraries and applications - into a working
> configuration file that I can use.
>
> --
> How many people can stand on the shoulders of a giant before the giant
> collapses?
>
> Sent with [Proton Mail](https://proton.me/) secure email.


Hi,

Regarding how to build your code without putting it into a fork of the
NuttX repo:

Yes, this is possible.

First, for the board support package, you can set up something called an
"out of tree" board, which means you can have either a clone of the NuttX
repo or the extracted contents of a NuttX release tarball, without
modification, and then set up a configuration that finds your board in a
directory you specify.

Second, regarding the additional "nuttx-apps" repository, that is an
optional repository in the sense that it serves as an example of how to do
various things with NuttX while also serving as a valid distribution with a
shell (NSH) and other goodies (like, say, basic web server or whatnot). You
can use it (and configure which parts of it to enable in your build) or
supply your own "apps" which need not contain anything from NuttX's apps.

For your development environment, you might use a directory layout like:

directory
|-nuttx
|-apps
|-board1
|-board2
.
.
|-boardN

Where "apps" is either your own apps or NuttX's apps, and board1 through
boardN are your custom out-of-tree boards.

Hope this helps,
Nathan

Re: ESP32 (classic) RAM size question

[Nathan Hartman]

I recommend to add a comment there, to explain that although the board has
320KB in total, ~200KB is used for WiFi and BLE.

On Thu, Apr 25, 2024 at 8:36 PM Alan C. Assis  wrote:

> Hi Bernd,
>
> You can use 320KB only if you don't need to use WiFi and BLE.
>
> The memory is used but the WiFi/BLE driver!
>
> Do you remember the old days where your video card used to eat your main
> memory and you should define in the BIOS how much memory the video card
> will use?
>
> Same thing here! ;-)
>
> Best Regards,
>
> Alan
>
> On Thu, Apr 25, 2024 at 8:59 PM Bernd Walter 
> wrote:
>
> > The original ESP32 is said to have 320k RAM.
> > All board configs have the following:
> > CONFIG_RAM_SIZE=114688
> >
> > Are RAM sections added later in the startup process or is there another
> > reason?
> >
> > --
> > B.Walter  https://www.bwct.de
> > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
> >
>

Re: Options to contribute to NuttX without github?

[Nathan Hartman]

Even if the NuttX PMC requested to opt-out from "The Stack" there could be
(and probably are) a million other stacks, and many of those might be quite
a bit less transparent about what they're doing. So, like I said before,
all our code is public and there's not much we can do to prevent AIs from
training on it, any less than we could prevent people from studying it.

Nathan

On Thu, Mar 21, 2024 at 7:06 PM Gregory Nutt  wrote:

> The more I think about, I believe you don't have to be concerned about
> accessing github for Apache NuttX.  Certainly, I respect your choice to
> keep your personal code out of "The Stack".  But NuttX will most likely
> be in the Stack and any changes you submit to NuttX will be in the
> Stack.  So it may be awkward for you, but I don't see any reason for you
> to avoid Apache NuttX in github while moving your personal code elsewhere.
>
> Am I missing something?  You would probably like to make a clean break
> with github, but I think continuing to use the Apache NuttX repository
> (only) would be the more practical way to accomplished what you want to do.
>
> On 3/21/2024 4:43 PM, Gregory Nutt wrote:
> > I think we need to continue to use PRs at some point in the process.
> > PRs are so tied into our CI that I don't think we could work around it.
> >
> > Can you use another GIT repository?  If you create a PR on gitlab or
> > bitbucket, someone could move the PR to github.  Or perhaps we could
> > take commits from a local repository clone?  We haven't done it for a
> > while, but patches could also be converted to github PRs with a little
> > more effort.
> >
> > I think there are options, but without PRs on github, I don't see how
> > you could independently make changes.
> >
> > On 3/21/2024 4:08 PM, Sebastien Lorquet wrote:
> >> Hi,
> >>
> >> I plan to leave github completely and delete my account, because of
> >> this: https://huggingface.co/spaces/bigcode/in-the-stack
> >>
> >> It is the last of reasons that make me want to leave this place for
> >> good.
> >>
> >> How can we imagine a process so I (and others) can continue to
> >> contribute to NuttX without using pull requests from github? or any
> >> public "forge" for that matter.
> >>
> >> Sebastien
> >>
>

Re: Options to contribute to NuttX without github?

[Nathan Hartman]

For those who cannot or don't want to access GitHub, the gitbox repos on
ASF infrastructure are actually the "real" source of truth. As I understand
it, our GitHub repos are really some kind of mirror that is kept in a
two-way sync with gitbox. (Unless something has changed since I last looked
into it.)

However, the way we use GitHub makes it so that GitHub is for all practical
purposes the central thing for us and gitbox is some kind of afterthought
(if we even remember that it's there).

We as a project don't have to work in a GitHub-centric way. We could choose
to use ASF's Jira for issues, ASF's buildbots for CI, etc. But GitHub's
all-in-one way of working and the fact that it's so entrenched makes it the
path of least resistance for most users and contributors around the world,
and probably the least maintenance and administration effort for us. That's
probably why GitHub is in such widespread use. The convenience and
entrenchment is either an advantage (if you just want to write code and not
muck around with administering all kinds of systems or teaching
contributors your special way of working) or a disadvantage (if you don't
like dealing with the other baggage that comes with it), depending on your
point of view.

While I would rather we didn't depend on GitHub as much as we do, I
recognize that if we work any other way, it will introduce friction and
we'd likely take a big hit in the amount of contributors and contributions.
So, not because I like it but just because that's practical reality, I'd
rather accept it and just focus on getting work done.

I went off on a tangent. I began by talking about gitbox, which is on ASF
infra. If you set that up as your remote, you can pull from it and not deal
with GitHub for pulling. But what about the other direction, when you want
to upstream your work? Since we have adopted the convention that no one
merges their own changes (this is a good convention in my opinion), and
because of CI, anything you want to push has to become a PR somehow. I
don't really know how that can happen. I suppose you can email it to dev@
with a subject line starting with [PATCH] and someone can volunteer to put
it in a PR and sort of become the steward of it on GitHub.

But this won't get us out of the "AI" training datasets. Nothing will. As
others have said, all our code is public so anyone can take it and do
things with it, including training AI, and I'm sure there are lots more of
them than just this "Stack" thing.

Nathan

On Thu, Mar 21, 2024 at 6:43 PM Gregory Nutt  wrote:

> I think we need to continue to use PRs at some point in the process.
> PRs are so tied into our CI that I don't think we could work around it.
>
> Can you use another GIT repository?  If you create a PR on gitlab or
> bitbucket, someone could move the PR to github.  Or perhaps we could
> take commits from a local repository clone?  We haven't done it for a
> while, but patches could also be converted to github PRs with a little
> more effort.
>
> I think there are options, but without PRs on github, I don't see how
> you could independently make changes.
>
> On 3/21/2024 4:08 PM, Sebastien Lorquet wrote:
> > Hi,
> >
> > I plan to leave github completely and delete my account, because of
> > this: https://huggingface.co/spaces/bigcode/in-the-stack
> >
> > It is the last of reasons that make me want to leave this place for good.
> >
> > How can we imagine a process so I (and others) can continue to
> > contribute to NuttX without using pull requests from github? or any
> > public "forge" for that matter.
> >
> > Sebastien
> >
>

Re: Rust in the OS?

[Nathan Hartman]

tl;dr: I am in wait-and-see mode regarding Rust.

The long story:

I have been watching the programming language landscape for some time to
see if there is a viable successor to C/C++.

C has many advantages:

* Standardized (ISO and ANSI standards) since more than 30 years ago, which
makes the language very stable. Code that compiles and works today will
very likely compile and work tomorrow.

* Supported on all hardware.

* Supported by numerous compiler toolchains, free and proprietary.

* Supported by lots and lots of development tools of all kinds, such as
testing and analysis.

* Close to the hardware.

* Pretty much all operating systems and language interpreters are either
implemented in C or implemented in other languages that have a dependency
on C.

This (in addition to the Lindy Effect [1]) suggests to me that C will be
around and well supported for a long, long time to come.

C has only one disadvantage that I can think of, which is how easy it is to
make dumb mistakes that lead to big problems.

This one disadvantage is big enough that many people are searching for a
solution in the form of a new, safer programming language.

I personally don't think that Rust is necessarily "better" than C (I don't
think it's "worse" either). But AFAICT, if there is a language in
widespread use that could take over from C, it might be Rust. There is
significant interest in Rust and a lot of buzz about Rust around the
Internet. There is more than buzz. There is an ongoing effort to use Rust
in (isolated parts of) the Linux kernel, as well as the Windows OS. These
things are important because when it comes to choosing a language that
needs to be supported long term, widespread adoption is arguably the most
important factor.

The advantages of using Rust in the NuttX OS proper are, we hope, better
and safer code.

There would be some disadvantages also: Splitting the implementation
between C and Rust means:

* Needing to know both languages

* Dealing with the boundaries between the languages and whatever marshaling
needs to be done there

* To my knowledge, at this time Rust is *not* standardized by ISO or any
other standards organization, and the language is evolving, so we'd need to
deal with the incompatibility issues of tracking a specific version of the
language and possibly revisiting/rewriting code as new versions of Rust are
introduced. This may cause compatibility issues to our users. (Example:
What if their application is targeting a different version of Rust than
NuttX?)

I recently read an article on LWN about Rust in the Linux kernel. I think
it was the one at [2]. I highly recommend to read that if we're considering
Rust in NuttX to understand what some of the challenges might be, and to
learn how the Linux kernel devs are approaching that.

Back to my tl;dr about being in wait-and-see mode, I would like to see
standardization of the language by a recognized standards body before
adopting it for long-term use. That will indicate to me that the language
can be expected to stick around for a long time.

Also it will allow us to specify to what standard NuttX is written. We'll
be able to say NuttX is written to, say, Rust25 (or whatever the number
would be), the same way we say NuttX is written to C89.

Having said that, if the NuttX community wants to adopt Rust, provided it
is well discussed and the issues like evolving language are handled
somehow, I wouldn't oppose it. (But at this time, I'm not pushing for it.)

Hope this helps,
Nathan

[1]
https://en.m.wikipedia.org/wiki/Lindy_effect

[2]
https://lwn.net/Articles/952029/


On Wed, Mar 13, 2024 at 2:29 PM Gregory Nutt  wrote:

> There is some discussion in Issue #11907 proposing to use the Rust
> language within the OS (vs Rust applications on a pure C OS).  If anyone
> has any feelings, Pro or Con,  you should participate in this
> discussion.  This kind of decision impacts the entire community and
> should have the input of all of the community that has an opinion.
>
>
>

Re: Re:Re: mm/mm_heap assertion error

[Nathan Hartman]

One possibility is stack was too small before and overflowed.

Another possibility is that stack size is OK but some code makes an
out-of-bound write to an array on the stack.

Try Alan's suggestion to use stack monitor, and that will help understand
if there is something wrong. (If it shows that old stack size was OK, while
we know corruption was happening, then we will know to look for some out of
bound write.)

Nathan


On Tue, Mar 12, 2024 at 6:38 AM yfliu2008  wrote:

> Dear experts,
>
>
>
> After enlarging the stack size of "AppBringUp" thread, the remote
> node can boot NSH on RPMSGFS now. I am sorry for not trying this earlier. I
> was browsing the "rpmsgfs.c" blindly and noticed a few auto variables
> defined in the stack... then I thought it might worth a try so I did it.
>
>
> Now I am still unclear about why small stack leads to heap corruption?
> Also how we can read this stack issue from stackdump logs? Let me
> know if you have any hints.
>
>
> Regards,
> yf
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Original
>
>
>
> From:"yfliu2008"< yfliu2...@qq.com ;
>
> Date:2024/3/12 15:10
>
> To:"dev"< dev@nuttx.apache.org ;
>
> Subject:Re:Re: mm/mm_heap assertion error
>
>
> Nathan,
>
>
> Here I disabled RPMsg UART device initialization but the crash still
> happens, I don't see other options to disable for now. On the other hand,
> if we choose not mounting NSH from the RPMSGFS, it can boot smoothly and
> after boot we can manually mount the RPMSGFS for playing.
>
>
>
>
> I uploaded the logs, callstacks and ELFs at
> https://github.com/yf13/hello/tree/debug-logs/nsh-rpmsgfs . There are two
> sets from two ELFs created from same code base but with different DEBUG _xx
> configs. The crash happens earlier in the build with more debug
> options.
>
>
> Please let me know if you have any more suggestions.
>
>
> Regards,
> yf
>
>
>
>
> Original
>
>
>
> From:"Nathan Hartman"< hartman.nat...@gmail.com ;
>
> Date:2024/3/12 1:27
>
> To:"dev"< dev@nuttx.apache.org ;
>
> Subject:Re: mm/mm_heap assertion error
>
>
> What's needed is some way to binary search where the culprit is.
>
> If I understand correctly, it looks like the crash is happening in the
> later stages of board bring-up? What is running before that? Can parts
> be disabled or skipped to see if the problem goes away?
>
> Another idea is to try running a static analysis tool on the sources
> and see if it finds anything suspicious to be looked into more
> carefully.
>
>
> On Mon, Mar 11, 2024 at 10:00 AM Gregory Nutt  wrote:
> 
>  The reason that the error is confusing is because the error probably
> did
>  not occur at the time of the assertion; it probably occurred much
> earlier.
> 
>  In most crashes due to heap corruption there are two players:  the
>  culprit and the victim threads.  The culprit thread actually cause the
>  corruption.  But at the time of the corruption, no error occurs.  The
>  error will not occur until later.
> 
>  So sometime later, the victim thread runs, encounters the clobbered
> heap
>  and crashes.  In this case, "AppBringup" and "rptun" are potential
>  victim threads.  The fact that they crash tell you very little about
> the
>  culprit.
> 
>  On 3/10/2024 6:51 PM, yfliu2008 wrote:
>   Gregory, thank you for the analysis.
>  
>  
>  
>  
>   The crashes happened during system booting up, mostly at
> "AppBringup" or "rptun" threads, as per the assertion logs. The other
> threads existing are the "idle" and the "lpwork" threads as per the sched
> logs. There should be no other threads as NSH creation is still
> ongoing. As for interruptions, the UART and IPI are running in kernel
> space and MTIMER are in NuttSBI space. The NSH is loaded from a
> RPMSGFS volume, thus there are a lot RPMSG communications.
>  
>  
>  
>  
>   Is the KASAN proper for use in Kernel mode?
>  
>  
>   With MM_KASAN_ALL it reports a read access error:
>  
>  
>  
>   BCkasan_report: kasan detected a read access error, address at
> 0x708fe90,size is 8, return address: 0x701aeac
>  
>   _assert: Assertion failed panic: at file: kasan/kasan.c:117
> task: Idle_Task process: Kernel 0x70023c0
>  
>  
>   The call stack looks like:
>  
>  
>   #0 _assert (filename=0x7060f78 "kasan/kasan.c",
> linenum=117, msg=0x7060ff0 "panic", regs=0x7082720   #2
> 0x070141d6 in kasan_report (addr=0x708fe90, size=8,
> is_write=false, return_address=0x7

Re: mm/mm_heap assertion error

[Nathan Hartman]

What's needed is some way to binary search where the culprit is.

If I understand correctly, it looks like the crash is happening in the
later stages of board bring-up? What is running before that? Can parts
be disabled or skipped to see if the problem goes away?

Another idea is to try running a static analysis tool on the sources
and see if it finds anything suspicious to be looked into more
carefully.


On Mon, Mar 11, 2024 at 10:00 AM Gregory Nutt  wrote:
>
> The reason that the error is confusing is because the error probably did
> not occur at the time of the assertion; it probably occurred much earlier.
>
> In most crashes due to heap corruption there are two players:  the
> culprit and the victim threads.  The culprit thread actually cause the
> corruption.  But at the time of the corruption, no error occurs.  The
> error will not occur until later.
>
> So sometime later, the victim thread runs, encounters the clobbered heap
> and crashes.  In this case, "AppBringup" and "rptun" are potential
> victim threads.  The fact that they crash tell you very little about the
> culprit.
>
> On 3/10/2024 6:51 PM, yfliu2008 wrote:
> > Gregory, thank you for the analysis.
> >
> >
> >
> >
> > The crashes happened during system booting up, mostly at "AppBringup" or 
> > "rptun" threads, as per the assertion logs. The other threads existing are 
> > the "idle" and the "lpwork" threads as per the sched logs. There should be 
> > no other threads as NSH creation is still ongoing. As for 
> > interruptions, the UART and IPI are running in kernel space and MTIMER are 
> > in NuttSBI space. The NSH is loaded from a RPMSGFS volume, thus there 
> > are a lot RPMSG communications.
> >
> >
> >
> >
> > Is the KASAN proper for use in Kernel mode?
> >
> >
> > With MM_KASAN_ALL it reports a read access error:
> >
> >
> >
> > BCkasan_report: kasan detected a read access error, address at 
> > 0x708fe90,size is 8, return address: 0x701aeac
> >
> > _assert: Assertion failed panic: at file: kasan/kasan.c:117 task: Idle_Task 
> > process: Kernel 0x70023c0
> >
> >
> > The call stack looks like:
> >
> >
> > #0 _assert (filename=0x7060f78 "kasan/kasan.c", linenum=117, 
> > msg=0x7060ff0 "panic", regs=0x7082720  > misc/assert.c:536#1 0x07010248 in __assert 
> > (filename=0x7060f78 "kasan/kasan.c", linenum=117, msg=0x7060ff0 "panic") at 
> > assert/lib_assert.c:36
> > #2 0x070141d6 in kasan_report (addr=0x708fe90, size=8, 
> > is_write=false, return_address=0x701aeac  > kasan/kasan.c:117
> > #3 0x07014412 in kasan_check_report (addr=0x708fe90, size=8, 
> > is_write=false, return_address=0x701aeac  > kasan/kasan.c:190
> > #4 0x0701468c in __asan_load8_noabort (addr=0x708fe90) at 
> > kasan/kasan.c:315
> > #5 0x0701aeac in riscv_swint (irq=0, context=0x708fe40, 
> > arg=0x0) at common/riscv_swint.c:133
> > #6 0x0701b8fe in riscv_perform_syscall (regs=0x708fe40) at 
> > common/supervisor/riscv_perform_syscall.c:45
> > #7 0x07000570 in sys_call6 ()
> >
> >
> >
> > With MM_KASAN_DISABLE_READ_CHECKS=y, it reports:
> >
> >
> > _assert: Assertion failed : at file: mm_heap/mm_malloc.c:245 task: rptun 
> > process: Kernel 0x704a030
> >
> >
> > The call stack is:
> >
> >
> > #0 _assert (filename=0x7056060 "mm_heap/mm_malloc.c", linenum=245, 
> > msg=0x0, regs=0x7082720  > 0x0700df18 in __assert (filename=0x7056060 
> > "mm_heap/mm_malloc.c", linenum=245, msg=0x0) at assert/lib_assert.c:36
> > #2 0x07013082 in mm_malloc (heap=0x7089c00, size=128) at 
> > mm_heap/mm_malloc.c:245
> > #3 0x07011694 in kmm_malloc (size=128) at 
> > kmm_heap/kmm_malloc.c:51
> > #4 0x0704efd4 in metal_allocate_memory (size=128) at 
> > .../nuttx/include/metal/system/nuttx/alloc.h:27
> > #5 0x0704fd8a in rproc_virtio_create_vdev (role=1, notifyid=0,
> >   rsc=0x80200050, rsc_io=0x7080408  > priv=0x708ecd8,
> >   notify=0x704e6d2  >   at open-amp/lib/remoteproc/remoteproc_virtio.c:356
> > #6 0x0704e956 in remoteproc_create_virtio (rproc=0x708ecd8,
> >   vdev_id=0, role=1, rst_cb=0x0) at 
> > open-amp/lib/remoteproc/remoteproc.c:957
> > #7 0x0704b1ee in rptun_dev_start (rproc=0x708ecd8)
> >   at rptun/rptun.c:757
> > #8 0x07049ff8 in rptun_start_worker (arg=0x708eac0)
> >   at rptun/rptun.c:233
> > #9 0x0704a0ac in rptun_thread (argc=3, argv=0x7092010)
> >   at rptun/rptun.c:253
> > #10 0x0700437e in nxtask_start () at task/task_start.c:107
> >
> >
> > This looks like already corrupted.
> >
> >
> >
> > I also noticed there is a "mm_checkcorruption()" function, not sure how to 
> > use it yet.
> >
> >
> >
> > Regards,
> > yf
> >
> >
> >
> >
> >
> > Original
> >
> >
> >
> > From:"Gregory Nutt"< spudan...@gmail.com ;
> >
> > Date:2024/3/11 1:43
> >
> > To:"dev"< dev@nuttx.apache.org ;
> >
> > Subject:Re: mm/mm_heap assertion error
> >
> >
> > On 3/10/2024 4:38 AM, yfliu2008 wrote:
> >  Dear experts,
> > 
> > 
> > 
> > 
> >  When doing 

Re: Ethernet direct RMII connection

[Nathan Hartman]

RMII just means it uses fewer I/O pins from the MCU as compared to MII. I
don't remember the details either but it's possible that some chips support
RMII and not MII because they don't have the additional I/O pins.

Tiva-C (arch/arm/src/tiva) supports RMII (the chip has the built-in MAC and
PHY) so maybe you can use that as a general example. Of course the details
of drivers for STM32 will be quite different.

Cheers
Nathan

On Thu, Feb 29, 2024 at 2:15 PM Alan C. Assis  wrote:

> Hi Roland,
>
> We had a discussion about it a few months ago!
>
> We know it is possible, but nobody until now tried to do it.
>
> Basically you will need RMII support on both chips, I don't remember the
> details why MII will not work (or will be more difficult to work)
>
> There is a discussion about it here, maybe you can get more insights:
>
> https://stackoverflow.com/questions/39503466/can-two-ethernet-mac-chips-be-connected-directly-without-going-thru-phy
>
> Best Regards,
>
> Alan
>
>
> On Thu, Feb 29, 2024 at 2:11 PM Roland  wrote:
>
> > Hi,
> >
> > I would like to directly connect a STM32F7 processor running Nuttx, to an
> > external MCU (i.e., NXP imx8m) through RMII directly, without the need
> for
> > PHY IC in between.
> > Is this supported by Nuttx? I checked into the documents but this direct
> > mode seems not been mentioned anywhere.
> > Can anyone please confirm if this is supported, or I have to change
> > something by myself?
> >
> > Thank you.
> >
> > /Roland
> >
> >
>

Re: [Article] Drag-n-Drop a NuttX App

[Nathan Hartman]

The NuttX website says so little yet NuttX can do so much in so many
different areas. How can we draw attention to all those possibilities?

On Sat, Feb 24, 2024 at 5:03 PM Lee, Lup Yuen  wrote:

> Remember MakeCode? BBC micro:bit and its Drag-n-Drop App Builder? MakeCode
> for BBC micro:bit is an awesome creation that’s way ahead of its time (7
> years ago!)
> - TypeScript Compiler and Arm Assembler in the Web Browser (in JavaScript!)
> - Custom Embedded OS (CODAL + Mbed OS)
> - micro:bit Simulator in JavaScript
>
> Today 7 years later: How would we redo all this? Maybe with...
> (1) Hardware Device: Ox64 BL808 64-bit RISC-V SBC
> (2) Embedded OS: Apache NuttX RTOS
> (3) JavaScript Engine: QuickJS for NuttX
> (4) Web Emulator: TinyEMU WebAssembly for NuttX
> (5) C Compiler + Assembler: TCC WebAssembly for NuttX
> (6) Device Control: Web Serial API with Term.js
>
> This article explains how we gave MakeCode a wholesome wholesale makeover
> with NuttX:
> https://lupyuen.codeberg.page/articles/quickjs2.html
>
> Lup
>

Re: Nuttx not starting after jumping from bootloader

[Nathan Hartman]

I've run into problems like that before. I recommend ensuring that the
bootloader performs a cleanup: return all peripherals to their
original state and turn off any interrupts it previously enabled.
Otherwise, very subtle and hard-to-find bugs can creep in.

Out of curiosity, is this a custom bootloader or an existing
open-source project? If an open-source project, I recommend to
upstream your fixes...

Cheers,
Nathan

On Wed, Feb 21, 2024 at 11:19 AM Alan C. Assis  wrote:
>
> Just a update here for people facing similar issue in the future.
>
> Actually Jose discovered the issue was not on NuttX itself, but it was
> an Interrupt enabled in the bootloader that was missing an entry IRQ
> vector table.
>
> Best Regards,
>
> Alan
>
> On 2/20/24, Ambrocio, Jose  wrote:
> > Hello Nuttx team,
> > I'm currently working on an embedded project that uses a bootloader and an
> > application. The target is a STM32G0B1VCI6 chip. I'm using the initial
> > address (0x0800 ) for the bootloader with 40K of size. Application
> > starts at 0x0800 A000 with 216K of size. Before jumping to the application
> > I'm setting the main stack pointer and configuring the vector table to point
> > to the start address of the app.  I see that the app is executed but it
> > remains in the function irq_initialize  and doing some debug I noticed that
> > it is stuck in the assert function, in an infinite loop:
> > [cid:image003.jpg@01DA63E7.A577AD90]
> >
> > I wonder if nuttx has some dependencies with the initial addresses or if
> > there is something that must be configured before jumping. This is the code
> > I have for the jumping:
> >
> > [cid:image004.png@01DA63E7.A577AD90]
> > Where NUTTX_APPLICATION_ENTRY_POINT is 0x0800A000.
> > I did a different test using another application (without nuttx) and the
> > bootloader can jump without any problem and the application can be
> > executed.
> > I would appreciate your help. Thanks
> > José Daniel Ambrocio
> > Embedded SW Engineer
> >

NuttX poster?

[Nathan Hartman]

At this year's Community over Code Europe 2024 (formerly ApacheCon),
there is an opportunity for PMCs to submit posters to be on display in
high-traffic areas throughout the conference.

This could be particularly applicable if a project has a major new
release, new algorithms, novel use of existing technologies, etc.

It would be cool if the NuttX PMC could submit a poster to increase
awareness and interest in our project by showcasing something unique
about us in an artistic way.

Do we have any artists among us who would like to put something
together? Please speak up, and I'll help by coordinating with the
organizers.

Cheers,
Nathan

Re: STM32H7 board with ethernet

[Nathan Hartman]

That's good news. I missed that somehow. Hopefully it means that I can go
ahead and delete some custom application code!

Cheers
Nathan

On Tue, Feb 6, 2024 at 10:55 AM Gregory Nutt  wrote:

> The network monitor is part of apps/netutils/netinit so it is not a part
> of NSH.  NSH can automatically perform the network initialization if so
> configured and which, optionally, starts the network monitor thread.
> But the logic is not architecturally a part of NSH nor does it depend on
> N SH.
>
> On 2/6/2024 9:32 AM, Nathan Hartman wrote:
> > On Tue, Feb 6, 2024 at 8:45 AM Sebastien Lorquet 
> > wrote:
> >
> >> However, the default network configuration provided in NuttX examples is
> >> cumbersome and too much linked with NSH
> >>
> >> It can work for simple tests and demos, but you will have to write a
> >> proper network management daemon if you plan to use more than one
> >> network app.
> >
> >
> > It would be a nice thing if the network management daemon could be
> factored
> > out of NSH so that boards that don't run NSH could have the same network
> > management without implementing it again.
> >
> > Cheers
> > Nathan
> >
>
>

Re: STM32H7 board with ethernet

[Nathan Hartman]

On Tue, Feb 6, 2024 at 8:45 AM Sebastien Lorquet 
wrote:

>
> However, the default network configuration provided in NuttX examples is
> cumbersome and too much linked with NSH
>
> It can work for simple tests and demos, but you will have to write a
> proper network management daemon if you plan to use more than one
> network app.



It would be a nice thing if the network management daemon could be factored
out of NSH so that boards that don't run NSH could have the same network
management without implementing it again.

Cheers
Nathan

Re: [Article] NuttX in the Web Browser (TinyEMU + VirtIO)

[Nathan Hartman]

Hi Lup,

That's great! The NuttX website is hosted from the nuttx-website repository
(see [1]) so it should be pretty easy to add it there. The site is coded
with jekyll. Everyone in the project can update the site and quite a few of
us have done it at one time or another. If you have any questions just ask
here on the list!

Cheers,
Nathan

[1] https://github.com/apache/nuttx-website


On Tue, Jan 16, 2024 at 6:46 PM Lee, Lup Yuen  wrote:

> Hi Nathan: Yep it's easy to host the NuttX Online Demo on any website, it's
> just a bunch of Static HTML, JavaScript and WebAssembly files. Please lemme
> know whom I should work with :-)
>
> Meanwhile I'll upstream the TinyEMU RISC-V Port of NuttX. Thanks!
>
> Lup
>
> On Wed, Jan 17, 2024 at 8:40 AM Nathan Hartman 
> wrote:
>
> > This is very cool! Could it be possible to put it direct on the NuttX
> > website? e.g., "Try NuttX in the browser"
> >
> > On Mon, Jan 15, 2024 at 5:58 PM Alan C. Assis  wrote:
> >
> > > Interesting!
> > > Thank you very much Lup for investigating it further!
> > >
> > > BR,
> > > Alan
> > >
> > > On Mon, Jan 15, 2024 at 2:34 AM Lee, Lup Yuen 
> wrote:
> > >
> > > > << Do you think it is possible to find an alternative to use the
> users'
> > > > browser connection to communicate to the Internet? This way it avoids
> > > > users' consumption of all internet limits on the server side. >>
> > > >
> > > > Hi Alan: You're right, TinyEMU Emulator talks to a WebSocket VPN
> hosted
> > > at
> > > > `
> > > > relay.widgetry.org` that's throttled at 40 kB/s (for free, fair
> use).
> > > But
> > > > I
> > > > don't see a good alternative to this WebSocket VPN:
> > > >
> > > > (1) Can the Web Browser talk directly to the internet without
> WebSocket
> > > > VPN?
> > > >
> > > > TinyEMU and VirtIO Networking are sending Ethernet Frames / IP
> Packets
> > > from
> > > > the Web Browser to the internet. But Web Browsers are not allowed to
> > send
> > > > IP Packets directly. That's why we need to tunnel the packets
> through a
> > > > WebSocket VPN.
> > > >
> > > > (2) Can we host our own WebSocket VPN on our Local Computer?
> > > >
> > > > Possibly. But then we will have to host the Web Server on our Local
> > > > Computer too. Which makes it cumbersome to install.
> > > >
> > > > (3) Can we host the WebSocket VPN on a server operated by the NuttX
> > > > Project?
> > > >
> > > > Probably not, because we need to throttle the internet traffic for
> > free,
> > > > fair use. And prevent abuse.
> > > >
> > > > I've documented my findings on TinyEMU, VirtIO Networking and
> WebSocket
> > > > VPN:
> > > >
> > > >
> > >
> >
> https://github.com/lupyuen/nuttx-tinyemu#tinyemu-networking-in-the-web-browser
> > > >
> > > > Lup
> > > >
> > > > On Sun, Jan 14, 2024 at 9:54 PM Alan C. Assis 
> > wrote:
> > > >
> > > > > Hi Lup,
> > > > >
> > > > > Thank you very much!
> > > > >
> > > > > Looking at the WebSocket VPN article it said the connection goes
> > > through
> > > > > the server hosting the emulator.
> > > > >
> > > > > Do you think it is possible to find an alternative to use the
> users'
> > > > > browser connection to communicate to the Internet?
> > > > > This way it avoids users' consumption of all internet limits on the
> > > > server
> > > > > side.
> > > > >
> > > > > BR,
> > > > >
> > > > > Alan
> > > > >
> > > > > On Sun, Jan 14, 2024 at 4:17 AM Lee, Lup Yuen 
> > > wrote:
> > > > >
> > > > > > Thanks Alan! Yep "The Construct" looks like a cool way to learn
> ROS
> > > > > online,
> > > > > > we should do something similar for Teaching NuttX Online!
> > > > > >
> > > > > > As for Emulated Networking in the Web Browser: TinyEMU Emulator
> > > > supports
> > > > > > VirtIO Networking. But it's tunnelled through a WebSocket VPN,
> > > because
> > > > of
> > > > > > browser limitations.
> 

Re: [Article] NuttX in the Web Browser (TinyEMU + VirtIO)

[Nathan Hartman]

This is very cool! Could it be possible to put it direct on the NuttX
website? e.g., "Try NuttX in the browser"

On Mon, Jan 15, 2024 at 5:58 PM Alan C. Assis  wrote:

> Interesting!
> Thank you very much Lup for investigating it further!
>
> BR,
> Alan
>
> On Mon, Jan 15, 2024 at 2:34 AM Lee, Lup Yuen  wrote:
>
> > << Do you think it is possible to find an alternative to use the users'
> > browser connection to communicate to the Internet? This way it avoids
> > users' consumption of all internet limits on the server side. >>
> >
> > Hi Alan: You're right, TinyEMU Emulator talks to a WebSocket VPN hosted
> at
> > `
> > relay.widgetry.org` that's throttled at 40 kB/s (for free, fair use).
> But
> > I
> > don't see a good alternative to this WebSocket VPN:
> >
> > (1) Can the Web Browser talk directly to the internet without WebSocket
> > VPN?
> >
> > TinyEMU and VirtIO Networking are sending Ethernet Frames / IP Packets
> from
> > the Web Browser to the internet. But Web Browsers are not allowed to send
> > IP Packets directly. That's why we need to tunnel the packets through a
> > WebSocket VPN.
> >
> > (2) Can we host our own WebSocket VPN on our Local Computer?
> >
> > Possibly. But then we will have to host the Web Server on our Local
> > Computer too. Which makes it cumbersome to install.
> >
> > (3) Can we host the WebSocket VPN on a server operated by the NuttX
> > Project?
> >
> > Probably not, because we need to throttle the internet traffic for free,
> > fair use. And prevent abuse.
> >
> > I've documented my findings on TinyEMU, VirtIO Networking and WebSocket
> > VPN:
> >
> >
> https://github.com/lupyuen/nuttx-tinyemu#tinyemu-networking-in-the-web-browser
> >
> > Lup
> >
> > On Sun, Jan 14, 2024 at 9:54 PM Alan C. Assis  wrote:
> >
> > > Hi Lup,
> > >
> > > Thank you very much!
> > >
> > > Looking at the WebSocket VPN article it said the connection goes
> through
> > > the server hosting the emulator.
> > >
> > > Do you think it is possible to find an alternative to use the users'
> > > browser connection to communicate to the Internet?
> > > This way it avoids users' consumption of all internet limits on the
> > server
> > > side.
> > >
> > > BR,
> > >
> > > Alan
> > >
> > > On Sun, Jan 14, 2024 at 4:17 AM Lee, Lup Yuen 
> wrote:
> > >
> > > > Thanks Alan! Yep "The Construct" looks like a cool way to learn ROS
> > > online,
> > > > we should do something similar for Teaching NuttX Online!
> > > >
> > > > As for Emulated Networking in the Web Browser: TinyEMU Emulator
> > supports
> > > > VirtIO Networking. But it's tunnelled through a WebSocket VPN,
> because
> > of
> > > > browser limitations.
> > > >
> > > > I might test this with NuttX and see how well it works. (I'm also
> keen
> > to
> > > > emulate Ox64 BL808 RISC-V SBC in the Web Browser)
> > > >
> > > > TinyEMU VirtIO Networking: https://bellard.org/jslinux/tech.html
> > > >
> > > > WebSocket VPN:
> > > > https://www.benjamincburns.com/2013/11/10/jor1k-ethmac-support.html
> > > >
> > > > Lup
> > > >
> > > > On Sun, Jan 14, 2024 at 8:10 AM Alan C. Assis 
> > wrote:
> > > >
> > > > > Really cool Lup!
> > > > >
> > > > > Maybe it could be used for training and deduction purposes. Do you
> > know
> > > > > "The Construct" they are using a solution like that to run Linux in
> > the
> > > > > browser:
> > > > >
> > > > > https://app.theconstructsim.com/login/
> > > > >
> > > > > Is it possible to get network enabled and use it to communicate? It
> > > could
> > > > > open new possibilities!
> > > > >
> > > > > BR,
> > > > >
> > > > > Alan
> > > > >
> > > > >
> > > > > On Sat, Jan 13, 2024 at 8:30 PM Lee, Lup Yuen 
> > > wrote:
> > > > >
> > > > > > NuttX now boots and runs inside a Web Browser! (With WebAssembly)
> > > > > >
> > > > > > Try "ostest" here: https://lupyuen.github.io/nuttx-tinyemu
> > > > > >
> > > > > > This article explains how we…
> > > > > > (1) Boot NuttX in the Web Browser with TinyEMU RISC-V Emulator
> > > > > > (2) Modify NuttX for HTIF Console (Berkeley Host-Target
> Interface)
> > > > > > (3) Explore VirtIO Console with OpenAMP Library
> > > > > > (4) And how we might use it: Emulate NuttX Gadgets in the Web
> > > Browser?
> > > > A
> > > > > > Real-Time NuttX Dashboard that lights up as the various NuttX
> > Drivers
> > > > are
> > > > > > called?
> > > > > >
> > > > > > Here's the article:
> > > > https://lupyuen.codeberg.page/articles/tinyemu.html
> > > > > >
> > > > > > How will you use NuttX in a Web Browser? Please lemme know 
> > > > > >
> > > > > > Lup
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: debugging user app crashes

[Nathan Hartman]

On Thu, Jan 11, 2024 at 10:35 AM Gregory Nutt  wrote:

> Everything you need to know is in that referenced wiki page:
>
> https://cwiki.apache.org/confluence/display/NUTTX/Debugging+ELF+Loadable+Modules
>
> I don't know anything about QEMU or RISC-V.  But assuming that NSH is
> your init application...
>
>   * NSH is not in memory when you start the OS; it resides in your init
> file.  The OS will automatically start NSH as the init application
> (if properly configured).
>   * Since there is no gdbserver or ptrace, there is not elegant way to
> break into the program.  Some kludgey ways to do that are described
> in the referenced wiki page.
>   * Then just follow the instructions in the wiki page:
>   o Start the debugger
>   o Load the symbol table of the NSH application.  You probably
> don't need as load offset as described in the wiki page.
>   o Set a breakpoint at nsh_parse, and
>   o Continue
>
> I have nothing to add to that.



Note to self: Check whether above-linked wiki page has been migrated to
Documentation in the repository and, if not, migrate it...

I likely won't be able to work on that until next week, so if someone else
wants to do it, feel free. :-)

Cheers
Nathan

Re: debugassert vs assert in apps

[Nathan Hartman]

On Wed, Jan 3, 2024 at 11:22 AM Gregory Nutt  wrote:
>
> On 1/3/2024 10:11 AM, Fotis Panagiotopoulos wrote:
> >> That would seem a little odd since there was a PR a few years ago to
> > change all instances of assert/ASSERT to DEBUGASSERT to save code size.
> >
> > How is that so?
> >
> > As I see here:
> > https://github.com/apache/nuttx/blob/master/include/assert.h#L122
> > assert defined exactly as DEBUGASSERT.
> >
> > There shouldn't be any code size difference at all.
>
> When CONFIG_DEBUG_ASSERTIONS is not defined, then all occurrences of
> DEBUGASSERT compile to nothing (actually the current version compiles to
> an expression that is optimized out):
>
> #undef DEBUGASSERT  /* Like ASSERT, but only if
> CONFIG_DEBUG_ASSERTIONS is defined */
>
> #ifdef CONFIG_DEBUG_ASSERTIONS
> #  define DEBUGASSERT(f) _ASSERT(f, __DEBUG_ASSERT_FILE__,
> __DEBUG_ASSERT_LINE__)
> #else
> #  define DEBUGASSERT(f) ((void)(1 || (f)))
> #endif
>
> This value, ((void)(1 || (f))), is completely removed by the optimizer
> because of short-circuiting and dead code removal.  So the code is much
> smaller if CONFIG_DEBUG_ASSERTIONS is not enabled.  If DEBUGASSERT() is
> replaced with assert() than that code bloat would be unconditional,
> although somewhat less than when assertions are enabled.
>
> This same kind of logic also applies to  DEBUGPANIC and DEBUGVERIFY.
>
> Xiao Xiang made that change to reduce the size as needed by their
> products.  He is the person you should be talking to.


Maybe we need NX_DEBUGASSERT, NX_DEBUGPANIC, NX_DEBUGVERIFY. The NX
prefix would make it more clear that this is NuttX-specific. These
would be used in the OS only, not in applications, and
CONFIG_DEBUG_ASSERTIONS would continue to control if these are real or
optimized out.

Applications that need their own specific, Kconfig-controlled debug
assertion, should define one themselves, and their own Kconfig to
optimize it out. Rationale: If you are debugging an application,
enable assertions only in that application, not everywhere throughout
the system.

Cheers
Nathan

Re: debugassert vs assert in apps

[Nathan Hartman]

This is an excellent summary! I suggest this should be documented
somewhere in Documentation, with a more summarized version in the
comment block of these macros. This way, the discussion and its
conclusions will not be forgotten in the future!!

Happy New Year,
Nathan

On Tue, Jan 2, 2024 at 11:16 AM Fotis Panagiotopoulos
 wrote:
>
> Hello everyone, and happy new year!
>
> After discussing this with Tim, I would like to present my opinion on this
> topic, in the hope we build better code conventions
> (or maybe understand better how apps are developed in Nuttx, as I don't use
> them often).
>
> So the idea is:
>
> DEBUGASSERT shall only be used for the kernel.
> assert shall only be used for apps.
>
> Rationale:
>
> DEBUGASSERT is a custom macro that only exists in the NuttX world.
> As such it is best being used in NuttX-specific code.
>
> assert on the other hand is a standard function, it exists in all systems.
> It seems better suited for generic and portable code (i.e. apps).
>
> Benefits of this approach:
>
> 1. Kernel and apps development can be isolated.
> It is very common to work only on one of the two parts of the system at a
> time.
> In some cases, different people (or teams) work on these two different
> codebases,
> so it is advantageous to only enable what you actually care for.
>
> 2. assert is more portable.
> Generic applications shall remain portable (in the POSIX domain), and not
> have dependencies on
> "custom things". So one can easily grab a NuttX app and run it on another
> system (e.g. Linux).
> Or get an external library, not meant for NuttX, and run it directly and
> unaltered.
> I see minimal value in adding OS-specific macros in generic code.
>
> 3. The two macros may have different implementations.
> Having two different macros with different scopes may allow as in the
> future to have them implemented
> optimally for their use case.
> For example, DEBUGASSERT may provide more OS-specific information about the
> time of crash,
> reboot the system etc.
> On the other hand assert may only terminate the offending task, or provide
> more task-specific information etc.
> Of course, I know how complicated this is. For the time I only discuss
> about keeping the distinction and having
> the future ability.
>
> 4. Code readability / maintainability.
> Mixing up assert and DEBUGASSERT in the same code (i.e. in an app), is very
> confusing.
> I don't understand, why use one or the other? Are they different? Why be
> inconsistent?
> If they are identical now, will they remain so forever?
> What if someone needs to make OS-specific changes to DEBUGASSERT.
>
> 5. Static code analysis.
> There are several good static code analysis tools, and I use some of them.
> They can mostly understand assert but not the custom DEBUGASSERT macro.
> This causes headaches to re-define correctly DEBUGASSERT in the scope of
> the static analysis tool.
> Using non-standard macros I have seen checks to fail, or cause false
> positives / negatives:
> * About unused variables (that are only used in the asserts).
> * About asserts with side effects (the tool does not check properly custom
> macros)
> * About NULL pointer dereferences (that however are checked by asserts).
> and more...
>
>
>
> On Sun, Dec 17, 2023 at 7:04 AM Daniel Appiagyei
>  wrote:
>
> > While we’re on this topic I would also like to encourage authors to put
> > only one condition in their asserts instead of multiple.
> > So, DEBUGASSERT(cond1)
> > ; DEBUGASSERT (cond2); (…)
> >
> > Instead of DEBUGASSERT(cond1 && cond2 &&..).
> >
> > When an assertion happens and there’s multiple conditions then I don’t know
> > which one triggered it.
> > Best,
> > Daniel
> >
> >
> > *Daniel Appiagyei | Embedded Software Engineer *Email:
> > daniel.appiag...@braincorp.com
> > *Brain*
> > * Corp™ *10182 Telesis Ct, Suite 100
> > San Diego, CA 92121
> >
> > (858)-689-7600
> > www.braincorp.com
> >
> >
> > On Fri, Dec 15, 2023 at 3:40 AM Alan C. Assis  wrote:
> >
> > > I think debugassert() is for finding BUGs during the development/testing
> > > phase.
> > >
> > > In the other hand assert() should be put in case where something really
> > > catastrofic is going to happen and cannot be avoid anyway.
> > >
> > > My personal opinion is that release code shouldn't have (or should have
> > the
> > > minimum as possible) assert() and PANIC(). You don't wasn't want your
> > code
> > > to fail in a critical moment, do you?
> > >
> > > So assert() code could be used during an inicial validation phase in the
> > > field. But of course, if it is a HW issue, there is nothing your code can
> > > do except showing a BSOD.
> > >
> > > BR,
> > >
> > > Alan
> > >
> > > On Thu, Dec 14, 2023 at 11:50 AM Tim Hardisty 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I'm wondering if there is an "approved" usage of assert vs debugassert
> > > > for files/apps in the nuttx-apps repo?
> > > >
> > > > My thinking is:
> > > >
> > > >   * use debugassert if a function in apps would 

NuttX on i486?

[Nathan Hartman]

Has anyone tried to run NuttX on a physical x86 i486 machine?

(I haven't tried yet. Asking first. :-)

Cheers,
Nathan

Re: Read response from console

[Nathan Hartman]

So, in Kconfig, Example/popen should "depends on" FIFO and named pipe
drivers?


On Wed, Dec 20, 2023 at 2:08 PM Alan C. Assis  wrote:

> That is because you forgot to enable:
>
> Device Drivers --->
> [*] FIFO and named pipe drivers  --->
>
> Remember: "git grep" is your friend!
>
> BR,
>
> Alan
>
> On Wed, Dec 20, 2023 at 9:53 AM Gustavo Soares <
> gustavo.felipesoa...@hotmail.com> wrote:
>
>> Hi Alan!
>>
>>  Yes, this message pops up when trying to compile:
>>
>> the problem seems to be in the apps/system/popen.
>> Should any other configuration be applied besides enabling the
>> popen()/pclose() functions?
>>
>> --
>> *De:* Alan C. Assis 
>> *Enviado:* quarta-feira, 20 de dezembro de 2023 08:15
>> *Para:* dev@nuttx.apache.org 
>> *Assunto:* Re: Read response from console
>>
>> Hi Gustavo,
>>
>> Do you mean apps/examples/popen is not working?
>>
>> I remember using popen() in the past to get the result of other program
>> output.
>>
>> Best Regards,
>>
>> Alan
>>
>> On Mon, Dec 18, 2023 at 3:39 PM Gustavo Soares <
>> gustavo.felipesoa...@hotmail.com> wrote:
>>
>> Hello everyone!
>>
>>  I have some i2c devices connected to my ESP32 and I can get their values
>> by using the i2c get command from NuttX. Now I need my app to extract the
>> value from the response, so I enabled the popen() and pclose() functions
>> but it still not possible to use them, is there any other config that must
>> be enabled? Even the popen example can't find the method reference.
>>
>>
>> BR,
>> Gustavo.
>>
>>

Re: Networking Delay: SO_SNDTIMEO odd behavior

[Nathan Hartman]

On Tue, Nov 28, 2023 at 3:58 AM Alan C. Assis  wrote:

> Hi Hakeem,
>
> Thank you very much for reporting an issue your team found.
>
> Could you please open an issue with more information at
> https://github.com/apache/nuttx/issues and supply a little bit more
> information (board/mcu used, version of NuttX, host OS, etc).
>
> Please also supply your board config (run "make savedefconfig" and
> attach the defconfig generated).



Also please specify which version of NuttX you are using -- is it a
released tarball and if so which version, or is it a clone from git and if
so is it the latest available master?

Thanks
Nathan

Re: NXP RT Processor Suport

[Nathan Hartman]

On Sun, Nov 26, 2023 at 4:32 PM Igor Kovriga
 wrote:

>
> Hello Apache NuttX Community,
>
>
> Due to this Link
>
> https://nuttx.apache.org/docs/latest/platforms/arm/imxrt/index.html
>
> NuttX  support RT1020 processor , and also at  the botom of this page
> specified   i.MX RT1020 Evaluation Kit
>
> But when I tried to create an assembly on the NXP web-site, I did not
> see NuttX  there (only FreeRTOS and Azure).



I am not familiar with NXP, but based on familiarity with other parts
vendors, I imagine NXP provides some kind of easy-to-use configurator tool
to set up a firmware project with their tooling and with various 3rd party
code like RTOS and other middleware and drivers.

If so, and if you don't see NuttX as an option there, then it likely means
they have not added support for NuttX in their tooling.

To configure NuttX for the i.MX RT1020 eval kit, you would first need to
set up a development system as is described in the Getting Started guide:

https://nuttx.apache.org/docs/latest/quickstart/index.html

This involves making sure you have the appropriate compiler toolchain
installed along with some other tools, like kconfig-frontends for example.

Once you have the necessary tools installed and the NuttX tree on your
system, in the nuttx directory, select the board with a command like:

$ tools/configure.sh imxrt1020-evk:nsh

Possibly customize the configuration, or just look through the Kconfig
menus to see which compile-time NuttX configurations are present with
something like:

$ make menuconfig

Build with:

$ make

And flash-program with the appropriate tool. I don't know which tool is
used for i.MXRT but you can look through the documentation and READMEs in
the NuttX tree, check the board directory at
boards/arm/imxrt/imxrt1020-evk/, or ask on this mailing list for more help.

More below:


NXP doesn't mention support   OS NuttX by RT10120 processor.
> How can I get a build for this processor?



In other words, what I'm explaining is that (I assume, based on what I know
from other architectures) getting NuttX built for this board requires using
our (NuttX's) tooling and build system, rather than a NXP configurator tool.

Cheers
Nathan

Re: Dumb question re: "full path", out of tree board

[Nathan Hartman]

On Thu, Nov 23, 2023 at 6:42 AM Tim Hardisty 
wrote:

> Hi,
>
> I have an out-of-tree custom board (which lives resides in my main NuttX
> folder as  ./../CustomBoards/boardname). I use checkpatch.sh even on my
> board software in that locations as I like to be consistent, but it
> complains that the path (line 2 of the header comment) must begin with
> the root directory as it's a relative path other than "nuttx".



I hope it is *not* requiring an absolute path here, because that would be
unacceptable: a developer might put the NuttX tree in, e.g.,
/home/bob/work/NuttX/... on one machine, and another team member might put
it in /home/alice/NuttX, and if we're requiring an absolute path then the
source files become tied to one particular machine with one particular
layout which is not portable to other machines. This may or may not apply
in Tim's case, but even if this doesn't apply to Tim's case, it would be
incorrect.

I am using my phone atm so I cannot dig into the sources right now, but
I'll try to look a little later...

Cheers
Nathan

Re: Multiple IP addresses with a single GMAC (RMII PHY)

[Nathan Hartman]

On Thu, Oct 26, 2023 at 3:10 PM Gregory Nutt  wrote:

>
> On 10/25/2023 10:41 PM, Zhe Weng 翁喆 wrote:
> > But I do have another idea:
> > Maybe you can try to register two network devices even if you only have
> a single GMAC, just dup all the rx packets to both interfaces, and let all
> tx packets go out.  Since the IP addresses are different on each interface,
> the stack may drop packets on the incorrect interface and accept the
> correct one.  It may have some problems in some situations like broadcast I
> guess, but I think it may have a chance to work.
>
> I think there might be a couple of minor issues with that. First, the
> MAC should not know anything about IP address.  The OSI Seven Layer
> Model prescribes that architecture and we really should make some effort
> to conform to it: https://en.wikipedia.org/wiki/OSI_model
>
> Without getting involved with IP routing, a single MAC driver could not
> handle multiple IP address.  It would have to parse the incoming
> packets, look up the IP address in the packet, match it with a device
> driver, then forward the the correct driver structure with the packet.
>
> Replies to the IP message could be awkward as well.  We could not reply
> using the same device.  The network would always have to notify the
> driver of data availability using that IP address to identify the
> correct device structure to use.
>
> What about non-IP packets, they would probably have to use the same
> device structure?
>
> This would not be a systematic solution; it would apply to only a single
> MCU type.  A better solution would be generalized to the MAC of all
> current and future MCUs.  The solution should be generalized and common.
>
> I think the lack of architectural modularity, generality, and overall
> complexity would make this approach undesirable.



I wonder if this hasn't been solved already in some industry-accepted
manner. For example (not saying this is the solution, just thinking out
loud) there is a redundancy mechanism that makes two network interfaces
look like one, with automatic failover. What the OP wants looks like the
reverse of that: make one network interface look like two. It just feels
like a problem that might have been solved already.

Nathan

Re: nsh_fileapps and usage of sched_lock()

[Nathan Hartman]

On Wed, Oct 25, 2023 at 5:16 AM Ville Juven  wrote:

> Hi all,
>
> I noticed that when spawning a new task/process from a file in
> nsh_fileapps, the scheduler is locked prior to calling posix_spawn(), which
> does the file loading into memory etc.
>
> I noticed one issue with this; when the file size is large (in the order of
> MB) the scheduler is locked for very long periods at a time, in the order
> of hundreds of milliseconds.



This sounds like a bug. The scheduler should not be locked during IO-bound
operations, since there is no way to know how long they will take. Loading
from flash could take hundreds of milliseconds (which is already terrible)
but imagine a different scenario where loading from a network with
connection problems outside of the device could lock the device for many
seconds!

More below...


So my question is, is the scheduler lock strictly necessary in this case ?
> The only reason I could surmise from the comment below is that waitpid is
> not performed on a stale pid (or even a possibly re-taken pid ?):
>
>   /* Lock the scheduler in an attempt to prevent the application from
>* running until waitpid() has been called.
>*/
>
>   sched_lock();
>
> A follow-up question obviously is, what happens if the scheduler lock is
> removed ? Will something bad happen and if so, is there a way to mitigate
> this (other than the sched_lock())?



I have not studied the code but conceptually the file should be loaded (or
other IO operations) and only when ready to perform scheduler operation the
scheduler should be locked for the minimal length of time.

More below...


My reason for removing the scheduler lock is obviously that I lose all
> real-time assurances of the OS when I'm starting a process, e.g. I start
> losing sensor data during the process load time.



This is exactly why the scheduler should not be locked for extended lengths
of time.

Nathan

Re: [VOTE] Apache NuttX 12.3.0 RC0 release

[Nathan Hartman]

Hi Tomek,

On Wed, Oct 11, 2023 at 3:21 PM Tomek CEDRO  wrote:
>
> Hello world,
>
> I have encountered a basic esp32:nsh build error in nuttx-12.3.0-RC0
> related to xtensa g++ 8.4.0 compiler:
>
> xtensa-esp32-elf-g++: error: unrecognized command line option
> '-std=gnu++20'; did you mean '-std=gnu++2a'?

This was changed in d6453cfc3cd4771a5221528cab3056660be4b1e3 (PR # 8244).

See mail thread:
https://lists.apache.org/thread/rkq99os8ql28bv1w8fy5mdqwl3h2vp6m

The workaround is to set Kconfig CXX_STANDARD to gnu++2a instead of gnu++20.

It would be nice if the build system could automatically detect the
compiler version and set this value accordingly and automatically,
without a Kconfig. IIRC there are programs in tools that determine
compiler options based on the compiler and version. (Can't remember
details off the top of my head at the moment.)

More below:

> Therefore -1 from me at this point. This does not happen in 12.2.1. If
> a minimum required version of a compiler is required then this must be
> somehow clearly stated. This would break older setups. Looks like a
> breaking change. I do not even use C++. Can we please make this
> optional? Details below.
>
> BUILD HOST:
> FreeBSD octagon 13.2-RELEASE-p4 FreeBSD 13.2-RELEASE-p4 GENERIC amd64
>
> REMARKS:
> 1. flock is a new system build dependency.

I think documentation needs to be updated? I think not all systems
have flock. Is it a Linux-only thing? (Non-BSD?)

Cheers,
Nathan

Re: Updated the wiki section about validating a staged release;

[Nathan Hartman]

On Mon, Oct 9, 2023 at 3:03 PM Tiago Medicci Serrano <
tiago.medi...@gmail.com> wrote:

> Hi!
>
> I've found some issues with verifying the signatures of the last release
> candidate. After I fixed it locally, I updated the wiki content about it:
>
>
> https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release
>
> Please let me know if you find any issues regarding this. I hope this helps
> everyone trying to test the new release candidate ;)
>
> Best regards,
> --
> Tiago Medicci Serrano
>
> Embedded Software Engineer
> MSc Electronics/Microelectronics
> m: +55 (19) 981403886 <+55+(19)+981403886>
> e: tiago.medi...@gmail.com
> a: Campinas, Brazil
> Follow me:
> 
> 
>

Hello Tiago,

The changes look very good. Thank you for taking care of this!

Cheers
Nathan

Error: Unrecognized gnu++20, did you mean gnu++2a?

[Nathan Hartman]

Hi all,

Commit d6453cfc3cd4771a5221528cab3056660be4b1e3 (PR # 8244) changes
the default CXX_STANDARD for libxx to gnu++20 to make llvm libcxx
15.0.7 happy.

Unfortunately this makes GCC versions < 10.3 fail with something like:

arm-none-eabi-g++: error: unrecognized command line option
'-std=gnu++20'; did you mean '-std=gnu++2a'?

And (as you can see in the PR discussions) on some host OSes
(including mine) it isn't convenient to install a newer GCC.

In commit 4e93f93f303a85e04bdd7e4da22df028c0f76de3, the documentation
is updated to tell us that we need to update GCC to 10.3.

The ---help--- for Kconfig CXX_STANDARD lists possible values:
gnu++98/c++98, gnu++11/c++11, gnu++14/c++14, gnu++17/c++17 and
gnu++20/c++20. Is it possible to add gnu++2a to that list, so that
people with old(er) host OSes (like me) can continue?

Thanks,
Nathan

Re: fat32 sd-card filesystem broken

[Nathan Hartman]

On Wed, Sep 20, 2023 at 1:58 PM Petro Karashchenko <
petro.karashche...@gmail.com> wrote:

> Hi,
>
> I think that FAT32 is not a fail-safe file system by its nature. There may
> be data losses (file table corruption) in case of power loss during file
> write (file table update) or maybe in some other cases when file system
> access is interrupted.



Regarding hardware (because others haven't mentioned it yet): Are you able
to verify signal integrity to the SD card hardware? I don't remember off
the top of my head but are there pull-up resistors and/or capacitors
required on the SD card lines and, if so, are they populated and soldered
correctly? Any other solder connections that might need reflowing?

Nathan

Re: ESP32S3 arbitrary crash when no optimization configured

[Nathan Hartman]

On Mon, Sep 18, 2023 at 12:07 PM Mike Moretti 
wrote:

> This is the kind of thing that really should be documented somewhere.
> In bold, "DO NOT TURN OFF OPTIMIZATION because...". Either that or
> disallow it being changed, or make FULLOPT the default for every platform?



Sometimes you really do need to disable optimization or you cannot
single-step through code in a coherent manner.

Yes, that could affect stack sizes and other things. Debugging can be a
tricky business.

Cheers
Nathan

Re: write method for audio driver?

[Nathan Hartman]

On Sun, Aug 27, 2023 at 6:24 PM Tim Hardisty  wrote:

> SAMA5D2 specific, I should add.
>
>
> > On 27 Aug 2023, at 23:23, Tim Hardisty  wrote:
> >
> > The classD driver DOES register itself as /dev/audio/pcm0, and works
> correctly as such with nx_player.
> >
> > The conversions are wav (or mp3 etc) to pcm.
> >
> > Don’t if we’re talking cross purposes or the classd driver works in a
> way it shouldn’t!!!



I don't know whether you've had a chance to read [1] yet, but if not, it
might help visualize the two-part structure of device drivers in NuttX. (If
you've already read it, then never mind, and apologies for the noise. :-)

[1]
https://nuttx.apache.org/docs/latest/components/drivers/index.html

Cheers,
Nathan

[DISCUSS] Out-of-tree builds should be standard?

[Nathan Hartman]

PR # 10328 is bringing support for STM32 MCUs that have two different kinds
of cores on chip: Cortex M7 and Cortex M4. In other words, AMP-style
(Asymmetric Multi Processing) chip. This requires building NuttX twice,
once for each core, with two different configs.

In the GitHub comments, it was mentioned that we should not make cmake
mandatory for certain boards, and then mentioned that with make the problem
is that you have to make distclean between the two builds. Copying the
comments here:

slorquet writes:

> > It would be good to avoid cmake-specific features.
>
> >
>
> > Is make a supported build system or was it deprecated?
>
> >
>
> > If it's supported no feature should work only with cmake. Thanks.

xiaoxiang781216 writes:

> The change should work with make too. But make doesn't support out of
tree build, it's very annoying to develop AMP system like this patch
because you have to `make distclean` and `make` every time.

This makes me wonder whether we should consider making out-of-tree builds
the blessed way to build, with both make and cmake.

I realize that this might disrupt many people's builds -- including myself.
I have been building in-tree from the start, so this will require me to
change my workflows.

However, after the dust settles, this could have several advantages:

1. Not polluting the source tree with build artifacts and temporary files.

2. Simplifying the.gitignore rules throughout.

3. Allowing AMP builds and builds for multiple different boards without
make distclean. To switch between boards, just change to a different build
dir.

I am starting this thread here because this kind of proposal really needs a
discussion on the mailing list.

Thoughts?

Cheers
Nathan

Re: Small annoyances when building NuttX on FreeBSD

[Nathan Hartman]

On Sat, Aug 19, 2023 at 2:22 AM Milan Obuch  wrote:

>
> Note: using 12.0.0 sources, this problem does not occur. It looks like
> there was some change in build process after 12.0.0 was released.
>

Are you able to do git bisect between 12.0.0 and latest master to find
which commit introduces the error?

Nathan

Re: octospi implementation

[Nathan Hartman]

On Thu, Aug 17, 2023 at 4:22 PM Luca Giambonini  wrote:

> Hi, I'm new to NuttX and I'm intrigued by its structure and philosophy. I'm
> currently testing it on the STM32L4R9AI-DISCO board, where I've been able
> to get the console and some LEDs working. I'd now like to use the Flash,
> which is a Macronix MX25LM51245GX connected to the microcontroller via an
> octo SPI interface. Looking at nuttx I saw that:
> - octospi is not implemented, only quadspi
> - this Macronix memory is not implemented in MTD
>
> Is it correct that octospi is not available? Are there any alternatives
> that I can use?
>
> If I would like to create a merge request to implement octospi, what is the
> correct procedure? For example, would I need to:
> 1) create a octospi_flash.c under drivers/spi
> 2) extend the mx25lx.c functions
>
> Thank you
> Luca




Hi Luca,

Lup has written a very good article about how to prepare pull requests for
the NuttX repository, which will be helpful if you would like to implement
octo SPI support.

Article:
https://lupyuen.github.io/articles/pr

It would probably be helpful to study the quad SPI and see how that is
implemented, and then either extend the implementation or use it as a
template to implement octo SPI. They probably aren't that different, right?
Just more bits moving in parallel.

A discussion about the structure of drivers and architectural code will be
helpful as well. NuttX uses a split approach where the "upper half" driver,
the one applications interface with, appears like a POSIX device that can
be opened/closed and accessed with read, write, and ioctl calls, while the
"lower half" driver is implemented for each microcontroller and handles the
low-level details of register-stuffing and whatnot. The upper half driver
is more or less easy to implement by following along with a similar driver.
The lower half driver is more involved because you have to look at the
microcontroller datasheet and setup and control the necessary peripherals
by programming their various registers.

There's some documentation about drivers and the upper/lower half here:
https://nuttx.apache.org/docs/latest/components/drivers/index.html

Hope this helps,
Nathan

Re: Fixing tcpblaster - anybody using it?

[Nathan Hartman]

On Sun, Aug 13, 2023 at 9:09 AM Milan Obuch  wrote:

> On Sun, 13 Aug 2023 08:32:53 -0400
> Nathan Hartman  wrote:
>
> > On Sat, Aug 12, 2023 at 3:15 PM Milan Obuch  wrote:
> >
> > > Hi,
> > >
> > > as I was building NuttX with bl602evb:wifi configuration, it failed
> > > with AF_INET being undefined. I found it is easy to fix with simply
> > > adding one include:
> > >
> > > # diff -u tcpblaster_cmdline.c.orig tcpblaster_cmdline.c
> > > --- tcpblaster_cmdline.c.orig   2022-12-11 22:21:46.630131000 +0100
> > > +++ tcpblaster_cmdline.c2023-08-12 17:57:30.831047000 +0200
> > > @@ -24,6 +24,8 @@
> > >
> > >  #include "config.h"
> > >
> > > +#include 
> > > +
> > >  #include 
> > >  #include 
> > >  #include 
> > >
> > > Then NuttX builds and run (somewhat) well. While I have no
> > > knowledge on tcpblaster, I decided to look where it is being used:
>
> [ snip ]
>
> > > This means it is defined for following configurations:
> > >
> > > spresense:rndis
> > > spresense:rndis_smp
> > > spresense:wifi
> > > spresense:wifi_smp
> > > spresense:rndis_composite
> > > sabre-6quad:netnsh
> > > sabre-6quad:netnsh_smp
> > > sabre-6quad:netnsh_wb
> > > giant-board:netnsh
> > > giant-board:sdmmc-net-nsh
> > > giant-board:sdmmcnsh
> > > sama5d2-xult:netnsh
> > > sama5d2-xult:sdmmcnsh
> > > sama5d3-xplained:ethernet-over-usb-2-high-speed
> > > jupiter-nano:netnsh
> > > jupiter-nano:sdmmc-nsh-net-resolvconf
> > > jupiter-nano:sdmmcnsh
> > > viewtool-stm32f107:tcpblaster
> > > bl602evb:wifi
> > > icicle:network
> > > sim:tcpblaster
> > > sim:tcploop
> > > sim:rtptools
> > >
> > > Is anybody using any configuration in this set? I did not look more
> > > into history to find when it brake, but anyway, the fix looks
> > > trivial to me.
> > >
> > > Regards,
> > > Milan
> >
> > I recall things getting moved around in the networking headers some
> > time back (maybe a year?) so it's possible this source file wasn't
> > updated at that time. If it solves the problem, please open a pull
> > request!
> >
> > Cheers,
> > Nathan
>
> For me the problem is fixed. How should the patch above be translated
> into pull request? I gained some skill with git, but still only in
> direction 'to me', not the other one :(
>
> Regards,
> Milan
>

Lup has written a very good article about how to prepare pull requests for
NuttX:
https://lupyuen.github.io/articles/pr

Cheers
Nathan

Re: Building NuttX for PineCone (on FreeBSD)

[Nathan Hartman]

On Sat, Aug 12, 2023 at 1:43 PM Milan Obuch  wrote:

> Hi,
>
> after some tests, with some hints and discussion with Lup, I am able to
> build NuttX for PineCone (BL602 based evaluation board) on FreeBSD. I
> am able to build almost all configurations present in recent sources (I
> used sources from git, snapshot old maybe a week or two), with
> configuration as follows:
>
> tools/configure.sh bl602evb:dma  BUILDS
> tools/configure.sh bl602evb:elf  FAILS
> tools/configure.sh bl602evb:fpu  BUILDS
> tools/configure.sh bl602evb:gpio BUILDS
> tools/configure.sh bl602evb:i2c  BUILDS
> tools/configure.sh bl602evb:nsh  BUILDS
> tools/configure.sh bl602evb:spi  BUILDS
> tools/configure.sh bl602evb:spiflash FAILS
> tools/configure.sh bl602evb:timerBUILDS
> tools/configure.sh bl602evb:wifi FAILS
>
> I have no idea what elf and spiflash configurations are for, maybe
> nothing interesting for me, but I'd like to get wifi configuration to
> build. It fails with following:
>
> CC:  tcpblaster_cmdline.c
> tcpblaster_cmdline.c:121:23: error: use of undeclared identifier 'AF_INET'
>   ret = inet_pton(AF_INET, argv[1], _tcpblasterserver_ipv4);
>   ^
> 1 error generated.
> gmake[3]: *** [Makefile:92: tcpblaster_cmdline.hobj] Error 1
> gmake[2]: *** [Makefile:55:
> /wrk/usr/ports/devel/apache-nuttx/work/apps/examples/tcpblaster_context]
> Error 2
> gmake[1]: *** [Makefile:168: context] Error 2
> gmake: *** [tools/Unix.mk:443:
> /wrk/usr/ports/devel/apache-nuttx/work/apps/.context] Error 2
>
> I was able to fix this one, more on the issue in next mail.
>
> However, generated binaries (most of them) have a problem - 'help'
> command does not work, it does not output anything, just new shell
> prompt is displayed.



Do any other commands work?

Cheers
Nathan

Re: Fixing tcpblaster - anybody using it?

[Nathan Hartman]

On Sat, Aug 12, 2023 at 3:15 PM Milan Obuch  wrote:

> Hi,
>
> as I was building NuttX with bl602evb:wifi configuration, it failed
> with AF_INET being undefined. I found it is easy to fix with simply
> adding one include:
>
> # diff -u tcpblaster_cmdline.c.orig tcpblaster_cmdline.c
> --- tcpblaster_cmdline.c.orig   2022-12-11 22:21:46.630131000 +0100
> +++ tcpblaster_cmdline.c2023-08-12 17:57:30.831047000 +0200
> @@ -24,6 +24,8 @@
>
>  #include "config.h"
>
> +#include 
> +
>  #include 
>  #include 
>  #include 
>
> Then NuttX builds and run (somewhat) well. While I have no knowledge on
> tcpblaster, I decided to look where it is being used:
>
> # grep -Rl CONFIG_EXAMPLES_TCPBLASTER=y *
> boards/arm/cxd56xx/spresense/configs/rndis/defconfig
> boards/arm/cxd56xx/spresense/configs/rndis_smp/defconfig
> boards/arm/cxd56xx/spresense/configs/wifi/defconfig
> boards/arm/cxd56xx/spresense/configs/wifi_smp/defconfig
> boards/arm/cxd56xx/spresense/configs/rndis_composite/defconfig
> boards/arm/imx6/sabre-6quad/configs/netnsh/defconfig
> boards/arm/imx6/sabre-6quad/configs/netnsh_smp/defconfig
> boards/arm/imx6/sabre-6quad/configs/netnsh_wb/defconfig
> boards/arm/sama5/giant-board/configs/netnsh/defconfig
> boards/arm/sama5/giant-board/configs/sdmmc-net-nsh/defconfig
> boards/arm/sama5/giant-board/configs/sdmmcnsh/defconfig
> boards/arm/sama5/sama5d2-xult/configs/netnsh/defconfig
> boards/arm/sama5/sama5d2-xult/configs/sdmmcnsh/defconfig
>
> boards/arm/sama5/sama5d3-xplained/configs/ethernet-over-usb-2-high-speed/defconfig
> boards/arm/sama5/jupiter-nano/configs/netnsh/defconfig
> boards/arm/sama5/jupiter-nano/configs/sdmmc-nsh-net-resolvconf/defconfig
> boards/arm/sama5/jupiter-nano/configs/sdmmcnsh/defconfig
> boards/arm/stm32/viewtool-stm32f107/configs/tcpblaster/defconfig
> boards/risc-v/bl602/bl602evb/configs/wifi/defconfig
> boards/risc-v/mpfs/icicle/configs/network/defconfig
> boards/sim/sim/sim/configs/tcpblaster/defconfig
> boards/sim/sim/sim/configs/tcploop/defconfig
> boards/sim/sim/sim/configs/rtptools/defconfig
>
> This means it is defined for following configurations:
>
> spresense:rndis
> spresense:rndis_smp
> spresense:wifi
> spresense:wifi_smp
> spresense:rndis_composite
> sabre-6quad:netnsh
> sabre-6quad:netnsh_smp
> sabre-6quad:netnsh_wb
> giant-board:netnsh
> giant-board:sdmmc-net-nsh
> giant-board:sdmmcnsh
> sama5d2-xult:netnsh
> sama5d2-xult:sdmmcnsh
> sama5d3-xplained:ethernet-over-usb-2-high-speed
> jupiter-nano:netnsh
> jupiter-nano:sdmmc-nsh-net-resolvconf
> jupiter-nano:sdmmcnsh
> viewtool-stm32f107:tcpblaster
> bl602evb:wifi
> icicle:network
> sim:tcpblaster
> sim:tcploop
> sim:rtptools
>
> Is anybody using any configuration in this set? I did not look more
> into history to find when it brake, but anyway, the fix looks trivial
> to me.
>
> Regards,
> Milan



I recall things getting moved around in the networking headers some time
back (maybe a year?) so it's possible this source file wasn't updated at
that time. If it solves the problem, please open a pull request!

Cheers,
Nathan

Re: CAN TX fail handling

[Nathan Hartman]

On Thu, Aug 10, 2023 at 4:38 AM Tim Hardisty 
wrote:

> I like your idea of IOCTLs - I will be revisiting this issue in the next
> few weeks and will look to see what's involved in implementing this as it
> "feels" right.
>

snip

In trying to cover potential board faults, I have found that if
> there's something that prevents a CAN message reaching an
> endpoint/destination, the CAN transmitter (of course, as I
> understand it) is continuously retrying the message send, meaning
> the test app hangs when you try and close the file once the test has
> been deemed to fail. That is "by design" in the higher (i.e.
> non-arch specific) can code as it waits for the TX FIFO/queue to empty
> until the close is allowed.
>
> What is the correct POSIX way to handle this error condition?
>
>
Sounds like in CAN we need the equivalent of tcflush() / tcdrain() as found
in termios. (Try looking up the man page for these functions on your system
or at online manpages.) In NuttX, at least for serial ports (i.e., UARTs),
these functions call IOCTLs which (if I remember correctly) are partly
implemented in the upper half driver (to clear the software buffer) and
partly passed to the lower half driver (to flush the hardware FIFO, if
applicable in the arch in question).

I am not sure whether actual *termios* and its tc family of functions like
tcflush() / tcdrain() are a good fit for CAN. Maybe they are and you can
just adopt the same IOCTLs they use. But even if not, you can follow along
how these are implemented in NuttX and do something very similar.

Hope this helps,
Nathan

Re: CI testing on FreeBSD [originally: NuttX on FreeBSD survey]

[Nathan Hartman]

On Sun, Aug 6, 2023 at 6:02 PM Brennan Ashton 
wrote:

> On Sun, Aug 6, 2023, 2:41 PM Milan Obuch  wrote:
>
> > On Mon, 31 Jul 2023 10:51:33 -0300
> > "Alan C. Assis"  wrote:
> >
> > > Hi Milan and Tomek,
> > >
> > > It should be nice to have our CI testing on FreeBSD as well.
> > >
> > > Milan, after you get the port done, please let us know if you can help
> > > us to get it integrated in the github CI.
> > >
> > > BR,
> > >
> > > Alan
> > >
> >
> > [ snip ]
> >
> > Hi,
> >
> > I have no idea how could such testing be integrated in the github CI.
> > Also, NuttX has so much various configurations, I think there must be
> > more test builds in order to get some coverage...
> >
> > Is there some document how CI works and how could new tests be added?
> > Could you eventually write something about the subject? At the moment,
> > I can't even tell if I am able to help with the task.
> >
> > Regards,
> > Milan
> >
>
> freeBSD is not a supported build host in GitHub CI. The only way to get
> around that would be by triggering a VM build and I would not personally be
> supportive of that, at least triggered by default as it will be exceedingly
> slow.
>
> I would expect macOS provides a fair bit of coverage already for BSD style
> build hosts.
>
> --Brennan
>
> >
>

Besides GitHub's buildbots, there is also Apache.org's build farm:

https://ci-builds.apache.org/

Maybe some additional targets could be built there, perhaps nightlies?

Cheers
Nathan

Re: No error return in fprintf().

[Nathan Hartman]

Thanks Fotis,

I haven't had a chance to look at the code for stream_putc (i'm away from
my computer and on my phone) but based on your description, it sounds like
stream_putc should check and propagate errors. Even if the write to disk
won't happen until later, any errors that are caught shouldn't be discarded.

Nathan

On Thu, Jul 20, 2023 at 3:56 PM Fotis Panagiotopoulos 
wrote:

> Hello Nathan,
>
> Indeed, I should have mentioned that I have selected
> CONFIG_STDIO_DISABLE_BUFFERING.
> So, at least in my case, no buffering is taking place.
>
> But in the case of buffered output, I think that I agree that fprintf() may
> return success for buffered (but not written) data.
>
> On Thu, Jul 20, 2023 at 10:16 PM Nathan Hartman 
> wrote:
>
> > On Thu, Jul 20, 2023 at 3:02 PM Fotis Panagiotopoulos <
> f.j.pa...@gmail.com
> > >
> > wrote:
> >
> > > Hello,
> > >
> > > I am using fprintf() to output some data to a file. This file is
> located
> > on
> > > an SD card.
> > >
> > > As I realised, fprintf() never returns an error.
> > >
> > > I tried to completely remove the SD card from the system, and fprintf
> > > happily succeeds,
> > > returning the number of bytes that it would have written, if the write
> > was
> > > successful.
> > >
> > > By checking the call trace, I see that the problem lies within
> > > vsprintf_internal().
> > > It calls stream_putc() but no error checking is done there.
> > >
> > > Shouldn't this be considered a bug?
> > >
> >
> > I haven't studied the code, so I may be off here, but...
> >
> > If fprintf() return code indicates success to my application, my
> > expectation is that the data has been written. However it might be a
> little
> > more complicated than that: what if fprintf() successfully *buffered* the
> > data and the fs layer is waiting for an opportunity to write it? In this
> > scenario fprintf would return to the application before writing
> completes.
> > Then, it would be sensible for fprintf to indicate success (of the
> > buffering) even though data wasn't actually stored on flash yet. Maybe a
> > separate call to sync the fs is needed?
> >
> > Having said all that, stream_putc should probably do error checking and
> > propagate errors.
> >
> > Cheers
> > Nathan
> >
>

Re: Unable to get nsh working on Adafruit Feather rp2040

[Nathan Hartman]

On Thu, Jul 20, 2023 at 3:28 PM Richard Fox  wrote:

> Hi,
>
> I'm new to NuttX and to the pico-sdk, (and RTOSs in general). I have an
> Adafruit Feather RP2040 that I was using to experiment with NuttX and I
> haven't been able to get either the nsh or usbnsh apps to work, (and I
> haven't really tried anything else).
>
> I have the Feather RP2040 connected to my Mac using an Adafruit #954 USB
> to TTL serial cable (pre 2014). I have the device wired so that the
> serial cable is connected to GND, Green TX to rp2040:GPIO1, white RX to
> rp2040:GPIO0.
>
> Using this configuration, I have successfully built installed, and
> tested the pico-sdk "pico-examples/build/uart/hello_uart" example that
> prints a string via the serial cable to a terminal emulator on the Mac.
> This was operating at 115200 baud.
>
> I've also successfully built and installed the bi-directional example
> from the Arduino distribution: Arduino:Built-in Examples:4.
> Communications:SerialPassThrough and am able to send to and receive from
> the Feather RP2040 through the serial cable and through the
> cu.usbmodem101 device that gets created when the controller is attached
> to my Mac with a USB cable. Communications were at 9600 baud.
>
> I have the following environment variables set in my build terminal.
> export PICO_SDK_PATH=/opt/pico/pico-sdk
> export HOST_PLATFORM=mac
>
> I can start the build process and it seems to succeed:
>
> make distclean
> ./tools/configure.sh -m adafruit-feather-rp2040:nsh
> make -j4
> ...
> LN: platform/board to
>
> /Users/rfox/Documents/Computers/rtos/apache-nuttx/nuttxspace/apps/platform/dummy
> Register: hello
> Register: nsh
> Register: getprime
> Register: sh
> Register: ostest
> CPP:
> /Users/rfox/Documents/Computers/rtos/apache-nuttx/nuttxspace/nuttx/boards/arm/rp2040/adafruit-feather-rp2040/scripts/adafruit-feather-rp2040-flash.ld->
>
> /Users/rfox/Documents/Computers/rtos/apacheLD: nuttx
>
>
> Generating: nuttx.uf2
> tools/rp2040/elf2uf2 nuttx nuttx.uf2;
> Done.
>
> Then I copy the uf2 binary over to the mounted controller volume using
> the handy BOOTSEL feature.
> After the volume is disconnected and my Mac has harped at me for doing
> it wrong, I open a screen to the device:



I'm not familiar with this board or BOOTSEL so this might be a dumb
question, but is it supposed to be the nuttx.uf2 file? (Note: It is
possible to produce several different types of binary images. On my boards,
I use "nuttx" -- no extension.)

More ideas below...


screen /dev/cu.usbserial-110 115200
>
> Hit return a few times and get no response.
>

By chance do you have sn oscilloscope or logic analyzer to look at the
serial signals and see if anything is being transmitted, and at what baud
rate?

Have you tried running "make menuconfig" (after configure.sh and before
make) to verify that the serial driver is in fact enabled and that the
console is configured to use it? (Maybe the output is going elsewhere.)

Does the board have software-controlled LEDs and if so do they light up,
blink, or stay off? l

Do you have ability to try single step debugging, at least for the first
part of bootup, to see if anything is running?

Maybe others will have other ideas.

Especially, input from someone familiar with this board will be helpful!!

Hope this helps,
Nathan

Re: No error return in fprintf().

[Nathan Hartman]

On Thu, Jul 20, 2023 at 3:02 PM Fotis Panagiotopoulos 
wrote:

> Hello,
>
> I am using fprintf() to output some data to a file. This file is located on
> an SD card.
>
> As I realised, fprintf() never returns an error.
>
> I tried to completely remove the SD card from the system, and fprintf
> happily succeeds,
> returning the number of bytes that it would have written, if the write was
> successful.
>
> By checking the call trace, I see that the problem lies within
> vsprintf_internal().
> It calls stream_putc() but no error checking is done there.
>
> Shouldn't this be considered a bug?
>

I haven't studied the code, so I may be off here, but...

If fprintf() return code indicates success to my application, my
expectation is that the data has been written. However it might be a little
more complicated than that: what if fprintf() successfully *buffered* the
data and the fs layer is waiting for an opportunity to write it? In this
scenario fprintf would return to the application before writing completes.
Then, it would be sensible for fprintf to indicate success (of the
buffering) even though data wasn't actually stored on flash yet. Maybe a
separate call to sync the fs is needed?

Having said all that, stream_putc should probably do error checking and
propagate errors.

Cheers
Nathan

Re: Raspberry pi 4 Support

[Nathan Hartman]

On Wed, Jul 19, 2023 at 1:05 PM Joseph Gonzalez  wrote:
>
> Hi, I wanted to try out the NuttX RTOS, but didn't saw support for the RPi 4, 
> is this board supported if not is there a way to add support to it?
>
>
> Best regards, Joseph Gonzalez.


Hello Joseph,

Not yet...

NuttX supports the ARM64 processor (see, for example, the port to
PinePhone), but does not support the RPi 4 *yet* because no one has
written the necessary board support for it yet.

This is a platform that I would very much like to see NuttX running
on, specifically the RPi CM4 (Raspberry Pi Compute Model 4), as that
seems like a perfect and very powerful processor for real-time
embedded applications. Currently, use of a RPi CM4 requires a
full-blown OS like FreeBSD or Linux, with all the goodies they include
but also with all the overhead, and perhaps more importantly, without
real-time. (I tried and wasn't successful getting a Linux kernel built
with the real time patch set for this processor.)

Cheers,
Nathan

Re: [Article] NuttX on Star64 JH7110: RISC-V Privilege Levels and UART Registers

[Nathan Hartman]

On Tue, Jul 18, 2023 at 10:34 PM Lee, Lup Yuen  wrote:

> Thanks Nathan! I'm still getting used to NuttX Kernel Mode and RISC-V
> Machine / Supervisor Modes, so I thought I might stick with QEMU Kernel
> Mode and make it work on Star64.
>
> But you're right, when I'm more familiar with Star64, I ought to explore
> more of CONFIG_ARCH_USE_S_MODE and RISC-V Machine Mode :-)
>
> Lup



Great! Just food for (future) thought... Looking forward to following along
on more RiscV discoveries:-)

Cheers
Nathan

Re: [Article] NuttX on Star64 JH7110: RISC-V Privilege Levels and UART Registers

[Nathan Hartman]

On Tue, Jul 18, 2023 at 7:33 PM Lee, Lup Yuen  wrote:

> We’re in the super-early stage of porting NuttX to the Pine64 Star64 64-bit
> RISC-V SBC. (Based on StarFive JH7110 SoC)
>
> In this article we’ll talk about the interesting things that we learnt
> about RISC-V and Star64 JH7110…
>
> (1) What are RISC-V Privilege Levels
>  (And why they make NuttX a little more complicated)
>
> (2) What is NuttX Kernel Mode
>  (And how it differs from Flat Mode)
>
> (3) All about JH7110’s UART Registers
>  (And how they are different from other 16550 UARTs)
>
> (4) Why (naively) porting NuttX from QEMU to Star64 might become really
> challenging!
>  (Thankfully we have the LiteX Arty-A7 and PolarFire Icicle ports)
>
> https://lupyuen.codeberg.page/articles/privilege.html
>
> Lup
>

Beautiful article!

Question: In section 6, "NuttX flat mode becomes kernel mode," isn't it
possible to set CONFIG_ARCH_USE_S_MODE for the FLAT build as well? Since
the board's built-in firmware switches from Machine Mode to Supervisor Mode
before calling U-Boot -> NuttX, I think that all configurations running on
this board should select CONFIG_ARCH_USE_S_MODE by default. This can be set
in Kconfig by default whenever this board is selected, so there is no need
to remember and add it in multiple places/configs; however if someone
figures out an alternative firmware that lets us boot NuttX on this board
in Machine Mode, it will be easy to override. Just a thought...

Thanks for a great article as always!

Cheers,
Nathan

50,000th commit!

[Nathan Hartman]

Congrats to the NuttX community for reaching our 50,000th commit in
the main repo!

Cheers,
Nathan

Re: adding a new board - files?

[Nathan Hartman]

On Tue, Jul 18, 2023 at 7:12 AM Lee, Lup Yuen  wrote:

> Hi Krasimir: I wrote an article about submitting a NuttX Pull Request on
> GitHub, I hope this helps :-)
>
> https://lupyuen.codeberg.page/articles/pr.html
>


Hi Lup,

That is a very helpful and detailed article -- thanks for writing it!

Cheers
Nathan

Re: [VOTE] Apache NuttX 12.2.1 RC0 release

[Nathan Hartman]

Hi all,

Pleased to submit my vote:

Summary:
+1 to release (binding)

Per Alan's request for size information [1]:

* NuttX-12.2.1-RC0, b-g474e-dpow1:nsh configuration:

$ arm-none-eabi-size nuttx
   textdata bss dec hex filename
 109963 8202908  113691   1bc1b nuttx

This config has grown somewhat since NuttX-11.0.0-RC0, same config:

$ arm-none-eabi-size nuttx
   textdata bss dec hex filename
 107623 6722012  110307   1aee3 nuttx

Text is increased by 2340. Data increases slightly by 148, bss
increases by 896.

Also built the b-g474e-dpow1:ostest configuration:

Compared to b-g474e-dpow1:nsh, it adds the following configs:

+CONFIG_BUILTIN=y
+CONFIG_NSH_BUILTIN_APPS=y
+CONFIG_TESTING_OSTEST=y

During the NuttX-11.x.x release cycle, ostest was failing when built
with priority inheritance, so currently the following configs are not
present; eventually I intend to re-test with these and possibly open a
PR to enable them:

-CONFIG_PRIORITY_INHERITANCE=y
-CONFIG_PTHREAD_MUTEX_DEFAULT_PRIO_INHERIT=y

Here is the size information for that build:

* NuttX-12.2.1-RC0, b-g474e-dpow1:ostest configuration:

$ arm-none-eabi-size nuttx
   text   databssdechex filename
 184991852   5272 191115  2ea8b nuttx

Development system: Debian "Bullseye" 5.10.179-1 x86_64 GNU/Linux

Verified:
* Signatures
* SHA-512 sums
* LICENSE, NOTICE, and README.md present in both tarballs
* Build, FLASH program, and boot b-g474e-dpow1:nsh to the NSH prompt
  successfully.
* Build, FLASH, boot b-g474e-dpow1:ostest and ran 'ostest'
  successfully.

Dependencies:
* GCC as installed via 'sudo apt install gcc-arm-none-eabi':
  arm-none-eabi-gcc (15:8-2019-q3-1+b1) 8.3.1 20190703 (release)
  [gcc-8-branch revision 273027]
* kconfig-conf as installed via 'sudo apt install kconfig-frontends':
  kconfig-frontends/oldstable,now 4.11.0.1+dfsg-5 amd64 [installed]

Other dependencies from Debian packages:
* binutils-dev 2.35.2
* bison 3.7.5
* flex 2.6.4
* gperf 3.1
* libelf-dev 0.183-1.1
* libgmp-dev 2:6.2.1+dfsg-1+deb11u1
* libisl-dev 0.23-1
* libmpc-dev 1.2.0-1
* libmpfr-dev 4.1.0-3
* libncurses5-dev 6.2+20201114-2+deb11u1
* libusb-1.0-0-dev 2:1.0.24-3
* libusb-dev 2:0.1.12-32
* openocd 0.11.0~rc2-1
* texinfo 6.7.0.dfsg.2-6

A very big **THANK YOU** to our RM and to everyone in the Apache NuttX
community for making this release (candidate) possible!

References:

[1] Alan Carvalho de Assis's message to the dev@nuttx.a.o thread "Re:
[VOTE] Apache NuttX 10.0.0 (incubating) RC0 release" on 26 Nov 2020,
archived:
https://lists.apache.org/thread/nxvwxol948psr2z7fc6cwtdv9ofoz9yj

Cheers,
Nathan

On Fri, Jul 14, 2023 at 6:39 PM Tomek CEDRO  wrote:
>
> On Mon, Jul 10, 2023 at 4:47 PM Alin Jerpelea wrote:
> > Apache NuttX 12.2.1 RC0 has been staged under [1] and it's time to vote on
> > accepting it for release. Voting will be open for 72hr.
> > (..)
> > [1] https://dist.apache.org/repos/dist/dev/nuttx/12.2.1-RC0/
>
> +1 :-)
>
> BUILD HOST:
> FreeBSD octagon 13.2-RELEASE-p1 FreeBSD 13.2-RELEASE-p1 GENERIC amd64
>
> TARGETS:
> 1. ESP32.
> 2. ESP32-C3.
> 2. ESP32-S2.
> 3. ESP32-S3.
>
> === ESP32 ===
>
> % /usr/bin/time -h ./tools/configure.sh -B esp32-devkitc:coremark
> 2,94s real  1,51s user  1,47s sys
>
> % /usr/bin/time -h gmake -j8 V=1
> 16,69s real 52,18s user 32,14s sys
>
> % /usr/bin/time -h gmake flash
> 9,70s real  1,69s user  1,01s sys
>
> % cu -l /dev/cuaU0 -s 115200
> rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
> configsip: 0, SPIWP:0xee
> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
> mode:DIO, clock div:2
> load:0x3fff0030,len:7076
> load:0x40078000,len:15660
> load:0x40080400,len:4
> load:0x40080404,len:3756
> entry 0x40080640
> I (29) boot: ESP-IDF v5.2-dev-544-g54576b7528 2nd stage bootloader
> I (29) boot: compile time May 16 2023 16:18:19
> I (30) boot: Multicore bootloader
> I (35) boot: chip revision: v1.0
> I (38) boot.esp32: SPI Speed  : 40MHz
> I (43) boot.esp32: SPI Mode   : DIO
> I (47) boot.esp32: SPI Flash Size : 4MB
> I (52) boot: Enabling RNG early entropy source...
> I (57) boot: Partition Table:
> I (61) boot: ## LabelUsage  Type ST Offset   Length
> I (68) boot:  0 factory  factory app  00 00 0001 0010
> I (76) boot: End of partition table
> I (80) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=014b4h
> (  5300) map
> I (90) esp_image: segment 1: paddr=000114dc vaddr=3ffb25b0 size=001b0h
> (   432) load
> I (97) esp_image: segment 2: paddr=00011694 vaddr=4008 size=020d4h
> (  8404) load
> I (109) esp_image: segment 3: paddr=00013770 vaddr= size=0c8a8h ( 
> 51368)
> I (132) esp_image: segment 4: paddr=00020020 vaddr=400d0020
> size=0de98h ( 56984) map
> I (154) boot: Loaded app from partition at offset 0x1
> I (154) boot: Disabling RNG early entropy source...
> 

Re: [Article] Boot NuttX from Network with U-Boot and TFTP

[Nathan Hartman]

On Thu, Jul 13, 2023 at 12:24 PM Gregory Nutt  wrote:
>
>
> > Maybe you could that a look in the minnsh PoC, it was running on MCU
> > with less than 16KB Flash and 8KB RAM. As you can see in the image it
> > is using less than 2KB RAM:
>
> To get to the minimal size, that configuration also depended on the
> ability to disabled file system support (and, in the longer run, on the
> development of a HAL).  There is no HAL and the option to disable the
> file system has been removed.


This is one of the reasons I think we should not be too eager to
remove Kconfig options. I know that we have many Kconfig options and
it can be frustrating to maintain sometimes, but there are times when
we really need a minimalistic build, such as to implement a bootloader
app. Also, other ideas could be implemented that will benefit from
minimalistic builds.

Cheers,
Nathan

Re: [Article] Boot NuttX from Network with U-Boot and TFTP

[Nathan Hartman]

Hi Lup,

Excellent article, as always!

On Thu, Jul 13, 2023 at 10:38 AM Alan C. Assis  wrote:
> In NuttX case it is easier because we can do it without the bootloader!

There was a recent discussion about using a minimal build of NuttX
itself as a bootloader, which would load a more full-featured build of
NuttX.

One of the advantages of doing this would be reduced driver
development, since the same implementation of network, USB, and/or
serial drivers, and other board support, could be shared between the
"bootloader" build of NuttX and the "real" build of NuttX. It is a
very cool idea and one that I think is very much worth exploring.

Meanwhile, having information about how to do it with u-boot comes in
very handy, too.

Oh, that discussion was called "Bootloaders other than u-boot?" and
started on July 1st, 2023... Archived here:

https://lists.apache.org/thread/wx0yqx7t1vw9os9psv1y8dcpcto5vpc7

or here:

https://www.mail-archive.com/dev@nuttx.apache.org/msg10109.html

Some of the key messages in that thread:

https://lists.apache.org/thread/fh1k3ln45hqv1p9v8539hcxmkjwm3oyg

https://lists.apache.org/thread/jfyxv7hksv7ftkrt2n0xg9zmrs4z386j

Cheers,
Nathan

Re: Mailing List

[Nathan Hartman]

@Brennan, thanks for catching that!

Nathan

On Thu, Jun 8, 2023 at 11:44 PM Brennan Ashton 
wrote:

> Email aggressively remove the sender from the reply list when sent to a
> list so they likely did not get this email. I was doing the same thing a
> couple weeks ago Added them to this one.
>
> Sharwin Patil hopefully you get this response from Nathan.
>
> --Brennan
>
> On Thu, Jun 8, 2023, 6:28 PM Nathan Hartman 
> wrote:
>
> > On Thu, Jun 8, 2023 at 7:01 PM Sharwin Patil 
> > wrote:
> >
> > > Hello,
> > >
> > > I am a developer using NuttX and would like to be added to the mailing
> > list
> > > for NuttX development.
> > >
> > > Thanks!
> > > Sharwin Patil
> > > GreenSight
> > >
> >
> > Great to have you! To subscribe, send an email to:
> > dev-subscr...@nuttx.apache.org.
> >
> > Youll get a confirmation email; once you confirm by replying to that,
> > you'll be on the mailing list.
> >
> > Similarly, if you ever wish to unsubscribe, just send an email to:
> > dev-unsubscr...@nuttx.apache.org.
> >
> > We should probably update the NuttX website to document this process more
> > clearly. :-)
> >
> > Hope this helps,
> > Nathan
> >
>

Re: Mailing List

[Nathan Hartman]

On Thu, Jun 8, 2023 at 7:01 PM Sharwin Patil 
wrote:

> Hello,
>
> I am a developer using NuttX and would like to be added to the mailing list
> for NuttX development.
>
> Thanks!
> Sharwin Patil
> GreenSight
>

Great to have you! To subscribe, send an email to:
dev-subscr...@nuttx.apache.org.

Youll get a confirmation email; once you confirm by replying to that,
you'll be on the mailing list.

Similarly, if you ever wish to unsubscribe, just send an email to:
dev-unsubscr...@nuttx.apache.org.

We should probably update the NuttX website to document this process more
clearly. :-)

Hope this helps,
Nathan

Re: qencoder / long / float / double / maximum values

[Nathan Hartman]

On Thu, Jun 8, 2023 at 8:12 PM Tomek CEDRO  wrote:

> On Fri, Jun 9, 2023 at 1:53 AM Tomek CEDRO wrote:
> > I am working on ESP32 (no FPU) and using Quadrature Encoder for motor
> > control and range positioning. Current qencoder implementation stores
> > counted values on int32_t so the maximum and minimum value is only
> > around +/- 32k. I need far bigger numbers to be counted and available
> > for readout quickly.
>
> Sorry its 2AM here and I sit too much in front of the computer with no
> fresh air :-P
>
> int is 32 bit with range unsigned 4.294E9 aka 4,294,967,295 and
> -2,147,483,648 to 2,147,483,647 signed.
>
> long is 64 bit with range 1.833E19 unsigned and
> -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 signed.
>
> I need to get familiar with the qencoder code more and know why there
> is a 32k modulo.
>
> I know that float and double are discouraged in embedded. Maybe its a
> silly idea to use floating numbers where speed is important. Will
> changing INT to LONG impact performance a lot?



I know it is sometimes unpopular to suggest adding more Kconfigs but maybe
this is something that should be configurable, allowing developers to
choose if they need a 64-bit count for range or a 32- (or even 16-) bit
count for efficiency. The needed speed and counter size really depends on
how the application is going to use the qencoder.

Nathan

Re: STM32F4 tickless

[Nathan Hartman]

On Wed, Jun 7, 2023 at 3:39 PM Fotis Panagiotopoulos 
wrote:

> Ah! Yes this is exactly the cause.
>
> Within nxsched_resume_timer(), nxsched_timer_process() sometimes returns
> only 1 tick!
>
> Later on, up_timer_start() will try to schedule the timer expiration 1 tick
> in the future.
>
> Since we don't know the phase of timer, the scheduled tick may be up to 1
> tick less.
> And since we try to schedule only 1 tick, then in reality the time may be
> even close to 0!
>
> And since all the above need at least some time for the CPU to execute
> these functions,
> we can easily end up scheduling something in the past!
>
> At least in STM32 there is no protection about scheduling things to the
> past.
> As far as I can tell, it would be impossible with the current
> implementation.
>
> ---
>
> What I don't really understand is "why" it is implemented like this?
>
> During all these calculations, and setting of the match register, the timer
> is left running.
> Thus it can run beyond our intended target while we set it.
>
> Sanity checks are impossible due to TOCTOU errors.
>
> Should the timer be stopped?
> Then possibly reset to a known value (0?), with a known phase.
> Then the match register be loaded (that now will be more accurate, since
> the phase of the clock is known),
> And then restart the timer.



If you stop the timer, then wouldn't we gradually accumulate error? Like a
gradual clock drift... Not sure yet what to suggest. I need to think about
it some more...

Nathan

NuttX participation in Community Over Code 2023?

[Nathan Hartman]

Dear NuttX community,

Even as our hard-working event organizers are preparing for NuttX
International Workshop 2023, there is an ASF-wide event coming up that
may also be significant for our community: Community Over Code 2023
(formerly known as ApacheCon), taking place this August in Beijing,
China. This event represents a cross-section of many ASF projects and
might help us spread the word about NuttX to grow our user and
developer community. Currently there is an open Call For Presentations
(see forwarded message below). A number of subjects are mentioned,
including IoT and IIoT (Internet of Things, Industrial Internet of
Things). Perhaps we have some community members who are interested in
presenting?

Forwarded message follows below...

Cheers,
Nathan

-- Forwarded message -
From: Rich Bowen 
Date: Mon, Jun 5, 2023 at 12:08 PM
Subject: Call for Presentations, Community Over Code Asia 2023
To: rbo...@apache.org 


You are receiving this message because you are subscribed to one more
more developer mailing lists at the Apache Software Foundation.

The call for presentations is now open at
"https://apachecon.com/acasia2023/cfp.html;, and will be closed by
Sunday, Jun 18th, 2023 11:59 PM GMT.

The event will be held in Beijing, China, August 18-20, 2023.

We are looking for presentations about anything relating to Apache
Software Foundation projects, open-source governance, community, and
software development.
In particular, this year we are building content tracks around the
following specific topics/projects:

AI / Machine learning
API / Microservice
Community
CloudNative
Data Storage & Computing
DataOps
Data Lake & Data Warehouse
OLAP & Data Analysis
Performance Engineering
Incubator
IoT/IIoT
Messaging
RPC
Streaming
Workflow / Data Processing
Web Server / Tomcat

If your proposed presentation falls into one of these categories,
please select that topic in the CFP entry form. Or select Others if
it’s related to another topic or project area.

Looking forward to hearing from you!

Willem Jiang, and the Community Over Code planners

Re: Systick tickless on STM32F4

[Nathan Hartman]

On Tue, Jun 6, 2023 at 5:44 PM Fotis Panagiotopoulos
 wrote:
>
> Hello,
>
> I just noticed the option STM32_TICKLESS_SYSTICK for the STM32.
> However, it seems that it does nothing.
>
> After a source code search, this option is not used anywhere.
> There is no tickless implementation that supports the systick timer.
>
> Shall I remove this?

Are there other STM32 sub-families that do support Tickless? Perhaps
it makes sense to port the support for that to this STM32 sub-family?

Cheers,
Nathan

Re: SD and eMMC performance in Nuttx

[Nathan Hartman]

On Thu, Jun 1, 2023 at 12:35 PM Gregory Nutt  wrote:

>
> > This may be way off base but, have you tried reverting
> >
> https://github.com/apache/nuttx/commit/7312a553bbc40f3771c5d53ccded89bed7391f2a
> >
> > It release the CPU but traded that for potentially quantized large delays
>
> Yes, I would expect the up_udelay to be in error by about about 0.5 uS
> (provided that the delay loop is properly calibrated).  The
> nxsig_usleep() should be error by about 1.5 x system-timer-period plus
> context switching delays.
>
> With the default timer period of 10 MS, that would be an error of about
> 15 MS -- Always longer in time than requested.
>
> A fix would be to use the tickless mode with a timer period of about 1 uS.



That would help when tickless mode is used. But what about tickful mode? I
guess the intent of 7312a553b was to avoid wasting processor cycles on busy
waiting, but if tickless isn't being used, perhaps busy waiting is
necessary here? It could choose between the two wait types at compile time
based on tickless mode.

Or a bigger question: if tickless mode is "better" (longer battery life,
fewer unnecessary interrupts, more processor cycles for real work) why
aren't we always using tickless mode? Are there limitations/bugs that make
it unsuitable in some situations? Not universally supported on all
microprocessors? Other reasons?

Cheers,
Nathan

Re: SD and eMMC performance in Nuttx

[Nathan Hartman]

On Wed, May 31, 2023 at 3:11 AM Radek Pesina 
wrote:

> Hi Nathan,
>
> Thanks for the reply.  The round-robin interval was set to 200ms and
> reducing it down to 10 marginally improved the transfer speed.  Our current
> code base and dev board is running a slightly quicker clock than what I
> used when I measured 75KiB/s, and the current setup is transferring at
> 100KiB/s with a RR interval of 200 and this increases to 135KiB/s with a RR
> interval of 10ms.



This leads me to think that there are several threads of same priority
competing for CPU time together with the thread that is transferring the
information. When the round robin time was 200ms, the transfer thread would
be made to wait up to 1/5th of a second per other thread of same priority
with which it was competing. (I say "up to" because those other threads
could voluntarily sleep or block waiting on other things.)

You could try raising the priority of the thread in question, but test
carefully because a higher priority thread will block lower priorities from
running. Maybe you want that, maybe not. Maybe you want that only during
startup.

It sounds like performance still isn't where you need it, so besides
priorities there may be additional factors contributing. Perhaps some other
threads are running needlessly and should explicitly relinquish CPU time?

Hopefully a good fix won't require major rework...



Yes I do have access to an oscilloscope and logic analyzer so will
> endeavour to obtain some traces tomorrow to rule in/out possible unexpected
> delays and/or noise.



Great!

Hope this helps...

Nathan

Re: SD and eMMC performance in Nuttx

[Nathan Hartman]

On Tue, May 30, 2023 at 8:07 PM Radek Pesina 
wrote:

(snip)

 *Configurations Tested:*
>
> For eMMC, I've tried optimising the menuconfig settings to improve it,
> including options such as below.   However, the performance remains
> lacking:
>
>- Turning on CONFIG_MEMCPY_VIK gave slight improvement
>- Setting USEC_PER_TICK to 1000 or below gave most improvement, however
>at the detriment of other aspects of the system. The fastest speeds
>observed by adjusting this was ~370KiB/s write and 700KiB/s read though
>overall this was unacceptable given the effect on the rest of the
> system.
>- Adjusting LittleFS parameters (e.g.
>CONFIG_FS_LITTLEFS_PROGRAM_SIZE_FACTOR,
>CONFIG_FS_LITTLEFS_READ_SIZE_FACTOR,
> CONFIG_FS_LITTLEFS_BLOCK_SIZE_FACTOR,
>CONFIG_FS_LITTLEFS_CACHE_SIZE_FACTOR, CONFIG_FS_LITTLEFS_LOOKAHEAD_SIZE
>- Ensuring SD/eMMC DMA read/writes are enabled.
>- Setting MMCSD_MULTIBLOCK_LIMIT to 0
>

(snip)

Out of curiosity, what is the value of CONFIG_RR_INTERVAL, and, if you
reduce it to something like 20 or 10, does that show any improvement?

Do you have an oscilloscope or logic analyzer available to monitor the
signals between the microcontroller and MMC? That might shed additional
light on this. E.g., extremely noisy signals, intermittent signals,
unexpectedly long delays between bursts of communication, etc.

Nathan

Re: Thank you!

[Nathan Hartman]

Kudos from me also, and best of luck getting that product released!

If I may suggest, perhaps at some future NuttX workshop, you could present
about how NuttX is being used in automotive.

Cheers
Nathan

On Thu, May 25, 2023 at 4:23 PM Alan C. Assis  wrote:

> Hi Tim,
>
> Congratulations! I'm very happy that you succeed!
>
> We are glad to have you aboard!
>
> BR,
>
> Alan
>
> On 5/25/23, Tim Hardisty  wrote:
> > My NuttX journey started in earnest about a year ago, after an enforced
> > pause for personal reasons. The processor on my board is ATSAMA5D2. In
> the
> > last year I have submitted (nearly all) merged PRs for this processor:
> >
> > - mcan
> > - flexcom SPI
> > - ClassD audio
> > - SPI DMA
> > - flexcom USART
> > - efuse support
> > - fixed usb problems, related to RNDIS
> > - added dual role port/OTG capability
> > - ADC fixes
> > - TSD fixes
> > - SPI performance enhancements
> >
> > Also added drivers for:
> >
> > - apds9922 proximity/light sensor
> > - LP503x RGB multi-LED driver
> > - FUSB302 USB-C controller
> > - act8945A PMIC power control
> >
> > And other stuff along the way and things I have already forgotten.
> >
> > I have learned a lot, my coding is more consistent, and I am WAY more
> > comfortable with not just NuttX but POSIX in general, and can mostly use
> > GitHub with only a small amount of swearing!
> >
> > All this has resulted in me finally being in a position to actually start
> > writing the application I need for the niche automotive product we'll
> > hopefully release this autumn.
> >
> > So: I would like to thank everyone who has replied to my usually dumb
> > questions, reviewed my PRs, and, generally, have just been so very
> > supportive and helpful.
> >
> > I couldn't have done it without you. Once the final product is ready I
> will
> > post much more information, pictures, videos, whatever.
> >
> > Until then: please keep helping as you have so far :)
> >
> > THANK YOU EVERYONE!!!
> >
> >
>

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Nathan Hartman]

On Tue, May 23, 2023 at 10:06 AM Brennan Ashton
 wrote:
>
> On Tue, May 23, 2023, 5:05 AM Nathan Hartman 
> wrote:
>
> > On Tue, May 23, 2023 at 6:12 AM Brennan Ashton
> >  wrote:
> > > I have also asked in the past about cutting down on the amount of configs
> > > we have checked in to be something like
> > >
> > > board:nsh -- only nsh and somewhat small
> > > board:jumbo -- nsh, plus as many features as can fit and are interesting
> > in
> > > the platform.
> > >
> > > For sim and some other targets it would make sense to have more targets,
> > > but not for every board.
> >
> >
> > The idea of "board:jumbo" is very similar to what I was saying
> > earlier. Maybe it will allow us to test fewer boards in less time but
> > still get better test coverage. I am in favor of *better* test
> > coverage, not less test coverage!!
> >
> > In the past, we talked about having some tests in CI for each PR, and
> > then a bigger nightly test that builds all boards/configs like Greg
> > used to do before releases. I don't think that ever happened, but ASF
> > has a build farm separate from GitHub that we might use, or we could
> > request from INFRA a virtual machine to set up a complete environment.
> > Maybe that's something to think about.
> >
>
>
> I'm not sure why we would need anything new? We can still run this in
> GitHub actions, but generally I don't think we should be having PRs merge
> that are not passing build tests.
>
>
> As for more testing of system on boards, QEMU is great for some tests and
> there is a thin framework that does some of that work that Xiang and others
> have started.  A few years ago I also gave a talk to see if there was
> interest in working with the folks a renode.io. Their open source simulator
> is what Zypher is using and at the time had minimal support, but check out
> this awesome dashboard.
>
> https://zephyr-dashboard.renode.io/
>
>
> It would be really cool if we could join forces a bit and continue to build
> off that effort and improve some of the emulation as needed (some work is
> required).


Wow, that is cool! I must have missed it when you mentioned it
previously. Yes, this is something the NuttX project should look into.

I agree with the QEMU idea as well, for those who want to build a
test/development setup they can run locally.

Both of these ideas are very good and we should pursue them. If we do
QEMU, we should document it, or script it, or both, so that other
community members can reproduce it and run a test system locally.
Personally I would like such a setup, and I am interested in helping
to document it.

Cheers,
Nathan

Re: [OT] Learning Makefiles

[Nathan Hartman]

On Tue, May 23, 2023 at 8:07 AM Tomek CEDRO  wrote:
>
> On Tue, May 23, 2023 at 9:31 AM Sebastien Lorquet wrote:
> > Hello Tomek,
> > Whatever is decided, the mere fact of wanting to make a decision on this
> > point will lead to more split.
> > either from people that want cmake
> > or from people who dont.
> > this is an intrinsically bad decision
> > Sebastien
>
> I am afraid of that, trying to help to avoid that! :-(
>
> I know each group has its points.
>
> Maybe we should just see how it works out in practice?


I very much *don't* want to cause a split in the community!!!

We're only having a *discussion* and comparing/contrasting. We're not
moving ahead and making any huge changes yet. I think it is a good
thing for everyone to say their thoughts and explain pros/cons.

If we try it in practice, we will definitely find out if it makes life
better, or worse. Unfortunately that would require doing all the work
(some is already done in PRs 3704 and 6718 but will need attention)
and maintaining two parallel build systems for a while. Will people
want to volunteer to do that if all the work might be thrown away?
Maybe, maybe not. I suppose it depends on how strongly people feel
about CMake.

So I think, first, we should make a nice coherent list of pros/cons.

I'm okay with tracking pros/cons in a GitHub issue instead of CWIKI.

Cheers,
Nathan

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Nathan Hartman]

On Tue, May 23, 2023 at 6:12 AM Brennan Ashton
 wrote:
> I have also asked in the past about cutting down on the amount of configs
> we have checked in to be something like
>
> board:nsh -- only nsh and somewhat small
> board:jumbo -- nsh, plus as many features as can fit and are interesting in
> the platform.
>
> For sim and some other targets it would make sense to have more targets,
> but not for every board.


The idea of "board:jumbo" is very similar to what I was saying
earlier. Maybe it will allow us to test fewer boards in less time but
still get better test coverage. I am in favor of *better* test
coverage, not less test coverage!!

In the past, we talked about having some tests in CI for each PR, and
then a bigger nightly test that builds all boards/configs like Greg
used to do before releases. I don't think that ever happened, but ASF
has a build farm separate from GitHub that we might use, or we could
request from INFRA a virtual machine to set up a complete environment.
Maybe that's something to think about.

Cheers,
Nathan

Re: [OT] Learning Makefiles

[Nathan Hartman]

On Mon, May 22, 2023 at 8:44 PM Alan C. Assis  wrote:

> On 5/22/23, Tomek CEDRO  wrote:
> > On Tue, May 23, 2023 at 1:55 AM Alan C. Assis wrote:
> >> I think it is better to keep the documentation in a single place:
> >> https://nuttx.apache.org/docs/latest/contributing/index.html
> >> We're moving those documentations from confluence to our internal
> >> repository.
> >> So, that could be nice if you could send patches to Documentation/
> >> directory directly.
> >
> > Yup, cwiki at this moment is a kind of scratchpad, all documentation
> > is being transferred to git / documentation.. but we may still use
> > cwiki to keep project administrative information like notes, rfc,
> > etc..?
> >
>
> No, I don't think so. Please search in the mailing list about this
> moving docs discussion.



Docs should move to repo, yes, BUT if I understand correctly Tomek is
talking about things like ongoing discussions, debates within the
community, such as arguments for and against adopting CMake. That is not
documentation for users of NuttX. That is a place for the community to
collect all the arguments in a debate so they will be easy to reference in
one place and easy to see if there are more pros than cons, or more cons
than pros. That should be able to go in the CWIKI and not docs in the repo,
IMHO.

Cheers
Nathan

CI tests (was: Re: [OT] Learning Makefiles)

[Nathan Hartman]

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: New docs not appearing on website?

[Nathan Hartman]

On Sun, May 21, 2023 at 11:30 AM Brennan Ashton
 wrote:
>
> On Sun, May 21, 2023, 8:02 AM Gregory Nutt  wrote:
>
> > On 5/21/2023 8:12 AM, Nathan Hartman wrote:
> > > Recently I added the new docs [1] and [2] to Documentation/guides but
> > > they are not appearing on the website [3].
> > >
> > > Does anyone know what I missed?
> > >
> > > [1]
> > https://github.com/apache/nuttx/blob/master/Documentation/guides/zerolatencyinterrupts.rst
> > >
> > > [2]
> > https://github.com/apache/nuttx/blob/master/Documentation/guides/nestedinterrupts.rst
> > >
> > > [3] https://nuttx.apache.org/docs/latest/guides/index.html
> > >
> > > Thanks,
> > > Nathan
> >
> > I see them:
> >
> > https://nuttx.apache.org/docs/latest/guides/zerolatencyinterrupts.html
> >
> > https://nuttx.apache.org/docs/latest/guides/nestedinterrupts.html
>
>
>
> As Greg said they are showing up, so I think everything is good, but you
> should be aware that there is a once a day cron job that will pick up the
> changes from the OS repo.  Changes to the website repo will be triggered
> nearly immediately. If you want to trigger this job manually you can also
> do that and there are instructions here for that
> https://github.com/apache/nuttx-website#force-deployment
>
> Additionally there are some cache settings that we do not not control, so
> if the publish job ran and you still don't see it, give it a ctrl-f5 and it
> might appear.
>
> --Brennan


Interesting. I do see them now, but I didn't see them before. Maybe it
was a browser refresh issue or something trivial like that.

Thanks,
Nathan

New docs not appearing on website?

[Nathan Hartman]

Recently I added the new docs [1] and [2] to Documentation/guides but
they are not appearing on the website [3].

Does anyone know what I missed?

[1] 
https://github.com/apache/nuttx/blob/master/Documentation/guides/zerolatencyinterrupts.rst

[2] 
https://github.com/apache/nuttx/blob/master/Documentation/guides/nestedinterrupts.rst

[3] https://nuttx.apache.org/docs/latest/guides/index.html

Thanks,
Nathan

Re: [OT] Learning Makefiles

[Nathan Hartman]

On Fri, May 19, 2023 at 12:53 PM Gregory Nutt  wrote:

> On 5/19/2023 10:25 AM, Lwazi Dube wrote:
> > Alan,
> >
> > Can you summarize? I have not been following this PR. Is make going away?
> >
> > Thanks,
> >
> > -Lwazi
> >
> > On Fri, 19 May 2023 at 11:47, Alan C. Assis  wrote:
> >> Hi Everyone,
> >>
> >> While PR #6718 is waiting to get merged, please take a look:
> >>
> >> https://makefiletutorial.com
> >>
> >> BR,
> >>
> >> Alan
>
> The decision to switch from GNU Make to CMake is highly controversial.
> Many people are wildly in favor and a large number are strong opposed.
> This is a change that must be brought before the PMC for a vote before
> any action is taken.
>
> Special rules apply to code change votes.  We don't often do votes on
> code changes.  But such votes are critical in order to serve the
> community with fairness.



I'm neutral regarding CMake but *if* the project wants to think about a
switch, I do think that we should consider very carefully the pros and
cons, and think about any disruption that might affect users.

If we want to consider supporting both GNU Make and CMake, then we should
consider the benefits against the added maintenance burden and possible
different behaviors that could occur because of inconsistencies between the
two systems. I am usually opposed to spreading our limited resources thin
over redundant systems.

Nevertheless I am neutral and happy for the project to choose whatever is
best, as long as we can reach a useful consensus as a community.

Note that work began on CMake support in PRs such as 3704 and 6718. If the
community is interested in CMake support, we shouldn't throw away that work.

Cheers,
Nathan

Re: Recommended configuration practices question

[Nathan Hartman]

On Fri, May 19, 2023 at 8:24 AM Milan Obuch  wrote:

> Hi,
>
> I started testing NuttX on Raspberry Pi Pico board, using FreeBSD as
> host for building. I was able to build NuttX using all configuration
> files for this board (but one - nshsram, it does not finish, but I
> don't care about it for now). All those configurations use default UART
> placement (pins 0, 1).
>
> These pins are not available on 01space board RP2040-0.42LCD, so I
> changed UART placement to pins 28, 29 running 'make menuconfig'. This
> way, .config in NuttX working/build directory is modified, and
> resulting binary (or uf2 for this board) file works as expected.
>
> This file, however, gets deleted when running 'make distclean' for
> different build. Thus I run 'make savedefconfig', altering defconfig
> file in working directory. This gets deleted on 'make distclean' as
> well, so I manually created new directory, where I copied defconfig
> file - boards/arm/rp2040/raspberrypi-pico/configs/nsh_28_29, and now my
> config is listed in 'tools/configure.sh -L' output, so I can use it as
> any other config file.
>
> So my questions now - is this intended way for saving and reusing
> config file? While it works for me, I'd like to have my configs
> separated from standard source files, maybe as third parallel directory
> to standard nuttx and apps, with ability to see them in
> 'tools/configure.sh -L' output, and using my configuration with
> 'tools/configure.sh '.
>
> Any hints for this one?
>
> Regards,
> Milan



There are various possibilities:

After running 'make savedefconfig' you would normally want to copy the
resulting defconfig file somewhere.

You could copy it to a new config under the board in question, and if you
feel this configuration could be helpful to the wider community, you could
opt to open a PR to upstream it.

Or you could create your own variant of the board by copying the whole
board directory and then customizing it. The copy could be in-tree (in
boards/arm64/) or out-of-tree (leaving the nuttx sources alone and
putting your board in another directory, which you can specify). This
option (copying the whole board directory) makes sense if you want to
customize more than just the config and don't plan to upstream your
customizations.

As a side note, if you are customizing any in-tree nuttx sources, it's
probably a good idea to create your own long-lived branch, keep your master
branch up-to-date with upstream, add your customizations to your private
branch, and occasionally merge updates from master into your branch. Or you
could base your branch off of a release tag if you prefer to use released
versions.

Hope this helps,
Nathan

Re: Article: PinePhone Accelerometer with NuttX (InvenSense MPU-6050)

[Nathan Hartman]

On Wed, May 17, 2023 at 7:34 PM Brennan Ashton 
wrote:

> On Wed, May 17, 2023, 5:13 AM Nathan Hartman 
> wrote:
>
> >
> > Let's create a blog section on the nuttx.apache.org site and fill it
> with
> > articles like these!
> >
> > Cheers
> > Nathan
> >
>
> This is supported, just no content added
>
> See https://github.com/apache/nuttx-website/tree/master/_posts
>


Woohoo! Thanks, Brennan!

Nathan

Re: nxsem_tickwait_uninterruptible randomly timeouts one tick too soon?

[Nathan Hartman]

Was it working before? If so, are you able to use a git bisect to find
the commit where the bug was introduced? This might minimize the
amount of testing and debugging that needs to be done.

On Wed, May 17, 2023 at 11:12 AM Jukka Laitinen  wrote:
>
>
>
> Petro Karashchenko kirjoitti keskiviikko 17. toukokuuta 2023:
> > How do you measure the wait period? Are you togging a pin or used MCU free
> > running HW timer?
>
> I used RISC-V MTIMER, so it is a free running HW counter at 1us resolution
>
> >
> > Best regards,
> > Petro
> >
> > On Wed, May 17, 2023, 5:43 PM Jukka Laitinen  wrote:
> >
> > >
> > > On 17.5.2023 16.38, Gregory Nutt wrote:
> > > > On 5/17/2023 7:21 AM, Gregory Nutt wrote:
> > > >> On 5/17/2023 4:21 AM, Jukka Laitinen wrote:
> > > >>>
> > > >>> Hi,
> > > >>>
> > > >>> I just observed the behaviour mentioned in the subject;
> > > >>>
> > > >>> I tried just calling in a loop:
> > > >>>
> > > >>> "
> > > >>>
> > > >>> sem_t sem =SEM_INITIALIZER(0);
> > > >>>
> > > >>> int ret;
> > > >>>
> > > >>> ret = nxsem_tickwait_uninterruptible(, 1);
> > > >>>
> > > >>> "
> > > >>>
> > > >>> , and never posting the sem from anywhere. The function return
> > > >>> -ETIMEDOUT properly on every call.
> > > >>>
> > > >>> But when measuring the time spent in the wait, I see randomly that
> > > >>> sometimes the sleep time was less than one systick.
> > > >>>
> > > >>> If I set systick to 10ms, I see typical (correct) sleep time between
> > > >>> 1 - 2us. But sometimes (very randomly) between 0 - 1us.
> > > >>> Also in these error cases the return value is correct (-110,
> > > >>> -ETIMEDOUT).
> > > >>>
> > > >>> When sleeping for 2 ticks, I see randomly sleep times between
> > > >>> 1-2us, for 3 ticks 2-3us. So, randomly it is exactly
> > > >>> one systick too small.
> > > >>>
> > > >>> I looked through the implementation of the
> > > >>> "nxsem_tickwait_uninterruptible" itself, and didn't saw problem
> > > >>> there. (Actually, I think there is a bug if -EINTR occurs; in that
> > > >>> case it should always sleep at least one tick more - now it doesn't.
> > > >>> But it is not related to this, in my test there was no -EINTR).
> > > >>>
> > > >>> I believe the problem might be somewhere in sched/wdog/ , but so far
> > > >>> couldn't track down what causes it.
> > > >>>
> > > >>> Has anyone else seen the same issue?
> > > >>>
> > > >>> Br,
> > > >>>
> > > >>> Jukka
> > > >>
> > > >>
> > > >> If I understand what you are seeing properly, then it is normal and
> > > >> correct behavior for a arbitrary  (asynchonous) timer.  See
> > > >> https://cwiki.apache.org/confluence/display/NUTTX/Short+Time+Delays
> > > >> for an explanation.
> > > >>
> > > >> NuttX timers have always worked that way and has confused people that
> > > >> use the timers near the limits of their resolution.  A solution is to
> > > >> use a very high resolution timer in tickless mode.
> > > >>
> > > >>
> > > > Oops.  You are seeing a timer that is 1 tick too short.  That is an
> > > > error and should never happen.  Sorry for reading incorrectly. It was
> > > > still early in the morning here.
> > > >
> > > > The timer logic adds +1 tick to the requested to assure that that
> > > > error never occurs.  If +1 were not added, the bad result would be
> > > > exactly as you describe (and as explained in the confluence reference).
> > > >
> > > >
> > > Hi, yes, exactly. Seeing timeout 1 tick too short. Sorry for not
> > > explaining it clearly enough :)
> > >
> > > I fear that there is now some bug. It was rather easy to re-produce,
> > > just a loop with few thousand iterations, and it occurs (infinite loop,
> > > 10 ms tick, less than a minute to catch). Most of the time it works ok;
> > > the sleep time is longer than the requested ticks. But when it triggers,
> > > the sleep is exactly one tick too short (and shorter than the requested
> > > timeout in ticks).
> > >
> > > I was just asking, if others have seen this as well; I'd like to know if
> > > it is really a bug in current nuttx main. It is always possible that
> > > there is something funny in our local build - although I can't see what
> > > it could be.
> > >
> > > -Jukka
> > >
> > >
> > >
> > >
> >

Re: Article: PinePhone Accelerometer with NuttX (InvenSense MPU-6050)

[Nathan Hartman]

On Wed, May 17, 2023 at 3:12 AM Lee, Lup Yuen  wrote:

> When we tilt our Smartphone from Portrait to Landscape... How does it know
> that we're tilting our phone? Watch what happens when we snoop the
> Accelerometer Data from PinePhone's MPU-6050 Accelerometer...
>
>
> https://www.hackster.io/lupyuen/inside-a-smartphone-accelerometer-pinephone-with-nuttx-rtos-b92b58
>
> Thanks to Filipe Cavalcanti for inspiring this tutorial! :-)



Kudos!!


BTW Hackster.io has problems for me, it got stuck at "Saving..." and lost
> my edits a few times. Remember to copy and paste your Article Text into
> another Backup Project at Hackster.io! :-)



Let's create a blog section on the nuttx.apache.org site and fill it with
articles like these!

Cheers
Nathan

Re: imxrt interrupt locking

[Nathan Hartman]

On Thu, May 4, 2023 at 8:08 AM Jernej Turnsek  wrote:
>
> Hi,
> thanks. Will take a look.
>
> On Thu, May 4, 2023 at 1:25 PM Nathan Hartman 
> wrote:
(snip)
> > I found it in the old wiki:
> >
> >
> > https://cwiki.apache.org/confluence/display/NUTTX/High+Performance%2C+Zero+Latency+Interrupts
> >
> > I don't see it in the repo Documentation. This is an important thing that
> > should be in the repo.


Just following up... I just opened PR #9302 [1] to bring this
documentation into the repo. Once merged and processed by CI, it will
also appear in the nuttx.apache.org site and therefore will be easier
for users to find.

[1] https://github.com/apache/nuttx/pull/9302

Cheers,
Nathan

Re: The NuttX Handbook

[Nathan Hartman]

On Sun, May 14, 2023 at 7:44 PM Gregory Nutt  wrote:

>
> > On 5/14/23, Brennan Ashton  wrote:
> >> Before I do more work to wire this up, please let me know if this pdf
> >> I have attached here seems like a reasonable start for people
> >> https://github.com/apache/nuttx/issues/9095#issuecomment-1547008998
> >>
> >> It is basically the same content on the website, so missing
> >> information is out of scope of this change,
> >> but I don't want to fix some compatibility issues here unless people
> >> actually think this is of value.
> >>
> Over the years, there have been several people with the dream of writing
> a commercial, NuttX book in the spirit of the famous uC/OS book.  There
> were even a few starts but all gave up when the magnitude of the effort
> sunk in.
>
> But this looks like a good begubbubg.  It looks like a book.



It does look very good for starters!

Of course there are a lot of omissions right now but that is OK right now
because it is generated from Documentation in the repo, which contains a
lot of omissions...

I think that having the docs in the form of a book or PDF allows us to see
the structure of the documentation more easily and therefore we can write
better documentation.

I recommend to keep it as automatically generated from Documentation in the
repo because that will reduce duplication of effort. When we improve
Documentation, we will automatically improve the website and the PDF book.

There are many "easy" areas to fix and improve. For example, the section of
supported architectures lists only a few while in truth we support a lot
more.

But as Brennan said, we're not talking about omissions right now. :-)

How much additional effort would it take to develop a book (like an
> O'Reilly book) or a free eBook on Amazon or Google Books?


That would be a neat idea!

Maybe we could reach out to some professional technical writers and find
out if they'd like to take on the project and publish a professional (for
sale) book.

The first author that comes to mind, just off the top of my head, is Derek
Molloy, the author of books like Exploring Raspberry Pi [1] and Exploring
BeagleBone [2]. Both of these are about embedded systems. Both of these
include tutorials not only in electronics (how to use FET transistors, for
example) and embedded systems (how to use GPIOs and not blow up your board)
but also higher level topics in Linux, since both boards run Linux distros
by default. (Side note: I would love to see these boards run NuttX!!) So
this author is no stranger to electronics, embedded, coding, and POSIX
systems.

It might sound like a fabulous idea but unfortunately I have no idea how
one would reach this author to ask!! If someone knows, please do it!!

[1] https://a.co/d/5S3Etz0

[2] https://a.co/d/avmNiH7

Cheers
Nathan

Re: Warning: Apache Mailing list was silently down

[Nathan Hartman]

On Tue, May 9, 2023 at 1:20 PM Alan C. Assis  wrote:

> It seems that since (at least) yesterday Apache mailing list was
> silently dropping emails.
>
> So it you sent some email at least in the last 24h please submit it
> again because the email server sent it to /dev/null !
>
> BR,
>
> Alan
>

Should talk to Infra?

Nathan

Re: Article: NuttX for PinePhone: Phone Calls and Text Messages

[Nathan Hartman]

On Thu, May 4, 2023 at 7:52 AM Tomek CEDRO  wrote:

> On Thu, May 4, 2023 at 8:12 AM alin.jerpe...@sony.com wrote:
> > This is great progress !
> > With an UI will be easier to handle
>
> Some important architectural decisions will have to take place when
> designing the UI part for whole system and userland applications and
> their interoperability (including external application store or
> something like that in future).
>
> I have been fighting with "mobile applications" for Android and iOS
> for years and there is no good stable and coherent solution right
> now.. and probably there will never be as these enforced changes seems
> to be part of the design.. in fact it all seems a "moving disaster"
> for me, aka "catch the rabbit" game.
>
> I worked with native tools (Android Studio and XCode), cross platform
> JavaScript (ReactNative, Vue), recently Python (Kivy). I also at some
> point considered using LVGL on SDL2 then putting it all together into
> a mobile application. Recently I even considered compiling whole NuttX
> + LVGL + SDL and linking into a mobile application, after seeing NuttX
> + LVGL demo on my desktop. There is still a unavoidable dependency on
> a mobile platform SDK, NDK, etc, that constantly changes, and it is
> hard to catch. I hope things will never get that way in NuttX :-)
>
> NuttX as independent (mobile) platform seems unavoidable for people
> that just want simple things working. Maybe even on older hardware
> that will again provide week or more battery life time :-)
>
> We just cannot get ourselves into a "modern mobile world mess" please :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

I have seen those fast-moving-target frameworks described as having the
"lifecycle of yogurt" in multiple places around the internet.

+1 for stability!!!

Nathan

Re: imxrt interrupt locking

[Nathan Hartman]

On Thu, May 4, 2023 at 7:11 AM Nathan Hartman 
wrote:

> On Thu, May 4, 2023 at 5:46 AM Jernej Turnsek 
> wrote:
>
>> I am developing a driver which is processing peripheral interrupts every
>> 6.4 microseconds and every 16th interrupt calling notify function from HP
>> work queue. But scheduling workqueue does lock interrupts (through
>> critical
>> section) up to 20us sometimes, causing my peripheral missing interrupts.
>> The same thing occurs if calling the notify function with nxsem_post
>> directly from ISR. DMA is not an option. I am working with the NXP RT1064
>> board. How can I wake the read function without locking interrupts?
>> Thanks.
>>
> That chip is Arm Cortex M7. I think zero-latency interrupts are supported
> on that. If so, you could try to use that to service the 6.4us interrupt.
>
> Zero-latency interrupts cannot use OS services because they exist outside
> the OS. Therefore, to rendezvous with the hp queue, each 16th interrupt,
> trigger an otherwise unused interrupt vector, which will be serviced by a
> "normal" ISR, which can in turn hand off the data to the hp queue.
>
> There's a page about this somewhere...
>


I found it in the old wiki:

https://cwiki.apache.org/confluence/display/NUTTX/High+Performance%2C+Zero+Latency+Interrupts

I don't see it in the repo Documentation. This is an important thing that
should be in the repo.

Cheers
Nathan

Re: imxrt interrupt locking

[Nathan Hartman]

On Thu, May 4, 2023 at 5:46 AM Jernej Turnsek 
wrote:

> I am developing a driver which is processing peripheral interrupts every
> 6.4 microseconds and every 16th interrupt calling notify function from HP
> work queue. But scheduling workqueue does lock interrupts (through critical
> section) up to 20us sometimes, causing my peripheral missing interrupts.
> The same thing occurs if calling the notify function with nxsem_post
> directly from ISR. DMA is not an option. I am working with the NXP RT1064
> board. How can I wake the read function without locking interrupts? Thanks.
>
That chip is Arm Cortex M7. I think zero-latency interrupts are supported
on that. If so, you could try to use that to service the 6.4us interrupt.

Zero-latency interrupts cannot use OS services because they exist outside
the OS. Therefore, to rendezvous with the hp queue, each 16th interrupt,
trigger an otherwise unused interrupt vector, which will be serviced by a
"normal" ISR, which can in turn hand off the data to the hp queue.

There's a page about this somewhere...

Nathan

ARMv7-m strcmp broken?

[Nathan Hartman]

I posted this as a comment on GitHub [1] but writing this here in case
it isn't seen:

Has anyone tried to use the ARMv7-m optimized (assembly-coded) strcmp?

I cannot seem to build with CONFIG_ARMV7M_STRCMP:

```
$ tools/configure.sh tm4c129e-launchpad:nsh

(snip)

$ make menuconfig
```

Here I enable these options:
CONFIG_ARMV7M_MEMCHR=y
CONFIG_ARMV7M_MEMCPY=y
CONFIG_ARMV7M_MEMMOVE=y
CONFIG_ARMV7M_MEMSET=y
CONFIG_ARMV7M_STRCMP=y
CONFIG_ARMV7M_STRCPY=y
CONFIG_ARMV7M_STRLEN=y

```
$ make
Create version.h
LN: platform/board to /home/work/NuttX/apps/platform/dummy
Register: ping
Register: nsh
Register: sh
Register: telnetd
AS:  machine/arm/armv7-m/gnu/arch_strcmp.S
machine/arm/armv7-m/gnu/arch_strcmp.S: Assembler messages:
machine/arm/armv7-m/gnu/arch_strcmp.S:51: Error: bad instruction `def_fn strcmp'
machine/arm/armv7-m/gnu/arch_strcmp.S:75: Error: bad instruction `s2lo
r12,r3,r12'
machine/arm/armv7-m/gnu/arch_strcmp.S:94: Error: bad instruction `s2hi
r0,r2,#24'
machine/arm/armv7-m/gnu/arch_strcmp.S:95: Error: bad instruction `s2lo r2,r2,#8'
machine/arm/armv7-m/gnu/arch_strcmp.S:98: Error: shift expression
expected -- `cmpcs r0,r3,S2HI#24'
machine/arm/armv7-m/gnu/arch_strcmp.S:99: Error: IT falling in the
range of a previous IT block -- `it eq'
machine/arm/armv7-m/gnu/arch_strcmp.S:100: Error: bad instruction
`s2loeq r3,r3,#8'
machine/arm/armv7-m/gnu/arch_strcmp.S:247: Error: shift expression
expected -- `cmp r5,r3,S2LO#8'
machine/arm/armv7-m/gnu/arch_strcmp.S:256: Error: shift expression
expected -- `cmp r5,r3,S2HI#24'
machine/arm/armv7-m/gnu/arch_strcmp.S:261: Error: bad instruction
`s2lo r3,r3,#8'
machine/arm/armv7-m/gnu/arch_strcmp.S:278: Error: bad instruction
`s2lo r5,r2,#24'
machine/arm/armv7-m/gnu/arch_strcmp.S:285: Error: bad instruction
`s2lo r5,r2,#24'
machine/arm/armv7-m/gnu/arch_strcmp.S:292: Error: bad instruction
`s2hi r5,r2,#16'
machine/arm/armv7-m/gnu/arch_strcmp.S:294: Error: bad instruction
`s2lo r5,r5,#16'
machine/arm/armv7-m/gnu/arch_strcmp.S:296: Error: shift expression
expected -- `cmp r5,r3,S2LO#16'
machine/arm/armv7-m/gnu/arch_strcmp.S:303: Error: shift expression
expected -- `cmp r5,r3,S2HI#16'
machine/arm/armv7-m/gnu/arch_strcmp.S:321: Error: bad instruction
`s2lo r5,r2,#16'
machine/arm/armv7-m/gnu/arch_strcmp.S:328: Error: bad instruction
`s2hi r3,r3,#16'
machine/arm/armv7-m/gnu/arch_strcmp.S:329: Error: bad instruction
`s2lo r5,r2,#16'
machine/arm/armv7-m/gnu/arch_strcmp.S:331: Error: bad instruction
`s2lo r3,r3,#16'
machine/arm/armv7-m/gnu/arch_strcmp.S:338: Error: shift expression
expected -- `cmp r5,r3,S2LO#24'
machine/arm/armv7-m/gnu/arch_strcmp.S:347: Error: shift expression
expected -- `cmp r5,r3,S2HI#8'
machine/arm/armv7-m/gnu/arch_strcmp.S:352: Error: bad instruction
`s2lo r3,r3,#24'
machine/arm/armv7-m/gnu/arch_strcmp.S:361: Error: bad instruction
`s2lo r5,r2,#8'
machine/arm/armv7-m/gnu/arch_strcmp.S:380: Error: bad instruction
`s2loeq r5,r5,#8'
machine/arm/armv7-m/gnu/arch_strcmp.S:381: Error: bad instruction
`s2loeq r3,r3,#8'
machine/arm/armv7-m/gnu/arch_strcmp.S:382: Error: branch must be last
instruction in IT block -- `beq .Lstrcmp_tail'
machine/arm/armv7-m/gnu/arch_strcmp.S:383: Error: instruction not
allowed in IT block -- `sub r0,r2,r0'
machine/arm/armv7-m/gnu/arch_strcmp.S:73: Error: undefined symbol MSB
used as an immediate value
machine/arm/armv7-m/gnu/arch_strcmp.S:246: Error: undefined symbol MSB
used as an immediate value
machine/arm/armv7-m/gnu/arch_strcmp.S:286: Error: undefined symbol LSB
used as an immediate value
machine/arm/armv7-m/gnu/arch_strcmp.S:337: Error: undefined symbol LSB
used as an immediate value
machine/arm/armv7-m/gnu/arch_strcmp.S:357: Error: undefined symbol LSB
used as an immediate value
machine/arm/armv7-m/gnu/arch_strcmp.S:362: Error: undefined symbol MSB
used as an immediate value
machine/arm/armv7-m/gnu/arch_strcmp.S:374: Error: undefined symbol LSB
used as an immediate value
machine/arm/armv7-m/gnu/arch_strcmp.S:375: Error: undefined symbol LSB
used as an immediate value
{standard input}: Error: .size expression for strcmp does not evaluate
to a constant
make[1]: *** [Makefile:143: bin/arch_strcmp.o] Error 1
make: *** [tools/LibTargets.mk:180: libs/libc/libc.a] Error 2
```

I noticed that some of the other files have something like this:

```
.macro def_fn f p2align=0
  .text
  .p2align \p2align
  .global \f
  .type \f, %function
 \f:
  .endm

```

However I do not understand the assembly sources so I don't know
what will happen if I copy-and-paste that.

Interestingly, I found the newlib code and it also doesn't have the
macro def_fn. See [2].

[1] https://github.com/apache/nuttx/pull/8042#issuecomment-1527653447

[2] 
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/machine/arm/strcmp-armv7.S;h=7cafca151b162210c2af4a512a14255a2aecc4cd;hb=HEAD

Cheers,
Nathan

Re: SAMA5(D2) SPI speed is restricted by the driver

[Nathan Hartman]

On Thu, Apr 27, 2023 at 11:27 AM Tim Hardisty  wrote:

> Just posted this same text on GitHub:
>
> https://github.com/apache/nuttx/issues/9127#issue-1687069010.
>
> Content copied here for those that don't go there.
>
> ---
>
> I have been investigating poor MTD performance with a GD25 memory on SPI0
> of a SAMA5D27 processor.
>
> Using LittleFS, dd was showing 37KB/s transfer speeds. I ruled out
> LittleFS - SmartFS was even slower.
>
> The memory is set to run at 50MHz, but I was seeing only 10MHz, and long
> delays between transfers.
>
> looking at arch/arm/src/sama5/sam_spc.c it seems the SPI interface is hard
> coded to be deliberately slow:


>
> 1) SCBR (Serial Clock Bit Rate) forced to have a minimum value of 9, when
> the datasheet says 1 should be the minimum
> 2) DLYBS (Delay from NPCS going active to first valid clock) forced to be
> 2us
> 3) DLYBCT(Delay between 2 consecutive transfers) forced to be 5us
> 4) SPI clock defaulting to using main clock (164MHz) whereas it could use
> the Peripheral Clock (492MHz) which limits the resolution of the actual
> frequency realisable
>
> Changing these to the fastest allowable values results in a huge
> improvement in transfer speed - it's now 263KB/s.
>
> BUT...is there a good reason why these very big values have been chosen?
> Should they not be configurable rather than hard coded, even?
>


I don't work with this architecture so take with a grain of salt, but my
guess is that these settings were based on the board used at the time it
was implemented. Perhaps whoever implemented it didn't need the additional
logic to select interface speeds etc.



I am aware there are other processors in the SAMA5 family (i.e. SAMA5D3 and
> SAMA5D4) so input from anyone who knows those would be welcomed, along with
> any general observations and suggestions on the best way to improve this?
>
> As an aside, DMA doesn't work for the SAMA5D2 SPI - it uses "XDMAC" not
> "DMAC" so Kconfig settings get disabled and the driver never works out the
> right DMA setup (which would be wrong for this device anyway!).
>
> I am very happy to work on the fix and a PR after some feedback.
>
> Cheers
Nathan

Re: FAQ :-)

[Nathan Hartman]

On Thu, Apr 27, 2023 at 6:03 PM Tomek CEDRO  wrote:

> Hello world :-)
>
> I have some in-development question that could probably go to DOC/FAQ
> as I found some questions/answers there already :-) Any hints
> appreciated. Also the logic / approach errors and valid solution
> propositions welcome :-) :-)


>
> 1. Daemon / Service:
>
> 1.1. I would like to have application running as daemon in the
> background all the time. Is this possible?



Yes, though I don't think there's a way to designate a program as a
"daemon" necessarily, but a program can run all the time.

In Kconfig there's a setting (I'm on my phone now so don't remember the
name off the top of my head) that determines what initial task to run. In
most in-tree board configs this is set to nsh_main. You could set this to
your own init-style program that launches your daemon, or multiple daemons,
and perhaps nsh as well, if you want it in the end product. Continued below:


1.2. On application error / crash I would like the application to
> restart so it is always available. Is this possible?
>


One idea is to make your init-style program monitor that your daemon is
running and if not, either restart it or reboot the board, whichever is
applicable to your product.


1.3. There is a Watchdog in NuttX. Who feeds the watchdog? Is it
> possible that there are two watchdogs: one for the OS and second for
> the Application? In case of  either system / application crash the
> system should be rebooted by one of the watchdogs. Is this possible?
>
> 1.4. Is it possible to call the nsh as sub-process from within my
> application so the application keeps feeding the watchdog?



It is possible to start nsh from another program. It doesn't have to be the
default application launched at boot. In fact, everything in the apps repo
should be seen as examples and demonstration programs that you can use
as-is, or use as a guide to building your own. So you need not actually
have nsh at all, if it isn't appropriate in your product.


1.5. If the timing is important should I rather keep my application in
> the foreground and abandon the idea of a daemon?



If the daemon responds to some outside stimulus, you can give the daemon a
high priority and have it wait on a semaphore for the event to occur.
Perhaps interrupt logic would post the semaphore. (Be careful with priority
inheritance and the recently changed semantics.)

Hopefully others will be able to help with these:

2. Sim -> HW.
>
> 2.1.. I would like to develop my application first on the Simulator,
> and then when its working at some point I would like to port is to the
> real hardware. How my firmware could know what Arch is it currently
> running on?


>
> 2.2. On Sim I would like to produce log messages, while on the real
> Hardware driver actions should be performed. What would be the best
> way to achieve that? Is is possible to determine hardware / arch at
> runtime? Should I use #ifded CONFIG_BLAH macros to attach driver code
> when real hardware is selected?
>
> 2.3. I can see that there is GPIO available in the SIM. How can I
> interact with that gpio from my host OS? Is there sort of additional
> application to perform such interaction with the simulator
> application?
>
>
> 3. Out of tree Application / Board / Drivers.
>
> 3.1. My current working setup is based on git. I would like to keep
> all firmware code in my project's repository and external to the NuttX
> + NuttX-Applications source tree.  So that nuttx.git and nuttx-app.git
> is provided as git submodule on the main project repo. Is this
> possible?
>
> 3.2. I know that Application can be kept out-of-tree if linked to
> nuttx-apps.git. Should I do the same with Boards and Drivers?
>
> 3.3. Is it possible to attach Application / Board / Driver code
> out-of-tree with no linking?
>
> 3.4. Is it possible to provide full path and no non-relative path to
> nuttx-apps in ./tools/configure.sh?
>
>
> Thanks :-)
> Tomek
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
Cheers
Nathan

Re: asprintf failure

[Nathan Hartman]

On Wed, Apr 26, 2023 at 9:32 AM Fotis Panagiotopoulos
 wrote:
>
> Hello,
>
> I fixed all critical usages of asprintf and strdup.
>
> These fixes are in the following PRs:
> https://github.com/apache/nuttx/pull/9009
> https://github.com/apache/nuttx/pull/9010
> https://github.com/apache/nuttx-apps/pull/1713
>
>
> The OS itself is now fixed, there should be no other issues pending.
>
> However, there are some uses that are still to be fixed.
> These are in the tools directory and in some apps (strdup mostly).
>
> They should not affect the stability of the system in any way, and I
> consider these "minor" issues.
>
> Unfortunately, I cannot spend any more time on this.
> So, if anyone has any free time, I would encourage you to improve the apps
> or the tools in this regard.

Thank you for doing this!

If I may make a suggestion, it would be helpful to post an issue to
the issue tracker about the ones that aren't fixed yet (strdup etc) so
that we won't forget to eventually fix them.

Thanks again for taking care of these!!

Nathan

Re: Usage of mutex_t inside libc

[Nathan Hartman]

On Wed, Apr 26, 2023 at 8:34 AM Ville Juven  wrote:

> Hi,
>
> Thanks for pointing that out, basically the same issue I face.
>
> First I thought it would be simple to fix OR wrap around the usage of
> SEM_INITIALIZER/NXSEM_INITIALIZER/NXMUTEX_INITIALIZER. My assumption was
> that they are not used in very many places in user space. For wrapping
> one option would be to do a lazy init of the semaphore when sem_wait() /
> sem_post() / etc. are called and identify the non-init state by some
> special flagging.
>
> However I'm totally wrong, PTHREAD_MUTEX_INITIALIZER exists as well and
> this is used to initialize the semaphore in pthread_mutex_t and
> pthread_cond_t. Trying to get rid of the initializer macro proves to be
> too much re-factoring of code I'm not very familiar with (big risk
> something will break) -> I'll try to figure out something else.



PTHREAD_MUTEX_INITIALIZER not only exists, it's in the standard:

https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_init.html

Nathan

Re: The NuttX Handbook

[Nathan Hartman]

On Tue, Apr 25, 2023 at 3:12 PM Brennan Ashton 
wrote:

> On Tue, Apr 25, 2023, 7:45 PM Tomek CEDRO  wrote:
>
> > On Tue, Apr 25, 2023 at 8:14 PM Gregory Nutt wrote:
> > > Tomasz Cedro now owns nuttx.com and nuttx.org.
> >
> > Yes the domains are for the project use, just let me know how you want
> > them configured, at this point they redirect to the main project site
> > :-)
> >
> > I was thinking about maybe some showcases of the projects and products
> > made with NuttX at nuttx.com? That could present solid real world
> > applications and gather more interest around the project?
> >
>
> Why would we not use the real project website for this?  I think it is
> correct that they should just redirect to the Apache NuttX domain.
>
> The framework for the website supports blog articles but no one has ever
> added one.
> They would be added here
> https://github.com/apache/nuttx-website/tree/master/_posts the CI will
> then
> run generate the artifacts and publish as needed.
>
> Let's try to have less places where there are things not more. So far
> everything I have heard can be done with what we already have is just a
> matter of people creating content, not adding more tools, sites, etc... We
> also have to be mindful of official project work being hosted within the
> Apache organization.
>
> --Brennan


Big +1 to this from me! Let's try to make the information people need
easier to find. :-)

Cheers
Nathan

Re: The NuttX Handbook

[Nathan Hartman]

On Tue, Apr 25, 2023 at 1:10 PM Tomek CEDRO  wrote:

> On Tue, Apr 25, 2023 at 5:47 PM Brennan Ashton wrote:
> > On Tue, Apr 25, 2023, 3:18 PM Gregory Nutt wrote:
> > > My experience with using Deoxygen on large, projects has been
> > > disastrous.  People don't always maintain the tags to the documentation
> > > was wrong and so the auto-generated  documentation was not
> > > trust-worthy.  So you always end up looking at the code anyway.  There
> > > is nothing in the auto-generated code that is not in the the files so
> > > there is no real value added (there would be if you could trust it).
> > >
> > > Also, minor errors in the tags cause a lot of CI failures.  A couple
> per
> > > week.
> > >
> > > I suppose if documentation tags were added to all files and were all of
> > > the highest quality, it would be a good thing.   That that would be an
> > > enormous job and ongoing maintained of the documentation tags would be
> a
> > > problem:  Most people won't change them or put in useless, low value
> > > tags.  Much like PR comments. Or comments and documentation in general.
> > >
> > > If we could do it right, then +1 with a significant commitment of time
> > > and effort.  If we would do only a half-assed job, then -1.
> >
> > I _very_ much agree. I have very rarely found doxygen to be useful and
> > usually just results in unhelpful boilerplate to make the tool happy and
> > generates some html that no one will ever look at again.   It is usually
> > much better when someone spends the time to actually document the
> > interfaces and the why behind them (like man pages) we already have a
> > section in the docs for interfaces and it would be great as people extend
> > and adapt them to continue keeping these up to date.
>
> Okay, Doxygen is the past.. currently Sphinx is the way to go, no
> doubts, just an (not really convenient) example to keep doc in sync
> with src and that can be quite PITA :-)
>
>
> After some consideration a "safer" approach may be more desirable for now:
>
> 1. Migrate all documentation to a separate Documentation/ as it is
> currently done, so we do not lose any content from
> MediaWiki/README/CWIKI, we can add additional content that we need,
> the documentation form is shaped to a satisfactory state, automation
> is verified, nice references, tables of contents, sections, etc.
> People will have solid documentation all the time and we cause no mess
> and we can see how the work on doc goes in reality :-)


Suggestion: The "separate" Documentation could be simply an "Unfinished" or
"WorkInProgress" subdirectory inside Documentation. Just dump everything in
there as quickly as possible and then gradually fixup and move sections to
the right places.

And then this:

2. When we have a well shaped "separate" documentation then it may be
> the time to consider merging it with the source code, but not before,
> if desired at all?


doesn't require moving things from some other system into git. It will just
become a rename within the repo.

What do you think?


I like the idea of keeping documentation in sync with the code(as much as
possible given our volunteer-based project).

The biggest pro for keeping doc within src is to stay in sync, maybe
> to also have self documented source code. But there are also dangers
> here, like messing up the whole unfinished doc and the source code!!
> It would be wise to list all pros and cons and then after some time
> make some decisions but not necessarily right now.. :-)


At the very least, documentation will be included in our release artifacts,
so people will have docs "offline" when they download releases. I think
that's a good thing.

Pros:
> 1. It would be more coherent to keep doc inside src files and this
> will result in better doc-in-sync-with-src.
> 2. Source code will have documentation "inside".
> 3. Sphinx has a better syntax than Doxygen so less ci / format / tag
> errors may occur.
> 4. Working examples are available as reference point
> (https://github.com/kivy/kivy/tree/master/doc,
> https://github.com/kivy/kivy/blob/master/kivy/config.py).
>
>
> Cons:
> 2. It can (and probably will) mess up current doc _and_ src!!
> 2. Separation of documentation from the source code will enable easy
> switch to other documentation system rather than rewrite of all source
> code.
> 3. This is even more work than migrating docs from wiki.
> 4. This will make source files bigger (any impact on
> (pre)process/build time or something?).
> 5. The "separate" documentation is already out there just needs
> reformatting (wiki -> rst).
>
>
> > Additionally from this discussion I have opened two tickets from this
> > thread.
> >
> > * Generate and publish the PDF alongside the html docs
> > https://github.com/apache/nuttx/issues/9095
> > * A tracking ticket to unify more of the docs.
> > https://github.com/apache/nuttx/issues/9094
> >
> > I will start in on both once I return from holiday and have time in front
> > of a real computer again.
>
> I 

Re: The NuttX Handbook

[Nathan Hartman]

On Tue, Apr 25, 2023 at 9:59 AM Gregory Nutt  wrote:

> Sorry, I know I am way to anal retentive:
> > In the past, documentation was partly in README files in various
> > directories in the repo, partly on the NuttX website which was running on
> > MediaWiki.
> It was actually DocuWiki and was the landing page for the old nuttx.org
> website (not that it matters)



Ah, I stand corrected!

Thank you,
Nathan

Re: The NuttX Handbook

[Nathan Hartman]

On Tue, Apr 25, 2023 at 8:55 AM Brennan Ashton 
wrote:

> On Tue, Apr 25, 2023, 1:46 PM Brennan Ashton 
> wrote:
>
> >
> >
> > On Tue, Apr 25, 2023, 1:37 PM Tomek CEDRO  wrote:
> >
> >> Hello world :-)
> >>
> >> I was on a trip recently (and it happens quite often) so I was looking
> >> for a PDF version of NuttX Documentation, kind of Handbook, but I did
> >> not find one.
> >>
> >> I got used to PDF Handbook style because it is all-in-one approach
> >> that is also easily available and searchable offline.
> >>
> >> As I am getting into details and reading the docs, so I can help this
> >> part :-)
> >>
> >> I would like to know what is the current and past approach to the
> >> documentation, to plan the work and align the tasks (with other people
> >> working on the documentation?). What is the future preferred way of
> >> documentation? git+documentation? (c)wiki?
> >>
> >> I know there is a doc part on the website that is generated from the
> >> main repository Documentation/ location. This part seems to need some
> >> improvement (looks a bit like incomplete copy-paste?) :-)
> >>
> >> I know there is a CWIKI. I know there was some bigger documentation
> >> before..?
> >>
> >> It would be best to have HTML and PDF documentation (maybe other
> >> formats too) in a form of "Handbook" (all-in-one-place + searchable +
> >> offline). This Handbook could be also provided in a form of e-book for
> >> free and maybe some pay-as-you-want basis to support the project. This
> >> would be also probably the first point of contact with the project for
> >> the newcomers.
> >>
> >> As a reference documentation I could point to:
> >> 1. https://docs.freebsd.org/en/books/handbook/
> >> 2. https://kivy.org/doc/stable/
> >>
> >> Please let me know what you think folks :-)
> >> Tomek
> >>
> >> --
> >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> >
> >
> >
> > It is easy enough to generate the PDF from the sphinx documentation if we
> > want that can you create an issue on the website project and I'll enable
> > that in a few weeks.
> >
> > --Brennan
> >
>
>
> Also I want to be very clear since this was incorrect
>
> > I know there was some bigger documentation before..?
>
> Others and I _extended_ and converted this to be what is now in
> Documentation it was a lot of work.  This is the documentation for the
> project although it has been slow to convert all the readmes and the wiki
> to be here. I would love to see others help with this time consuming
> effort.
>
> --Brennan
>

I wrote my reply before I saw this. Are there any more CWIKI pages that
need to be migrated into the repo?

Thanks for your (and other's) efforts in this area.

Nathan

Re: The NuttX Handbook

[Nathan Hartman]

On Tue, Apr 25, 2023 at 8:37 AM Tomek CEDRO  wrote:

> Hello world :-)
>
> I was on a trip recently (and it happens quite often) so I was looking
> for a PDF version of NuttX Documentation, kind of Handbook, but I did
> not find one.
>
> I got used to PDF Handbook style because it is all-in-one approach
> that is also easily available and searchable offline.
>
> As I am getting into details and reading the docs, so I can help this part
> :-)
>
> I would like to know what is the current and past approach to the
> documentation, to plan the work and align the tasks (with other people
> working on the documentation?). What is the future preferred way of
> documentation? git+documentation? (c)wiki?



In the past, documentation was partly in README files in various
directories in the repo, partly on the NuttX website which was running on
MediaWiki.

As the project moved to Apache Software Foundation, most of the MediaWiki
was migrated into CWIKI (because ASF has that setup) and there has been a
gradual effort to reorganize the content of the README files in the repo
under the Documentation directory and convert them from purely text to
Sphinx format (which is still text and readable in its source format, but
can be processed into webpages and probably PDF; it would be nice to offer
a download link to the latest generated PDF from the NuttX website).

I think that some docs were copied and pasted from the CWIKI to the in-repo
Documentation directory but I don't know whether everything was. Some
important stuff might be missing.

Personally I think it would be best to put all the docs in Documentation in
the repo and _not_ continue to keep it in the CWIKI. (But first we should
ensure everything has been migrated so that we won't lose anything.)

In the past some people expressed that they wanted to centralize docs for
boards under Documentation rather than keeping README files scattered
around. I responded that if we do that, we should have a directory
structure under Documentation that parallels the structure under boards,
which will serve both to keep things organized and to make it easy, given a
board path, to find its corresponding docs path (i.e., just prepend
"Documentation/").

Right now, it is well acknowledged that our documentation is lacking in
several areas. Any help improving it will be tremendously appreciated.

Among other improvements, it would be nice if the documentation could be
organized to flow like a NuttX Handbook. I totally recommend to look at the
FreeBSD Handbook for inspiration. :-)


I know there is a doc part on the website that is generated from the
> main repository Documentation/ location. This part seems to need some
> improvement (looks a bit like incomplete copy-paste?) :-)
>
> I know there is a CWIKI. I know there was some bigger documentation
> before..?
>
> It would be best to have HTML and PDF documentation (maybe other
> formats too) in a form of "Handbook" (all-in-one-place + searchable +
> offline). This Handbook could be also provided in a form of e-book for
> free and maybe some pay-as-you-want basis to support the project.



Not sure how donations would work. Probably they would have to be paid
directly to ASF, but I think it is possible to earmark donations for
specific things or projects. This is something that needs to be checked.


This
> would be also probably the first point of contact with the project for
> the newcomers.



Agreed.


As a reference documentation I could point to:
> 1. https://docs.freebsd.org/en/books/handbook/
> 2. https://kivy.org/doc/stable/
>
> Please let me know what you think folks :-)
> Tomek
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info



Cheers
Nathan

Re: Telnet broken?

[Nathan Hartman]

On Mon, Apr 24, 2023 at 4:54 PM Gregory Nutt  wrote:

>
> > Including the doubling of characters and momentary display of some
> > characters which seem to change rapidly?
>
> That probably comes from NSH.  I think it still sends an escape sequence
> to clear to the end of the line.  So any additional garbage at the end
> after the first four characters would only be present momentarily.
>
> But things are changing rapidly, obviously more rapidly than can be
> tested.  So I would have to studly the nshlib code again to see what it
> is doing today.
>
> So do you think that that last release was too shaky?  Should there be a
> bugfix release for that one?



Unfortunately I wasn't available to test and vote on the most recent
release and I also don't currently know in exactly which commit or PR this
broke, but it is definitely broken now, so if it has been released, then
yes, I think it makes sense to do another release once it's fixed.

I don't know how many people are using the telnet/nsh combination but I
have to do it with this particular board since the only communication port
it has is a network port. When telnet doesn't work correctly it really
messes everything up for me because I can't really interface to it.

Cheers
Nathan

Re: Telnet broken?

[Nathan Hartman]

On Mon, Apr 24, 2023 at 2:06 PM Gregory Nutt  wrote:
>
>
> > $ ./nuttx
> > login: admin
> > password:
> > User Logged-in!
> > nsh> duk
> > ((o) Duktape 2.5.0 (v2.5.0)
> > duk> hheellpp
> Note that only the characters sent from the remote peer and echoed by
> the driver are corrupted.
> > ReferenceError: identifier 'help' undefined
> >  at [anon] (duktape/src-noline/duktape.c:83732) internal
> >  at global (input:1) preventsyield
> > duk>
> Note that the actual received text is correct, only the echo back is wrong.
> > It was caused by recent carry return modifications.
>
> This seems to be the case.

Including the doubling of characters and momentary display of some
characters which seem to change rapidly?

I noticed that in the past we had a CONFIG_TELNET_CHARACTER_MODE (or
similar name). That doesn't seem to exist anymore. Are we expected to
always be in Character Mode? Line Mode? Which?

Thanks,
Nathan

Re: Telnet broken?

[Nathan Hartman]

I am having some trouble understanding how NSH_TELNET is supposed to
work in NuttX now. It used to work for me on real hardware.

I saw that some people had problems because of not synchronized nuttx
and apps repos, because some PRs were merged at different times. My
nuttx and apps are both based on latest master.

Recently (last couple of weeks?) there were some PRs in both repos
related to telnet, CR/LF, CLE, or I don't know what, and the behavior
changed:

Now, when I type, I see double characters, and they get mixed up, and
also seem to change with some delay. For example, if I type 'help':

[[[

$ telnet 192.168.10.100
Trying 192.168.10.100...
Connected to 192.168.10.100.
Escape character is '^]'.

NuttShell (NSH)
nsh> hehehelp

]]]

Typing 'help' and pressing Return does not work: Momentarily I see ^M
when I press Return but it is replaced by duplicated characters of
'help' and the help does not print.

Typing 'help' followed by Ctrl+J instead of Return does work and the
help does print, but there is garbage displayed momentarily.

If I change telnet mode to 'line' instead of 'character', it works
better, but then I see each line of input echoed a second time. For
example, notice how I type 'help' + Return and I see "helphelp usage"
on the next line:

[[[

$ telnet 192.168.10.100
Trying 192.168.10.100...
Connected to 192.168.10.100.
Escape character is '^]'.

NuttShell (NSH)
nsh> ^]
telnet> mode line

nsh> help
helphelp usage:  help [-v] []

. basename  ddexit  ifup  nslookup  set
   uname
[ break delroute  false kill  printfsleep
   umount
? cat   dffree  lspssource
   unset
addroute  cddmesg help  mkdir pwd   test
   uptime
alias cpecho  hexdump   mkrd  rmtime
   usleep
unalias   cmp   env   ifconfig  mount rmdir true
   xd
arp   dirname   exec  ifdownmvroute truncate

Builtin Apps:
telnetdmorsecode  sh ping   tmutil
ostest renew  netcat nsh
nsh>

]]]

If telnet is working for you, what telnet program are you using and
what telnet settings do you have?

Thanks,
Nathan

Re: sched_lock() should be completely removed

[Nathan Hartman]

On Sun, Apr 23, 2023 at 10:22 AM Gregory Nutt  wrote:
> These are internal OS interfaces.  In NuttX, sched_lock() is exported as
> a standard application interface.  That, I think is wrong.  An
> application should not require such an interface, there is no precedent
> in any standard for application control of the pre-emption state, and,
> in fact, I think it is a security issue that we permit this.  Does it
> really make since that any application should be able to just stop the
> scheduler
>
> There are many uses of sched_lock() in apps/ now:

(snip)

> It might be possible to re-design some of these to avoid disabling
> pre-emption.  I am not sure.  We would probably lose some of them  and
> the re-design of the others could be a very complicated job.
>
> OStest, for example, requires sched_lock() to control order of execution
> of threads to set up test cases.  Without sched_lock(), we could not
> test the OS from user space.  OStest has historically used internal OS
> interface in order to implement semi-white-box testing.

Possibly stupid idea: Maybe OStest needs to become part of the OS and
not part of apps?

> My position is:
>
>   * We have to keep sched_lock() as an OS internal interface and retain
> its current behavior.
>   * Re-naming the interface, documenting the interface, doing whatever
> we can to assure proper usage is fine.
>   * I have mixed feelings about removing user access to sched_lock().  I
> think it is the correct thing to do, but I don't know if I would
> like the consequences of that decision.
>
> NOTE: sched_lock() was documented in the past, but that documentation
> was removed from the repository and from general access for some reason:
> https://cwiki.apache.org/confluence/display/NUTTX/User+Guide#schedlock

>From that page:

"Description: This function disables context switching by Disabling
addition of new tasks to the ready-to-run task list. The task that
calls this function will be the only task that is allowed to run until
it either calls sched_unlock (the appropriate number of times) or
until it blocks itself."

I would suggest to add something like: "Interrupts are not disabled,
allowing real-time interrupt response to take place."

Also on that page:

"POSIX Compatibility: This is a NON-POSIX interface. VxWorks provides
the comparable interface:
STATUS taskLock(void);"

I would suggest to add other known similar interfaces that Greg just mentioned:

>   * Linux has pre-empt disable:
> https://www.kernel.org/doc/Documentation/preempt-locking.txt,
> 
> https://elixir.bootlin.com/linux/latest/source/tools/testing/selftests/rcutorture/formal/srcu-cbmc/src/preempt.c#L58
>   * Zephyr has k_sched_lock():
> 
> https://docs.zephyrproject.org/3.0.0/reference/kernel/scheduling/index.html

As we learn of and confirm additional ones from other OSes, we can
continue to add them. Gradually, over time, I recommend to add such
documentation to other interfaces as well. That could help people
migrating from other RTOSes to NuttX.

The file sched/sched/sched_lock.c contains a rather good explanation IMO:

/* Pre-emption is disabled via the interface sched_lock(). sched_lock()
 * works by preventing context switches from the currently executing tasks.
 * This prevents other tasks from running (without disabling interrupts) and
 * gives the currently executing task exclusive access to the (single) CPU
 * resources. Thus, sched_lock() and its companion, sched_unlock(), are
 * used to implement some critical sections.
 *
 * In the single CPU case, pre-emption is disabled using a simple lockcount
 * in the TCB. When the scheduling is locked, the lockcount is incremented;
 * when the scheduler is unlocked, the lockcount is decremented. If the
 * lockcount for the task at the head of the g_readytorun list has a
 * lockcount > 0, then pre-emption is disabled.
 *
 * No special protection is required since only the executing task can
 * modify its lockcount.
 */

#ifdef CONFIG_SMP
/* In the multiple CPU, SMP case, disabling context switches will not give a
 * task exclusive access to the (multiple) CPU resources (at least without
 * stopping the other CPUs): Even though pre-emption is disabled, other
 * threads will still be executing on the other CPUS.
 *
 * There are additional rules for this multi-CPU case:
 *
 * 1. There is a global lock count 'g_cpu_lockset' that includes a bit for
 *each CPU: If the bit is '1', then the corresponding CPU has the
 *scheduler locked; if '0', then the CPU does not have the scheduler
 *locked.
 * 2. Scheduling logic would set the bit associated with the cpu in
 *'g_cpu_lockset' when the TCB at the head of the g_assignedtasks[cpu]
 *list transitions has 'lockcount' > 0. This might happen when
 *sched_lock() is called, or after a context switch that changes the
 *TCB at the head of the g_assignedtasks[cpu] list.
 * 3. Similarly, the cpu bit in the global 'g_cpu_lockset' would be cleared
 *

Re: [Breaking change] Move nxmutex to sched

[Nathan Hartman]

On Tue, Apr 18, 2023 at 8:52 AM spudaneco  wrote:

> Perhaps you could use accessor functions to read/write 8, 16 32, 64 bit
> values.  Each scalar value will be properly aligned and, hence, will lie
> within a page.



And those accessor functions could be macros in FLAT builds where functions
are not required, so no memory or code size increase.

Cheers
Nathan

Re: V NuttX International Workshop

[Nathan Hartman]

On Sun, Apr 16, 2023 at 9:44 AM Alan C. Assis  wrote:

> On 4/15/23, Tomek CEDRO  wrote:
> > On Fri, Apr 14, 2023 at 4:03 PM Alan C. Assis wrote:
> >> Hi Everyone,
> >> We have confirmed the data/local of 5o NuttX Workshop:
> >
> > Is online attendance possible / desired? :-)
> >
>
> Good question, the first event in Gouda/Netherlands was physical-only.
>
> We need to know how to make this real-virtual to work!
>
>  As you know the metaverse is not working to happen as
> soon as we supposed :-) 
>
> BTW, we will try to conciliate both expectations.
>
> BR,
>
> Alan
>

Perhaps the simplest low-tech way is to video tape the presentations and
post the videos online afterwards.

In fact, not only will this make it possible to see the event for people
who can't attend, but it will also become possible to refer back to the
presentations for people who do attend, and can be added to our online
video repertoire for people who discover NuttX in the future.

So, if it is possible , I hope the presentations can be video taped and put
online.

Cheers
Nathan

Re: Hardcoded Pin mux, pad control and Drive Strength (AKA Slew-rate and Frequency) Settings #1570

[Nathan Hartman]

@davids5, I saw the request on GitHub for help with the STM32G families but
unfortunately something has come up and I won't be able to work on it this
week. Hopefully someone else can volunteer, otherwise I'll try to help next
week...

Thanks,
Nathan

On Tue, Apr 11, 2023 at 7:58 AM David Sidrane 
wrote:

> @slorquet Please have a look at #8992. Let me know if it addresses all the
> concerns you have.
>
> -Original Message-
> From: Sebastien Lorquet 
> Sent: Friday, April 7, 2023 9:58 AM
> To: dev@nuttx.apache.org
> Subject: Re: Hardcoded Pin mux, pad control and Drive Strength (AKA
> Slew-rate and Frequency) Settings #1570
>
> Thanks for the notification.
>
> Your proposal is mostly OK for me, I hope others will send reactions too. I
> have just one concern.
>
>
> If I attempt to rephrase the proposal: Starting from a commit in a
> future, stm32h7 GPIO definitions will not include speed indications
> anymore, and these will have to be added manually in board.h, but ONLY
> if the LEGACY_PINMAP is not set?
>
>
> Here is my concern: What will happen if a user (me, probably) builds a
> NuttX with this new commit from a full stored defconfig, but does not
> regenerate its config prior to rebuilding ? the LEGACY_PINMAP setting
> will not be present when building in that case.
>
> Can we force a config update before starting the build, so the
> LEGACY_PINMAP setting will be set to Y automatically in all cases?
>
>
> Also, this has to be documented very clearly, not just the official
> release notes for the next release!
>
> Aditionnally, if LEGACY_PINMAP is set in user config, maybe we can add a
> compile time warning in stm32h7/stm32_gpio.c that in the future, users
> are required to update their board.h and once done, disable LEGACY_PINMAP ?
>
> Sebastien
>
>
> Le 07/04/2023 à 15:34, David Sidrane a écrit :
> > Opening the discussion for this issue on the list. See
> > https://github.com/apache/nuttx/issues/1570
> >
> >
> >
> > I would like to get feedback on the approach see if we can move forward
> on
> > this.
> >
> >
> >
> >
> >
> > While some solutions were discussed in
> >
> > - Revert "stm32h7 sdmmc: set SDMMC_CK pin to high speed (50 MHz)
> > mode."
> >  #5012 
> >
> > I would like to propose a solution for this issue as a request for
> > comment:
> >
> > 1. That will not affect any existing boards
> > 2. Will allow us to fix the issues without forcing massive changes.
> > 3. Eventually after N more releases of NuttX deprecate the solution.
> >
> > Steps to get there:
> >
> > 1. Kconfig for all effected arches will have
> > STM32xxx_USE_LEGACY_PINMAP
> > set to yes as a default.
> > 2. Rework top level pinmap files E.G. hardware/stm32_pinmap.h.
> > 3. The current pinmap file will be renamed with _legacy E.G.
> > hardware/stm32h7x3xx_pinmap_legacy.h
> > 4. Rework chip specific files removing speeds and adding _0 to the
> > previous no-selectable pins with speeds
> > 5. Rework chip specific files adding _0 to the previous no-selectable
> > pins
> >
> > The hardware/stm32_pinmap.h will have the following structure
> >
> > #if defined(STM32H7_USE_LEGACY_PINMAP )
> >
> > #  if defined(CONFIG_STM32H7_STM32H7X3XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap_legacy.h"
> >
> > #  elif defined(CONFIG_STM32H7_STM32H7X7XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap_legacy.h"
> >
> > #  else
> >
> > # error "Unsupported STM32 H7 Legacy Pin map"
> >
> > #  endif
> >
> > #else
> >
> > #  if defined(CONFIG_STM32H7_STM32H7X3XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap.h"
> >
> > #  elif defined(CONFIG_STM32H7_STM32H7X7XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap.h"
> >
> > #  else
> >
> > # error "Unsupported STM32 H7 Pin map"
> >
> > #  endif
> >
> > # endif
> >
> >
> >
> > Moving forward boards will turn off STM32xx_USE_LEGACY_PINMAP and update
> > the board.h files to fully define
> > the pins with selected speeds.
> >
> > was:
> >
> > #define GPIO_SDMMC2_CK   GPIO_SDMMC2_CK_1  /* PD6  FC_PD6_SDMMC2_CK  */
> >
> > #define GPIO_SDMMC2_CMD  GPIO_SDMMC2_CMD_1 /* PD7  FC_PD7_SDMMC2_CMD */
> >
> > //  GPIO_SDMMC2_D0   No Remap  /* PB14 FC_PB14_SDMMC2_D0 */
> >
> > //  GPIO_SDMMC2_D1   No Remap  /* PB15 FC_PB15_SDMMC2_D1 */
> >
> > #define GPIO_SDMMC2_D2   GPIO_SDMMC2_D2_1  /* PG11 FC_PG11_SDMMC2_D2 */
> >
> > //  GPIO_SDMMC2_D3No Remap /* PB4  FC_PB4_SDMMC2_D3  */
> >
> > is:
> >
> > #define GPIO_SDMMC2_CK   (GPIO_SDMMC2_CK_1|  GPIO_SPEED_25MHz)  /*
> > PD6  FC_PD6_SDMMC2_CK  */
> >
> > #define GPIO_SDMMC2_CMD  (GPIO_SDMMC2_CMD_1 |  GPIO_SPEED_2MHz)  /*
> > PD7  FC_PD7_SDMMC2_CMD */
> >
> > #define GPIO_SDMMC2_D0   (GPIO_SDMMC2_D0_0  | GPIO_SPEED_2MHz) /* PB14
> > FC_PB14_SDMMC2_D0 */
> >
> > #define GPIO_SDMMC2_D1   (GPIO_SDMMC2_D1_0  |  GPIO_SPEED_2MHz)/* PB15
> > FC_PB15_SDMMC2_D1 */
> >
> > #define GPIO_SDMMC2_D2

Re: Hardcoded Pin mux, pad control and Drive Strength (AKA Slew-rate and Frequency) Settings #1570

[Nathan Hartman]

On Fri, Apr 7, 2023 at 9:58 AM Sebastien Lorquet 
wrote:

> Thanks for the notification.
>
> Your proposal is mostly OK for me, I hope others will send reactions
> too. I have just one concern.
>
>
> If I attempt to rephrase the proposal: Starting from a commit in a
> future, stm32h7 GPIO definitions will not include speed indications
> anymore, and these will have to be added manually in board.h, but ONLY
> if the LEGACY_PINMAP is not set?
>
>
> Here is my concern: What will happen if a user (me, probably) builds a
> NuttX with this new commit from a full stored defconfig, but does not
> regenerate its config prior to rebuilding ? the LEGACY_PINMAP setting
> will not be present when building in that case.
>
> Can we force a config update before starting the build, so the
> LEGACY_PINMAP setting will be set to Y automatically in all cases?
>
>
> Also, this has to be documented very clearly, not just the official
> release notes for the next release!
>
> Aditionnally, if LEGACY_PINMAP is set in user config, maybe we can add a
> compile time warning in stm32h7/stm32_gpio.c that in the future, users
> are required to update their board.h and once done, disable LEGACY_PINMAP ?
>
> Sebastien



I am okay with this and have substantially the same remarks as Sebastien.

We should be careful to document it in the release notes, and I have some
(still vague) idea how to help people notice this change (and future
breaking changes) if they build from a stored full defconfig (meaning a
saved .config):

Could we add a Kconfig setting that in some way identifies the version of
NuttX with which it was created? The idea is that if you load a full
defconfig from an earlier release, you could get a build-time warning about
breaking changes that happened since that release. Each time we add a
breaking change, we would encode/document it in some kind of file that
encodes all such breaking changes (at least starting with the release where
this feature is introduced) along with logic what to check for each
breaking change...

So for an example related to STM32 GPIO pin speeds, you load an old saved
full .config and try to build with it, and if the config was created with a
NuttX version older than X.Y and the arch is STM32 and
STM32xx_USE_LEGACY_PINMAP is not set, then the build would output a
warning: "Warning: You may need to update your board.h to specify GPIO pin
speeds. See PR #." or something like that.

Just an idea to consider...

Nathan

Re: os_test failure - Improper use of semaphores?

[Nathan Hartman]

On Tue, Apr 4, 2023 at 5:53 PM Gregory Nutt  wrote:

>
> On 4/4/2023 3:43 PM, Fotis Panagiotopoulos wrote:
> > I drafted this change here:
> >
> > https://github.com/apache/nuttx/pull/8965
> >
> > Have a look, please.



PR 8965 looks good to me. In fact I had the exact same garbage access
problem with some in-house software (not related to NuttX) and the solution
was basically exactly the same.

Good catch on the error and the fix!

Cheers,
Nathan