I have posted the FIFOed avalon UART in the Hardware Projects area. It is the standard UART that comes with Nios but it has additional features such as FIFOs and hardware CTS fifoed avalon uart project (http://www.niosforum.com/pages/project_details.php?p_id=89&t_id=18)

This implementation works really great! Everyone should use these! I have used them at up to 2 Mbps and I am now able to service the receive interrupt and read all incoming data. Thanks!

Hi Longshot, thanks for this new uart. I hope it will be part of the sopc ... One question comes into my mind. This module has hw cts. What about HW RTS support for RS485 half duplex transmission ? If you connect a MAX485 f.e. to implement a differential half duplex connection between nios2 and a multidrop differential bus, mostly the rts is used to switch between receive and transmit. if the uart would automatically switch from receive to transmit as long as there is data to be transmitted and then back to receive then the software would not need to monitor any buffer of fifo structure. This would make a RS485 connection fast in the point of switching between receive and transmit, the nios would not have to do that (inside the interrupt routine) The switchover from transmit to receive and vice versa is always a very important point to be monitored in multidrop half duplex application. if you transmit data and do not switch to receive mode fast enough you could miss the start of data if the system on the other side of the multidrop bus that ist trying to comunicate with you is very fast. i have seen this on new fast plc where they switch over from receive to transmit (to acknowledge the receive of your data) with less than a couple of bittime (1-2 bit time space after the your last stopbit before the send the first startbit). the fifo between nios and the uart even at 115200 bit/sec is not the problem. the main problem ist the switch time between tx and rx. anyway thanks for this uart. Michael Schmitt

I will look at adding that in my next version. It should not be hard to do. longshot --- Quote Start --- originally posted by mschmitt@Aug 28 2006, 04:12 AM hi longshot, thanks for this new uart. i hope it will be part of the sopc ... one question comes into my mind. this module has hw cts. what about hw rts support for rs485 half duplex transmission ? if you connect a max485 f.e. to implement a differential half duplex connection between nios2 and a multidrop differential bus, mostly the rts is used to switch between receive and transmit. if the uart would automatically switch from receive to transmit as long as there is data to be transmitted and then back to receive then the software would not need to monitor any buffer of fifo structure. this would make a rs485 connection fast in the point of switching between receive and transmit, the nios would not have to do that (inside the interrupt routine) the switchover from transmit to receive and vice versa is always a very important point to be monitored in multidrop half duplex application. if you transmit data and do not switch to receive mode fast enough you could miss the start of data if the system on the other side of the multidrop bus that ist trying to comunicate with you is very fast. i have seen this on new fast plc where they switch over from receive to transmit (to acknowledge the receive of your data) with less than a couple of bittime (1-2 bit time space after the your last stopbit before the send the first startbit). the fifo between nios and the uart even at 115200 bit/sec is not the problem. the main problem ist the switch time between tx and rx. anyway thanks for this uart. michael schmitt <div align='right'><{post_snapback}> (index.php?act=findpost&pid=17892) --- quote end --- --- Quote End ---

The FIFOed Uart calculates from a wrong clock if a sopc pll is used ... If you open the Configuration dialog and have a look at the Baud Rate you will see the value of the input clock. the value is wrong. it is the value of the input clock that enters the sopc and feeds the pll but not the one this module is connected to. as it is actually the c0 output of the pll. im my case 48MHz input and 64MHz output. all SOPC modules are connected to the 64MHz output of the pll. The dialog displayes the 48MHz what ist wrong in this case. But i am not shure if the values internaly calculated are based on 48MHz or 64MHz in my case ... regards. Michael

I&#39;m using the FIFOed avalon Uart with HW CTS RTS control flow to send data to a Bluetooth tranceiver at 921Kbps. The bluetooth tranceiver send the data to a PC through a virtual COM port configured at 921 kbps too. My problem is that from time to time one byte send by software seems to be sent twice by hardware !!! I send 1MByte through the Fifoed Uart in high speed so flow control is often used by the bluetooth tranceiver, according to bluetooth datarate.. It seems that when Fifo goes full or goes empty and then goes to in between state, the last or first byte is send twice. I can see that in the file received : it&#39;s almost perfect, but sometines there is a duplicated byte. I can see that all over the file in no coherant manner.. FIFO lenght : 1024 Circular buffer lenght : 4096 Does someone could try to explain what happens ?? Thanxxx

FIFOed Avalon Uart | Altera Community

58 Replies

Altera_Forum
Honored Contributor
15 years ago
If you need dma, you really want a uart that has a descriptor based interface - more like that seen on ethernet chips.
A software solution might be to put down a 2nd nios with minimal, tightly coupled code+data to act (effectively) as a progammable dma engine.
Altera_Forum
Honored Contributor
15 years ago
The standard Altera UART can be connected directly to the DMA Controller Core which needs to be controlled by a NIOS. The DMA core has an internal (limited FIFO).

Could the UARTed be used in the same way ?

Does anyone know anything about the possible differences between these 2 types of configurations ?

Also - Does anyone have an answer to an option to increase the FIFO size of the FIFOed ?
Altera_Forum
Honored Contributor
15 years ago
Hi,

I have the same problem as luchnikov mentioned above. I use the Fifoed Avalon UART 9.3 in one project and it seems to work fine. But for some reason the complete system hangs after a while.
When I debug this behaviour it shows up, that the software hangs in the altera_interrupt_handler subroutine.
Does onybody know how to fix this problem in the 9.3 version of that core?

Thanks, M.Schulz.
Altera_Forum
Honored Contributor
14 years ago
Is there any way to reset only the Transmit channel ? What type of resets are available for this component ?
Altera_Forum
Honored Contributor
14 years ago
There is an error in the fifoed_avalon_uart.c file (both 9.1 & 9.3 versions). When using as ALT_USE_SMALL_DRIVERS or FIFOED_AVALON_UART_SMALL (non-interrupt mode), the read routine doesn't work if requesting more than 1 byte, in fact it fails to get any bytes at all. I am attaching the changes I made to make it work. There were no tests for errors in status and I have not added any here. The only changes are in the "fifoed_avalon_uart_read" function. The changes have been tested and are working here. The uarts are being used here with 1K read and 1K write fifos at 1M baud in the FIFOED_AVALON_UART_SMALL mode. At this speed interrupts are not used as they interfere with operation.</SPAN>

int fifoed_avalon_uart_read (fifoed_avalon_uart_state* sp, char* ptr, int len, int flags)
{
int block;
int i;

block = !(flags & O_NONBLOCK);
i = 0;

do
{
while((IORD_FIFOED_AVALON_UART_STATUS(sp->base) &
FIFOED_AVALON_UART_CONTROL_RRDY_MSK) && (i < len))
{
IOWR_FIFOED_AVALON_UART_STATUS(sp->base, 0); // clear any error flags
ptr[i++] = IORD_FIFOED_AVALON_UART_RXDATA(sp->base); // get data
}

if( i > 0) // if anything there, return it
return i;
}
while(block);

ALT_ERRNO = EWOULDBLOCK;

return 0;
}
Altera_Forum
Honored Contributor
14 years ago
I'm using the FIFOed Avalon Uart in a project and I'd like to modify the driver so that it blocks, but has a timeout. Basically I don't want to risk hanging if I miss a byte while in blocking mode. I've also seen cases where I miss replies if I don't block because the call to the fread function happens before the data is sent from the device. I figure with a time-out I get the reply as fast as possible, but I don't hang if the reply never comes (or is short a byte).

I think I see a way to modify the driver, but I thought I would post the question in case the author still checks these forums and might have some advice. Any "gotchas" I might not realize. Or any advice from driver experts.

Thanks!
Altera_Forum
Honored Contributor
14 years ago
My thoughts on this is that writing a driver for the UART isn't that difficult, so you might as well write one with the interfaces you need, and remove all the extra layers of abstraction between the driver itself and the stdio functions.

If your software 'scheduler' just calls every task in turn (adequate for a small embedded system), it may be appropriate to have a read_uart() function that is called where you now have fread() that directly recovers data from the fifo itself.
Altera_Forum
Honored Contributor
14 years ago
Very true, I actually wrote a driver for our custom UART that we use on other products. I figured all I would need to do is add a timeout to the ALT_FLAG_PEND call in the fifoed_avalon_uart_read() function, but I would still need to figure out a way to pass the value of the timeout into the function.

I was focused on "fixing" the driver, so I hadn't yet considered the benefits of losing the stdio overhead if I just wrote my own functions. Might also save some data copying to go that route.

Thanks.
Altera_Forum
Honored Contributor
14 years ago
Hello GrandAdmiral,

I have the same problem. I need also a blocking read with timeout for the FIFOED UART. My intention was to use the ioctl() functions to set the type of the reading (blocking or non-blocking) and to set the timeout value for the driver.
Actually I did not do anything on that project for several months and I remember that I had problems with the ioctl() for that driver in general.

Has maybe someone else a solution for this proiblem?

Regards, MSchulz.
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---
Hi,

I have the same problem as luchnikov mentioned above. I use the Fifoed Avalon UART 9.3 in one project and it seems to work fine. But for some reason the complete system hangs after a while.
When I debug this behaviour it shows up, that the software hangs in the altera_interrupt_handler subroutine.
Does onybody know how to fix this problem in the 9.3 version of that core?

Thanks, M.Schulz.
--- Quote End ---

Hello mschulz,
I facing same problem you had falling in deadlock situation within altera_interrupt_handler subroutine. I suppose that problem is effectively within FIFOed component. The deadlock is caused by an ipending register clear performed by FIFOed UART component before it's ISR subroutine is served.
I face the problem quite rarely and with uart speed of 460800 baud.
Did you solved your problem?
Thank you.
Regards,
Paolo

Forum Discussion

FIFOed Avalon Uart

58 Replies

Recent Discussions

Dual Port Nios V BSP error

set_output_delay explained for dummies

[Test only]How to verify Agilex 3 in radiation tolerant environment

gdb server problem when debugging

Nios IDE CPU Detection