XTC Tools 15.0.6 released

[CousinItt]

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

[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]

Does anybody know when one could get XCORE-AI-EXPLORER and XTAG4? This year or next year?

[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]

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]

Transition guide....

https://www.xmos.ai/documentation/XM-01 ... index.html

[RitchRock]

Any thoughts on what to do at the moment if using, for example the I2S library which relies on the interface concept?

[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.

[akp]

I suppose they don't want to support XC while they need to support upstream C tools, too.

[RitchRock]

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.