Part and Tools Migration

Technical questions regarding the XTC tools and programming with XMOS.
RitchRock
XCore Addict
Posts: 194
Joined: Tue Jan 17, 2017 9:25 pm

Part and Tools Migration

Post by RitchRock »

Is there a migration guide for those of us that would like to take code we have running on the older 216 parts and the older tools to the newer 316 part and latest tools?


User avatar
vergil19
Member++
Posts: 22
Joined: Thu Jan 20, 2022 3:54 am

Post by vergil19 »

The introdution about installation and configuretion of XTC15.2 could help: https://www.xmos.com/documentation/XM-0 ... index.html

Follow the guide and you are all set!
Joe
Active Member
Posts: 33
Joined: Sun Dec 13, 2009 1:12 am

Post by Joe »

Generally speaking it depends what system resources the existing code is using. e.g. a flashing LED or simple IO app will just build for xcore.ai in the same way as for xcore-200 - it's just a matter of changing the XN file for the project to specify an xcore.ai device instead of xcore-200. The tools build methods under the skin are the same it's just for tools 15 there isn't the Eclipse GUI front end.

If you are using xmos libraries most of these will work automatically (or I should say the libraries are written to work on xcore.ai and xcore-200).

Best bet is to pick an xcore.ai device which has the required pins for your existing application, change the XN to specify that device and then try to build your existing project with the new tools. You can then work through any issues you find.
RitchRock
XCore Addict
Posts: 194
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

My sticking point is that in my older v14 tools code, I create different interface tasks. I don't know how to call these interfaces from the new way we are given to setup the main in C. For example here is a custom QSPI interface I made that other tasks interact with. How do I do this in v15 tools?


Code: Select all

main()
{
interface qspi_storage_if i_qspi_storage;
interface dsp_ctl_if i_dsp_ctl[2];
interface pga_ctl_if i_pga_ctl;

chan c_state_ctl;
chan c_dsp_ctl;

...

on tile[0]: qspi_storage(i_qspi_storage);

...

Then the control manager task uses this interface (and others):

on tile[1].core[2]: control_manager(c_state_ctl, i_pga_ctl, c_dsp_ctl, i_qspi_storage);

}
Joe
Active Member
Posts: 33
Joined: Sun Dec 13, 2009 1:12 am

Post by Joe »

Generally speaking there's no obligation to use C with tools 15, you can continue to use xc.

I guess you may be forced to use C for some libraries? My knowledge of interfaces is not great but I'm sure someone else would be able to advise. I would be very surprised if this language feature had been removed in tools 15 so maybe this is more of a C/xc interoperability question?
RitchRock
XCore Addict
Posts: 194
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

V15 supports interfaces and I can still program in xC., however how do you create interface tasks and assign them to cores? There is no API or macro that implements interfaces in C. Perhaps I set this up in mapfile.xc somehow...
RitchRock
XCore Addict
Posts: 194
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

OK, I think I have a basic misunderstanding. Upon inspecting the new USB Reference design, I see that it's actually almost the same as the previous one. main() is called within main.xc and includes interface setup like I have in my programs. There does not appear to be a main.c file as shown in the getting started with v15 tools. So, I guess I keep on programming as is using xC and don't actually need to have a main.c file. I'll ask the basic question to be clear: Does a v15 program need a file called main.c at all? The programming notes lead me to believe it does.
RitchRock
XCore Addict
Posts: 194
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

The answer to my question from someone at XMOS: You can have main in XC or in C. e.g. You can have a main() in XC and par{} your threads and connects them with channels/interfaces. The functions calls inside your threads can be written in XC or C (or C++) if it doesn’t use interface. So you will have the beauty of both XC and C world. e.g. taking advantage of interface in XC while flexible pointer usage in C without using XC’s unsafe pointer.