cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC™ 5, 3 & 1

DaVi_4379521
New Contributor II

I have a simple project that turns the onboard LED on/off via the switch.

Then reads the state and outputs "Light On" or "Light Off" via usb uart using _PutString function.  The code and the working serial out:

cyp03.PNG

However, when I add a second consecutive line with the _PutString function, the output garbles badly and ultimately fails to respond after 13 or so button presses.

I'm expecting a "Line2" to get printed underneath "Light On".

cyp04.PNG

0 Likes
1 Solution
MotooTanaka
Esteemed Contributor

Hi,

In general an UART is relatively slow component.

PutString() returns just after putting the data into the buffer,

so apparently in your case you are calling the second PutString() before the previous one is done.

For USBUART there is a function USBUART_CDCIsReady() which returns 0 if USBUART is still working.

So you could write

  USBUART_PutString("Light On\r\n") ;

  while(USBUART_CDCIsRead() == 0) {

     // wait for USBUART to finish sending

     // may be we need to check timeout here to prevent infinite loop

  }

  USBUART_PutString("Light2\r\n") ;

Or usually writing something like below takes care of the problem

  USBUART_PutString("Light On\r\n") ;

  CyDelay(10) ; // About this value 10, your mileage may vary

  USBUART_PutString("Light2\n\n") ;

moto

View solution in original post

0 Likes
5 Replies
NoriakiT_91
Employee

I recommend to implement a software FIFO because the original USBUART component do not have any buffer.

Please refer my repository as follows.

GitHub - noritan/Design307: FIFO Implementation for USBUART for BLOG - "CY8C5888LTI-LP097" on "CY8CK...

Sorry, all comments are written in Japanese.

0 Likes
DaVi_4379521
New Contributor II

Thank you for taking the time to reply.  I'll take a look at your library and get back to you if I have any questions.

0 Likes
MotooTanaka
Esteemed Contributor

Hi,

In general an UART is relatively slow component.

PutString() returns just after putting the data into the buffer,

so apparently in your case you are calling the second PutString() before the previous one is done.

For USBUART there is a function USBUART_CDCIsReady() which returns 0 if USBUART is still working.

So you could write

  USBUART_PutString("Light On\r\n") ;

  while(USBUART_CDCIsRead() == 0) {

     // wait for USBUART to finish sending

     // may be we need to check timeout here to prevent infinite loop

  }

  USBUART_PutString("Light2\r\n") ;

Or usually writing something like below takes care of the problem

  USBUART_PutString("Light On\r\n") ;

  CyDelay(10) ; // About this value 10, your mileage may vary

  USBUART_PutString("Light2\n\n") ;

moto

View solution in original post

0 Likes
DaVi_4379521
New Contributor II

brilliant.

while (USBUART_CDCIsReady() == 0u){}

takes care of the problem.  Thank you.

Len_CONSULTRON
Honored Contributor II

Hi,

Actually the USBUART component is pretty fast (I've clocked it at about 1 MBytes/sec average).  The problem you are facing is the USBUART component has no FIFO (as Noriaki pointed out).  The USBUART has a 64 byte RAM buffer.  When you issue the PutString() it puts 64 bytes of your string into the buffer.  If your string is bigger than 64 bytes, it puts the first 64 and waits until those bytes are transferred.  Then it does the next 64 and so on.  When the last 64 bytes (or less) are put into the buffer, it leaves the PutString() function.  Your next PutString() immediately overwrites the one 64 byte buffer with the new string contents EVEN IF THE PREVIOUS CONTENTS WERE NOT FINISHED TRANSFERRING!.

This is why Motoo is correct.  You need to issue the

while (USBUART_CDCIsReady() == 0u){}

to wait until the previous buffer contents are transferred.

If you time the data transfer with the USBUART and Motoo's fix, you will see about 1MB/sec or faster transfer.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes