Can anyone pull my head out of the clouds

New to XMOS and XCore? Get started here.
User avatar
leon_heller
XCore Expert
Posts: 546
Joined: Thu Dec 10, 2009 10:41 pm
Location: St. Leonards-on-Sea, E. Sussex, UK.
Contact:

Post by leon_heller »

64k per core (256 kbytes total) should be plenty for most applications. You have a 4 Mbit flash memory (512 kbytes).

Just program the on-board flash memory with your application if you want it to run when the board is powered up.
Last edited by leon_heller on Fri Jan 15, 2010 10:33 pm, edited 1 time in total.


Heater
Respected Member
Posts: 296
Joined: Thu Dec 10, 2009 10:33 pm

Post by Heater »

As it stands there is 64K of RAM per core. This can be used to hold both code and data.
There is also 8K byte (is that right?) of One Time Prom (OTP) per core that can be used for code and constant data. This is One Time, not EEPRPOM or FLASH.

What does this mean?

For development and debugging one downloads code to RAM from the PC, into one or more cores RAM, runs it, tests it, iterate, iterate.

For the final release product one could, if the code is small, blow it to the OTP and that's it.

If the code is bigger, or there is some chance you want to update it in the future then what?

Well if the OPT contains a boot loader it can fetch the code from a SPI FLASH. On boot up the boot loader in OTP runs, fetches the application code from SPI FLASH and loads 1, 2 or 4 cores with it. The XDE can program such a SPI FLASH easily for you.

But now consider, you can have a system with many XMOS chips. Only one of them needs the boot loader in OTP to run. It can fetch code from it's SPI FLASH to boot up many other connected XMOS devices. See the Video pointed at from the news page of this site.
User avatar
paul
XCore Addict
Posts: 169
Joined: Fri Jan 08, 2010 12:13 am
Contact:

Post by paul »

Hey seulater,

I see from your other threads that you are putting XMOS down for the moment. From this thread I am intrigued to find out a bit more about what kind of applications you were wanting to implement.
Then the XCORE is useless for code sizes > code + ram. which makes it only good for small applications.
Well, it depends on what you define as 'small' - as you may have spotted on the XMOS website we are able to support a stereo in/out with SPDIF USB Audio Class 2.0 device - there is also a multichannel implementation that can handle 10 in/out using our 4 core device.

