Contents
- 1 Install on macOS
- 2 System requirements
- 3 Version
- 4 XTAG access
- 5 Configuring an IDE
- 6 Sneak preview of lib_xcore contents
- 7 Update macOS
- 8 XCT 15.1.0 and a Tools Archive
- 9 FreeRTOS whitepaper
- 10 Installing Visual Studio Code (on macOS)
- 11 Stepping back for a timeout
- 12 14.4.1 on a reserved machine!
- 13 XCore Exchange (1)
- 14 XCORE SDK announced
- 15 14.4.1 on Big Sur
- 16 xcore X4 RISC-V
- 17 Newest
- 18 XC compiler lives
← → Started 14May2021. Updated 27Sep2023 (Search for that date. “Big Sur” and “RISC-V”) xTIMEcomposer + new machine = ok is in group Technology and My XMOS pages
This is structured as a log: newest at the bottom.
Install on macOS
Documentation of 15.0.6: https://www.xmos.ai/documentation/XM-014363-PC-4/html/tools-guide/install-configure/getting-started.html#get-started
System requirements
Aside: OS X / macOS: Yosemite, El Capitan (OS X 10.11), Sierra (macOS 10.12), High Sierra (macOS 10.13), Mojave (macOS 10.14), Catalina (macOS 10.15), Big Sur (macOS 11), Monterey (macOS 12), Ventura (macOS 13) (here).
- 5Jul2022: I run macOS Monterey 12.4, which is the max on this late 2015 iMac. However, I haven’t tried the XTC tools yet on it, and the xTIMEcomposer 14.4.1runs on that other machine through a virtual screen
14May2021: I am running macOS 10.13.6 (High Sierra) at the moment. Because I need xTIMEcomposer 14.4.1 to easily run (Java 6)- “Operating systems macOS 10.14 (Mojave) and newer are supported (I did update, see below). Intel processors only. Older operating systems are likely to also work, though they are not supported.”. Strange, I thought Rosetta 2 should convert every Intel binary to the Apple Arm-based M1. I queried about this at the Apple community: Rosetta 2 not for which binary?
Open Terminal, write “cd ” and drag the XTC directory (in Programs) with Finder into Terminal:
cd /Applications/XMOS_XTC_15.0.6
Error 01 in the docs: Do the second line, not the first (I have reported this to XMOS: Ticket #161052#):
$ SetEnv.command $ ./SetEnv.command
Alternatively just drag the SetEnv.command from the XTC directory with Finder into Terminal. This will look like this:
/Applications/XMOS_XTC_15.0.6/SetEnv.command
Version
xcc --help cat "$XMOS_TOOL_PATH"/doc/version.txt 15.0.6 (build: 445-3976dcf) xcc --version Build 8-2f98842, Mar-25-2021 Copyright (C) XMOS Limited 2008-2021. All Rights Reserved.
USB driver: “USB driver support is provided natively on OS X”
Interesting comment: “Using XTAG from within a VM. If you are using the tools from within a VM..” Maybe the last xTIMEcomposer 14.4.1 in the future can run in a HighSierra VM (Virtual Machine) on Big Sur and then run Java 6 there? With Parallels desktop for Mac? (now Corel). Hopefully this will not be necessary since the new install of 15.x.y might cover what I need (I do use xta, but it’s not crucial I think).
XTAG access
xrun -l Available XMOS Devices ---------------------- ID Name Adapter ID Devices -- ---- ---------- ------- 0 XMOS XTAG-3 2NMGxQiY [Invalid firmware: 0x1006] 1 XMOS XTAG-3 mqnHNZCF [Invalid firmware: 0x1006]
Configuring an IDE
They show examples for:
- Visual Studio Code (VSCode, VS Code, Live share by Microsoft. For Windows etc, but also for macOS. (Extensions support folding, like Explicit Folding. I have also heard about PlantUML)
- Eclipse
- xTIMEcomposer Studio is based on Eclipse, but they don’t recommend using that instance of it. Here is what they say: “Integration of the 15.0.x toolchain with the xTIMEcomposer Studio IDE packaged with previous tools releases is not recommended. Developers desiring a similar IDE experience should follow the instructions for Eclipse.“
What about using:
- Isabelle (proof assistant) and jEdit (which is in Java, but supports folding)
- macOS Xcode
Sneak preview of lib_xcore contents
Looks rather low level to me. But I guess more fingerspitz control:
xcore/assert.h xcore/chanend.h xcore/channel_streaming.h xcore/channel_transaction.h xcore/channel.h xcore/clock.h xcore/hwtimer.h xcore/interrupt_wrappers.h xcore/interrupt.h xcore/lock.h xcore/minicache.h xcore/parallel.h xcore/port_protocol.h xcore/port.h xcore/select.h xcore/swmem_evict.h xcore/swmem_fill.h xcore/thread.h xcore/triggerable.h
Update macOS
I did update from five years old macOS 10.13.6 High Sierra (Sep 2016) to Mojave (Sep 2018, 10.14.6 as of May2021). I decided to not go to Catalina (Oct 2019) yet, since XTC Tools are not yet properly signed for it at the moment. But again, it’s XMOS who unnecessarily holds me back 😳.
So now, with Mojave the xTIMEcomposer will is not able to run on the newer Java runtime that came with it. I don’t think I bother downgrade to this, since I plan to do a clean cut with 14.4.1 and go for the XMOS 15.x.y.
XCT 15.1.0 and a Tools Archive
Taking up this thread again on 26Jul2021 I see that 15.1.0 has arrived on 18Jun2021. The release note is here. Since I am following the xcc compiler (more known territory), here is the version, which has indeed also been updated with one build since 15.0.6:
bash-3.2$ xcc --version Build 9-c6fa813, May-19-2021 Copyright (C) XMOS Limited 2008-2021. All Rights Reserved. bash-3.2$ cat "$XMOS_TOOL_PATH"/doc/version.txt 15.1.0 (build: 446-e647144)
I also see that XMOS has supplied the legacy versions in a Tools Archive on the top page (here). I don’t think it has been at this level before. There would be:
- xTIMEcomposer v15.0.6
- xTIMEcomposer v14.x
- xTIMEcomposer v13.x
- xTIMEcomposer v12.2.0
- xTIMEcomposer v11.11.1
Of course this helps for many of us Mac users, even if it might mean configuring an older Mac to run the older version. This may be a better solution that trying to be super compatible, I guess. (Am I too loyal now?). Personally I have kept all mine, starting at Jan 2015 with XMOS_xTIMEcomposer_Community_13.2.1.
FreeRTOS whitepaper
See 200:[FreeRTOS whitepaper].
Installing Visual Studio Code (on macOS)
According to https://code.visualstudio.com/docs/?dv=osx then “It comes with built-in support for JavaScript, TypeScript (here) and Node.js (here) and has a rich ecosystem of extensions for other languages (such as C++, C#, Java, Python, PHP, Go) and runtimes (such as .NET and Unity)”. I like it, specially Node.js which I have shown some interest in: CSP on Node.js and ClojureScript by JavaScript. (Aside: Python concurrency: 135:[Python]. Not that I think any of this would suit the xCore architecture. But I have been surprised before now.)
I installed Visual Studio Code (May 2021 (version 1.57.1)) with help from
- Configuring an IDE – XMOS
Observe there that button ctrl on (Windows) is cmd or ⌘ on (macOS). Like this for build;
shift+ctrl+b → shift+cmd+b
In other words, the three tabs for Linux | Windows | Mac should have been also in the Configuring an IDE page. The mappings for macOS are seen here:
- Key Bindings for Visual Studio Code – page sensitive to which operating system it’s sent to
I installed C/C++ for Visual Studio Code with the help from these urls (I think):
- C/C++ for Visual Studio Code extension
- Using Clang in Visual Studio Code
- Visual Studio Code on macOS
However, I was not able to start code before I had installed the Command Palette as per (5) above. Only then did this work, and the VS Code window appeared:
bash-3.2$ cd projects bash-3.2$ code .
Observe that #!/bin/bash (“hash-bang”) in top of the bash scripts is necessary (see why here). I was told that I needed to make them executable (but that’s not in the XMOS page):
mymachine:single-tile teig$ls -l total 32 -rw-r--r--@ 1 teig admin 55 Jul 27 14:17 build.sh -rw-r--r--@ 1 teig admin 9 Jul 27 14:17 debug.sh -rw-r--r--@ 1 teig admin 78 Jul 27 12:36 main.c -rw-r--r--@ 1 teig admin 14 Jul 27 14:17 run.sh mymachine:single-tile teig$ chmod +x *.sh mymachine:single-tile teig$ ls -l total 32 -rwxr-xr-x@ 1 teig admin 55 Jul 27 14:17 build.sh -rwxr-xr-x@ 1 teig admin 9 Jul 27 14:17 debug.sh -rw-r--r--@ 1 teig admin 78 Jul 27 12:36 main.c -rwxr-xr-x@ 1 teig admin 14 Jul 27 14:17 run.sh
I was able to build single-tile with no errors (but not debug or run).
I was not able to build switch-setup since <xcore/channel.h> was not found.
I should be able to resolve these points, but spending time on this I need to have a macOS version of Configuring an IDE page or know what differences there may be.
Stepping back for a timeout
I reported the below “open letter” to XMOS and it became ticket #165546#:
See my encounters at https://www.teigfam.net/oyvind/home/technology/222-my-xmos-xtc-tools-notepad/.I have now spent as much time as I feel possible and come to some place that feels like a dead end. As much as I can’t wait to see the new scheme up and running, I feel it not “15.1.0” but rather “0.8.0”. I do appreciate that quite much documentation already is ready. However, in order sleep well again I need to do an unwanted break until:
Observe I am sitting alone and have nobody next door to ask. |
Going on
Update 2Aug2021. I believe there was something with my tasks.json file. I copied the new(?) contents from the XMOS page, and I have now succeeded with single-tile and switch-setup, using macOS keys. I guess all of the points are still valid, but I did get a heightener just now.
I run on macOS Mojave 10.14.6, and I do want to update to Catalina and Big Sur.
Contrary to what (1) Configuring an IDE wrote (“then start typing task Run. When Run active file is highlighted, press enter.”) I just pressed enter. The log you see is from the previous run:
Fig.10 – “Task run” then enter in VS Code
Out of XTC directory
I just copied everything under ../XMOS_XTC_15.1.0/projects/.. to my own directory and renamed the projects to make sure I saw those (to ws-switch-setup etc.) and ran this in Terminal:
cd /Applications/XMOS_XTC_15.1.0 ./SetEnv.command cat "$XMOS_TOOL_PATH"/doc/version.txt cd /Users/teig/workspace_xtc/projects code
Then, when in VS Code, I had to add the terminal window by hand, to let it stay. All worked fine.
14.4.1 on a reserved machine!
13dec2022: It seems like it is indeed possible to run xTIMEcompser 14.4.1 on macOS Big Sur (like 12.6.1) See XCore Exchange (1) (bullet 2, below).
21Aug2021: I had so much xC code that I didn’t want to wait for XTC Tools “going 14.4.1” for me. I suspect it will, one of these days. I decided to do something with my combination of (1) XMOS and (2) being 70+ years of age induced summer depression (*). My solution isn’t for rocket scientists, ..unless perhaps, getting there is most important.
(*) Darn, I dont’ have that many years to get this done! You should try it.
xTIMEcomposer + new machine = OK
Update 1Oct2022: I have discovered that it’s working very well to run Microsoft Visual Studio Code VSCode on my late 2015 iMac (with Monterey 12.6, the newest they have), with the xTIMEcomposer projects residing on the 2010 Mac Mini (below). The Mini has been shared as shown in a chapter below.
I have set up .xc files to look like C files (Code | Preferences | Setting | Files: Associations → Item *.xc Value c). At the moment that’s all I have done. I can update on any of the two screens and the other machine will detect it, although xTIMEcomposer may need a double-click on one of the modified files – or I need to do a Refresh. (Problem: After I started using VSCode like this I think the original xTIMEcomposer is a little confused of the fact that the files are uppdated asynchronously. It detects this some times, anyhow using Refresh helps. Then from the debug situation I got a spinning wheel stuck some times. I then had to force quite xgdb as well. However, I saw that these incidents appeared less often (gone?) if I am careful when I press the red square button and wait, and not move the cursor out of thet red square button before I have seen the response. However, the xTIMEcomposer still uses about 100% on one processor. On another iMac I have (from 2009), it only uses around 5%, so I think the below-the-loop updating causes Java to do some kind of spin-loop.) VSCode is much better then the xTIMEcomposer IDE! (Strange, some technologies you like, and some not. While I love Java, I don’t like the virtual machine runtime files needed (why don’t they compile to native binaries for these cases?) – and the fact that the Eclipse IDE runs Java and then needs it. This is the whole reason for having to do this “old machine” stuff!) This is just like XMOS have been trying to tell me a couple of years! Even .git is working! It’s called Timeline in VSCode. At the moment I haven’t committed in VSCode, though. I compile and debug on the old machine, inside xTIMEcomposer there.
PS. As you can see I use long source files. The excerpt of the present screen is shown on the right part of the VSCode screen as being greyed/grayed out. Nice! It’s actually called a minimap. Large files is contrary to most advice, where the other side of the road is an overwhelming number of files. Complexity has to get in there no matter. I worked with real folding editors for 25 years, where any place in the file page I would get a total overview in one screen, that’s why. I must learn more about folding in VSCode and see whether the WinF’s first citizen folding might be possible. However, I will try to do some testing. See 060:[Extensions/plugins for state of the art IDEs]. Update: I just discovered that the FreeRTOS file tasks.c contains almost 5500 lines of source code. The file stream_buffer.c contains about 1400 lines of code. So I seem to be in good company. At the moment (9Jan2023) my two largest Beep-BRRR files are 2372 and 1836 lines long.
Alternatives
13Dec2022, since it is indeed possible (see above) to run xTIMEcoposer 14.4.1 on macOS Big sur, I guess this list is not very interesting.
- Wait for XTC Tools to run my xC in some “14.4.1” manner. Maybe they’re there already, but the threshold for me is prohibitive at this stage
- Dig deep → deeper → deepest to resolve my problem with the present XTC Tools. After all, I plan to end up with it. Too hard for me, I assume
- I already have (or rather had) Parallels Desktop run Windows 10 on my iMac. But it turned out to be a separate hobby to keep it alive (here: 059:[]). I could have installed xTIMEcomposer 14.4.1 on it. I guess that would have been even an extra hobby #2
- Software virtualisation of some other sort with another macOS instance, so that I could run an old enough version of the Java JRE for Eclipse 4.3 to work properly
- Some point here that might have come up if I had anybody to talk to, who could give me advice..
- Hardware-isation (!?) became my solution: I decided to look for and purchase the oldest Mac Mini that runs OS X Sierra (macOS 10.12.x). I have documented that this was a good version for xTIMEcomposer 14.4.1 (here: 098:[]). This solution is along the line that any large company would easily revert to. There’s always some machine around that would more or less automatically have the role as a build machine for xC systems and 14.4.1 only, as long as the products are alive
- Alternatively, virtualization through build containers – which I did not go for. Too hard for a single person working from home, I have enough hobbies(?). But there is Docker (here) – which since 31Aug2021 isn’t free for all any more. Kubernetes (here) by Google, might then be an alternative. Both Docker and Kubernetes are written in Go: For me who “fought” for some understanding of channels (here, using occam) in the nineties, this is so exciting! (Update: But then, neither Docker nor Kubernetes have been built for machine-learning systems. Thanks, student paper (at NTNU) – also for the references to Run:AI, Apache Kafka, Google Dataflow, Apache Spark, MLflow and Databricks – I assume all too complex and expensive for me (..but some are open source), should I ever have a need for any of them. I hope that the XMOS Xcore SDK will contain all that I need, either directly or indirectly. Then the student paper also shows the Python world with Conda, PyTorch, NumPy, config.json and CasADi. If this name dropping was helpful, fine!)
Mac Mini (mid 2010)
13Dec2022: since it is indeed possible (see above) to run xTIMEcoposer 14.4.1 on macOS Big sur, I guess this chapter only is interesting if you d want to use a dedicated machine for it.
By the telly I had a Mac Mini (2007) which was retired for a newer machine two years ago. But I was not able to restore it to any usage for this case. I found a “Mac OS Compatibility Guide” (here) which stated that the Mac Mini (Mid 2010) Macmini4.1 would do High Sierra (macOS 10.13.x) as the newest. This is also shown in the Apple guide (here, upgrade here). Which means that this machine could follow for seven years, to Sept2017 for the newest OS.
I decided to go for a Mid 2010 and found one on “finn.no” here in Trondheim, where I live. I paid 1000 NOK for it (110$ or 95€), even with 4 GB of RAM. But without screen, keyboard or mouse – which I didn’t need in that delivery. It looked like new, and sounded like new. The owner had erased everything for me, and it was running plain(?) Sierra and waiting for a new owner to be created.
Update 5Jul2022: On its way to becoming el-waste at my sister’s place I got a really nice iMac early 2009. 13 years old! I installed OSX from Yosemite 10.10.5 to the newest possible El Capitan 10.11.6 and installed xTIMEcomposer 14.4.1 on it. It certainly works. (Even if these days, machines with mechanical disk drives feel rather slow at times.) Now I have two xTIMEcomposer 14.4.1 stations, one with a screen and one ran through a virtual screen.
I connected it to the telly with an HDMI cable. It didn’t find my Bluetooth keyboard and mouse initially. I had to find the USB based, cabled keyboard and mouse, which belonged to my museum “lamp” iMac G4. That done it was easy to configure the Bluetooth keyboard and mouse for any future encounter with a direct screen. I set the screen and files to be shared and disconnected it, to have it placed on a new shelf below my desk. See photo (above).
As said, it runs plain Sierra (macOS 10.12.x of Sept2016) which is just fine for xTIMEcomposer 14.4.1. I now see it from my iMac (running Mojave for the XTC tools, which does not yet have the signed executables that Catalina would require) through a shared screen window and shared disk when I need it. See photo (here).
Should I ever need to update to High Sierra, which should be possible from the page mentioned above.
When I had downloaded and installed xTIMEcomposer 14.4.1 from the xmos.ai site (here) and started it, there was the standard procedure about downgrading Java. I did, and as “always”, I now have (Mac Mini 2010):
myMachine$ java -version java version "1.6.0_65
The xTIMEcomposer 14.4.1 now runs like in the old days months (since before I updated the macOS on my work machine and installed XTC Tools, this spring). The virtual screen is a little slower and the resolution a little lower, but it builds proper xC for me. As always, I run it off-line with respect to the XMOS servers. I have always had to do this, I have never been able to resolve that problem.
Since the USB cables to my targets now would have needed to be longer than previously, I decided to go for a 4-port USB 3.0 hub instead, and a one meter USB 2.0 extension cable. The hub needs 5V external power, so I assume it straightens up the signals. And USB 2.0 is all the xTIMEcomposer needs (some 480 Mbps).
As described in 141:[XFLASH from Terminal] I do see my connected board (Mac Mini 2010):
bash-3.2$ xflash -l Available XMOS Devices ---------------------- ID Name Adapter ID Devices -- ---- ---------- ------- 0 XMOS XTAG-3 2NMGxQiY O[0] bash-3.2$
Don’t involve iCloud
It is no good idea to move the workspace to the Documents folder /Users/oyvindteig/Documents/dev/xc/workspace and then tick to “on” to have them in iCloud! xTIMEcomposer complained that a file it wanted to save because of a change, had gone. I did not respond to this box then. I had to tick this feature off and then copy the files from iCloud and back to /Users/oyvindteig/Documents/dev/xc/workspace again. Some was left when I did this, and Sierra politely asked whether I wanted to merge. Yes, of course. I then answered “no” on that dialogue box (since I knew what I had modified). After that all seemed fine again. When this is ticked to on, the Documents folder files would reside both on iCloud and on the machine. On the machine in a shadow directory that xTIMEcomposer would not know about, it seemed to. It’s not as transparent as I thought.
The virtual screen
- SIZE: I am only able to have the Mac Mini (2010) Sierra have an external screen of 1280 * 1024 when set as Scaled. Holding the option key, then the find screen option also returns 1280 * 1024 only. This also comes out when selecting “Standard for screen”. I have no physical screen connected. Alternatively, when I press the | apple | About this machine | Screens | then I see that it says Built-in screen 23-inch (1280 * 1024) NVIDIA GeForce 320M 256 MB and there is no other to select. But I don’t use that screen driver, I think. Therefore, is it possible to set an external virtual screen to become larger? I guess Mission Control is used for the virtual desktop (here)
- SQUARE’ISH: With xTIMEcomposer the dialog boxes cover more than I am used to these days, with resolution and format, as being almost square. On my iMac the screen is 4096 * 2304. When Screen Sharing shows the Mac Mini (2010) it indeed also shows a window size of 1280 * 1024
- COPY/PASTE: Copy/paste from the virtual screen onto my host iMac just works. Nice!For some reason it is possible to tick it off in the topmost field of Screen Sharing
- ALWAYS READY: Even if I have set both the Mac Mini (2010) machine and screen to enter idle after some 10 minutes, the virtual screen seems to be always immediately available.That is, the screen is black when I come back, but a mouse click makes it appear immediately. I also have the Awake by network traffic set. And in the meantime the Mini feels cool. This is so cool
- Aside: The Mac Mini (2021) DVD player’s video part is only greyed out on my iMac virtual screen. So I still need the external DVD drive for my iMac to view those plastics that come in some model train magazines.
Log
- On the 2.4 GHz Intel Duo Core 2 it takes about 75 seconds to load xTIMEcomposer
- Startup actions are then done in the background – for minutes
- C/C++ indexing is also done in the background for quite some time
- xgdb some times is not stopped like it should. It could be smart to run the Activity Monitor and stop it if it more or less hogs a core
git
I got a surprise when I wanted to make a new git version control directory. Git had worked indeed worked with Team|commit and all, but when I was going to a new git init, there was no git present! I soon realised that the .git directory that I now have worked with a month, was moved over from my iMac’s xTIMEcomposer’s workspace, and had been initialised there. In other words, xTIMEcomposer in some way contains its own git which I didn’t reach in the Terminal window, not even after SetEnv.command. Strange..
The solution was easy. I didn’t have to install the older macOS Xcode, it was enough to install the Command line tools. See Aside (begin): git needs to be installed first
XCore Exchange (1)
- XTC Tools 15.0.6 released – started on 28May2021. I added a comment on 28Jul202
- xTIMEcomposer Big Sur macOS 11 – by Redeye 13Nov2020, updated by Savoca on 12Dec2022
XCORE SDK announced
Update Oct2021: I can’t help thinking that this looks exciting! They write:
“Including IO interfaces, FreeRTOS examples and support for TensorFlowLite for Microcontroller, the xcore SDK incorporates libraries and tools, designed to harness xcore.ai’s versatility, making it easier for engineers to develop connected products that can sense, think, decide and act. This kit equips developers with standardised tools and resources to create devices that absorb contextual data from their environment, infer meaning from that data, and translate the results into action. Coming in November 2021“. From https://www.xmos.ai/xcore-sdk/ 27Oct2021. Update: 12Nov2021: “Coming in early 2022“
14.4.1 on Big Sur
13dec2022: It seems like it is indeed possible to run xTIMEcompser 14.4.1 on macOS Big Sur (like 12.6.1) See XCore Exchange (1) (bullet 2, above).
xcore X4 RISC-V
13Dec2022. See USING RISC-V TO DEFINE SOCS IN SOFTWARE. Very, very interesting!
Newest
XC compiler lives
Update 27Sep2023. I read on Transitioning from older tools releases from xmos.com .. (not xmos.ai”?) (most of this was not present in my previous storing of it in Aug2021. It had not been stored in Wayback Machine at the Internet Archive either, but I added it now) .. that
There are no fundamental features of the XCore architecture that demand a proprietary programming language.
Writing CSP-style tasks with their own private memory, like those used in XC, remains an excellent approach to parallel programming and the same mental model is recommended when programming in C. The move towards the use of C/C++ retains access to all of the unique benefits of the xcore architecture alongside the latest C and C++ features and fixes.
Existing XC source code does not need to be ported to C.
The XC compiler, accessed via the XCC compiler driver, will remain part of the tools release. No date has been set for its removal.
Writing multi-tile applications currently still requires the writing of a minimal declarative XC source file, often called mapfile.xc as per the examples: Targeting multiple tiles and Communicating between tiles.
I have also commented this at 221:[A quote of XMOS]. I repeat from that page: But then, personally I would have preferred the abstraction level of a continually developed xC language, not just one that is frozen. XTC is a pragmatic step down.
I haven’t studied or tried to move my rather big projects over to XTC 15.x. But is there a script to help me do that, or an explanation to import all of the projects and files? I guess the answer is at Migrating existing projects. It even describes how the XCORE-200-EXPLORER.xn file should now look.
Also, will XMOS fix errors (or have they already done it, they do mention a “change” here) in the xcc compiler 14.4.1 which I use? (Yes I do know that xTIMEcomposer Enterprise Tools reached end of life (EOL) in 2017, here). The new XCC description page is at XCC manual. From it:
XCC is a wrapper around a collection of tools to make the use of those tools simpler. Those tools perform the steps of preprocessing, compilation (both C/C++ and XC), assembly and ‘mapping’. Those tools may be used individually, but are more easily used via xcc.
I have discussed the XC three tier task model of standard, combinable and distributable in C plus lib_xcore black-boxes xC and XMOS xcore RISC-V.
← →