You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Matteo Golin <ma...@gmail.com> on 2025/05/08 16:21:53 UTC
USB console issues
Hello,
I am working on making an application run on the W5500-EVB RP2040 boards on its own instead of via NSH. I've noticed
that the moment I turn off the USB console option (i.e. I don't use boardctl to start the USB driver and duplicate the
file descriptor as 0, 1 and 2), the application no longer functions (it should connect to something over the network and
it doesn't). I'm suspicious that it is hanging on printf statements because it no longer has a stdout to write to?
Any suggestions to just have fprintf and printf statements ignored so that the application can run normally just without
console output?
Alternatively I wouldn't mind keeping the USB device driver as an option, but I've noticed that if it is not plugged
into a receiving computer the program hangs as well. It seems like it requires some receiving device in order to
continue outputting. Is there a way I can make it non-blocking?
Thank you for your help,
--
Matteo Golin
Re: USB console issues
Posted by Matteo Golin <ma...@gmail.com>.
It appears that is working, however I'm dealing with some side-effect where
the GPIO interrupt devices I am registering (/dev/gpio<n>) are not being
created when I disable the USB console. I'm reading debug information out
of the I do have CONFIG_DEV_GPIO enabled so this is odd. I'll have to
investigate further.
Thanks for your help!
Matteo
On Thu, May 8, 2025 at 11:40 PM Xiang Xiao <xi...@gmail.com>
wrote:
> Do you have dev/null? nuttx could fallback /dev/null if you disable
> console:
>
> https://github.com/apache/nuttx/blob/master/sched/group/group_setupidlefiles.c#L79
>
> On Fri, May 9, 2025 at 12:22 AM Matteo Golin <ma...@gmail.com>
> wrote:
>
> > Hello,
> >
> > I am working on making an application run on the W5500-EVB RP2040 boards
> > on its own instead of via NSH. I've noticed
> > that the moment I turn off the USB console option (i.e. I don't use
> > boardctl to start the USB driver and duplicate the
> > file descriptor as 0, 1 and 2), the application no longer functions (it
> > should connect to something over the network and
> > it doesn't). I'm suspicious that it is hanging on printf statements
> > because it no longer has a stdout to write to?
> >
> > Any suggestions to just have fprintf and printf statements ignored so
> that
> > the application can run normally just without
> > console output?
> >
> > Alternatively I wouldn't mind keeping the USB device driver as an option,
> > but I've noticed that if it is not plugged
> > into a receiving computer the program hangs as well. It seems like it
> > requires some receiving device in order to
> > continue outputting. Is there a way I can make it non-blocking?
> >
> > Thank you for your help,
> >
> > --
> > Matteo Golin
> >
>
Re: USB console issues
Posted by Xiang Xiao <xi...@gmail.com>.
Do you have dev/null? nuttx could fallback /dev/null if you disable console:
https://github.com/apache/nuttx/blob/master/sched/group/group_setupidlefiles.c#L79
On Fri, May 9, 2025 at 12:22 AM Matteo Golin <ma...@gmail.com> wrote:
> Hello,
>
> I am working on making an application run on the W5500-EVB RP2040 boards
> on its own instead of via NSH. I've noticed
> that the moment I turn off the USB console option (i.e. I don't use
> boardctl to start the USB driver and duplicate the
> file descriptor as 0, 1 and 2), the application no longer functions (it
> should connect to something over the network and
> it doesn't). I'm suspicious that it is hanging on printf statements
> because it no longer has a stdout to write to?
>
> Any suggestions to just have fprintf and printf statements ignored so that
> the application can run normally just without
> console output?
>
> Alternatively I wouldn't mind keeping the USB device driver as an option,
> but I've noticed that if it is not plugged
> into a receiving computer the program hangs as well. It seems like it
> requires some receiving device in order to
> continue outputting. Is there a way I can make it non-blocking?
>
> Thank you for your help,
>
> --
> Matteo Golin
>