Hi, 

I want to control DAC Output through USBUART but have problems with getting data from USB.

I assume the function USBUART_GetAll () should get the whole null terminated string? It doesn't in my project. When I send 255 over serial line, the function returns 2 and then next time 55 or 25 and 55. I might have made mistake as this is the first time I am using USBUART.

And the next problem  - atoi returns something odd. Even if I pass '2', it returns something but not 2. It must be something wrongh with my code:

/* check the icoming data through usbuart */
if (USBUART_1_DataIsReady())
{
/* read incoming message */
USBUART_1_GetAll(rdBuffer);

PrintToUSBUART("\r\n");
PrintToUSBUART((char8 *)rdBuffer);
PrintToUSBUART("\r\n");

/* convert ascii to int */
Wave_Value = (uint8)atoi(rdBuffer);

/* Set the value in VDAC_2 data register */
VDAC8_2_SetValue(Wave_Value);

sprintf((char *)wrBuffer, "%u\r\n", Wave_Value);
PrintToUSBUART((char8 *)wrBuffer);
}

Thank you,

Oleg

what I have found so far that  USBUART_1_GetAll(rdBuffer) doesn't receive the whole string. It receives chars separately. So it's working like USB U AR T_GetChar() then.

USBUART_GetAll() returns you the retrieved data. So when you get only a single byte this just means that the PSoC hasn't received more at this moment. And since you call it as soon as _DataIsReady() return yes, this situation is rather likely.

This also depends on how the sender is transmitting - if each character is send in its own USB packet, this also will increase the likelihood of this. If, on the pother hand, the sender sends the whole string as one packet, it should never occur.

Note that _GetAll() doesn't return a null-terminated string, which might explain why atoi doesn't return what it should.

thank you very much,

that is clear now. I find the functions are not described well in the reference document. At least for me.

What is then suggested method to get the message? Using getchar and checking the terminator probably? 

Oleg

If you cannot ensure that the senders sends the whole message in one go, you need to handle single characters. Just use _GetChar() and construct the message, until you reach the separator. Just remember - you are basically doing serial communication!

I think the _GetAll() is just there because USBUART is just a special version of the generic USB component, where it makes more sense. The UART mode is just character-based, there is no notion of a 'message' there.

The speed of UART transfer is relatively slow compared to the speed of the processor, so you will need something to decide if the message you expect is already complete or if you have to wait for some more characters.

There are some approaches to ensure that.

1st. Messages of fixed length.

2nd. The message itself contains information about its length.

3rd. A "finish"-character, usually something like Newline (0x0a) Carriage Return (0x0d) FormFeed(0x1a) or Escape (0x1b). All these characters are taken from the ASCII-set of "Non-Printable" chars, which start with the "Space" (0x20)

Of course the sender of the message has to comply to one of the above rules.

Bob

I vote for Bob's third approach, as it is self healing, eg. if a message

becomes corrupted, the 3'rd approach acts as a message framing byte.

Of course one can always consider applying an ECC algorithim to the

message but that takes BW and limits max messaging speed.

Regards, Dana.

Some basic approachs to managing traffic -

http://en.wikibooks.org/wiki/Serial_Programming/Error_Correction_Methods

Regards, Dana.

But when the message becomes corrupt, the frame delimit might be the one getting lost :)

But USB already has its own transport-level protocol, ensuring that nothing gets lost. So when using USBUART, there should be no need to add another protocol on top of that (provided that you trust the other side to send its data correctly).

Thank you so much for such a great attention to my little problem.

I'll stay with getchar approach and \r\n termination as it's something I've used before. Normaly psoc's APIs worked well for me even if I didn't understand what they did. But not this time.

I've just checked the simple echo back and it still doesn't work:

if (USBUART_1_DataIsReady())
{
uint8 temp;

/* get the char into the buffer */
temp = USBUART_1_GetChar();

/* echo the char back */
USBUART_1_PutChar(temp);
}

this perfectly  works  (nearly - i think it should send chars back in column once I heat enter but it reports them in a row)  with a single char sent from terminal but once it goes to 3 chars, the psoc strarts loosing chars and then sends rubbish back. Is something wrong with my code again?

thanks

Correct me if I am wrong, the only perfect transport protocol would take an infinite

amount of time, hence there will never be perfect packet transport. So framing

objects, retransmission, all fall under Shannon limits.

Regards, Dana.

I wonder if someone used usbuart to send data to chip. I'd love to have a look on implementation. The exapmple project from cypress sends only a single char to the chip and that works well. but once there are more chars in a message the  USBUART_1_DataIsReady() seems do not work correctly

You can see my old project (comments in Russian language).
http://mylab.wmsite.ru/ftpgetfile.php?id=59
Project is made for PSoC Creator 1.0 and can be found here.
http://mylab.wmsite.ru/moi-razrab/kardiograf
I hope this will help a bit

thank you very much for sharing the project. Good ideas but the data in the project are sent from the chip to computer only which also works well in my design.

