Help me understand Control Token Usage

[bearcat]

After reviewing the USB code, I believe the only control token programmed is the XS1_CT_END, which tells some threads to exit. In general, on thread start, some initial values may be sent as a special case over the channel.

If the XS1_CT_END is sent, is that used only at my application level?

I see other control tokens defined, which are classed as application tokens:
#define XS1_CT_END 0x1
#define XS1_CT_PAUSE 0x2
#define XS1_CT_ACK 0x3
#define XS1_CT_NACK 0x4
#define XS1_CT_READN 0x10
#define XS1_CT_READ1 0x11
#define XS1_CT_READ2 0x12
#define XS1_CT_READ4 0x13
#define XS1_CT_READ8 0x14
#define XS1_CT_WRITEN 0x15
#define XS1_CT_WRITE1 0x16
#define XS1_CT_WRITE2 0x17
#define XS1_CT_WRITE4 0x18
#define XS1_CT_WRITE8 0x19
#define XS1_CT_CALL 0x1a

I suspect the read/write n-8 are used by the xs-1 routines like outuint?

If I want to send multiple variables over a channel, lets say on change only, can I define a control token for each variable (assume a few not alot) then sent the token then the value outuint? Arrays could be handled similiarly. If that works, it seems a much more robust method then send x int's when the thread starts. If I have the concept right, why doesn't XMOS use it?

Is there a range of values that is for application use (not by XC compiler)? Or am I all wrong?

[monk_is_batman]

I believe the only control token programmed is the XS1_CT_END, which tells some threads to exit.

This could be possible, the END token is used to free the connection of the channel and inform the target that it is doing so. This is similar to PAUSE, but that does not inform the target (PAUSE goes in one end and does come out the other).

I suspect the read/write n-8 are used by the xs-1 routines like outuint?

What makes a control token different from normal data you send through a channel is that you do not use the normal routines to send them. There is a special set of instructions for using these (inct, outct, testct...). These all handle sending and receiving control tokens. If you try to read in a control token with a normal in (normal instruction for reading from a channel) it will raise an exception. This is why control tokens are useful to your application, they can protect communication flow in your program.

If I want to send multiple variables over a channel, lets say on change only, can I define a control token for each variable (assume a few not alot) then sent the token then the value outuint?

I believe there are a total of 255 control tokens, some of which are used like END and PAUSE listed above. I think this could make a good system controlling variables if you don't have too many.

On the end of page 4 of the XS1 system spec it talks about ranges for control tokens and what they are used for. http://www.xmos.com/system/files/xsystem.pdf

You also might be able to find a little bit more information from this thread http://xcore.com/forum/viewtopic.php?f=25&t=585. I was asking a bunch of questions about control tokens not too long ago.

[bearcat]

I had looked at the XMOS reference manual, but I didn't look close enough where they do explain the pre-defined tokens and that you can use the other ones anyway you want.

I think I will try the control token to variable and see how that works. I also wasn't aware they were two forms of the instruction with the immediate form limited in token number. Not sure if this is an issue using XC or not, I am sure I will be looking at the dis-assembly anyways.

Is the XLINK a fault tolerant link (i.e. retry on error)? I have not found anything on this subject. They do say they send an even parity bit last to return the channel to low power. Do they use this parity check and provide a re-send on parity error?

I have not found a forum search, is there one?

[Bianco]

You can search on the forum here: http://xcore.com/forum/search.php

Xlinks are not fault tolerant, there will be no retransmission when an error occurs despite the fact that the two-wire link has a parity bit. You can however implement fault-tolerant protocols at the application level.

[bearcat]

Thanks for the replies, and the link for the search.

After attempting to do the above, I quickly realized there is no instruction to check if a token is ready in the channel. That seems curious the instruction is not there. Without such an instruction you cannot perform any un-solicited (unsynchronous) messaging. Maybe there is a status register someplace, but that's not realistic to use I suspect.

So now I understand why.

In general, the approach shown first is not possible. Yes, using synchronous comms can perform the above, but at either greater complexity, less efficiency, or an extra thread or two using events or interrupts or indexes. So I will not worry about control tokens any more, as I will probably only use the end token to end a thread as the reference firmware uses.

[segher]

You can do a getps on your channel end, and see if bit 4 (the bit with value 0x10)
is set; if so, there is data available to receive on that channel end.

I don't think this is documented. Tested to work on a G4.

[monk_is_batman]

This sounds like it will be very useful. How did you learn about this? Do you think it is likely to work on devices other than the G4?

[segher]

See http://www.xcore.com/projects/xs1-disas ... jtag-tools .

If you hack the psregs tool a bit, it can show the registers for resources other than
0x0b (processor status). Most of it isn't so hard to understand; just flip something
and see what changes.

It is documented that bits 7..0 are the resource type; this is wrong, 3..0 are the resource
type, and 7..4 is register number (for example, 0 is the main control reg, 5 is the data
reg (setd), 6 is the clock source reg (setclk)).

I think most of this will work fine on L chips; some bits might have changed though.
I don't have an L to test.