UART interrupt handler

Kira,

I think you're missing something here. A UART device driver is provided so that if you wish to send or receive characters over the uart you just use the standard C library calls putc, printf or any of those functions, for receiving you can use getc, scanf etc. see http://sources.redhat.com/newlib/libc.html (http://sources.redhat.com/newlib/libc.html) for the documentation.

You should not really be using the functions in the uart driver directly, unless you wish to re-write the driver, if so why?

I think the best thing you can do now is open the system library that the Nios II IDE should have generated for you. If you look in there, you'll see the alt_sys_init code, and the system.h file that defines all the stuff you need to know about your SOPC design.

If you look at the properties of your system library, you'll find a page which shows which UART that stdin/out/err are connected to. If that's the UART you want to talk to, then you can just use the standard POSIX routines printf, scanf, putc, getc, etc. to talk to the UART.

If that's not the UART you want to talk to, you can get its name from system.h. There should be a line like:

#define MY_UART_NAME "/dev/my_uart"

and you would then use MY_UART_NAME as a filename to pass to open(), close(), read(), write(), etc.

If you're dead set on reinventing the wheel, and absolutely must write your own interrupt handlers/drivers/everything else, you want to name your main function as "alt_main" and not "main". This skips all the interrupt setup, alt_sys_init, etc. and it becomes your problem to write.

--- Quote Start ---

originally posted by rugbybloke@Oct 19 2004, 10:29 AM

kira,

i think you're missing something here. a uart device driver is provided so that if you wish to send or receive characters over the uart you just use the standard c library calls putc, printf or any of those functions, for receiving you can use getc, scanf etc. see http://sources.redhat.com/newlib/libc.html (http://sources.redhat.com/newlib/libc.html) for the documentation.

you should not really be using the functions in the uart driver directly, unless you wish to re-write the driver, if so why?

--- Quote End ---

The supplied uart driver does not have all the functions we need, so that's why we've had to tackle it.

1/ Enable ioctl in small driver with ALTERA_AVALON_UART_USE_IOCTL compile flag.

2/ ioctl termios flags for expanding newlines to cr-lf and echoing input characters.

3/ Flush output buffer

4/ XON-XOFF

5/ Check for received character without reading it.

6/ Get a hook to drop RTS after the buffer transmit empties (half-duplex turnaround)

scanf requires the full 70k newlib. It would be nice to have finer control over the library build so functions like this can be selectively brought in. scanf and all the above are needed to port the console interface from 8- and 16-bit embedded applications that used very little memory.

I notice that the uart driver code will not work if called with a read or write length of 0 because do..while is used. Possibly 'it can't happen'? There's also a hole in (all?) the device initialisation routines, eg alt_flash_open_dev returns dev ('open' successful) during initialisation even if dev->open is null.

But this Nios stuff is wonderfully useful for new products, thank you to the Altera team.

Hi again!

I'll repeat my problem again.

I want to CATCH the moment , when UART already received data via rxd and to READ these data, character.

Now I realized timer and wrote the timer interrupt handler, which allows to read status register of UART. So I see how the condition of status register is changed after receiving data.

So, if the condition of status register is changed, then corresponding interrupts must appear.

How can I catch this interrupt (for receiving) ?

__I want to CATCH the moment , when UART already received data via rxd and to READ these data, character.__

Thank you.

Hi again!

I'll repeat my problem again.

I want to CATCH the moment by UART interrupt handler, when UART already received data via rxd and to READ these data, character.

Now I realized timer and wrote the timer interrupt handler, which allows to read status register of UART. So I see how the condition of UART status register is changed after receiving data.

Here my steps:

1. In the beginning I set control register 0x180. So I set IRRDY and IE bits. IRRDY - Enable interrupt for a read ready. IE - Enable interrupt for an exception.

2. then I define alt_irq_register( UART_0_IRQ , &uart_0, handle_uart_interrupt );

3.

static void handle_uart_interrupt (void* context, alt_u32 id)
{
  uval++;
  IOWR_ALTERA_AVALON_PIO_DATA( PIO_0_BASE ,uval);
 }

