"Good" documentation for use of UART FIFO?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
DaHu_285096
Level 5
Level 5
10 likes received 250 replies posted 100 replies posted

 Is there any decent document or examples around that shows how to use the UART FIFO?

   

I note many discussions on UARTs and there seems to be plenty of confusion.

   

At present, I set up the UART for single byte RX interrupt and have a circular buffer being fed by the interrupt and the mainline code dequing and parsing the received data, looking for valid packets.

   

It seems to me the FIFO should be able to replace my circular buffer.

   

There seem to be little documentation regarding inetrrupt driven UART, Use of the FIFO and what sort of error checking should be done.

   

 

   

Thanks

0 Likes
24 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

When you look at the descriptions of the UDB you can see the FIFOs there. Compare that to the generated files for the UART component and you see that every received packet is stored in the FIFO first from where the user retrieves it. A buffer declared for the component will be fed from the FIFO. When using the external (your) interrupt you are responsible for handling all that yourself. Easiest is the "Circular Buffer" and an interrupt handler getting signaled the receive of a single byte.

   

Yes, of course does the Cypress implementation runs as expected, but it is difficult to get control at the right moment for instance when a special character is received. Your interrupt and the component's interrupt may disturb each other.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Did you read the following UART Component manual ? If yes, what is missing in this document ? I know that UART registers are not documented in it and you have to look at the hugly PSOC5LP Registers TRM for registers documentation. In some Cypress survey, I point the problem and I hope they have grasped the request. When one want to develop PSOC Components because he has specific requirements, he is at least disappointed by the TRM document ...

   

 

   

Regards,

   

PNN

0 Likes
DaHu_285096
Level 5
Level 5
10 likes received 250 replies posted 100 replies posted

 Which pages show how to use the buffers when buffer size is greater than 4?

   

Also, the examples given simply read the uart, does this mean there is no need to specifically check for overrun errors and framing errors etc? I don't see any example of using error detection.

   

Page 28 example for half duplex operation. Does this mean you can set a buffer size to say 2000 and simply use PutString to send out large text string over serial port without needing to do anything else?

   

The ISR example on page 31 is using the following 2 lines to read data, is this all we need to do to read our 2000 byte buffer? And is no error detection required?

   

rec_status = UART_RX_RXSTATUS_REG;

   

if(rec_status & UART_RX_RX_STS_FIFO_NOTEMPTY)

   

{

   

rec_data = UART_RX_RXDATA_REG;

   

}

   

The examples given are rudimentary and the manual shows piecemeal, the various functions available from the components but how do those of us new to the PSOC UART understand how to put together an application using interrupt driven coms with larger buffers and error checking to ensure link is reliable?

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

For sending via UART, PutString takes care of everything you need. It will block until all data is put into the TX buffer (be it hardware or software).

   

Note that half-duplex mode cannot use the software TX buffer, so you are limited to 4 bytes TX buffer.

   

Regarding error handling: the UART component (we are talking about PSoC3/5?) provides interrupts on RX buffer overrun. This should even apply to the software buffer implementation. Or do you need something else?

0 Likes
DaHu_285096
Level 5
Level 5
10 likes received 250 replies posted 100 replies posted

 So I can simply set up the buffer size for TX and RX as 3000 bytes in the component on the schematic.

   

Then just putstring and any data from my Ram buffer up to 3000 bytes will be properly handled and sent.

   

For receiving all I do is simply read the UART.RXBuffer (or whatever the assigned buffer gets named) and that's it?

   

And I don't need to write any specific code to clear flags etc for over-run, they are all taken acre of.

   

Sounds simple. When I was writing code for micro chip we had to read each byte in the fifo to clear it and specifically check for overruns because if we didn't then the receiver stopped until the overrun flag was cleared. Great that I don't need to do all this with PSOC.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Only thing to care for is not to read more bytes than there are in the Rx-buffer. So check first the "size" which is actually a count before you read your data.

   

 

   

Bob

