Documentation on Channel Functions?

[Treczoks]

Hi!

[Although I believe that request for documentation should be a case for the help desk and not for the users forum, I was asked to put my request here instead into the ticket system]

In the XS1 library documentation (X6020D) there is a whole chapter on channel functions.

Sadly, they are just short description of a bunch of functions. Is there a concise documentation on how this stuff can be actually used? Some things make me wonder if they are needed or used at all, some are directly incompatible with the :> and <: notation, and a lot of points are still unclear to me.

What makes me wonder is:
- I'm using streaming channels in my app, but I had never the necessity to use start_streaming_master() et al.
- Looks like those streams can contain both data and control tokens, with some limitation on what a valid control token is. The control tokens are bytes, the data can be bytes or ints. How does this system handle control tokes mixed with int data tokens?
- Can I as an "end user" in XC somehow send a control token on my own, indicating the start of a data set, and then send my data? How do I untangle them at the receiving end?
- Does stestwct() wait for any token and just tells me what kind it is so I can use either inct() or inuint() to get the data?
- Am I right to assume that I need stestwct() instead of stestct() if I'm using inuint() for receiving data?

So: is there some more verbose documentation, maybe even some examples on how to utilize these functions?

Yours, Christian Treczoks

[sethu_jangala]

Hi,

The documentation is available here: https://www.xmos.com/xs1-library

You shouldn't be using the start_streaming_master(), etc. functions - they can cause deadlock in certain situations. They've been deprecated for sometime and they will be removed in the next version of tools. The functions for using control tokens are rather low level and can be used to implement custom protocols. Designing a custom protocol that is free from possible deadlock / race conditions due to packet overtaking is difficult, so it is not recommended unless you have no other choice.

Sethu.