1 2 Previous Next 24 Replies Latest reply on Jan 26, 2015 4:27 PM by JoMe_264151

    "Good" documentation for use of UART FIFO?


       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.





        • 1. Re: "Good" documentation for use of UART FIFO?

          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.





          • 2. Re: "Good" documentation for use of UART FIFO?

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







            • 3. Re: "Good" documentation for use of UART FIFO?

               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?

              • 4. Re: "Good" documentation for use of UART FIFO?

                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?

                • 5. Re: "Good" documentation for use of UART FIFO?

                   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.

                  • 6. Re: "Good" documentation for use of UART FIFO?

                    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.





                    • 7. Re: "Good" documentation for use of UART FIFO?

                       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();




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


                           myBuf[bufptr++] = UART_GetChar();








                      //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);

                      • 8. Re: "Good" documentation for use of UART FIFO?

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









                        • 9. Re: "Good" documentation for use of UART FIFO?

                          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.

                          • 10. Re: "Good" documentation for use of UART FIFO?

                             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.

                            • 11. Re: "Good" documentation for use of UART FIFO?

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

                              • 12. Re: "Good" documentation for use of UART FIFO?

                                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?

                                • 13. Re: "Good" documentation for use of UART FIFO?

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


                                  unsigned char COMErrorFree(void)








                                      U2STAbits.OERR = false;


                                      U2STAbits.FERR = false;


                                      return false;




                                    com_char = UARTGetDataByte(UART2);


                                    return true;



                                  • 14. Re: "Good" documentation for use of UART FIFO?

                                    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.





                                    1 2 Previous Next