Starting/stopping processes dynamically?

New to XMOS and XCore? Get started here.
Treczoks
Active Member
Posts: 38
Joined: Thu Mar 21, 2013 11:18 am

Starting/stopping processes dynamically?

Postby Treczoks » Wed May 15, 2013 11:20 am

Hi!

Another point where I have to find more information is the dynamic handling of processes.

In my system, devices are daisy-chained, so I have an uplink ("previous") and a downlink ("next") PHY. There are two states for such a device: It is at the end of the chain (without a "next" device) or somewhere in the middle (with a "next" device). Having no "previous" device is not an issue as the "previous" device also provides the power ;-)

So I would need two different sets of communication processes in the downlink direction: One for the last device which waits for the link to go up and some subsequent synchronisation and stuff, and another which handles the "normal" up and down communication. Starting with a sync process and moving to a normal transfer process is easy. BUT: Now the user might decide to unplug some part of the chain in the middle of things, and the new "last" unit needs to halt the normal process and return to the "wait for link" process.

Is it possible to kill a process (normal communication process) from another one (which e.g. watches the link status) and restart it, waiting for the link to re-establish?

Or is my idea not the way things are done on XMOS processors?

Yours, Christian Treczoks
User avatar
Ross
XCore Expert
Posts: 768
Joined: Thu Dec 10, 2009 9:20 pm

Postby Ross » Wed May 15, 2013 2:54 pm

Not exactly sure what you mean, but I think you just want to kill and start cores?

Code: Select all


while(1)
{
   if(atEnd)
   {
       par
       { 
              // Processes for end
              atEnd = a_end();   
              b_end(); 
              ....
       }
    }
    else
    {
        par
        {
              // Processes for middle
              atEnd = a_middle();
              b_middle(); 
              ....
        }
    }  
}
The processes could die and return the value atEnd based on some external change (process a can communicate the kill to b via a channel)

Really not sure if this helps you at all?
Treczoks
Active Member
Posts: 38
Joined: Thu Mar 21, 2013 11:18 am

Postby Treczoks » Wed May 15, 2013 3:09 pm

Ross wrote:Not exactly sure what you mean, but I think you just want to kill and start cores?
About right. N cores work on the MII ports, one core watches the SMI interrupt lines and checks the line status bits and maybe some other parameters (all this without impacting the MII processes perfomance or program flow). When this control core is convinced that the line went down, the SMI process kills the MII cores/processes hard and restarts them to get ready for a new "wait for a connect and sync session".

At least, thats what I thought. Maybe there are other possibilities.

Christian
User avatar
franksanderdo
Experienced Member
Posts: 69
Joined: Sat Apr 30, 2011 6:19 pm

Postby franksanderdo » Sun May 19, 2013 8:23 am

Hi Christian,

as far as I understand your question you are planning to run a "coordinator core (SMI core)" and "work horse cores (MII cores)" and want to know if there are other options ?

I believe to have a coordinator core is not such a bad Idea, but I do not yet see the reason to kill a work horse and then reanimate it just because it has one of two links lost!?

I would have the Coordinator just giving the information "Following Link Lost" to the work horse. with that it knows it does not have to listen there for Data any more.
If Connect Sync is done by the coordinator (which I would think so) after sync is done the Coordinaor informs the MII about the synced linked and the MII can (re)start listening to the data.

To think deeper into that I have a question first:
You said that it is possible that some body breaks the chain at any place.
Shall it be automatically 2 chains then? Something like:

|-> MII <-> MII <-> MII <-> MII <-> MII <-|
gets broken
|-> MII <-> MII <||> MII <-> MII <-> MII <-|
and there for it is after
|-> MII <-> MII <-|
and
|-> MII <-> MII <-> MII <-|

Regards
Frank
Treczoks
Active Member
Posts: 38
Joined: Thu Mar 21, 2013 11:18 am

Postby Treczoks » Tue May 21, 2013 9:18 am

Hi, Frank!

Thanks for answering!
franksanderdo wrote:I would have the Coordinator just giving the information "Following Link Lost" to the work horse. with that it knows it does not have to listen there for Data any more.
If Connect Sync is done by the coordinator (which I would think so) after sync is done the Coordinaor informs the MII about the synced linked and the MII can (re)start listening to the data.
Theoretically, yes. BUT: My workhorses timing is so tight that there is probably no time left for error checking, i.e. They just run and suddenly they are stuck in the middle of dealing with a frame.
A re-start of the workhorse implies a certain build-up: resetting the PHY, waiting for end of negotiation (if it ever comes, the last unit will be stuck here forever), initiating contact and getting things in sync, and, finally, pushing data in an endless loop. So, killing and re-starting the workhorse makes perfectly sense.
franksanderdo wrote: To think deeper into that I have a question first:
You said that it is possible that some body breaks the chain at any place.
Shall it be automatically 2 chains then? Something like:
No, there is only one running chain. There is a master device at the head of the chain, which also supplies the power and the overall system synchronisation. You can attach units to this master device in a daisy-chain configuration. Each unit first synchronises with its previous unit upon reboot, and then forwards this timing down the chain. If a sub-chain is seperated, it also looses power, and therefor will reboot if it is reattached to a working chain.
This works perfectly well with our proprietary (but slower) bus with up to several hundred devices in a chain. As we cannot speed up our own protocol where I am more or less doing the PHY in software without raising the parts prices into astronomical regions, we thought of using a common-as-muck, off-the-shelf ethernet PHY to the drudge work. So we are basically abusing the PHY for our own frames, no MAC addresses, no frame types, no switches, just two pairs and power connecting the devices.

Yours, Christian
User avatar
segher
XCore Expert
Posts: 843
Joined: Sun Jul 11, 2010 1:31 am

Postby segher » Tue May 21, 2013 4:55 pm

Hi Christian,

I think you would be best off if you made the process running
on each node an independent program. That is, if there is an
xcore on every node; is there?

Who is online

Users browsing this forum: No registered users and 1 guest