Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
4,437 Views

FIFOed Avalon Uart

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)
0 Kudos
58 Replies
Altera_Forum
Honored Contributor I
275 Views

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!
Altera_Forum
Honored Contributor I
275 Views

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
Altera_Forum
Honored Contributor I
275 Views

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 ---  

Altera_Forum
Honored Contributor I
275 Views

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
Altera_Forum
Honored Contributor I
275 Views

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
Altera_Forum
Honored Contributor I
275 Views

Great info. I can get that fixed in the next few days. 

Cal
Altera_Forum
Honored Contributor I
275 Views

 

--- Quote Start ---  

originally posted by billooj@Sep 27 2006, 06:24 PM 

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 

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

--- quote end ---  

 

--- Quote End ---  

 

 

With the same buffers lenght, I reduce Uart datarate to avoid hardware control flow : the problem disappear ! So, it seems that when the Fifo never goes full : no byte is sent twice. 

 

When I put buffers length as follow : 

 

FIFO lenght : 1024 

Circular buffer lenght : 512 

 

It seems that byte duplication occurs more often.. maybe it could help to understand what happens ? 

 

Ju.
Altera_Forum
Honored Contributor I
275 Views

New results for the problem I have (double byte sent instead of one) : 

 

It seems that there is no link with the fifo behaviour, contrary to what I said, but only with CTS signal behaviour of the UART !!! 

 

When there is no dataflow management by the bluetooth tranceiver (UART&#39;s CTS never goes high), there is no problem. 

 

Different lenght of Fifo and circular buffer (Fifo lenght > or < circular buffer) could modify CTS frequency. And CTS frequency is linked to the appearance frequency of the double byte. 

 

I&#39;ll export Fifo&#39;s signal to determine if there is a link with full state fifo frequency and the double byte transfer. 

 

I&#39;ll tell U
Altera_Forum
Honored Contributor I
275 Views

no there isn&#39;t link between Fifo and double byte transfer : only linked with CTS behaviour. 

 

I removed hadware CTS in SOPC Uart options : the double byte transfer disappear, but (with the same software) I loose some blocks of byte depending to datarate (7 blocks of 34 byte at 921K, only one block at 230K, no block lost at 115K) 

 

Could you let me know how to manage correctly CTS with Fifo options ??
Altera_Forum
Honored Contributor I
275 Views

Is there an update of the FIFOed Uart available ? 

Or what is the actual version ? 

 

My Word file and the class.ptf file are dates 2006-08-28 

 

Regards. 

 

Michael
Altera_Forum
Honored Contributor I
275 Views

I do have a new version coming out but it is not tested enough yet. So I am not quite ready to give it out yet. Hopefully soon. I do have the new features you requested. I guess I could release it as a kind of beta so you could try it out if you like.  

Longshot
Altera_Forum
Honored Contributor I
275 Views

Be aware of when using a PC serial port, its Tx FIFO will continue to empty itself after changing CTS. To ensure no more data is sent from the PC, go into "Port Settings - Advanced" on the Control Panel and set the Tx FIFO to 1. 

 

I don&#39;t use this UART but is it able to set CTS when the FIFO is full, or when it&#39;s nearly full?
Altera_Forum
Honored Contributor I
275 Views

 

--- Quote Start ---  

originally posted by billooj@Sep 27 2006, 11:24 AM 

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. 

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

--- quote end ---  

 

--- Quote End ---  

 

 

Do you have a bluetooth transceiver that its directly connected to the fpga ?  

I am still searching for a bluetooth solution to connect my fpga via a uart for a wireless terminal port. 

 

It would be cool if this is a 3,3V module that can directly be connected to a fpga and transmits the uart data to a pc f.e. and there i could open a "com" port from a application software. 

 

Any link to such a device is greatly welcome as i will include bluetooth as soon as possible 

 

Regards.
Altera_Forum
Honored Contributor I
275 Views

jason : Go to fifoed avalon uart project (http://www.niosforum.com/pages/project_details.php?p_id=89&t_id=18), signals behavior according to FIFO state are described in project files. 

Thx for your suggestion, I&#39;ll see.  

For the moment : When UART is directly connected to PC with RS232 cable, there is no flow control at 921K for data from FPGA to PC, so there is no double data byte sent. 

When UART is connected to PC through Bluetooth module and virtual COM port, there is flow controls at 921K for data from FPGA to BT module, and there is double data bytes sent. 

 

mschmitt : There are many complete Bluetooth module including antenna (BlueGiga, Stollman, Free2move, National Semiconductors, Philips NXP) that can be directly connect with an FPGA for Reset, RX, TX, RTS, CTS in 3,3V. 

I looked for a module 2.0 + EDR that can go at 3Mbit/s, but it seems that the Serial Port Profile protocole can&#39;t go over 921K, like 1.2 and 1.1 BT modules.
Altera_Forum
Honored Contributor I
275 Views

Thanks Billooj ! 

 

I just had visited National&#39;s web site and found the lmx9830. As we design microwave stuff this is very easy to be integrated into our target pcb&#39;s 

 

The only thing left seems to be FifodUart and somebody shouting it works @ 931kbit/sec ... :-)) 

 