4. When character is received via rx UART, the condition of status register become 0xE0. RRDY is 1, so the interrupt for read ready must appear. If the condition of status register is changed, then corresponding interrupts must appear.

But I didn’t see the results of handle_uart_interrupt function.

How can I catch this UART interrupt (for receiving) ?

Thank you.

Hi,

like 'rugbybloke' I'm a bit confused about exactly what it is you're trying to do, however it sounds like you want to write you're own device driver for the UART. Assuming that's the case, a good starting point for your own driver is the existing one.

If you copy the contents of altera_avalon_uart/HAL/src and altera_avalon_uart/HAL/inc into your system library project then this copy will be used in preference to the original. You can then modify the driver to provide additional functionality as you see fit.

If you find that manipulating the device through the ANSI C API, e.g. fopen(), fwrite(), printf() etc., is too much of an overhead for your application, then you can instead talk to the device using the underlying 'UNIX style' API, e.g. open(), read(), write() etc. This is a less sophisticated interface, but that's the trade off between the two options.

Hopefully that isn't at a complete tangent to what you're trying to do. If it is, can you have another stab at trying to explain the problem you're trying to solve?

Hello all!

Thank you for all your answers and efforts to help me.

I received the result I wanted. There were not any troubles - I just increased the period of simulation from 500 us to 900 us and I saw the result of my interrupt handler function.

Thanks to all.

--- Quote Start ---

originally posted by mike desimone@Oct 20 2004, 12:53 AM

i think the best thing you can do now is open the system library that the nios ii ide should have generated for you. if you look in there, you'll see the alt_sys_init code, and the system.h file that defines all the stuff you need to know about your sopc design.

if you look at the properties of your system library, you'll find a page which shows which uart that stdin/out/err are connected to. if that's the uart you want to talk to, then you can just use the standard posix routines printf, scanf, putc, getc, etc. to talk to the uart.

if that's not the uart you want to talk to, you can get its name from system.h. there should be a line like:

#define my_uart_name "/dev/my_uart"

and you would then use my_uart_name as a filename to pass to open(), close(), read(), write(), etc.

if you're dead set on reinventing the wheel, and absolutely must write your own interrupt handlers/drivers/everything else, you want to name your main function as "alt_main" and not "main". this skips all the interrupt setup, alt_sys_init, etc. and it becomes your problem to write.

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=2183)</div>

--- Quote End ---

I do like what you talk, but when I call "open(MY_UART_NAME,O_RDONLY)", the error message is that "O_RDONLY is undeclared ". can you tell me why and how to use open() function? if I can not open UART with open() function , I can not use the other function such as read(), write() and close(), and I can not communicate with nonblocking mode, right?

--- Quote Start ---

originally posted by kira@Oct 21 2004, 07:43 AM

hello all!

thank you for all your answers and efforts to help me.

i received the result i wanted. there were not any troubles - i just increased the period of simulation from 500 us to 900 us and i saw the result of my interrupt handler function.

thanks to all.

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=2226)

--- quote end ---

--- Quote End ---

Hi Kira,

I&#39;m having exactly the same problem as you, can you please tell me how you solved it.

Thanks a lot

This is the better disussion on interrupt over UART, so I won&#39;t open a new one.

I understand that there is device driver provided in system librairy, and you can use it with open(), read(), write(), ... or fopen(), fread(), fwrite(), fprintf(), fscanf(),...

I understand that you can re write device driver and interrupt handler.

I think interrupt are driven RTS, CTS signals if hardware flow control is done.

I think datas are in Rx and Tx buffers of UART driver at the interrupt time.

When you read Rx buffer through read() function, I think it&#39;s not an interrupt.

Interrupt just fill the Rx buffer, read() function take data stored into the Rx buffer, no ?

What happens if you don&#39;t get datas into Rx buffer before the buffer is full ? I think the circular buffer continue, and datas are lost ? Is there a signal or something telling the buffer is almost full ?

How getting datas at interrupts time ? (I&#39;m working at 921Kbds..)

Is it necessary to rewrite the driver and the interrupt handler ?