Hello everyone,
Currently working on an application for a network controlled switch box. So far
everything has gone great and we've
finally completed our application that is capable of sending switch commands
over the network using NuttX on the
W5500-EVB Pico.
I have one last hurdle left for th
Yup :-)
When PR has Documentation/ updates a CI build-html action is triggered
for verification.
Documentation build and publish is done daily by CI from master. If
you need faster update just ask and we can trigger that action
manually :-)
Take care :-)
Tomek
On Thu, May 1, 2025 at 1:14 AM Ma
Hello,
To my knowledge, the documentation website as whole is updated whenever a
change is made to the docs, up to once (or maybe twice?) a day via a CI/CD
pipeline. I don't know if there are any automated changes made to the
documentation, but that is the workflow when a PR is made by a developer
I saw some open projects for Nuttx at GSoC 2025.
I am interested in project on spe SPIMAC support.
Can anyone contact me further for that?
Regards,
Ujjval
Hi all,
Could someone please let me know how frequently the documentation at
https://nuttx.apache.org/docs/latest/index.html is updated?
Is there any CI/CD pipeline involved in this process (e.g., a GitHub
Action)?
Thanks in advance,
Rodrigo
On 30/04/2025 16:36, Karel Kočí wrote:
There are actually two ways. One for just application, but you probably know
that (`openlog("", LOG_PERROR, LOG_USER)`)
openlog is not supported in NuttX it seems. Sigh.
On 30/04/2025 16:36, Karel Kočí wrote:
On Wed 30 Apr 2025 03:45:36 PM , Tim Hardisty wrote:
I think that this system already exists and is the syslog.
I cannot find anywhere to configure NuttX syslog to send output to
stdout or stderr
...configure system itself to send syslog output to
On Wed 30 Apr 2025 03:45:36 PM , Tim Hardisty wrote:
> >> I think that this system already exists and is the syslog.
>
> I cannot find anywhere to configure NuttX syslog to send output to
> stdout or stderr...I am sure it is my inexperience but not being able to
> do is in part what drove m
See inline.
On 30/04/2025 14:26, Karel Kočí wrote:
Hi,
On Wed 30 Apr 2025 12:19:02 PM , Tim Hardisty wrote:
5. One issue I have with NXboot is lack of printf-type error/info
messages
I think that this system already exists and is the syslog.
I cannot find anywher
Hi,
On Wed 30 Apr 2025 12:19:02 PM , Tim Hardisty wrote:
>
> I already have a board .ld file with a relevant Kconfig setting (along the
> lines of CONFIG_BOARDNAME_RAM_START) that is used:
>
> 1. to denote the sdram start to the loader (but it is usually hard coded so
> no
> big deal
Hi,
On Wed 30 Apr 2025 12:19:02 PM , Tim Hardisty wrote:
>
> I already have a board .ld file with a relevant Kconfig setting (along the
> lines of CONFIG_BOARDNAME_RAM_START) that is used:
>
> 1. to denote the sdram start to the loader (but it is usually hard coded so
> no
> big deal
Thanks Karel.
See below, inline.
On 30/04/2025 11:06, Karel Kočí wrote:
4. MCUboot - for example - does the copy to RAM itself so, as has been
suggested, it would be good if NXboot gains this too. It will need
the destination RAM address for this which could:
* either be via
Hi,
On Wed 30 Apr 2025 10:28:56 AM , Tim Hardisty wrote:
> OK...here's my thinking this morning - from my point of view/my use
> case/but hopefully universally applicable:
>
> 1. I realise there is no need for the bootloader process, in kernel
> space, to know the details of the image vers
OK...here's my thinking this morning - from my point of view/my use
case/but hopefully universally applicable:
1. I realise there is no need for the bootloader process, in kernel
space, to know the details of the image version.
2. NXboot always calls so won't change that in any
way, but t
14 matches
Mail list logo