I have troubles with receiving string sent from pc terminal software to psoc chip. None of the methods I've used gives good results. Once the string is longer then 2 chars, psoc looses the rest 

I asked for help with USBUART to the technical support. Dan Sweet <drsw@cypress.com> very quickly helped to correct my project

There is an USBUART example project in Creator (at least for 1.0). It runs the PSoC in echo mode, meaning everything you send to is gets echoed back to the PC. This should work for you. (It did for me, just tested it with a -001. Remember the local echo, and you might also change the control lines to see this on the LCD).

Here is an example project, for the -001 kit with a PSoC5, which takes the input from USBUART, and prints it (line by line) to the LCD.

An additional note: I'm testing this connected to a Linux box. When I connect the PSoC to it, I get several lines of  'AT+GCAP' on the LCD. Turn out this is from the modem-manager program which tries to find out whether the new device is a modem or not. I uninstalled it since the last modem I owned was about 10 years ago... Now everything is fine.

Thanks a lot. Working now. The problem was the different function had to be used. I had the same advise from support. 

Cheers,

Oleg

What do you mean with 'different function'? Do you mean waiting for the USB to be ready before you send data back (USBUART_CDCIsReady)?

@Dana: yes, there is no perfect protocol. The CAP theorem states that you need todecide whether you want to skip one of consistency, availability and partition tolerance (e.g. split cables). As far as I understand USB it does handle the split cable scenario, but it makes the connection unavailable in these cases. I think I can live with that :)

See http://en.wikipedia.org/wiki/CAP_theorem

Not sure the CAP theorem is relevant in a point to point application. Does that qualify as

a distributed computing system ? And seems like theorum still evolving -

http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed

The point I was making about self healing is predicated that, yes the frame

delimiter could take an error hit, but likelihood it permanently becomes the only

byte(s) to take continuous hits in noise environment unlikely, unless of course a lot of

correlation in the noise relative to the messaging system. That each time

the framing byte(s) are error free it re-sychs the message packet, hence self

healing. And as always, we are dealing with noise, the enemy of BW and error

rates. Ala Shannon.

Regards, Dana.

Sure, the CAP theorem applies here too. You have the PC and a PSoC, connect by a cable - this is clearly a distributed system (because you have a link between them which can fail). And the communication wants to ensure that both parties have the same state (in the case of the OP, he wants to know both about the same DAC output value). So we need to make a decision: when somethings goes wrong (cable gets cut) what do we do? Do we stop the world and wait till we can communicate again (no availability). Do we just continue with sending bytes and skip updating the DAC (then we are inconsistent). Or do we pretend it won't never happen (no partition tolerance).

Our case is simpler that a real distributed system, since only one side is making updates, and it is not both sides trying to sync on the same set of data. But I think you have the same constraints which apply.

And regarding the self-healing: yes, with a frame designator, the communication will eventually self-heal. But you will have an inconsistent state inbetween. This might or might not be problematic (e.g. image you only transmit delta-values - then a missing byte can be a real problem).

But as I said: USB more or less guarantees that everything you send will actually be received, in the proper order and without missing data. If there are any problem, this will be communicated to both ends, so they can react to that (the link will be dropped).

hi, I see you've been busy here :)

the application note you've sent me and support suggested using something like this

if (USBUART_1_DataIsReady())//Wait till data is received
{
     count = USBUART_1_GetCount();//count will store the no: of bytes received
     /* get the char into the buffer */
     USBUART_1_GetData(temp, count);
     /* echo the char back */
    USBUART_1_PutData(temp,count);
}

where number of received bytes also is taken into account. and this perfectly works again for echoing messages back. but once I start changing it to extract the incoming message it goes wrong again. 

I've tried for a couple of days with no luck. These function seem to be not reliable when it goes to something more complicated then echoing chars back.

Or it's me who doesn't understand usbuart functionality. that's why I asked about any project which involves processing messages from pc through usbuart. there is none on the forum, I've been through all the posts with usbuart words inside. never had problems with real uarts but this is something different

getting desperate,

Two things:

1. when sending data back, you need to make sure you are send (with the USBUART_CDCIsReady() function). Otherwise you might overwrite data in the transmit buffer. (See the example project of PSoC Creator for that)
2. Maybe you can post your example project here (create a project bundle and attach the zip archive), so we can have a look (and maybe debug it if it doesn't depend on special hardware)

hli

one of my trials - I try to  sent string terminated by '*' but I don't get the message back. I tried debugging but that seems don't work with usbuart 

I'm pleased to say I overcome the problem. It happened becouse I didn't understant psoc APIs. but they are not well documented though.

usbuart functions get data from pc and put them into the specified buffer array. the problem is the functions don't get all the string at once but into pieces and every time the function called, it writes the new piece over the previus one in that array.

so every time the function gets the data, they have to be copied  to another array and added until string termination received.

Easy now. And thank you very much to all for the help. Test project attached. Note the string terminator is '*'

Oleg

this might help in UART functions

http://www.cypress.com/?rID=34582