Forum Discussion
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)58 Replies
- Altera_Forum
Honored Contributor
Yes, any code for being able to change the parity bit or stop bits setting in software would be great! I'm surprised that Altera didn't do this themselves in their UART, but clearly not. Sigh.
Simon - Altera_Forum
Honored Contributor
We just mapped the opencore uart into the avalon system. Works fine.
But it's pretty useless not to be able to change parity at runtime. apus - Altera_Forum
Honored Contributor
Hi again,
I've just tried to use this with version 8.1 and have come across a minor problem, hinted at in the documentation, which is that it can't get the right clock in the SOPC GUI, but I fixed that by editting the .tcl file to hard code the clock to 100MHz (ok for me, but not for general use!). I've just tried to build my project (VHDL) and it complained that the USEDW was the wrong size - should be 4 but was 9 bits - on the RX fifo. I created the component with 512 bytes of FIFO, so 9 bits is correct, but the component declaration at the head of the VHDL file hard sets the usedw width to (in this case) 3 downto 0. Just spotted the gotcha in me fixing it by setting it to 8 downto 0 which is that the TX fifo uses 16 bytes, and so is 3 downto 0, so that's now complained. So I've changed that to use lpm_width generic, but that's now complained elsewhere. It would appear that lpm_width is set to 8 on my TX fifo, despite only having 16 bytes..... Is this all because I'm using 8.1, not 9.0? Cheers, Simon - Altera_Forum
Honored Contributor
Ok, I've just set TX and RX depths to be the same, and that seems happy. Now the BSP isn't compiling properly because in the IOCTL routines it uses dev which is undefined (lines 701 and 740). I've just looked at the altera driver and that uses sp in those places, so have changed to that....
It would also appear that various# define's didn't make it into system.h, namely RS422_UART_PARITY, RS422_UART_STOP_BITS, RS422_UART_BAUD, RS422_UART_DATA_BITS, RS422_UART_FREQ Not at all sure why. And a minor thing, in SOPC Builder when I click Generate it asks me if I want to save, so I say Yes, but when it has finished generating and I exit SOPC builder it asks me again if I want to save even though I've not changed anything. Again, is this all because I'm using 8.1, not 9.0? Cheers, Simon - Altera_Forum
Honored Contributor
Next 'bug'. In alt_sys_init.c when it tries to create the component the compiler complains that FIFOED_avalon_uart_ioctl_fd is undefined anywhere, so the# define on line 91 of fifoed_avalon_uart_fd.h needs to be changed to have a lower case "FIFOED" in the definition, as that is what is in the .c file.
Excellent - now my BSP builds. Slight concern with the missing things in system.h because they'll need setting each time I run SOPC Builder...... sigh. Let's see if I can get the FPGA to build now.... Cheers, Simon - Altera_Forum
Honored Contributor
In 9.0.1 version of fifoed_avalon_uart, IRQ threshold logic is broke - can cause an interrupt to go away without user handling, which in turn can cause a lockup in the altera_irq_handler (which expects an IRQ, once asserted, to never to go away without a SW action).
Problem is that USED outputs on the internal FIFOs wrap around when FIFO is full. E.g. lets say you use FIFO depths of 128 and TX IRQ threshold of 1 and keep on sending data to the FIFO, the TXREADY interrupt will be de-asserted when FIFO has at least 1 entry but will be re-asserted when FIFO is full (because USED on TX FIFO will transition from 0x7F to 0); at that point IRQ handler will be called. While in the handler, the FIFO will get drained at least one character, USED will transition 0->0x7F and IRQ will be deasserted. Proper fix is to either use wider USED field on the FIFO (WIDTHU=log2(DEPTH)+1) or to consider FULL flag while looking at USED to determine TXREADY/RXREADY status for generating the interrupt. Here is the fix to mk_em_uart.pm: 1869c1869,1870 < ([e_signal->new ({name => "tx_almost_empty", never_export => 1}), "tx_used <=$Options->{tx_IRQ_Threshold}" ] )if $Options->{use_tx_fifo}; --- > ([e_signal->new ({name => "tx_almost_empty", never_export => 1}), "(tx_used <=$Options->{tx_IRQ_Threshold}) && tx_not_full" ] )if $Options->{use_tx_fifo}; > 1995c1996 < ([e_signal->new ({name => "rx_at_threshold", never_export => 1}), "(rx_used >=$Options->{rx_IRQ_Threshold}) || timer_timout" ] )if $Options->{use_rx_fifo}; --- > ([e_signal->new ({name => "rx_at_threshold", never_export => 1}), "(rx_used >=$Options->{rx_IRQ_Threshold}) || rx_full || timer_timout" ] )if $Options->{use_rx_fifo}; - Altera_Forum
Honored Contributor
Hi
Has some one used the EOP for the FIFOed uart. I want to use the dma to trasfer data to ram. I had it working with the altera uart, but with the fifoed uart the dma never stop due to the eop char. Christo - Altera_Forum
Honored Contributor
Hi
this fifoed uart is really great it solved me a lot of problems!! Now I have a question. I defined:# define UART_RX_FIFO_USED(base) IORD(base, 6)# define UART_TX_FIFO_USED(base) IORD(base, 7) To get the number of chars in the tx and rx FIFO, but when I call: printf("\nBytes in fifo RX:%i TX:%i", UART_RX_FIFO_USED(FIFOED_AVALON_UART_0_BASE), UART_TX_FIFO_USED(FIFOED_AVALON_UART_0_BASE)); I always get 0. And this is what I have in system.h: […] /* * fifoed_avalon_uart_0 configuration * */# define ALT_MODULE_CLASS_fifoed_avalon_uart_0 fifoed_avalon_uart# define FIFOED_AVALON_UART_0_BASE 0x4820a0# define FIFOED_AVALON_UART_0_FIXED_BAUD 0# define FIFOED_AVALON_UART_0_IRQ 4# define FIFOED_AVALON_UART_0_IRQ_INTERRUPT_CONTROLLER_ID 0# define FIFOED_AVALON_UART_0_NAME "/dev/fifoed_avalon_uart_0"# define FIFOED_AVALON_UART_0_SPAN 32# define FIFOED_AVALON_UART_0_TYPE "fifoed_avalon_uart"# define FIFOED_AVALON_UART_0_USE_CTS_RTS 0 […] What am I doing wrong? Thanks (Pleas tell me if it is the wrong place to ask this) - Altera_Forum
Honored Contributor
Hi
Possible bug in FIFOed uart9.3 I am routing 9 Uarts to 1 all running at 460800baud. I had to implement RTS for each in the FPGA using the exported fifo registers - would be a nice standard feature:). All worked great in buffering the rx-ed data, but I started loosing rx data as soon as I started sending data back on the uarts. It turned out that I lost all the data in the rx buffer (on the drivers side - not fifo) due to a rx interupt that were generated as soon as I tx any data when the rx buffer is full (rx buffer wrapped to start). I have for now solved the problem by clearing the rx irq when the rx buffer is full without reading the reg. Not nice but it is working for now Another possible bug is in the UART status reg (fifoed_avalon_uart_reg.h) is the position of the last two registers, FIFOED_AVALON_UART_STATUS_RX_TH_MSK (13) and FIFOED_AVALON_UART_STATUS_GAP_MSK (14). In the VHDL code they are swapped when the are passed to the status_reg. I am using NIOS/Quartus ver 10 on Win7 64bit PC so the IRQ buffer problem might be as a result of this. Thanks for a great UART component! Herman - Altera_Forum
Honored Contributor
I am interested in the FIFOed. I have two questions:-
1. Is there any way that the size of FIFOs can be increased ? 2. Can the FIFOed be connected to the standard Altera DMA Core so that the DMA can be used to trandfer data to\from the UART ? Thanks in advanced