Transitioning from older tools releases

Users of the XMOS xTIMEComposer Tools will notice some changes when using this XTC Tools release. This section aids users in migrating to the XTC Tools.

Programming language

A notable change within the XTC Tools is the move towards the use of the C language instead of XC as the preferred programming language for the xcore. The advantages of using C for xcore programming are:

• ANSI/ISO compliance

• Familiar to most embedded software developers

• 3rd-party algorithms and routines may be deployed

• There is an extensive support network

The xcore developer is encouraged to write communicating sequential processes (CSP) using tasks with their own private memory. This is largely enforced in XC and remains an excellent approach to parallel programming, and the same design pattern is recommended when programming in C. The move towards the use of C retains access to all of the unique benefits of the xcore architecture alongside benefits listed above.

For futher information on communicating sequential processes see References.

Existing applications using XC

Existing source code using the XC language, (with or without C or C++), can be built using this XTC Tools release. The XC compiler itself will be maintained for existing applications and libraries.

For guidance on projects developed within older tools releases, see Migrating existing projects.

New applications

New applications code should be written in C or a combination of C and C++.

The underlying hardware features of the xcore can be accessed through the C language using a new system library lib_xcore. Use of the new library is introduced in the guide: Programming an XCORE tile with C and lib_xcore.

Where new C code is required to interact with existing XC code, existing guidance should be followed. See Calling between C/C++ and XC.

Writing multi-tile applications currently still requires the writing of a minimal declarative XC source file, often called multitile.xc as per the examples: Targeting multiple tiles and Communicating between tiles. The file should not contain any procedural code, and should contain only the bare minimum to:

• Declare a C entry point on each tile

• Declare the channels over which the tiles communicate

The C language does not include equivalents for XC’s [[combine]], [[combinable]] or [[distributable]] keywords. Combining tasks onto a single logical core must be done manually, using functions in lib_xcore to wait for an event from one of many sources, or by using an RTOS.

Similarly, the C language does not have an equivalent for XC interfaces which are accessed via the interface keyword. Implementation of interfaces and their underlying transport and protocol can now be performed by the application developer, allowing greater scope for choosing an implementation appropriate to the real-time requirements and any resource availabilty constraints.

Users who rely on the XC language protecting them against unsafe concurrent access to shared memory should take appropriate care when programming in the C language. Similarly, care should be taken to ensure that resources are correctly allocated and deallocated before/after use, since such allocation is not handled implicitly by the language itself. These are all normal considerations for a C programmer.

The following XC to C conversion sheet XC to C cheat sheet is provided.

Graphical IDE

The XTC Tools no longer contain a graphical IDE within the installation package. Instead, the tools are intended to be used with VS Code as shown in Using VS Code.

Viewing of offline XSCOPE output is delegated to the user’s preferred VCD viewer. Use of GTKWave is demonstrated in Using xSCOPE for fast “printf debugging”, and other viewers are available.

Migrating existing projects

Some very minor changes in configuration files and procedures are required when migrating to the XTC Tools from xTIMEComposer. The following changes may be required.

Flash-related changes

XFLASH and the libquadflash library now support the SFDP standard. This reduces and in some cases eliminates manual configuration that previously had to be specified by the developer. Manual configuration is now considered as an override to the result of the SFDP query, whether supplied by XN file or SPI-spec file. Beware that if values for page size and number of pages are not set via XN file or SPI-spec file, XFLASH will have to interrogate the flash device to generate a flash image, which requires the flash build process to have the target device attached.

This may have consequences for migrating older xTIMEComposer projects to this release, due to the change in memory footprint of the library. Other aspects of the library have been further optimised for size to offset this but in the worst case scenario fl_connectToDeviceLight() can be used to restore the xTIMEComposer / Tools 14 behaviour and further decrease memory utilisation.

XFLASH option changes

The version of XFLASH supplied with the XTC Tools 15 series no longer performs image compression thus its default and only behaviour is to not compress the image. The option xflash --no-compression is therefore no longer provided. Simply do not supply the option.

XFLASH upgrade image guidance

When using the XTC Tools to produce a flash upgrade image for a factory image created under earlier tools releases, be sure to supply the correct value for the xflash --factory-version.

OTP-related changes

The xburn --no-compression option has similarly been removed, along with the update check facility, so likewise the option xburn --no-update-check is no longer provided.

In addition, the XCORE-200 xburn --serial-number family of options has been removed from the XBURN host tool - compatible data structures can be generated instead in CSV format using the example Python script referenced in CSV Format and subsequently programmed via XBURN.

xTAG adapters

The xTAG3 and xTAG4 adapters are supported by this release. The xTAG4 is a new-generation xTAG adapter. xcore.ai devices must use this adapter because it interfaces to them at lower voltages (1v8) which they require.

On Windows the xTAG drivers have been replaced, and a Windows Service is run when the host computer boots to manage connected xTAGs.