Do you need error control when using USBFS uart ?

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

cross mob
Anonymous
Not applicable

Hi,

this may be a silly question but I am not sure.

Suppose I use the USBFS as Uart to move data from a PC into the PSOC5.

Now this obviously is "a uart implementation over USB bus" .. but the USB bus I think has its own
protocols and stuff.

So, assume I then open a COM4 port on a PC to talk to that and I send a data packet from
the PSOC to the PC and/or vice versa using this "uart".

Because this is actually "simulating an RS232 line over an USB bus" which has its own low level
protocol for moving stuff around do I need some error checking/retry logic ( i.e. packet / ack / nack / crc
of some sort ) OR it's "totally pointless" because the USB implementation itself "already has it" ?

Can I ALWAYS assume that "if I send data to/from PC to that it will ALWAYS get correct OR it's NOT the case ?"

What I ideally ( but I don't know if it's possible ) to do is a simple thing like :

PSCO5: "give me data"

PC : "here it is a packet of something"

Without the need of a CRC/verify if the packet is good/send ack/nack try again/etc.

But I really don't know if the USB communication is "intrinsically safe" or not.

Thanks in advance for any reply.

NOTE : I already implemented "a canonical version" of an XMODEM CRC loader and works but I'd love "to simplify
at max" I don't know if it's doing "a job that is already done cause the USB".

0 Likes
1 Solution
Anonymous
Not applicable

Hi,

doing some extra search around the internet seems to suggest that "If that thing uses Bulk Transfers instead of Isochronous Transfers then data delivery SHOULD be guarantee/reliable - i.e. there's a logic of retry/resend" so "in pure theory" should not make sense to re-implement a protocol over to check for that "because it's already in place" (*).

You should get that "at the cost" that there's no guaranteed bandwidth ( because of course you may never know how many retries/packet lost there could be ).

But it seems "in all this there's a BIG but" .. "the but" is assuming the HW/SW implementation of the USB stuff is perfect and been perfectly tested, which it appears it's not quite always the case and even stuff that "should not act like that" may actually do.

(*) said that "because USB knows but you over it don't" I suppose at very minimal a timeout logic should always be implemented for cases like the cable is broken and/or nothing is replying the other side.

So in short : "Bulk Transfers" should guarantee delivery/retry/error control logic/data always coming/going ( except HW failure ).

View solution in original post

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

When there is something I've learnt in my 40 years of IT career it is "Nothing is safe". I even found a comment deep down in a pre-linux kernel where the author checked a pointer paramrter for != NULL "//Please do not think I am paranoid!".

Anything may go wrong. The question is: What might happen when it goes wrong. Think for Murphey's Law. Injuries to happen? Repairable?? Ignorable??? What might it cost???? Then decide how deep your error checking goes.

Bob

0 Likes
Anonymous
Not applicable

Hi,

I am getting close to 40 years of IT as well However I am not so expert of USB so I wasn't sure if the underlying USB protocol already is "reliable" (i.e. guarantees safe packet transmissions - like let's say TCP/IP ) and/or is "unreliable" ( let's say like UDP where you send something and could get there or never get there so you have to implement a full stack of error control/retransmission ).

OK, true.dat the USB cable could break or being defective between the PC and the PSOC so even that "is never safe" but was just curious if doing a protocol over USB was "redundant" or not ( assuming the cable or the PC or the PSOC does not break ).

Thanks to some luck I don't work any more in those situations where "injuries" or "gazillions in money lost if this SW stops", I had my fair share of that in those times if you would have said you would have used "Windows" or "some micro like this" in those systems they would have fired you on the spot

But yeah "today we are more modern" we use "assert (ptr != NULL)" oh and don't make me start on "LIBUSB" ( the 'OS one' ) or I'll get rabies

0 Likes
Anonymous
Not applicable

Hi,

doing some extra search around the internet seems to suggest that "If that thing uses Bulk Transfers instead of Isochronous Transfers then data delivery SHOULD be guarantee/reliable - i.e. there's a logic of retry/resend" so "in pure theory" should not make sense to re-implement a protocol over to check for that "because it's already in place" (*).

You should get that "at the cost" that there's no guaranteed bandwidth ( because of course you may never know how many retries/packet lost there could be ).

But it seems "in all this there's a BIG but" .. "the but" is assuming the HW/SW implementation of the USB stuff is perfect and been perfectly tested, which it appears it's not quite always the case and even stuff that "should not act like that" may actually do.

(*) said that "because USB knows but you over it don't" I suppose at very minimal a timeout logic should always be implemented for cases like the cable is broken and/or nothing is replying the other side.

So in short : "Bulk Transfers" should guarantee delivery/retry/error control logic/data always coming/going ( except HW failure ).

0 Likes