The "best" way depends on several different kriteria like size, MIPS ease of use etc...
A string needs to have a delimiter or an end-of-string indicator to find the place where your NULL-character shall be inserted (which is not transmitted/received as you indicated)
So you need some thought into "what indicates the string's end" (character count, delimiter, ...)
You may use the UART internal routines to accept and retrieve the incoming chars, but a good exercise would be to write an interrupt-driven "Circulat Buffer" (a good target to google) together with some functions as IsCharReady() and GetChar().
I figured out a solution to reading strings (see server.c file in my code).
What I am doing is communicating AT commands with a UART to a WiFi module. The link to the user manual is here.
Another fellow sucessfully used it with the Arduino.
I am having a problem sending commands despite entry into command mode.. I miticusley debugged the code and it is capturing +OK\r\n strings only during the command mode entry process. After that, it does not respond. For a simple test, I am just issuing the AT+ command. It should respond with +OK\r\n.
I initiallly used the PutString method for the UART. Since it is null terminated, I figured this may have been the problem. I then used a sequence of UART_PutChar methods (see main method). No Cigar. I have a feeling it is something simple I am not doing. Please assist.
I would suggest you to change in Server.C your line
while(WEB_ReadRxStatus() != WEB_RX_STS_FIFO_NOTEMPTY);
so that you can see the current status while debugging if any error bits are set. Might be an indication why it doesn't work.
Somehow I am seeing a decimal 32 in the status register after a breakpoint is hit. When I test for this running normally, the error never seems to occur. I cannot tell if this error relates to a breakpoint being hit or whether it is occurring during the reading of actual data. 32 seems to be a UART_RX_STS_STOP_ERROR. The only reason I can think of is I am using the internal oscillator, which has never been a problem with UARTs on the PSOC5 LP. I do not have any crystals on hand at the moment to test this theory. Any other ideas?
Your dec 32 is the FIFO not empty flag, look into Term.h, the shift count is 5, 0x01 <<5 = 0b100000 and that's 32. I would suggest to check the returned status (after the normal processing) by clearing the FIFO - bit, checking for nonzero and having a breakpoint then. I usually have a simple line with a n++; or something alike to keep the BP.
When that BP is never reached, your communication is OK.
I just found this out. When I run the ServerReadString method after the device is in command mode, the returned characters are "/r/n", no matter if I send a command or not. I did setup the error catch system you mentioned. There are no errors set in the status register.
I ran the same method reading strings off my PC and it works flawlessly.