Re: stdout
Hello
That fflush is for fgets
Yes, with a stdout flush, message prints but the question remains about why
is it needed and how can I get input echo
Thanks
Grr
El lun, 25 ene 2021 a las 13:30, Ken Pettit () escribió:
> Hey Grr,
>
> You need the fflush(stdout) call to be *after* the printf("\nEnter
> Command:").
>
> If the printf doesn't end with \n, then the stdout won't be flushed.
>
> Ken
>
> On 1/25/21 11:25 AM, Grr wrote:
> > Hello to all
> >
> > Is there a way to get stdout without a LF?
> >
> > I have something like
> >
> > case INPUT_CMD:
> >fflush(stdin);
> >printf("\nEnter Command:");
> >fgets(input, INPUT_STRING, stdin);
> >spitest.cmd = input[0]; /* First char is the command
> */
> >
> > that in Linux prints message and waits for input but in Nuttx shows
> nothing.
> >
> > I don't want LF because that destroys the format I want for program
> > interface
> >
> > Another related issue is I don't get echo from input
> >
> > How do I get messages printed without a LF and echo from input?
> >
> > TIA
> >
> > Grr
> >
>
>
Re: NuttX: big accomplishment and next steps
On Fri, Jan 22, 2021 at 3:16 AM wrote: > > Hi Nathan, > > Count me in > > Regards > Alin On Sat, Jan 23, 2021 at 7:51 AM Xiang Xiao wrote: > Nathan, thanks for raising the proposal. > We want to join the license clearing effort and will resolve some > engineer resource for it in this year. Thank you to Alin and Xiang for responding! It really is important that we make progress on license clearing to help us graduate from the Incubator. We need to follow some kind of simple plan. In my opinion, if we have an automated way to scan through all the files and convert all files that we have ICLAs/SGAs for all contributors, then we will convert many files in bulk. I don't know if that will be 50 files or 50,000 files, but I think that would be a good first step, especially if we can do it relatively quickly. It will make a big first progress on the job and also make everyone feel better about this big task. A few months ago, Matias wrote some scripts that are in a draft PR [1]. I think this is the first avenue we should explore. It looks like those scripts should be able to knock out that first step. Perhaps we shouldn't plan too far ahead, but if we can do this first step, then we will know which files have a more complicated situation and we can decide how to proceed. WDYT? [1] https://github.com/apache/incubator-nuttx/pull/1834 Cheers, Nathan
Re: stdout
Grr,
Yeah, in Nuttx, fgets, fgetc, etc. don't echo. Even in Linux, the echo
is actually a function of the terminal, not the running program and
'fgets'.
In Nuittx, use the readline routine instead. But keep in mind that
readline is only *inspired* by GNU readline and has different calling
parameters (you also have to ensure it is enabled / configured in 'make
menuconfig':
#include
my_get_command(struct spitest_s *spitest)
{
charinput[80];
ssize_t len = 0;
while (len == 0)
{
printf("\nEnter Command:");
fflush(stdout);
len = readline(input, sizeof(input), stdin, stdout);
if (len)
{
spitest->cmd = input[0]; /* First char is the command */
...
}
}
...
}
Ken
On 1/26/21 3:54 AM, Grr wrote:
Hello
That fflush is for fgets
Yes, with a stdout flush, message prints but the question remains about why
is it needed and how can I get input echo
Thanks
Grr
El lun, 25 ene 2021 a las 13:30, Ken Pettit () escribió:
Hey Grr,
You need the fflush(stdout) call to be *after* the printf("\nEnter
Command:").
If the printf doesn't end with \n, then the stdout won't be flushed.
Ken
On 1/25/21 11:25 AM, Grr wrote:
Hello to all
Is there a way to get stdout without a LF?
I have something like
case INPUT_CMD:
fflush(stdin);
printf("\nEnter Command:");
fgets(input, INPUT_STRING, stdin);
spitest.cmd = input[0]; /* First char is the command
*/
that in Linux prints message and waits for input but in Nuttx shows
nothing.
I don't want LF because that destroys the format I want for program
interface
Another related issue is I don't get echo from input
How do I get messages printed without a LF and echo from input?
TIA
Grr
Re: stdout
Grr,
Slightly revised version to remove trailing '\n', just for completenes. :)
my_get_command(struct spitest_s *spitest)
{
charinput[80];
ssize_t len = 0;
while (len == 0)
{
printf("\nEnter Command:");
fflush(stdout);
len = readline(input, sizeof(input), stdin, stdout);
if (len && input[len-1] == '\n')
{
input[--len] = 0;
}
if (len)
{
spitest->cmd = input[0]; /* First char is the command */
...
}
}
...
}
Ken
On 1/26/21 7:16 AM, Ken Pettit wrote:
Grr,
Yeah, in Nuttx, fgets, fgetc, etc. don't echo. Even in Linux, the
echo is actually a function of the terminal, not the running program
and 'fgets'.
In Nuittx, use the readline routine instead. But keep in mind that
readline is only *inspired* by GNU readline and has different calling
parameters (you also have to ensure it is enabled / configured in
'make menuconfig':
#include
my_get_command(struct spitest_s *spitest)
{
charinput[80];
ssize_t len = 0;
while (len == 0)
{
printf("\nEnter Command:");
fflush(stdout);
len = readline(input, sizeof(input), stdin, stdout);
if (len)
{
spitest->cmd = input[0]; /* First char is the command */
...
}
}
...
}
Ken
On 1/26/21 3:54 AM, Grr wrote:
Hello
That fflush is for fgets
Yes, with a stdout flush, message prints but the question remains
about why
is it needed and how can I get input echo
Thanks
Grr
El lun, 25 ene 2021 a las 13:30, Ken Pettit ()
escribió:
Hey Grr,
You need the fflush(stdout) call to be *after* the printf("\nEnter
Command:").
If the printf doesn't end with \n, then the stdout won't be flushed.
Ken
On 1/25/21 11:25 AM, Grr wrote:
Hello to all
Is there a way to get stdout without a LF?
I have something like
case INPUT_CMD:
fflush(stdin);
printf("\nEnter Command:");
fgets(input, INPUT_STRING, stdin);
spitest.cmd = input[0]; /* First char is the command
*/
that in Linux prints message and waits for input but in Nuttx shows
nothing.
I don't want LF because that destroys the format I want for program
interface
Another related issue is I don't get echo from input
How do I get messages printed without a LF and echo from input?
TIA
Grr
Re: stdout
On 2021-01-26 16:16, Ken Pettit wrote: Grr, Yeah, in Nuttx, fgets, fgetc, etc. don't echo. Even in Linux, the echo is actually a function of the terminal, not the running program and 'fgets'. It is actually not a function of the terminal, but the terminal (serial) device driver. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: stdout
Ken: Thanks a lot for your code. I will try it I was researching that echo thing and yes, that's a terminal device driver thing. More exactly, c_lflag of termios struct. Problem is I haven't found yet where that is set in the serial terminal setup sequence El mar, 26 ene 2021 a las 11:28, Johnny Billquist () escribió: > On 2021-01-26 16:16, Ken Pettit wrote: > > Grr, > > > > Yeah, in Nuttx, fgets, fgetc, etc. don't echo. Even in Linux, the echo > > is actually a function of the terminal, not the running program and > > 'fgets'. > > It is actually not a function of the terminal, but the terminal (serial) > device driver. > >Johnny > > -- > Johnny Billquist || "I'm on a bus >|| on a psychedelic trip > email: b...@softjar.se || Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol >
limitation in SIGEV_THREAD?
Hi, working with nimBLE I found that I had an issue when scheduling a callback to be made from within the signal handler for a timer, which was set with SIGEV_THREAD. The issue was that I was pushing to a POSIX queue from within the handler, and it was failing with BADFD. From debugging I realized that when trying to obtain the inode for the queue it was looking up at the open file descriptors from the lpwork thread, which of course would not share open file descriptors with main task. Since this is working for Linux (I had copied this part of the porting layer from Linux) my reasoning is that SIGEV_THREAD is there implemented as a thread that is a child of the process which registered the signal handler and thus shares the open file descriptors. In NuttX this is implemented via a work queue so this is not the case. Is my reading correct? If so, it may be worth adding this limitation to https://github.com/apache/incubator-nuttx/issues/1352 Best, Matias
Re: limitation in SIGEV_THREAD?
Yes, you are right. Perhaps this could be added to https://github.com/apache/incubator-nuttx/issues/1352 That is a different issue description but might still be a good location because both issues have the same solution. The solution to both issues is to enhance the OS by adding a new OS facility to start a pthread from within OS just as if pthread_create() were called from that application task. That is not really that difficult. The SIGEV_THREAD logic would then run on that pthread. This same facility is also needed to correct the implementation of the AIO APIs. They also should run on pthreads as well. However, I am not aware of any functional shortcoming of the current AIO implementation that would justify the change. The only unattractive thing about this solution is that is does require more resources and is less efficient in general. Greg On 1/26/2021 4:26 PM, Matias N. wrote: Hi, working with nimBLE I found that I had an issue when scheduling a callback to be made from within the signal handler for a timer, which was set with SIGEV_THREAD. The issue was that I was pushing to a POSIX queue from within the handler, and it was failing with BADFD. From debugging I realized that when trying to obtain the inode for the queue it was looking up at the open file descriptors from the lpwork thread, which of course would not share open file descriptors with main task. Since this is working for Linux (I had copied this part of the porting layer from Linux) my reasoning is that SIGEV_THREAD is there implemented as a thread that is a child of the process which registered the signal handler and thus shares the open file descriptors. In NuttX this is implemented via a work queue so this is not the case. Is my reading correct? If so, it may be worth adding this limitation to https://github.com/apache/incubator-nuttx/issues/1352 Best, Matias
Re: limitation in SIGEV_THREAD?
Thanks, I'll add a comment on that issue for reference. On Tue, Jan 26, 2021, at 20:12, Gregory Nutt wrote: > Yes, you are right. Perhaps this could be added to > https://github.com/apache/incubator-nuttx/issues/1352 > > That is a different issue description but might still be a good location > because both issues have the same solution. The solution to both issues > is to enhance the OS by adding a new OS facility to start a pthread from > within OS just as if pthread_create() were called from that application > task. That is not really that difficult. The SIGEV_THREAD logic would > then run on that pthread. > > This same facility is also needed to correct the implementation of the > AIO APIs. They also should run on pthreads as well. However, I am not > aware of any functional shortcoming of the current AIO implementation > that would justify the change. > > The only unattractive thing about this solution is that is does require > more resources and is less efficient in general. > > Greg > > On 1/26/2021 4:26 PM, Matias N. wrote: > > Hi, > > working with nimBLE I found that I had an issue when scheduling a callback > > to be made from within the signal handler for a timer, which was set with > > SIGEV_THREAD. The issue was that I was pushing to a POSIX queue from within > > the handler, and it was failing with BADFD. From debugging I realized that > > when trying to obtain the inode for the queue it was looking up at the open > > file descriptors from the lpwork thread, which of course would not share > > open file descriptors with main task. > > > > Since this is working for Linux (I had copied this part of the porting > > layer from Linux) my reasoning is that SIGEV_THREAD is there implemented as > > a thread that is a child of the process which registered the signal handler > > and thus shares the open file descriptors. In NuttX this is implemented via > > a work queue so this is not the case. > > > > Is my reading correct? If so, it may be worth adding this limitation to > > https://github.com/apache/incubator-nuttx/issues/1352 > > > > Best, > > Matias >
