Why is this slow? Working on the concepts

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
landon
Experienced Member
Posts: 71
Joined: Mon Sep 06, 2010 4:05 pm

Why is this slow? Working on the concepts

Post by landon »

I'm still just learning XC and the XMOS - I have an XK-1 dev kit.

I starting working with concurrency features and created this little example to work with channels:

Code: Select all

transaction thing1( chanend channel )
{
	while( 1 )
	{
		channel <: 'a';
	}

}

transaction  thing2( chanend channel )
{
	char thing;

	while( 1 )
	{
		channel :> thing;

		printchar(thing);
	}
}

int dr_suess()
{ 
  chan thread_channel;
  
  par {
	  master { thing1(thread_channel);}
	  slave { thing2(thread_channel);}
  }
  return 0;
}


int main()
{
  par
  {
    on stdcore[IO_CORE] : dr_suess();
  }
  return 0;
}
The result is a string of 'a' characters very slowly marching across my console window in XDev.

I figured it would just blaze but it's about 2400 baud.

I also tried this (no transactions):

Code: Select all

void thing1( chanend channel )
{
	while( 1 )
	{
		channel <: 'a';
	}

}

void thing2( chanend channel )
{
	char thing;

	while( 1 )
	{
		channel :> thing;

		printchar(thing);
	}
}

int dr_suess()
{ 
  chan thread_channel;
  
  par {
	  thing1(thread_channel);
	  thing2(thread_channel);
  }
  return 0;
}
Same results - 'a' just slowly chugs out of the console.

Also tried it with this variation (skipped dr_suess() thread):

Code: Select all

int main()
{
  chan thread_channel;
  par
  {
    // on stdcore[IO_CORE] : dr_suess();
	  on stdcore[IO_CORE] : thing1(thread_channel);
	  on stdcore[IO_CORE] : thing2(thread_channel);
  }
  return 0;
}
same results.

I doubt anything is "wrong" per se, except I don't understand why it's so slow....I suppose printchar() could be blocking, but it's only got one character to push, so I didn't think it would hang things up that much. Maybe my expectations are whacked.

I expected thing1() to quickly fill up the channel and then block...when I think of blocking I think of the thread then yielding, but maybe I'm conceptually broken. I could see it blocking....then timing out the thread before thing2() got run...is that why it's slow?

What's a better way to get the kind of fast output you would expect to see when one thread is constantly feeding another data via a channel? Is there a concept of a thread yielding when it blocks?

Landon


User avatar
rp181
Respected Member
Posts: 395
Joined: Tue May 18, 2010 12:25 am

Post by rp181 »

Channels are completely synchronized. Inputting 'a' blocks the thread until the other side receives the 'a'.

printf and printchar are slow. The communication is through the FTDI (i think), where slow is normal. I think the threads are working normally as you expect, but the communication is delayed. Try adding a new line "\n" after you print something, which should flush the characters to the computer. That way, the 'a's wont be as delayed (will still be slow).
User avatar
Berni
Respected Member
Posts: 363
Joined: Thu Dec 10, 2009 10:17 pm

Post by Berni »

Yeah the debug print commands are always very slow. If you need something faster you will need to use a real com port for it.
User avatar
landon
Experienced Member
Posts: 71
Joined: Mon Sep 06, 2010 4:05 pm

Post by landon »

I am glad to know it's mainly the print. The thing that doesn't make sense to me is that I can dump data out a UART, through an FTDI based serial to USB converter and it goes fast. So, there must be something more to it than just the FTDI translation....regardless, at least you have all confirmed it's not something stupid I'm doing with threads.

Thanks for all your responses. I appreciate the guidance as I come up to speed. I'm sure I will have more questions!

Landon
User avatar
Berni
Respected Member
Posts: 363
Joined: Thu Dec 10, 2009 10:17 pm

Post by Berni »

Well the FTDI it self provides that com port you can use for it. It will go up to 115200 baud.
User avatar
landon
Experienced Member
Posts: 71
Joined: Mon Sep 06, 2010 4:05 pm

Post by landon »

Hi Berni,

Thanks for your response. I had asked a question about how the XJTAG2 UART can be effectively used to push data to the XDev console over here: http://www.xcore.com/forum/viewtopic.php?f=26&t=695

Pretty much got the answer "it can't" - is that an incorrect conclusion? If not, how do you typically use it?

Because I find it easier to hook my serial to USB converters up to the expansion ports (fem-fem jumper wire) than to the UART pins of the XSYS->XJTAG, I don't see an effective way to use the XJTAG and standard UART pins at the same time. I remap the UART pins to expansion pins, and connect there. Then I use the 'screen' command to connect to the serial to USB in order to actually see UART output. Feel free to disabuse me of my procedures or misunderstandings. I could easily be missing something in how people use the XJTAG and designated UART pins.

I would like to be able to direct UART output to the XDev console and type UART input into the console (use the console like a real console ) - same spot where I see printstr output. That's my wish, but doesn't seem like the system is ready to do that (easily.) Thanks,

Landon
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am

Post by segher »

Berni wrote:Well the FTDI it self provides that com port you can use for it. It will go up to 115200 baud.
3Mbaud, actually.
User avatar
Berni
Respected Member
Posts: 363
Joined: Thu Dec 10, 2009 10:17 pm

Post by Berni »

segher wrote: 3Mbaud, actually.
Well on the XTAG i could only get it up to 115200, if i tried to open the port at any higher speed i got an error.
User avatar
rp181
Respected Member
Posts: 395
Joined: Tue May 18, 2010 12:25 am

Post by rp181 »

I've found that comm to the computer sucks, so i have actually been doing everything over a wireless link and UART. A pity that 1W transmitter is used to transmit less than a foot =p.

I thought the XTAG could go up to full USB 2.0 speed? And if it is not a port, what is the windows 7 driver for (on the XTAG-2 product page)?
mashc5
Member
Posts: 10
Joined: Sat May 29, 2010 6:06 am

Post by mashc5 »

The jtag isn't supposed to be high speed serial stream. It relays the status of registers and memory and such and allows you to have breakpoints built into hardware and trace program execution at the instruction level. If I'm not mistaken when you send a char through standard out (with printf or putchar) it actually pauses the thread execution while it sends it through the jtag sub-system. However, the ftdi chip has actual uart pins on it as well. The xc1a has 2 io pins hardwired to these pins on the ftdi so you have a standard serial to usb connection right out off the box. I do not know if the xtag has these.

I believe there is a library on the xmos website that allows you to redirect printf through the uart or any other interface you want. Its log.xc or xlog.xc or something like that. You'll still have to view the stream in a serial terminal but you shouldn't need any external hardware like your using now.