0 Likes
DaHu_285096
Level 5
Level 5
10 likes received 250 replies posted 100 replies posted

 In summary:

   

I place a UART component and set TX and RX buffer size to say 3000

   

The program automatically takes care of all the interrupts

   

I start the UART

   

The receive code would be like...

   

nbytes = UART_GetRXBufferSize();

   

if(nBytes){

   

  for(i=0; i< nbytes; i++){

   

     myBuf[bufptr++] = UART_GetChar();

   

  }

   

  Parse(MyBuf);

   

}

   

//where bufptr is incremeted as entire packet being received and cleared for next packet

   

//Assume each time new bytes appear that GetChar starts retrieving from unread data only and not beginning of buffer

   

For transmit

   

UART_PutArray(myTXbuf, 3000);

0 Likes
Anonymous
Not applicable

You'd better use UART_PutArray & UART_GetByte and check for errors. As a rule of thumb even if you wrote a first draft : "always check for errors returned".

   

 

   

 

   

Regards,

   

PNN

0 Likes
JiGi_284761
Level 4
Level 4
Welcome!

No. No decent documentation.

   

You should stay away from increasing the buffer size and instead use your own buffer. Depends on what you do of course. when you let the component interrupt do the work you have no control over it. You still have to sort the data so you might as well do it yourself.

   

When the status register indicates a received byte, If you selected more than 4 bytes, the interrupt is generated and whatever byte that is in the fifo at the moment is transferred to rx_buffer(size you picked) .

   

If you selected 4 or less nothing happens. You need to insert your own code in the  supplied interrupt to move the byte to your own buffer or use ISR(proto) and write your own routine.

   

There is space in the supplied interrupt code for initialization, error checking and sorting. You just need to tell it what to do.

   

 If you select 4 bytes or less, you have to write all your own code to parse the bytes as they arrive. 

   

If you are using a rs485 device, you need to make sure you enable the transmit pin when you transmit.  The component will do this for you if you use it but it you don't use it, make sure you engage it when sending and disengage it after sending.

0 Likes
DaHu_285096
Level 5
Level 5
10 likes received 250 replies posted 100 replies posted

 What error checking needs to be done and does simply checking the errors clear them?

   

This is what I meant about documentation. I see many posts regarding UART that reveal confusion in understanding how to use it.

   

All those who are answering the posts and giving information must have obtained the info from somewhere (maybe by experience of trial and error) but it does not appear to be in one place (like the datasheet for the UART component), and there don't seem to be any real PSOC books available either.

   

People will guide me to a snippet of information in a certain document and another snippet somewhere else. This is fine once they understandhow everything goes together but for someone learning to use the UART and wanting to do a bit more than the simplest of aplications that are shown in the datasheet (like sending a string in half duplex mode without interrupts), there does not appear to be sufficient information.

   

I understand when it comes to the PROCESSING of received data it is outside the scope of the UART component, but when we are talking about how to use the built in buffers properly or what error checking needs to be done to ensure reliable communication, this info is not obvious to me.

0 Likes
JiGi_284761
Level 4
Level 4
Welcome!

Error checking has nothing to do with the UART  Component. It is dependent on the protocol  you are using.

   

Error checking is error checking. It is application programming.

   

For example. I do a lot of Modbus RTU. I use a cyclic redundancy check.  CRC-16

   

For the most part the component consists of only the interrupt code, the status register masks , A ring buffer and a some variables.

   

All of this you can do yourself.

   

A good book to learn from is

   

C Programmers guide to serial communications.

   

all any UART is, is a shift register with a holding register and a status register.

   

Most have only a single holding register. But that is all you need. Your processor is many times faster than the data that is coming in via the UART so reading it via a simple Ored flag is all you really need to do at the basic level..

0 Likes
DaHu_285096
Level 5
Level 5
10 likes received 250 replies posted 100 replies posted

How will the 3rd party book you recommended, help me understand whether simply reading the UART will clear say overrun and frame errors ?

   

