My XMOS XTC Tools notepad

 Started 14May2021. Updated 22Nov2021.This not 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

  • 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:

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 and Node.js 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

  1. 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:

  1. 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):

  1. C/C++ for Visual Studio Code extension
  2. Using Clang in Visual Studio Code
  3. 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:

  1. XMOS develops the Configuring an IDE page ((1) above) with a macOS tag
    • I have already pointed out that even one of the Mac tags has missing ” ./” when running a command in the same directory. (Ticket #161052# – not fixed)
  2. XMOS has signed all their executables for macOS Catalina++. It is not taking me as a macOS user seriously to delay this
  3. XMOS has made an easy example (not “advanced”) on how to plug the new IDE’s (I will try to use VS Code, it looks nice) directly on top of my workspace. If this is not possible, explain how I can merge my five rather large xC applications as much “as is” as possible into VS Code

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!

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.

Alternatives

  1. 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
  2. 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
  3. 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
  4. 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
  5. Some point here that might have come up if I had anybody to talk to, who could give me advice..
  6. 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
  7. 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, PyTorchNumPy, config.json and CasADi. If this name dropping was helpful, fine!)

Mac Mini (mid 2010)

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.

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

  1. 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)
  2. 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
  3. 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
  4. 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
  5. 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

  1. On the 2.4 GHz Intel Duo Core 2 it takes about 75 seconds to load xTIMEcomposer
  2. Startup actions are then done in the background – for minutes
  3. C/C++ indexing is also done in the background for quite some time
  4. 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)

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

.←

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.