Multiple serial port misbehavior

Question

Quartus 4.1, Nios1.01:

The NiosII system has 2 uarts, a primary debug terminal@115K baud, and a secondary half-duplex slave device@19.2K baud.

During operation lots of printf output (from many uCos tasks) goes out to the terminal (a PC running hyperterm) to be logged. There is no input on this uart.

A dedicated task talks to a 2nd serial slave device. You send this device a short ascii string, and it returns 100 or so ascii chars terminated with cr.

When tested directly with hyperterm, the device works OK.

When tested on the NiosII system, I am losing chars both on input and output for the 2nd uart.

There appears to be a dependancy between the uarts such that as long as the primary uart is sending out chars, the secondary uart is getting partially or fully blocked. Changing the uart assignments ie. 1st uart is for slave device, 2nd uart is for terminal, did not fix the lost char issue with the slave device. Currently I am using fopen(),fgetc(), fputc() for this uart, and will try switching to open(),read(),write() to see if it makes a difference.

Any ideas?

thanks

altera_forum · Answer

for a test try to set the ring buffer size in avalon_uart.h to more than 64 (e.g. 2048) we also use 2 uarts and we open the uart twice (non blocked for input and blocked for output).

altera_forum · Answer

Which set of functions are you using, the fopen(),fread(),fwrite() or the open(),read(),write() ?

As I understand it, the fopen(),etc does thread-safe checking and would have more overhead than the open(),etc.

Increasing the buffer size is a great idea - but I had the impression from the program behavior that there already was a large print buffer for printf(). The reason I say that is the a multi-task app which generates a lot of output from several tasks, I never see interleaved print output. A 64 char buffer would fill up fast. I'd expect to see either interleaved print output or lost chars on my main terminal. I don't see this.

altera_forum · Answer

The larger buffer did not change things. I did discover something unusual. My 2nd uart, the one with problems, will spit out an &amp;#39;E&amp;#39; shortly after I send out a command string. There is no place in the code that would write this char to the uart, and I have specifically placed a filter to catch it. Either the uart driver is adding this &amp;#39;E&amp;#39;, or the uart itself is somehow generating it. Bizarre.

altera_forum · Answer

Are you using (or needing to use) hardware handshake?  Does the UART indicate Rx overrun?  If the device is talking to a PC, make sure the Tx FIFO is set to 1.

altera_forum · Answer

No HW handshake. The uarts are minimal implementations. I have increased the uart driver buffer size to 1K. I don't see any TX FIFO option. Does this dialog appear when you enable HW handshake?

The traffic on my 2nd uart is small. I send out 12 chars every 10secs or so, and I get a response of about 130 chars. Tx and Rx on this uart is 19200.

Forum Discussion

Multiple serial port misbehavior

6 Replies

Recent Discussions

Agilex Reset_Release no associated clock

How to reduce ROM/RAM requirements for a NIOSV Compact CPU Platform?

How to use SDRAM IP core on Agilex 3?

eCoS OS throws execption when freeing memory

Error creating Nios II Application and BSP from Template