These flags are part of the CYPRESS component are they not?

   

Are you saying tyhat it is not the responsibility or whithin the capability of the Cypress UART component to provide reliable serial communications? I am talking here about low level UART and not higher level parsers and CRC checking etc.

   

For example: If the UART component indicates a character is ready then I assume there was no frame errors or overruns?

0 Likes
DaHu_285096
Level 5
Level 5
10 likes received 250 replies posted 100 replies posted

 For instance, when using Microchip, I had to do this to clear the flags,

   

unsigned char COMErrorFree(void)

   

{

   

  if((U2STAbits.OERR)||(U2STAbits.FERR))

   

  {

   

    U2STAbits.OERR = false;

   

    U2STAbits.FERR = false;

   

    return false;

   

  }

   

  com_char = UARTGetDataByte(UART2);

   

  return true;

   

}

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

The UART implementation signals errors and conditions (as Tx empty, FIFO not empty...)

   

Like with a traffic light it is your choice in a certain application what you want to do with the signals provided: ignore them, drop the character ask for a re-transmit, cout errors and and and...

   

I am not a friend of total supervision of the UART interface by the provided software. Like with my camera I have to spend much time in disabling automatisms to have it exactly done what I want.

   

So having my own interface adapted to the complexity and / or required safety needed by the project (or my customer) wilol cost me additional 3 lines to write, that's it. Low price compared to not observing a red light.

   

 

   

Bob

0 Likes
JiGi_284761
Level 4
Level 4
Welcome!

@ Orbit.

   

You are overcomplicating this.

   

All the UART is a holding register that generates a interrupt upon change. When you read it, it is cleared. All else is software.

   

If you use the API all you are asking for is supplied for you. Look on page 40 of the UART PDF and you will find a description and names of bits in the status register. You can do what ever you want with them. As noted on this page, the related masks are defined in the .h file.

   

If you want to write your own code, You can either use the API and modify it or completely write your own using only the interrupt and register.

   

For a CY8C5868AXI-LP035 the Uart register is.B1_UDB08_F0:  address 0x40006548 it is located on page 933 of the TRM.

   

The best way to find how these API's work is to right click on the define or constant or variable you are interested in in the code then click on "Go to implementation or definition or all active references"

0 Likes
DaHu_285096
Level 5
Level 5
10 likes received 250 replies posted 100 replies posted

 I think the answer is what is being over complicated here. Do the flags get cleared when you read the buffer? If the buffer is greater than 4 bytes, does this get cleared each time it is read?

   

Here is an example of "Good" documentation that explains how the PIC miro UART handles the flags. If we use third party info (like your camera analogy), do I assume the 5LP will also not prevent reception on FEER bit and gets cleared by reading received data (regardless of buffer size). And that the UART stops receiving after an overrun error, and if so how does this error get cleared. You see the pic needs to have the CREN bit of RCSTA cleared.

   

I don't agree with your analogy and that the FIFO is just a buffer that is practically chip independant. The FIFO has characteristics and qwirks that are part of the UART component.. The way the flasg are set and cleared and how the component handles the reception after the error are determined. I am sure that though the general concept is the same, the implementation of the flags can differ. Does 5LP have a CREN bit in an RCSTA register? If not, then what does it do?

   

If you KNOW, the answers to my question then where did you get the information? Is it obvious in the UART component datasheet? I think not

   

Receive Error Detection

   

There are two types of errors which the microcontroller can automatically detect. The first one is called Framing error and occurs when the receiver does not detect the STOP bit at the expected time. Such error is indicated via the FERR bit of the RCSTA register. If this bit is set, it means that the last received data may be incorrect. It is important to know several things:

   
        
  • Framing error does not generate an interrupt by itself;
  •     
  • If this bit is set, the last received data has an error;
  •     
  • A framing error (bit set) does not prevent reception of new data;
  •     
  • The FERR bit is cleared by reading received data, which means that check must be done before data reading; and
  •     
  • The FERR bit cannot be cleared by software. If needed, it can be cleared by clearing the SPEN bit of the RCSTA register. It will simultaneously cause reset of the whole EUSART system.
  •    
   