Also, we run quite a serious AVB application on our 4 core device (http://www.xmos.com/avb)- which I wouldn't necessarily describe as small.

So, this is what also intrigues me as to what you application is.

Also, as for connecting memory to the device - for future reference (and for anyone else with the same question) there is a single core SDRAM interface - http://www.xmoslinkers.org/projects/sdram
Paul

On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
User avatar
seulater
Member++
Posts: 28
Joined: Sat Jan 09, 2010 11:04 pm

Post by seulater »

Hi Paul,
The main reason for me leaving is that its just taking me WAY to long to get up to speed on doing simple tasks with it. The biggest mental block is if some pins that connect to a external device are on 2 cores it "seems" a hassle to talk to it from yet a 3'rd. (though it must be easy because look at what everyone is doing with it). It making me pissed that i am not comprehending it.

I look at the XMOS examples on their site and say this part is AWESOME, DAM AWESOME. Yet as i try to do the simple things in life like spin the leds around the processor on the XC-1A kit it was a learning curve to say the least. Maybe, i am expecting to much from myself in learning the Environment, XC and the 4 core concept all at once. However, i have done that before many times with new products and its just not taken me this long to do simple things like this in the past. Maybe too i am getting older and loosing my edge :( (though i am not ready to admit that just yet).

If i have a "tone" about me, i dont mean to. I want to use this part so bad because i can see what it can do, yet i am moving like molasses with it, which is driving me nuts and frustrating the crap out of me.

The whole 64k memory per core thing has me in utter confusion when people speak of debugging.
If i slap a simple color LCD with 3-4 fonts sizes and a couple jpg's in there, that will chew up a good 200k. That is not even including any code yet. so if i debug, how is it going to cram this 200k of data into ram and then on top of that my code ? On top of that the debugger (so i am told) downloads my code to the 4 core total of 256k. ok, no problem. Then how is it that the debugger can have access to the total ram but i cant and i am stuck with 64k for the core i am in. Very confusing....

I dont debug, i always compile as the released version. so the above statement is not all that concerning to me. Just curios as to where its all going. So that leads me to my next curious thing.
i cant see me ever using the XS1-G4 part and my code is <8k for the OTP. So, that means that i have to place it another flash part of some type. I have not seem how this is done and how it works and what are the limits of it.

I think lastly, which is what sealed the deal for me leaving.

When i created a new project it included a file ( i think it was XC1A.xn) that clearly showed which core had what pins and gave then a name as well for me to use in my code. That too had problems, because though it gave a pin number of some type like "XS1_PORT_1H", where did they get that from. i could not find document that showed this. I was told to look at the Port Pin Table in the data sheet, but again there was no XS1_PORT_1H in there. On top of that the demo for the XC-1A kit gave me cramps. In that demo i could not find where the pin descriptions were at.
so i was like, OK.... i though i needed this .xn file to tell the processor what pins are going to be for what, yet this demo does not have it. ARGH!!!!! That is when my head exploded and i gave up trying to figure out things that should be in one simple document very well explained.

It seems there is just too much assumption on the writers of these documents that we know the product as well as they do. I think what they should do is take a third person who dont know jack about the product, teach them it and then have them write a nice document to explain it from the ground up.


I know this is crazy long, sorry. I want to use the part bad, because i believe its very powerful.
The proof is in the pudding as in the products i see using it and what they are doing. know its me limiting it and not it limiting me. So i am desperate for help and want it quickly as i will pull the sale of it off ebay to keep it and keep trying if i can get some good explanations for things.

To answer your question.
my application will consist of 2 main things.

#1) a 480x272 color TFT lcd with touch screen.
#2) VoIP internet phone.

I know, i know, that there are very similar things XMOS has done just like that and i would say even more complicated than this.

Now the memory for the display is going to be, 480 * 272 * 3 (R,G,B) . my VoiP needs 32k for the RX buffer and 32k for the TX buffer. So since i have to add external RAM for all this. I wanted to know how the heck do i request data from the ram from one core, when the ram part is psychically connected to 2 other cores. I will look at the link you send, maybe that will clear things up for me.


Sorry Guys this was so long, i am just desperate for understanding this product.
User avatar
leon_heller
XCore Expert
Posts: 546
Joined: Thu Dec 10, 2009 10:41 pm
Location: St. Leonards-on-Sea, E. Sussex, UK.
Contact:

Post by leon_heller »

What RAM chip are you going to use?

Leon
Heater
Respected Member
Posts: 296
Joined: Thu Dec 10, 2009 10:33 pm

Post by Heater »

seulater: OK let's try and sort this out. Don't give up so easily, I think programming for the XMOS could be a lot of fun. It may not fit the application you have in mind but you might soon see other uses for it.
..how is it that the debugger can have access to the total ram but i cant..
Not totally sure but don't forget the down loader/debugger is using JTAG and so could quite well be able to "see" all the RAM and all the registers of all the processors. Alternatively cores can boot themselves from data send down their links so one core can boot all the other cores with program fetched from a SPI FLASH or from one of it's external links or whatever.
I dont debug
That is an interesting statement. Presumably you do test your finished code. Is it really so that you have never found a bug to fix? Or do you mean you don't use a debugger for test and fix process?
...that means that i have to place it [ the code ] another flash part of some type...
Yes indeed. A number of the dev boards come with a SPI FLASH for exactly that purpose. The XDE can download and program that SPI FLASH. The SPI FLASH type and the pins it is connected to gets specified in the .xn file.

Now on to the RAM problem. Just happens I have a similar requirement. I want to run an emulation of my favourite 8 bit processor, the Motorola 6809, on an XMOS. That requires 64K bytes of RAM for the 6809 code/data to live in. The only way to do that is to make use of RAM on other cores.
The plan is to run the emulation on core 0 and then some RAM "server" threads on some other cores. The emulation can the read and write to RAM on other the other cores by sending the address and required operation, read or write, over channels to the RAM servers. The data bytes to be read or written are also exchanged over the same channels.

Below is what I have come up with so far. It has a single RAM server thread on core 1 and a thread on core 0 that tests it.

Code: Select all

#define RAM_SIZE (40 * 1024)
#define READ_OP  1
#define WRITE_OP 0

// Array of "remote" RAM
static unsigned char ram_array[RAM_SIZE];

// A RAM "server" thread
void ram_thread(chanend ramChan)
{
	int address;
	unsigned char operation;
       
        // Loop forever serving up RAM storage	
	while (1)
	{
		// Read RAM address from channel
		ramChan :> address;
		
		// Make sure we don't go out of range
		address %= RAM_SIZE;
		
		// Read the operation, read or write, from channel
		ramChan :> operation;
		if (operation == READ_OP)
		{
			// A read operation, return the addressesd byte through the channel
		    ramChan <: ram_array[address];
		}
		else
		{
			// A  write operation, get the byte to write from the channel
			ramChan :> ram_array[address]; 
		}
	}
}

// Write to a RAM "server" thread on the other end of a channel. (On  another core,  say)
void ram_write(chanend ramChan, int address, unsigned char data)
{
	// Send address to be written to the RAM thread
	ramChan <: address;
  
	// Send "write" operation command
	ramChan <: (unsigned char)WRITE_OP;
	
	// Send the data to be written to the RAM thread
	ramChan <: data;
}

// Read from a RAM "server" thread on the other end of a channel. (On  another core,  say)
unsigned char ram_read(chanend ramChan, int address)
{
	unsigned char data;
	
	// Send address to be written to the RAM thread
	ramChan <: address;

	// Send "read" operation command
	ramChan <: (unsigned char)READ_OP;

	// Get the read byte from the  RAM thread
	ramChan :> data;
	
	return(data);
}

void ram_test_thread(chanend ramChan)
{
	int address = 0;
	unsigned char data = 0x55;
	while (1)
	{
		address = 7987;
		ram_write(ramChan, address, data);
		data = ram_read(ramChan, address);
		address++;
	}
}

int main()
{
       // Channel to use between  RAM "server" and a RAM user thread.
	chan ramChan;

	par
	{
		// Run the RAM "server" on core 1
		on stdcore[1]: ram_thread(ramChan);
		
		// Run the RAM "server" tester on core 0
		on stdcore[0]: ram_test_thread(ramChan);
	}
	return (0);
}


Can't say if this code actually works. Not that I don't do debugging but I don't have any XMOS hardware yet. I pretty confident about it though.

Looks like a lot of code for a RAM! But think about it, here we have two threads on two different processors and all the communications between them sorted. Not bad really.
Last edited by Heater on Fri Jan 22, 2010 7:36 am, edited 1 time in total.
User avatar
leon_heller
XCore Expert
Posts: 546
Joined: Thu Dec 10, 2009 10:41 pm
Location: St. Leonards-on-Sea, E. Sussex, UK.
Contact:

Post by leon_heller »

He said that he uses printf for debugging because he doesn't trust JTAG.

Leon
User avatar
seulater
Member++
Posts: 28
Joined: Sat Jan 09, 2010 11:04 pm

Post by seulater »

Guys first i would like to thank you for your time in helping me grasp this. I will try to keep up ;)

For Leon's first post, i will be using a 512K x 8 part ALLIANCE AS7C34096A-15TC.

Now to Heater.
That is an interesting statement. Presumably you do test your finished code. Is it really so that you have never found a bug to fix? Or do you mean you don't use a debugger for test and fix process?


Sorry, i should have been more clear. I of course test & debug, but not using a debugger. If i run into a problem i will slap some printf's here and there. To be honest, i never did quite understand all the hype for debugging via JTAG or any other means. printf is all i have ever needed.

Yes indeed. A number of the dev boards come with a SPI FLASH for exactly that purpose. The XDE can download and program that SPI FLASH. The SPI FLASH type and the pins it is connected to gets specified in the .xn file.
ok, i see the .xn file when i create a new project, but the demo app for the kit does not have an .xn file in the directory tree. which threw me off.
Can't say if this code actually works. Not that I don't do debugging but I don't have any XMOS hardware yet. I pretty confident about it though.
Dont have any hardware you say, i know a guy selling 2 kits on ebay ;)
thanks for the code post. I will pick through it. I learn best by examples.

