XTC Tools 15.0.6 released

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
User avatar
CousinItt
Respected Member
Posts: 256
Joined: Wed May 31, 2017 6:55 pm

XTC Tools 15.0.6 released

Post by CousinItt »

plus new goodies on github. Maybe things are finally moving.


User avatar
akp
XCore Expert
Posts: 544
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

It will be interesting to see if using lib_xcore and programming in C incurs any overhead penalties vs programming in XC, e.g. for timing critical select {} statements. With the amount of functioning XC code I have at present I suspect I won't be migrating any time soon, regardless.
MaximLiadov
Active Member
Posts: 37
Joined: Mon Apr 16, 2018 9:14 am

Post by MaximLiadov »

Does anybody know when one could get XCORE-AI-EXPLORER and XTAG4? This year or next year?
MaximLiadov
Active Member
Posts: 37
Joined: Mon Apr 16, 2018 9:14 am

Post by MaximLiadov »

It's pity that XMOS does make great products, but does not do any blog and does not publish any magazine. Official site is just an information product page with no visible updates since 09/20. It would be nice to see a blog or something with current progress, not just some official statements and advertisement once in a year.
maxmatteo
Junior Member
Posts: 7
Joined: Wed Dec 30, 2020 8:11 pm
Location: Hamburg

Post by maxmatteo »

the move to a command line focused release is great!
also contains lots of setup infos in the document folder.

partial changelog:

Code: Select all

Release Notes for Development Tools: 15.0.6 (build: 445-3976dcf)
================================================================

Previous major release: 14.4.1 (build: 235-acbb966) (rc3)

OVERVIEW OF CHANGES SINCE LAST MAJOR RELEASE
--------------------------------------------

* Added support for development using xcore.ai family of products

  - Compiler support for new architecture. In particular, new FPU instructions
    supported
  - Simulator support for architecture core and chip-level features, including
    use of external memory and "software memory" via the new minicache
  - Assembler support for writing VPU code and new instructions
  - Debugger support for new architecture
  - XTAG firmware support for JTAG interface 
  - Support for XCORE-AI-EXPLORER board product
  - Continued support for existing xCORE-XS1 and xCORE-200 based products

* Enhanced support for programming in C
  
  - Inclusion of the lib_xcore system library and headers marks a shift in
    emphasis towards programming the xcore in C, rather than XC
  - The lib_xcore system library allows equivalents of XC constructs including
    select{} and par{} to be written without leaving the C language
  - XC compiler still included, though it is recommended that new code be
    written in C

* Removed xTIMEcomposer IDE

  - Marks a move towards allowing developers to partner the XMOS tools with a
    development environment of their choosing
  - Greater emphasis on command-line usage of the tools and the debugger

* Removed xta static timing analysis tool

  - Internal and external surveys point to very low usage of this tool

* xflash

  - Support for xcore.ai added
  - Now supports use of "software memory"

* The discontinued xtag2 is now unsupported

  - Users should upgrade to the newer xtag3 or xtag4
RitchRock
XCore Addict
Posts: 142
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

RitchRock
XCore Addict
Posts: 142
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

Any thoughts on what to do at the moment if using, for example the I2S library which relies on the interface concept?
User avatar
akp
XCore Expert
Posts: 544
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

It's fairly easy to call interface functions from C using a wrapper XC file passing the interface as an unsigned, so I don't think it will be a problem in most cases. I don't know if you'll be able to use the notification features (didn't look into it). You'll probably need to pass the interface into the C task from the stub main.xc or whatever it is that's still needed. Eventually it will all go away and there won't be "interface" anymore.

Like I said, I don't see changing to using C. I use XC where it makes sense, C where it makes sense, and assembly where it makes sense. I think that's the optimal approach. I haven't looked deeply into XMOS's select implementation (for C) but that in particular looks cumbersome. And I don't like that they've taken away [[combinable]] tasks -- I use those extensively.

At the end of the day, I'm probably a luddite but not a complete idiot -- I understand why XMOS is doing it. They need to appeal to the lowest common denominator. I just think it's a dumb idea from my perspective.
Last edited by akp on Fri Jun 04, 2021 1:18 pm, edited 1 time in total.
User avatar
akp
XCore Expert
Posts: 544
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

I suppose they don't want to support XC while they need to support upstream C tools, too.
RitchRock
XCore Addict
Posts: 142
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

akp wrote: Fri Jun 04, 2021 1:07 pm It's fairly easy to call interface functions from C using a wrapper XC file passing the interface as an unsigned, so I don't think it will be a problem in most cases. I don't know if you'll be able to use the notification features (didn't look into it). You'll probably need to pass the interface into the C task from the stub main.xc or whatever it is that's still needed. Eventually it will all go away and there won't be "interface" anymore.

Like I said, I don't see changing to using C. I use XC where it makes sense, C where it makes sense, and assembly where it makes sense. I think that's the optimal approach. I haven't looked deeply into XMOS's select implementation (for C) but that in particular looks cumbersome. And I don't like that they've taken away [[combinable]] tasks -- I use those extensively.

At the end of the day, I'm probably a luddite but not a complete idiot -- I understand why XMOS is doing it. They need to appeal to the lowest common denominator. I just think it's a dumb idea from my perspective.
Yes, specifically I was wondering about the notification feature. It helps a lot to keep things a bit more asynchronous. It would be nice to see some examples of code porting, how they expect us to implement combinable and distributable tasks, etc.

For how often we see official library updates, it will be interesting to see what happens to the reference designs (USB, AVB, etc).

I don't disagree that this move isn't best for the future of XMOS, but in general like you said, this seems a bit cumbersome.