But i am still seeking for other chips for this purpose. 

 

Longshot : 

If you think you have the RTS feature i requested ready i could give it a try @ 115200 bit/sec. Hope you have also fixed the wrong clock speed. The orignal zip showed a wrong input clock. assuming the clock that feeds the sopc pll is the clock speed and not c0...c2 as connected via sopc. 

 

Thanks to all here. 

 

Regards. 

 

Michael
Altera_Forum
Honored Contributor I
275 Views

Another bug found, the parity bit is inverted. 

 

IzI 

 

correction: 

there was no parity problem, i was programming the wrong file. 

 

 

uCLinux: 

I tested the Fifoed uart under uCLinux and if seems to work OK. With the original Altera Uart we had a lot of UART buffer overruns, just by pressing the up arrow in the console, there was no way of pasting text into the console: 

 

ttyS0: 1 input overrun(s) 

 

We currently use FIFOs of length 512 which still consumes the same amount of M4K blocks (4) as FIFOs of length 16. 

 

IzI
Altera_Forum
Honored Contributor I
275 Views

Have you solved my problem? 

 

I have a Nios project that talks to a PC. Apparently the Nios sends a buffer of data so fast that it overruns the PC without any flow control. Messages from PC to Nios don&#39;t seem to be a problem. 

 

Hardware flow control (PC tells Nios to go or wait) would probably be the solution, but as I understand the standard Nios UART (included with Quartus/Nios 6) the CTS/RTS are simply status bits that software can read, don&#39;t really do anything. 

 

My understanding is that the upgraded Uart you have provided allows Nios to use hardware flags to allow/stop incoming communication. Would it also serve in my case? That is, will it stop/resume transmission from Nios to PC in response to hardware handshakes from PC? 

 

And could you please confirm the polarity of the handshake signals? 

 

Thanks in advance...you may have been a lifesaver to me 

 

Michael
Altera_Forum
Honored Contributor I
275 Views

Trying to use this Fifoed Uart for low data rates, but not understanding the docs. A simple word description of what controls the CTS, RTS is needed. The perl is too obtuse for me.  

 

I have selected &#39;use cts rts&#39;, and a fifo size of 16. What do I gain or not gain by selecting &#39;hw cts&#39;? 

 

When I use the standard &#39;FAST&#39; compile option, I assume the packaged component/driver will properly handle the flow control: 

1) The uart will not send data to the DCE (a modem in my case) unless# CTS is asserted and there is something in the uart tx fifo to send. 

2)# RTS will be asserted only when the uart rx fifo is full.  

3) My app only needs to r/w to the circular sw buffer and does not need to inspect/control CTS,RTS registers or handle the data xfer between circular sw buffer and uart. 

 

Am I wrong in my assumptions?
Altera_Forum
Honored Contributor I
275 Views

On the configuration tab, the checkbox "Include CTS/RTS pins & control register bits" will only create register bits to control/read these signals. There&#39;s no hardware connection between the read/write FIFO&#39;s and CTS/RTS pins. It&#39;s up to SW. 

 

On the MISC tab, the checkbox "Create hardware CTS input" looks like it will throttle the NIOS & prevent it from sending when the connected device asserts CTS. 

 

However, there&#39;s no provision in hardware for NIOS to tell the connected device that its receive buffer is full with RTS (which is what I want!). 

 

Longshot--any chance of getting RTS support in there? 

 

Thanks
Altera_Forum
Honored Contributor I
85 Views

I figured out how to add RTS flow control in hardware using the UART with FIFO&#39;s. 

 

Add the FIFO&#39;ed UART component in SOPC builder. Check the configuration box to add RTS & CTS register bits. Generate the system. 

 

When it&#39;s done generating, open uart.vhd and edit: 

 

Look for: 

rts_n <= NOT rts_control_bit; 

 

Comment out this line and add the following: 

 -- Generate RTS  rts_c: process (clk, reset_n)  begin  -- process rts_c    if reset_n = &#39;0&#39; then               -- asynchronous reset (active low)      rts_n <= &#39;1&#39;; -- 1=OK to send    elsif clk&#39;event and clk = &#39;1&#39; then  -- rising clock edge      if (rx_used(rx_used&#39;left) = &#39;0&#39;) then -- FIFO is < 1/2 full        rts_n <= &#39;0&#39;;  -- inverted at tranceiver      else        rts_n <= &#39;1&#39;;      end if;    end if;  end process rts_c; 

 

This asserts RTS when the receive FIFO is 1/2 full. 

Note that reading the RTS bit in the UART register will not reflect the state of the pin. You&#39;d have to find where rts_control_bit is read and substitute rts_n. 

 

Note that RTS is inverted at the RS232 tranceiver, so the levels you&#39;ll see on the port are reversed from the code. 

 

Hope this helps. I tested it & it works well on my system.
Reply