FIFOed Avalon Uart

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

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

Cal

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

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

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

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