Can anyone pull my head out of the clouds

New to XMOS and XCore? Get started here.
User avatar
seulater
Member++
Posts: 28
Joined: Sat Jan 09, 2010 11:04 pm

Can anyone pull my head out of the clouds

Postby seulater » Fri Jan 15, 2010 7:05 pm

I have an XC-1A kit, and I have the book "Programming XC on XMOS Devices" and have read it.
while reading the book i was like ya its fast, but there is no built in peripherals. so you need to manually do everything, like UART, SPI, I2C , which i guess is no biggie but it chews up threads.
Not to mention to have such a fast processor with only 64k seem a bit strange to me. Then in the book i read on pg.12 "XC does not support floating point" i was like jeez, this thing is worthless compared to some ARM9 out there.

I have watched many utube videos from the XMOS site, and on things people have made and done which have all been impressive. If it was not for seeing these videos and all the impressive things XMOS is doing i would have just thrown the kit out after reading the book. The book to me explained things but in go great detail for me to comprehend things like sharing memory across cores. I felt there should have been more to that section than was there. I am still left bewildered about how to do that as there are different ways to share memory and why would i pick one over another method. It also seems that when sharing memory using the "chanend" method it only works accost 2 cores. I may be wrong on that.

So.... since XMOS is doing impressive things, that must mean that i am just not seeing things correctly. I dont know why by i am having trouble wrapping my mind around the whole 4 core concept. I was hoping that someone would be better able to explain some things to me than the book was.

Instead of being embarrassed about asking for this basic help i have chosen to ask.
The things that i am most troubled about are the following.

1) On the the G4 device there are 4 cores. So lets say i wanted to connect a external RAM IC to the processor and that requires me to use 2 core's IO pins to do that. For this example say stdcore[0] and stdcore[1] are used for the IO part of the RAM IC. Yet in stdcore[2] is the code that does things which require data to be read from the ram and in stdcore[3] there is code there that require data to be written to the ram. Since i cannot control one cores IO from another core, how am i going to achieve this task ?


2) I would also like to understand how the whole programming thing works. It appears that when i download my code to it, it is placed in the serial flash ? If this is the case, then am i only limited in code storage size by the size of the serial flash chip ? If so, how does one protect their code from simple being read out of the serial chip.


If anyone is bored and feels like explain this whole XMOS concept to me i would be very ,very thankful for it.
Heater
Respected Member
Posts: 296
Joined: Thu Dec 10, 2009 10:33 pm

Postby Heater » Fri Jan 15, 2010 8:10 pm

I think the main point is that an XMOS chips is not and is not intended to be a general purpose computer chip like an ARM or an Intel or such. If you want to run Windows CE or Linux an XMOS is not for you.

Rather its is supposed to be something that you can use to implement peripheral hardware functionality rather like you might use a CPLD or FPGA. The idea being that it should be easier to create your functionality in C and/or XC than in VHDL or Verilog.

Of course it makes a good micro-controller for all those things that an AVR, PIC or such might be used for as well.

Actually there is no way to "share" memory from core to core. You can only communicate the content of that memory between cores via channels. If you want to share that data among more than one core you will need to use more channels to do so.

As my old boss said "If you think you need floating point to solve the problem then you don't understand 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.

Postby leon_heller » Fri Jan 15, 2010 8:12 pm

64k is plenty for the sort of applications the chips are typically used for.

You have access to floating-point if you use C instead of XC. Both may be used in the same application.

What RAM are you thinking of using that requires two cores to connect it? Why do you need to share memory?

During software development you download code direct to the on-chip RAM for debugging. When the application is fully debugged and working you may place the code in flash memory. You can encrypt the code.

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

Postby seulater » Fri Jan 15, 2010 8:49 pm

What RAM are you thinking of using that requires two cores to connect it? Why do you need to share memory?
There is not enough IO per core brought out to the user edge to connect a ram chip. So if i was to design a board to plug into the kit, i would have to use 2 cores to do so.
as far as sharing memory, maybe i am using the wrong word. If say core0 and core1 are used to connect to the ram chip. and then core3 was doing all the work, how do i get the data from the ram chip in core0 & 1 to core3 ? This is why i was thinking that i need shared memory.

For most of my applications 64k just is not enough, i am looking to use the XMOS to replace another uP that we are using which is in a VoIP communications device. the audio buffering needs at least 32k for the TX and 32k for the RX data packets.

During software development you download code direct to the on-chip RAM for debugging. When the application is fully debugged and working you may place the code in flash memory. You can encrypt the code.
I never debug, i run it as if it were the final release. I have ran into debugging issues in the past and swore i would never do it again. i have found that a simple printf placed here and there have always allowed me to find the problem. When i go to the XMOS site and look at any of their chips i cant find anything about internal flash. So where is my code being downloaded to.
User avatar
leon_heller
XCore Expert
Posts: 546
Joined: Thu Dec 10, 2009 10:41 pm
Location: St. Leonards-on-Sea, E. Sussex, UK.

Postby leon_heller » Fri Jan 15, 2010 8:59 pm

I've used in-circuit debugging for years on many different MCUs, it's much easier and faster than printing data.

Your code is downloaded to RAM. XMOS chips don't have on-chip flash memory. There is 8k of OTP on-chip memory that can be used for small programs.

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

Postby seulater » Fri Jan 15, 2010 9:15 pm

but its only got 64k, so how does that work then? if my code is say 60k then i would only have 4k for ram usage.
Still, it does not have flash, so when i download the code to the kit where is it placing my code at for the uP to run it.
User avatar
leon_heller
XCore Expert
Posts: 546
Joined: Thu Dec 10, 2009 10:41 pm
Location: St. Leonards-on-Sea, E. Sussex, UK.

Postby leon_heller » Fri Jan 15, 2010 9:19 pm

It's got a von Neumann architecture - code and data use the same memory space in on-chip RAM.

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

Postby seulater » Fri Jan 15, 2010 9:23 pm

yas, but if its only got 64k, then my code must be less that than to debug.
User avatar
leon_heller
XCore Expert
Posts: 546
Joined: Thu Dec 10, 2009 10:41 pm
Location: St. Leonards-on-Sea, E. Sussex, UK.

Postby leon_heller » Fri Jan 15, 2010 9:33 pm

Of course!

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

Postby seulater » Fri Jan 15, 2010 9:40 pm

Then the XCORE is useless for code sizes > code + ram. which makes it only good for small applications.

I am still on the hunt for where my code is downloaded into in the released application.

Who is online

Users browsing this forum: No registered users and 3 guests