operator :> and <: versus inuint() outuint()...

[philwick]

Hello,

In the USB AUDIO 2 reference design the code makes a heavy usage of channel send/read routines named inuint(), outuint(), inct() etc... The XC langauge provides in/out operator :> and <:. I've read somewhere that these operators are "by default" blocking (unless using a streaming channel). I have some questions regarding the communication using channels:

- if outuint() is called on a "normal" non streaming channel, is it blocking or is there some sort of fifo between both ends of the channels? If yes, what is the size of this fifo?

- there is a piece of code in the USB AUDIO2 code (around line 639 in mixer.xc::mixer1() and line 675 in mixer.xc::mixer2() ) which is I believe used to synchronize both threads which looks like this:

   MIXER1                      MIXER2

    outuint(c, 0)      ->        inuint(c)

   do something                do something

   outuint(c, 0)        ->      inuint(c)

   inuint(c)             <-       outuint(c, 0)
   do something                do something

   ....
This code make me think that 'outuint' is non blocking while inuint() is. Am I right?

- Is there some API like try_inuint()?

- what is the behavior of outuint() when called on a streaming channel?

- there are APIs using the concept of "Control Token": chkct(), inct() and outct(). Is there an equivalent when using the operators  :> and <: ?

- is there performance drawbacks behind one or the other way to use channels?

Thank you.

[srinie]

Normal channels - 32-bit (4 byte) size before it goes to blocking.

Disassemble the code to see how exactly the sync handshake works - refer to '*CT*' usage from the manuals.

A general comment: use interfaces where ever the design permits. It takes care of the sync primitives, channel usages etc.,