Another type of error is called Overrun Error. The receive FIFO can hold two characters. An overrun error will be generated if the third character is received. Simply, there is no space for another one byte and an error is unavoidable! When this happens the OERR bit of the RCSTA register is set. The consequences are the following:

   
        
  • Data already stored in the FIFO registers (two bytes) can be normally read;
  •     
  • No additional data will be received until the OERR bit is cleared; and
  •     
  • This bit is not directly accessed. To clear it, it is necessary to clear the CREN bit of the RCSTA register or to reset the whole EUSART system by clearing the SPEN bit of the RCSTA register.
  •    
0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

I do not know where you have got the names for the registers and bits from, but this is usually not the level we deal with. Additionally there are some things in your explanation not quite right: The FIFO is normally 4 bits deep. in case of PSoC SCB even eight bits. Clearing the framing error depends on the underlying hardware which differs from using FF, SCB and UDB implementations. So the question remains for me: What do you want? And if it is not availlable: Why don't you program it?

   

 

   

Bob

0 Likes
DaHu_285096
Level 5
Level 5
10 likes received 250 replies posted 100 replies posted

 Bob,

   

you need to re-read my post again as you have misread what I was referring to regarding the specific registers I mentioned

   

Also, maybe refer back to the original post. I have been discussing the UART component in Creator. This component has a datasheet that describes API's that can be used with the component. Some of these involve Error status flags that can be read. 

   

It seems to me that if the issue is so dynamic and complex that this is all the more reason to provide better documentation.

   

Noone can simply state how or whether the flags require clearing ??

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Orbit wrote

   

For example: If the UART component indicates a character is ready then I assume there was no frame errors or overruns?

   

Exactly as you wrote: this is an assumption. The other assumption would be: there is a character received and there is a framing error. Since you cannot have a frame without a character it is quite logical that your assumption not to have a character is wrong.

   

Similarily with an overrun condition: when you do not manage to pick up the characters received the last one will be fed into the fifo (because it is a FIFO!) and the earliest received character will be pushed out into the nirwana pool. This is documented in the datasheet afaik (do not let me search for the exact place)

   

 

   

Bob

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

From your posts I am not sure which of the tree different UARTs you are reflecting to. Do not say "all of them", let's keep it overlookable

   

Then we can check that datasheet for any ambiguities or missing codes and inform Cypress.

   

 

   

Bob

0 Likes
JiGi_284761
Level 4
Level 4
Welcome!

Again. You don't seem to understand.

   

Your PIC UART is a specific piece of hardware within the microcontroller. You have one. That is it. There is a specific procedure built in by the manufacturer on how it operates.

   

The UART in the PSOC5 is derived. It doesn't really exist. It is derived from a  field-programmable ASIC. In other words you are not limited by hardware limitations. You can make 10 UARTS if you wish and program them whichever way you like. 

0 Likes
DaHu_285096
Level 5
Level 5
10 likes received 250 replies posted 100 replies posted

 UART v2.3 is the component name

0 Likes
DaHu_285096
Level 5
Level 5
10 likes received 250 replies posted 100 replies posted

 OK, I give up. It seems a simple answer is illusive. Using the API for a specific component(UART v2.3)  is not straight forward.

   

Because the component is derived, no-one understands whether the flags clear themselves or you have to read the buffer to clear them. After all, the "derived" function Sets the fals in the first place, surely they have a method to clear them?

   

And now I understand why the documention is not sufficient (and I assume this extends to other component API's), because the functions are derived, we cannot say how to use them!!! Rubbish.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

In the datasheet on page 17 I find some explanation for UART_ReadRxStatus(). There is clearly stated which bits are returned and which bits are clear-on-read. So what would you like to see explained more clearly?

   

 Could you explain for me more clearly (language problem) what you mean by "derived"?

   

 

   

Bob

0 Likes