Hi Guys,
I have been reading this thread and have a very similar question but perhaps phrased in a diffeent way. Rather than hijaking, I figured I post here cause I have a few other questions also.
-Code size.
Using SPI Flash boot mode, am I correct i'm assuming code size can be up to the size of the FLASH size and not limited to the 64k ram size? (per core)
-XLink
Can multiple XS1 be configured to talk to each other over Xlink's if they have been programmed independently and entirely separate from each other?
In my application I have a master and number of slaves (up to 15 in a chain), each with their own permanent program (probably on the OTP). The slaves which are in use at any one time may differ in number and also in type/task depending on the users requirements.
The master XS1 will be configured by the user to tell it which slaves are present and in which order.
I want to gather data from the slaves at high speed, hence why I am looking at Xlink's.
Thanks! I am excited at the possibility of this IC, just trying to get my head around it after being stuck in 'Spin' for years!
Code size & other questions.
-
- Member
- Posts: 9
- Joined: Tue Aug 17, 2010 11:21 pm
-
- Experienced Member
- Posts: 69
- Joined: Mon May 17, 2010 10:19 am
No. Your code, data, and stack must all fit in the 64KB of RAM per core. The flash can contain more than one program but only one can be run at once and each must fit in RAM.basil4j wrote: -Code size.
Using SPI Flash boot mode, am I correct i'm assuming code size can be up to the size of the FLASH size and not limited to the 64k ram size? (per core)
Yes. It is possible to enable (and disable) xlinks between devices that have been separately booted but the tools do not directly offer support for this; you have to write the code yourself and it will involve dropping back to assembly for some parts. This is rather easier on the L series devices than the G series.basil4j wrote: -XLink
Can multiple XS1 be configured to talk to each other over Xlink's if they have been programmed independently and entirely separate from each other?
That's achievable in the hardware, but it's not the usage model that the tools assume. The work needed to achive it wouldn't be trivial - you need not only to enable the links but the set up the routing tables, and node ids.basil4j wrote: In my application I have a master and number of slaves (up to 15 in a chain), each with their own permanent program (probably on the OTP). The slaves which are in use at any one time may differ in number and also in type/task depending on the users requirements.
The master XS1 will be configured by the user to tell it which slaves are present and in which order.
-
- Member
- Posts: 9
- Joined: Tue Aug 17, 2010 11:21 pm
Bummer, thanks :)m_y wrote: No. Your code, data, and stack must all fit in the 64KB of RAM per core. The flash can contain more than one program but only one can be run at once and each must fit in RAM.
Hmm too hard basket for the time being!m_y wrote: Yes. It is possible to enable (and disable) xlinks between devices that have been separately booted but the tools do not directly offer support for this; you have to write the code yourself and it will involve dropping back to assembly for some parts. This is rather easier on the L series devices than the G series.
Thanks for your responses, I think I might tackle something little easier to begin with but its good to know what is achievable!m_y wrote: That's achievable in the hardware, but it's not the usage model that the tools assume. The work needed to achive it wouldn't be trivial - you need not only to enable the links but the set up the routing tables, and node ids.
What is the maximum number of xs1-64 which can be connected in series?
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
Why is that? What make it easier?m_y wrote:Yes. It is possible to enable (and disable) xlinks between devices that have been separately booted but the tools do not directly offer support for this; you have to write the code yourself and it will involve dropping back to assembly for some parts. This is rather easier on the L series devices than the G series.