- 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)
This is structured as a log: newest at the bottom:
Install on macOS
- 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:
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:
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).
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)
- 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
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
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.
Installing Visual Studio Code (on macOS)
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
⌘ 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 .
#!/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.
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
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:
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.
- 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. If they don’t user Docker (here) and do build containers through it – which I will not pretend to do.
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 bash-3.2$
Don’t involve iCloud
It is no good idea to move the workspace to the
/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
- 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.
- 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
XCore Exchange (1)
- XTC Tools 15.0.6 released – started on 28May2021. I added a comment on 28Jul2021