poll stdin

cancel
Showing results for 
Search instead for 
Did you mean: 

poll stdin

664 Views
adyr
Contributor V

I'm using KDS 3.0 with KSDK 1.2 and MQX built with IAR.

I want to poll the stdin port to see if a character has been received so I can process code in a loop until the user presses a key in the console. I am using the shell to launch the code hence why I'm using stdin rather than other methods to access the ports.

 

So far the only way I can find to do this is to modify the nio_tty.c file so the nio_tty_ioctll function supports IO_IOCTL_CHAR_AVAIL as follows:

        case IOCTL_ABORT:

            retval = _nio_vioctl(devc->fd, error, IOCTL_ABORT, ap);

            break;

          //Added support for checking if characters are available

        case IO_IOCTL_CHAR_AVAIL:

            retval = _nio_vioctl(devc->fd, error, IO_IOCTL_CHAR_AVAIL, ap);

            break;

 

Then in my code I can use:

  if ((_nio_ioctl( stdin->_FD, &err, IO_IOCTL_CHAR_AVAIL, &cnt ) == 0) && (cnt > 0) && (fgetc( stdin ) == 27 ))

  {

   break;

  }

 

Have I missed another currently supported method or can this be added to the KSDK / MQX by freescale in the next update?

 

Best regards,
Adrian.

Labels (1)
0 Kudos
6 Replies

182 Views
Carlos_Musich
NXP Employee
NXP Employee

Hi Adrian,

You may use the KSDK1.2 UART driver. Please see attached KDS project, you may reproduce the same on IAR.

Note that I commented out line 283 in init_bsp.c. I did this to avoid MQX initializing UART0 and to be able to use the KSDK driver.

In main.c you can see and infinite 'while' loop with another 'while' instruction waiting to receive a character. You may change it for an 'if' statement

I hope it helps,

Regards,

Carlos

0 Kudos

182 Views
adyr
Contributor V

Thanks for taking the time to reply Carlos but unfortunately I need to use stdin as I am using the shell code. I have a shell command that needs to output data until the user presses ESC.

It would be nice if the shell could use KSDK UART instead of nio drivers as I'm sure it would be a lot more efficient but less flexible, as in harder to switch to Telnet, etc.

I also wanted to implement an X Modem protocol to send files to my board via the shell but the nio drivers convert \r\n to \n so the number of characters received and check sum are incorrect. Maybe I just need to rewrite the shell :-).

0 Kudos

182 Views
stevepye
Contributor I

I don't know if you're still facing this, but here's a slightly different (not necessarily the nicest) way to allow for polled console input non-blocking:

MQX_FILE_PTR stdInFilePtr = (MQX_FILE_PTR)_io_get_handle(IO_STDIN);

/* Make stdin non-blocking */

stdInFilePtr->FLAGS |= IO_SERIAL_NON_BLOCKING;

/* Poll for a hit key */

b = getchar();

if (b != IO_EOF)

{

/* Interrogate the character */

switch (b)

{

...

...

/* Set the console back to blocking I/O before returning */

stdInFilePtr->FLAGS &= ~IO_SERIAL_NON_BLOCKING;

Or, instead of accessing the flags directly, a 'cleaner' approach to enable/disable blocking console I/O is with ioctl(), e.g

ioctl(stdin, IO_IOCTL_SERIAL_GET_FLAGS, (void *)&flags);

flags |= IO_SERIAL_NON_BLOCKING;

ioctl(stdin, IO_IOCTL_SERIAL_SET_FLAGS, (void *)&flags);

0 Kudos

182 Views
adyr
Contributor V

Hi Steve,

Thanks for taking the time to reply. Unfortunately I can find no references to IO_SERIAL_NON_BLOCKING in the KSDK 1.3. I can find it in the old MQX 4.1 folder but it appears to have been completely removed from the KSDK, apart from a few old examples where it is exclude by other #defines.

Stepping through the code I can see no options to make the getchar or any other similar call to be non-blocking. So adding the three lines of code to nio_tty.c I mentioned above is the simplest way and has no side effects on existing code.

Best regards,

Adrian.

0 Kudos

182 Views
DavidS
NXP Employee
NXP Employee

Hi Adrian,

Not sure I am helping or confusing things.

With KSDK and MQX, the peripheral drivers are totally different as well as the API and implementation.

The KSDK_1.3 does have baremetal examples of using the UART in different modes:

- uart_blocking

- uart_edma_blocking

- uart_edma_non_blocking

- uart_non_blocking

- uart_polling

Look in C:\Freescale\KSDK_1.3.0\examples\frdmk64f\driver_examples\uart

Since MQX is using the KSDK peripheral drives you should be able to pick and choose. My assumption as I haven't been playing with it specifically (yet).

Regards,

David

0 Kudos

182 Views
adyr
Contributor V

Hi David,

My project is created with KDS 3.0 / KSDK 1.3 and I have selected the MQX_KSDK option of the os_abstraction component. I'm then using the MQX shell on the stdio (nio) port. So although this nio port ends up using the KSDK fsl_uart driver it has the nio driver on top of it which reads the data from the UART and puts it in it's own buffer, etc. So I don't really have access to the underlying KSDK driver without making even bigger changes to the nio drivers.

In one of my shell functions I want to be able to abort it when the user presses the ESC key so, as far as I can see, this has to be done within the nio drivers.

In other parts of my code where I use other UARTs I do use the KSDK drivers directly but with the stdio port I think I am unable to do that.

I'm not sure if that explains my situation better and why I think that adding support for IO_IOCTL_CHAR_AVAIL into the nio_tty is the simplest solution.

Or maybe in the next KSDK / MQX release the nio drivers could be by-passed completely so getchar and printf, etc. would directly access the KSDK drivers but I guess that would have a lot more problems.

Best regards,

Adrian.

0 Kudos