back to Leon,
He said that he uses printf for debugging because he doesn't trust JTAG.
Its not that i dont trust it, i just do see the need to use it for debugging. many moons ago i was working with some kit that i dont remember. i was trying out the debug thing and everything was going fine. when it came time to release it my code ran faster then it did in debug mode. My delays were quicker and thus broke it. Now i cannot say or remember the method it had for debugging to cause this. So i just went back to my method of using printf which have never failed me and never needed anything more to solve the problem.
User avatar
leon_heller
XCore Expert
Posts: 546
Joined: Thu Dec 10, 2009 10:41 pm
Location: St. Leonards-on-Sea, E. Sussex, UK.
Contact:

Post by leon_heller »

You can interface that SRAM to a single core. See the XDK schematic.

Release code always runs faster than debug code. I don't see why that should cause any problems.

Leon
User avatar
seulater
Member++
Posts: 28
Joined: Sat Jan 09, 2010 11:04 pm

Post by seulater »

You can interface that SRAM to a single core. See the XDK schematic
i have, there are only 16 io pins per core on the header. so it would take at least 2 cores to connect the ram.

Release code always runs faster than debug code. I don't see why that should cause any problems.
if you wrote a serial routine to clock out 24 bits and created a delay in between the bits, where the delay was critical, it would not work right from debug to release.
Post Reply