This page is in group Technology (plus My XMOS pages) and is a blog note about my experience with the XMOS toolset xTIMEcomposer and XMOS HW and how I am going to use used the startKIT to control a small 40 litre aquarium’s heating and light.

Fold handling with Collapse-O-Matic plugin

I am using Collape-O-Matic (here) on many pages.

Typical fold

Disclaimer

I have no association with XMOS and there is no money involved neither with this nor any other blog notes of mine. (Well, that’s not completely true: I have happily bought two HW boards from one of their resellers!). This blog note will show problems and matters I especially like (in addition my default, I especially like so much of what I have read about, that’s why I decided to come to this).

Since this is meant to be of help for XMOS users I will constantly delete matters that are not relevant any more, like problems that have been solved in newer versions of the tools or boards. But I realise this is easier to say than do..

My gut feeling right now

is exciting! Newest on top:

12May2021: is quite exciting. Now how do I proceed? No more xTIMEcomposer but XCT Tools. No xC language but lib_xcore for C!

See C plus lib_xcore black-boxes xC

See https://www.xmos.ai/software-tools/

Pre black-boxing

• 19Nov2020 (that’s when I discovered 7Oct2020). XMOS introduces the AIoT SDK! Press release from XMOS [17]. New: The AIoT SDK: AIoT tools (may convert TensorFlowLite) and FreeRTOS. From [17]: “Examples: examples showing a variety of operations based on bare-metal and FreeRTOS operation, including smart microphone sensing”. Bare-metal I assume is XMOS’s way of saying that they will continue with xTIMEcomposer and xC – without using those words. Also see XMOS FreeRTOS port
• Some time around Oct2020. The www… issue below has been solved
• 19Sep2020: I have some info that XMOS is having some (in my opinion: ongoing – but it may be region-dependent) trouble with their hosting company. But if I by hand remove www. from all urls that I press, then I seem to get there – provided the www. did caue trouble! Like if I try to log in, I do it, but then I get a gateway time-out. Until I just go to https://xmos.ai/account instead of https://www.xmos.ai/account. Repeating this I see that there may be some redirect problem – presumable originating from https://www.xmos.com to be rerouted to https://www.xmos.ai. (Maybe something like what I experienced when I moved from http to https (here)?)
• 18Sep2020: what is going on with XMOS? The web pages are either down or inconsistent. I so much hope that XMOS is fine. We once lost INMOS. But «EXMOS»!? Test: should any of these appear: https://www.xmos.com – https://www.xcore.ai – https://www.xmos.ai – then press further to investigate. I guess they should all redirect to https://xmos.ai – which might work as long as you stay there. If you know anything that’s public that I don’t seem to know, please mail me! According to http://web.archive.org and my own gut feeling of every now and then looking at those pages polling for the xcore.ai, the problems seem to have started already in August 2020.
• 6Jun2020: I have updated more at What me worrying about the role of xC?[200]
• 17Feb2020. Search for xcore.ai here!
• 10Jan2020. I have discovered that xTIMEcomposer 14.4.1 arrived on 19Dec2019 (here). XMOS say (here) that «Tools 14.4.1 should be used for all existing and new designs. Applications compiled with 14.4.0 and 14.3.3 are supported by 14.4.1.» This is because 14.4.0 was only released for a certain processor (XVF3510). Stay tuned, I will install and test soon.
• 10Nov2019: Reading Mark Lippet’s article in eeNews Europe (Oct2019) on Artificial Intelligence of Things (AIoT) certainly is very interesting reading [13]. Maybe it hints at a pivot away from sound and toward more connected devices. I certainly hope for xC and the multi-core architecture (with built in scheduler and logical threads) – or something even better, built on those foundations? Lippet serves a teaser here, and I just can’t wait to see the result!
• 31Jan2019: I am even more into the xCORE-200 eXplorerKIT these days. But the aquarium is controlled by the startKIT. A have several boxes that I have made, of each. I still love this xC and the processors. But I am little worried over the very large emphasis on sound and Amazon Alexa on the XMOS pages, and that the xTIMEcomposer has not had an update since April 2018. It’s still 14.3.3. However, see Update Sep2019 – 14.4.0 is seen! In the Development Kits menu, and For other solutions is only one of six and then there are only two choices: xCORE-200 Explorer kit and xCORE-200 sliceKIT. Great choices, but what does the tendency tell me?

MY OTHER NOTES WHERE XMOS MATTERS

See My XMOS pages (separate page 29Oct2019)

My startKIT based aquarium controller

startKIT end of life

Update Apr2018: The startKIT has reached end of life and is therefore obsoleted. XMOS writes in its EOL notice (dated 3Jan2018) that

XK-STK-A8DEV (xCORE startKIT starter kit) is end of life and will be withdrawn from sale immediately as XS1 series of silicon products are no longer recommended for new designs.

I expected this, so I have four altogether – one even never powered. But for new uses I use the xCORE-200 eXplorerKIT. I have three of those (to have two left if one breaks!)

My controller box: a picture at least

This chapter was added in Sept2017, after this note had been filled up over several years. It’s finished, and here is its picture! This is all I have at the moment. I will make a full blog note about it later on. Also to tell that the life in the glass box is doing all well. (At the moment (2018) I’m trying to port the RFM69 radio to it. See My aquarium’s data radioed through the shelf)

Fig.2 of note 151 – Aquarium controller based on XMOS startKIT, design Øyvind Teig, 2017 (Press for full resolution)

Observe that I have made a watchdog for it. See blog note 187 (referred above).

XMOS series of processors

XMOS PROCESSOR CATALOGUE

Sept2020: Do not use the below list as any reference – since XMOS now has made the PROCESSOR CATALOGUE page (at https://www.xmos.ai/processor-catalogue/).

My list

I have queried at xCore Exchange: XMOS series processors and tried to paste the answers (below). The catch is that XMOS didn’t seem to have this as a public list. I guess the newest are at the bottom. This list is more enthusiastic and coincidental than correct. Treat it with care. Every disclaimer apply! The [lib_i2c] (here) mention (below) is just to show that these processors are not as equal as two drops of water. Also, if SDA/SCL are placed on a multi-bit port, none of the processors seem to be able to use the other bits for any other function. So it’s best to use two one-bit ports for I2C (also called I²C or IIC). (The XMOS [lib_i2c] document does not explicitly mention other processor types).

• «XS1» = introduced in 2008
• XS1 G-Series
  • G = «General» purpose device. XMOS’ first chip.
  • Not recommended for new designs, no compiler support from xTIMEcomposer 14.2.2 (Oct. 2016). End of life (EOL) reached as of 31Mar2017 (here)
• XS1 A-Series
  • A = Analog – Basically an XS1-U with no USB PHY. i.e. just DC-DCs + ADC
  • Processor XS1-A8-DEV (8A6C5DEV is printed on it) is only used on the startKIT, so either read data sheet of
    • XS1-U16A-128-FB217 (here) «if you are using startKIT as a target platform» or
    • XS1-A8A-64-FB96 (here) «if you are using startKIT as a developer platform and intend to run your final application on» ..something else
  • Observe 8A6C5DEV does not have a watchdog (here)
  • Observe ADC noise (here)
• XS1 L-Series
  • Vanilla logic only XS1 device (L stands for ‘low power’ c.f. G-series)
  • [lib_i2c] SDA/SCL if placed on a multi-bit port then only write possible, and no clock stretching
• XS1 U-Series
  • U = USB (+ DC-DCs + ADC)
  • Observe ADC noise (here)
  • [lib_i2c] SDA/SCL if placed on a multi-bit port then only write possible, and no clock stretching
• XS1 XA-series
  • XA = eXtened Architecture, or Xmos/ARM. Single tile XS1-L + ARM M3 cortex. Being phased out (2017)
  • Used on xCORE-XA board (processor is XS1-XAU8A-10-FB265). End of life (EOL) reached (2016)
• «XS2» = xCore-200 based, introduced in 2015
  • added DSP functionality
  • 65 nm process node
• xCORE-200
  • See xCORE-200: The XMOS XS2 Architecture and Product Catalog
  • xCore-200 XL-Series = XL200 / XLF200 (GENERAL)
    Also called xCORE-200 GENERAL: XL and XLF series (Product Catalog, Mar2019)
    These are general purpose devices with no USB or Ethernet
  • xCore-200 XU-Series = XU200 / XUF200 (USB)
    Also called xCORE-200 USB: XU and XUF series (Product Catalog, Mar2019)
    Incorporates USB interface. Example Microphone Array, see here. Board with XU216-512-FB236 here (xTAG board included)
  • xCore-200 = XE-Series XE200 / XEF200 (ETHERNET)
    Also called xCORE-200 ETHERNET: XE and XEF series (Product Catalog, Mar2019)
    Incorporates Gigabit Ethernet and USB interface. The xCORE-200 eXplorerKIT has a XE216-512-TQ128 (xTAG board here needed to debug it)
  • XMOS also has two 4-tile (32 logical cores) processors, the XE232-1024-FB374 and with internal Flash the XEF232-1024-FB374. See «XMOS PROCESSOR CATALOGUE» reference (above), chapter XE Series. I see that there is a discontinued XE232-512 on Digikey. I did add this on xCore Exchange 12Jan2021: Commercial board containing XE232 or XEF232. There also is a XU232-1024 which is not discontinued (here) (Apr2021)
• xCORE-AUDIO family ::
  • Hi-Res 2 (may have external flash for program code and advanced configuration, but it seems like it’s mostly thought of as a configurable subsystem)
• xCORE-VOICE family ::
  • XVSM-2000 Smart Microphone processor
  • XVF-3000 VocalFusion processor. I believe this is their first subsystem on chip that’s not xC programmable. Voice Fusion is provided with source to the framework (to run from a host processor), but not the underlying speech enhancement algorithms (these are provided as binary only).
    : Update Oct2017: This is used in the XMOS Amazon Alexa Voice Service development kit (VocalFusion 4-Mic Kit for Amazon AVS), that also needs a Raspberry Pi.
    (Aside: a private comment about this is in My single-board boards and why notes, chapter Raspberry Pi in XMOS Amazon Alexa Voice Service development kit)
    : Update Sep2019: XVF3510 is an XMOS turnkey firmware that runs on the xCORE-200. XMOS packages it as VOCALFUSION™ XVF3510 FAR-FIELD VOICE PROCESSOR (here). xTIMEcomposer now is 14.3.3, but 14.4.0 for XVF3510 – meaning that it is used on the workbenches developing with that system. This is great, since 14.3.3 is from April 2018 – 17 months ago. Also, in the $19M funding interview with Mark Lippett, president and CEO at XMOS, he says that «.. as we ramp up the rollout of our exceptional XVF3510 2-mic voice interface and accelerate our AIoT roadmap.» [12]
  • Update Sep2021: 219:[The choices]
• «XS3» = xcore.ai Introduced in 2020
  • The XMOS XS3 Architecture 2020/07/15 Document Number: 014007, REV 1, from https://www.xmos.ai/xcore-ai/ (Oct2021: Thanks reader Marco, for pointing out that this document was missing!)
  • «XS3» affirmed  by Lazlo Kindrat of XMOS at [16] (28:56)
  • Can handle 256-bits multiply-accumulate in one cycle in a vector HW unit
  • 40 or 28 nm process node (206:[13], below)
  • Some of these processors also support the MIPI debug architectiure (Mobile Industry Processor Interface Alliance) which uses the I3C bus
  • Older notes
    • See https://www.xcore.ai. Whitepapers there are dated 7Feb2019
    • 206:[13] Linley Gwennap writes that
      • «In 2016, the company split in two, with then CEO Nigel Toon taking about a third of the employees to found Graphcore, which has since re- leased a high-performance deep-learning accelerator for data centers (see MPR 9/17/18, “Graphcore Makes Big AI Splash”). Mark Lippett became XMOS CEO after the split and now leads a team of about 60 people, most in the UK.»
    • «The xcore.ai Explorer Board which will be available by August 2020». 10May2020: I have added a chapter in note 151: My single-board boards and why notes
    • Also see Me worry?

A 2008 based summary

From Adam Sampson’s Doctorial Thesis from 2008 [11], here are some quite relevant quotes.

Adam Sampson (2008)

Starting with startKIT

First is #02.01

Observe that there is a beautiful description of the XMOS world at the element14 community fabulous blog note by «shabaz» entitled XMOS startKIT: Introduction, Terminology/Architecture, Getting Started and Example Programs. See [10].

1. February 2015: I run OS X Yosemite version 10.10.2 (14C109) on a MacBookPro10,2 (retina, 2012). I downloaded xTIMEcomposer 13.2.1 only to learn that I had to downgrade Java (it told me when I tried to start it), see OSX 10.10.2 Yosemite asks for «older version of Java SE 6 Runtime». (With xTIMEcomposer 14 that I downloaded on 23March2015 this is ok)
2. So, I downloaded Java from http://support.apple.com/kb/DL1572?viewlocale=en_US&locale=en_US  and downgraded to the newest 32-bit version of the Java runtime, «Java for OS X 2014-001» – even if http://support.apple.com/en-us/HT202912 told me that «This article is about older, unsupported Java software. Download the latest version of Java for OS X directly from Oracle». I had this:
   Java version «1.8.0_31»,
   Java(TM) SE Runtime Environment (build 1.8.0_31-b13).
   Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode) and downgraded to this:
   java version «1.6.0_65»
   Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
   Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)
3. However, I installed it with my own paths to libraries and user files. This was no success. It crashed several times, and I couldn’t run the debugger. It was only when it complained that it couldn’t find the include files (with no good reason) that I realised that I should remove and reinstall xTIMEcomposer with default directory positions. Now it runs, and hasn’t crashed so far.
4. But in order to run the debugger it’s not enough to press the buttons. You also have to give it the parameter -g (I knew this before the reinstall). You set -g in XMOS Edit, Project Explorer, find makefile and double-click on it and set xCORE xcc Flags, xC Compiler to -g and also ARM gcc Flags, C Compiler to -g (I think). Press the source tab below and you’ll see these:
   xCC_xC_FLAGS = -g
   ARM_GCC_C_FLAGS = -g
   I found this in a help file, even if it just told me to set the -g flag.
5. When I press the XT icon in the Dock the window doesn’t open. I have to press Show all windows and then press the foggy small window that appears. (However, it’s not that simple, OS X is confusing on this matter, also for f.ex. Finder)  (With xTIMEcomposer 14 this is ok)
6. Conclusion so far: some start problems. But what I see looks promising! Downloading the examples from GitHub was great!

Now my main.xc looks like this:

code main.xc of app_spinning_bar

#include <xs1.h>
#include <timer.h>

/*
 * the patterns for each bit are:
 *   0x80000 0x40000 0x20000
 *   0x01000 0x00800 0x00400
 *   0x00200 0x00100 0x00080
 *
 * As the leds go to 3V3, 0x00000 drives all 9 leds on, and 0xE1F80 drive all nine leds off.
 * The four patterns below drive a dash, backslash, pipe, and slash.
 * Modified by Teig to switch rotation and show when it switches.
 */

#define MODES 4

int leds[MODES] = {
    0xE0380, // dash     (When "startKIT" reads this way)
    0x61700, // backlash -"-
    0xA1680, // pipe     -"-
    0xC1580  // slash    -"-
};

/* This the port where the leds reside */
port p32 = XS1_PORT_32A;

int main(void) {
    int delay_ms = 1;            // Initial delay_ms 1 ms
    int delay_ms_now = delay_ms;
    int delay_ms_inc = 1;        // Starting clockwise
    int led_counter = 0;         // A counter to count through the leds array

    while(1) {
        delay_milliseconds(delay_ms_now);  // Wait
        delay_ms += delay_ms_inc;          // Slower or faster
        p32 <: leds[led_counter];          // Drive the next led pattern

        if (delay_ms_inc == 1) {         // Clockwise slower
            led_counter++;               // Pick the next pattern
            if (led_counter == MODES) {  // If we were at the last pattern
                led_counter = 0;         // then wrap down
            }
            else {}
        }
        else {                           // Anti-clockwise faster
            led_counter--;               // Pick the previous pattern
            if (led_counter == (-1)) {   // If we were at the first pattern
                led_counter = (MODES-1); // then wrap up
            }
            else {}
        }

        if (delay_ms == 100) {            // It's slow, enough clockwise
            delay_ms_inc = -1;            // To anti-clockwise faster
            led_counter = (MODES-1);      // Start with last
            p32 <: 0x0000;                // But first all LEDs on
            delay_ms_now = 500;           // for 500 ms
        }
        else if (delay_ms == 0) {         // It's fast, enough anti-clockwise
            delay_ms_inc = 1;             // To clockwise slower
            led_counter = 0;              // Start with first
            p32 <: 0xE1F80;               // But first all LEDs off
            delay_ms_now = 250;           // for 250 ms
        }
        else {
            delay_ms_now = delay_ms;      // Use the faster or the slower delay
        }
    }
    return 0;
}

More

First is #03.01

1. In order to stop at a line in the debugger you have to start it then press the suspend button. But you have to press a line in the Debug window to enable first.
2. An empty «Import xTIMEcomposer Software» window appeared on my screen. There’s nothing to push, and it’s not in OS X running app list (Since it’s Java I assume). Stopping xTIMEcomposer (13.2.1) removed it.
3. Pressing the green maximize button doesn’t maximize like f.ex. Safari does (ok), and doesn’t work if Dock is on the left (not ok). I think invisible right part is equal to the width of the Dock. But if I move the Dock down, then being at the bottom in some window editor is just as bad: I had to move the Dock to the left side again. It seems like Java calculates its needed window size disregarding the Dock. Ok, maybe I’l hide it automatically when I work with xTIMEcomposer.
4. Installed xSOFTip (spelt xSoftIP Explorer in the application). Exciting!
5. The Resource Glossary used for built-in help has a green button at the bottom that shows up even if the present version already is the newest version that the green button mentions. This is a general problem, it also suggests to download tools running.
6. Generate xTIMEcomposer Project, Location shows a workspace that confuses me. If Create new project in workspace (no colon) is ticked then there is a path window that shows a grayed out path (which is the automatic path, we can’t change it of course). The problem is that the line below the above ticked line says Create new project in: (obs.: the colon). If this is ticked then the path window is emptied and allows a Browse button. The placement of the path window together with two choices, without and without a colon, as I said, confuses me.
7. When I asked it to generate a project it complained that the I2C module had not had the ports mapped. I couldn’t find out how to do that, I canceled several times. I went on with the warning. When the project appeared and I looked at the source it started with this:

   r_i2c i2c_if = {on tile[0]:"<assign port here>", on tile[0]:"<assign port here>", 1000};

   I like it.
   

   code port mapping

   Now I must learn what to put there. I’m starting with driving a bit-mapped display. The display’s (Adafruit 128 x 32 I2C OLED, see [1]) I2C SDA is connector J7 pin 1 (1F at X0D13) and SCL is J7 pin 2 (1H at X0D23), and the notRST is J7 pin 3 (1G at X0D22). I’ll read myself up on th XS1 Ports: use and specification [2] or Introduction to XS1 ports [3]. Here’s the answer, at least it compiles:

   r_i2c i2c_if = {on tile[0]:XS1_PORT_1H, on tile[0]:XS1_PORT_1F, 1000};

   since in i2c.h I see the type r_i2c defined to be scl, sda and clockTicks.
   

Daily I (xTIMEcomposer 13.2.1 ff)

First is #06.01

1. The documentation download appeared inside xTIMEcomposer when I got an annotation of an update. Great! But it suggested to download to the path that I gave it for the non-successfull install that I deleted. There was some cleanup that wasn’t done with OS X delete.
2. The next thing is to import adafruit’s driver from GitHub. We use Git at work, but GitHub is new. Now, how do I get this C++ driver into the startKIT? (Now, after having studied it and realised that the way that ports in the xC world and wire in the Arduino world clash, and the general structure of the driver,  being not terribly impressed by its structure and conventions, I think I’ll make my own in xC proper. I might base that on the XMOS LCD-driver)
3. When I wanted to clean up the editor window’s list of files, and removed all of them I got An internal error occurred during: «Compute launch button tooltip». java.lang.NullPointerException. The OS X top row of xTIMEcomposer had gone, except for the leftmost xTIMEcomposer heading.  (With xTIMEcomposer 14 I don’t know yet)
4. Editing a source file in an external editor and then back to a still open xTIMEcomposer will cause xTIMEcomposer to query whether I want to replace it. There is a different question if a file is modified since I closed xTIMEcomposer last time. So it keeps both internal and external editing in sync. (Earlier I wrote that this was not so, but it must have been «finger trouble» on my behalf). However, I get no question about merging, only overwrite.
5. When the compiler finds the build to be free of errors it’s the linker that has the final say. The Problems window might show Errors (4 items). Undefined reference to ‘getRotation’ might be one of them. Double-click on them and nothing happens (i.e. no text window shows up. As an experienced programmer I get the situation: there is no code for getRotation. Right-clicking with «Show in properties» helps zero. Do observe that the window is wider than it looks, scroll it to leftwards to find more (but it only says Type is C/C++ problem, not linker problem). I don’t know if this is standard Eclipse behaviour or if it’s xTIMEcomposer. But the wording is not precise. More:
6. The problem I think is with the semantics is the word reference, which gets worse when it’s undefined. There is no reference or there is a reference but doesn’t point to anything? How about: Error from linker: ‘getRotation’ used but no code defined, or code ‘getRotation’ defined but not used. But this might be gcc matter? I’ll check out the latter case, some times it’s a warning only – if it makes this point contradictory.
7. I had a java.lang.NullPointerException when I pushed a file into the src tree from just below the src tree. It was random_conf.h that I had just created, obviously in the wrong place(?)   (With xTIMEcomposer 14 I don’t know yet)
8. By the way, finding out how to use the the random_module as seen from the #include "random.h" was actually quite understandable, after I first found it in the GitHub window. The Help system is great. I look forward to useing more xmos modules
9. I ran into a problem where the XE xCore Exchange community helped me: Changing file from .c to .xc causes mismatches with previous definitions. It turned out that I hadn’t used neither REFERENCE_PARAM nor extern "C" since my alerness had been lowered by xC calling C ok, but without pointers! Read the whole thread at http://www.xcore.com/questions/3175/changing-file-c-xc-causes-mismatches-previous-definitions. Afterword: I tried REFERENCE_PARAM and extern "C" and unsafe decoration, but I was not able to tweak my mind around to it! What am I doing wrong? I ended up changing the header parameter from *txt to txt[]. That worked
10. Now, here’s something I like: the compiler took me with an error for a function that had a parameter to an array but that array was in fact used hard-coded inside. This is not wanted aliasing (it might be wanted in a linked list, but this isn’t one). I haven’t seen that kind of error message for almost 20 years when occam had it. Here’s the message: call to `testdrawbitmap' in `examples_adafruit_ssd1306_128x32_i2c' makes alias of global 'logo16_glcd_bmp' examples_adafruit_ssd1306_128x32_i2c.xc /module_adafruit_SSD1306/src line 460

Bird’s eye view

This chapter has been replaced by note xC is C plus x (May2017).

Which LED driver?

First is #05.01

1. I posted a question to the XE xCore Exchange community: Rewrite XMOS LCD driver for a LED display or try to port existing Arduino LED driver?, see http://www.xcore.com/questions/3137/rewrite-xmos-lcd-driver-led-display-or-try-port-existing-arduino-led-driver. It took five days to get it approved… Then an answer appeared immediately. Thanks!

Cancelable timout: channels or interfaces?

First is #07.01

1. On 23March2015 I posted this to XE xCore Exchange community. It’s at http://www.xcore.com/questions/3196/cancelable-timout-channels-or-interfaces. The answer I got suggested «If everything is in one task and you don’t mind global state you could store a pointer to the button chanend as a global (this is all memory safe when using movable pointers). This would probably be the minimal changes to your current code. You’d have something like:» Summary of suggestion with global channel end
   First, the global declaration

   chanend * movable p_c_button;

   and then a delay_if_needed function (or task for a while) polls the channel in a select:

   case *p_c_button :> int:

   and in the main task which calls delay_if_needed (so the channel end is used one place at a time), the button channel is also polled in a select:

   chanend * movable p = &c_button;
   p_c_button = move(p);
   // ...
   case *p_c_button :> int:

   This is interesting! Thanks, Dave Lacey!

xCORE startKIT

First is #08.01

1. Also see startKIT board
2. Why is the startKIT‘s micro-USB connector upside down? The small cable needs a twist in order to connect to my Mac Book Pro. The USB logo on the cable is correctly upside on the machine but underneath on the board. (The xCORE-XA module (with 7 XMOS cores and an ARM core) has the debug micro-USB mounted on the underside of the board, which makes sense in this context. But even there the power micro-USB is mounted like on the startKIT: on the top of the board.)

Daily II (xTIMEcomposer 14.0.0)

First is #09.01. Started 25March2015. xTIMEcomposer 14.0.0 (13.2.2 in point 10). Release note here. Some points: Update from eclipse base version 3.6 –> 4.3 and Integration with eclipse marketplace for installing 3rd party software.

1. There are spelling errors in the examples. Like in «startkit_adc.h»: «Give it it’s own core» and «Pass i_adc control inteface«. In «startkit_adc.xc» I read «Special function to allow select on inuint primative» (inuint is a variable name). Etc. Since this is official XMOS stuff, it should have been peer reviewed all over (to misspell is human). Another, worse matter in the same file: It uses this defintion in the interface: 

   code in startkit_adc.h?

   adc_val[4]);

   In my opinion it should have been more like this (with obvious usage reasons):

   #define NUM_STARTKIT_ADC_VALS 4
   typedef struct tag_startkit_adc_vals {
       unsigned short x[NUM_STARTKIT_ADC_VALS];
   } t_startkit_adc_vals;

   Of course, the typedef mechanism is discussable, but I think this is most portable (as also discusued in Stack Overflow)
   

2. When I build by just importing libraries (and taking over from 13.2.1) I at the moment get 11 warnings of paths it can’t find. Do I need them, when they’re not errors?
3. Aside: I am studying different matters these days. Here’s a processor that might be viewed as a competitor to XMOS? Infineon Aurix [8]. Not that I would switch for my aquarium, and my enthusiasm of xC (with my heavy CSP and occam legacy..)
4. Aside 2: And then there’s Symtavision [9] XMOS competitor? As they say «Symtavision provides the leading timing analysis solution for planning, optimizing and verifying embedded real-time systems.» But there seems to be a huge difference in which level the problem is attacked. I wonder where analysis ends and guarantees start. After all, XMOS has what they say is «Software Defined Silicon».
5. xCore Exchange: I tried to post this in the xTIMEcomposer window and also my browser, but it did not accept because of illegal characters. Which of them it didn’t tell:

   Problem Occured
   ‘launching my_module.xe’ has encountered a problem
   No such debugger
   – Debug ran on 13.2.1. So I am not able to Debug and run to line and inspect variables etc. I can download the code and Run, though. I have tried to configure at places where I thought applicable, but I am blank now. It builds ok. But there are a lot of warnings of include libraries it can’t find, some of which I am not using. But all needed elements must be there, since I don’t get error.
   – This is among what I have tried several combinations of:
   Preferences : Run/Debug : Launching : Perspectives (Defaults:) : Open when launching («Never»), Open when application suspends («Prompt»), Modes Debug, None
   – xTIMEcomposer 14.0.0. startKIT
   Mac OSX 10.10.2. Java 8.1. JRE 1.80_31
   private project: http:/www.teigfam.net/oyvind/home/technology/098-my-xmos-notes/

   Update next day: after 3 hours of careful experience-building: I deleted my project, removed the files, made a new xC project and imported all my files again. Bingo! Of course it’s a challenge for any tool vendor to take heights for all beginner’s mess, but with the experience I do have after all these years it’s always a defeat to do what I did, since I’m the one to feel stupid. But then, now I am left with more than printf-debug! (By the way, it got worse than above; it even tried to run but failed on saying that it could find no source of main(). This took an extra 1.5 hours, by following that dead end. I think this happened when I had an extra round with 13.2.1)

6. When I had an internal error and wanted to report, now http://www.xmos.com/developer/support doesn’t exist. It’s a url from their page!  XMOS, where art though? (But this https://www.xmos.com/rt3/SelfService/Create-report-bug.html works; where I did report it, filed as «7404: Internal error».)
   

   Internal error log

   Compiling Aquarium.xc
   cd ./.build && xcc -c -D__random_conf_h_exists__=1 -I'../.' -I'.././bin' -I'.././src' -I'/Users/teig/workspace/lib_startkit_support' -I'/Users/teig/workspace/lib_startkit_support/api' -I'/Users/teig/workspace/lib_startkit_support/doc' -I'/Users/teig/workspace/lib_startkit_support/doc/pdf' -I'/Users/teig/workspace/lib_startkit_support/src' -I'/Users/teig/workspace/module_i2c_master' -I'/Users/teig/workspace/module_i2c_master/src' -I'/Users/teig/workspace/module_random' -I'/Users/teig/workspace/module_random/src' -O2 -g -DCONFIG=Default -Xcompiler-xc -analysis -Xcompiler-xc .././.build/pca.xml '../src/Aquarium.xc' '.././STARTKIT.xn' '.././config.xscope' -o '../.build/src/Aquarium.xc.o'
   xcc1: terminated due to internal unrecoverable error
   For bug reporting instructions, please see:
   

   http://www.xmos.com/support

   xmake[1]: *** [.build/src/Aquarium.xc.o] Error 1
   xmake: *** [bin//Aquarium.xe] Error 2

   Update: I had tried

   on tile[0].core[0]: adc_task (i_analogue, c_analogue, 0);  startkit_adc (c_analogue)

   which was not smart. It should be core[4]. At least it compiles then (but it doesn’t seem to run, I can’t see that core in the debug view). Stay tuned.
   More: trying to comment away lines I get the following:
   

   Internal error log 2

   10:08:31 **** Incremental Build of configuration Default for project Aquarium ****
   xmake CONFIG=Default all 
   Checking build modules
   Using build modules: lib_startkit_support(2.0.0) module_i2c_master module_random
   Analyzing Aquarium.xc
   mkdir -p '.build/src/'
   cd ./.build && xcc -pre-compilation-analysis   -O2 -g   -DCONFIG=Default -D__random_conf_h_exists__=1 -I'../.' -I'.././bin' -I'.././src' -I'/Users/teig/workspace/lib_startkit_support' -I'/Users/teig/workspace/lib_startkit_support/api' -I'/Users/teig/workspace/lib_startkit_support/doc' -I'/Users/teig/workspace/lib_startkit_support/doc/pdf' -I'/Users/teig/workspace/lib_startkit_support/src' -I'/Users/teig/workspace/module_i2c_master' -I'/Users/teig/workspace/module_i2c_master/src' -I'/Users/teig/workspace/module_random' -I'/Users/teig/workspace/module_random/src' '../src/Aquarium.xc' '.././STARTKIT.xn'  '.././config.xscope' -o '../.build/src/Aquarium.xc.pca.xml' > /dev/null
   ../src/Aquarium.xc:35:10: warning: unused variable `c_analogue'
       chan c_analogue;
            ^~~~~~~~~~
   ../src/Aquarium.xc:39:76: warning: `i_analogue' not used in two parallel statements
           on tile[0].core[0]: test_display (i_delay, c_button_1, c_button_2, i_analogue);
                                                                              ^~~~~~~~~~
   xcc1: terminated due to internal unrecoverable error
   For bug reporting instructions, please see:
   http://www.xmos.com/support
   xmake[1]: *** [.build/src/Aquarium.xc.pca.xml] Error 1
   xmake: *** [analyze] Error 2

   Here’s the code that seemed to fix this. There is something about placements here. I did send the failing code to XMOS:

   int main () {
       chan c_external_button_1;
       chan c_external_button_2;
       interface delay_interface i_delay;
       interface startkit_adc_if i_analogue;  // For triggering/reading ADC
       chan c_analogue;                       // Used by ADC driver to connect to ADC hardware
   
       // From AN00177_startKIT_adc_demo:
       // These interface connections link the application to the GPIO task
       interface startkit_led_if    i_startkit_led;    // For setting LEDs
       interface startkit_button_if i_startkit_button; // For reading the button
   
       par {
           // Setup from lib_startkit_support.pdf:
           startkit_adc (c_analogue); // Declare the ADC service (this is the ADC hardware, not a task
           on tile[0]: adc_task (i_analogue, c_analogue, 0); // Run ADC server task (on same core as GPIO!)
   
           // Needed so far?:
           on tile[0]: startkit_gpio_driver (i_startkit_led, i_startkit_button, null, null, gpio_ports); // Run GPIO task for leds/button
           on tile[0].core[0]: startkit_blackhole (i_startkit_led, i_startkit_button);
   
           // Certainly needed:
           on tile[0].core[0]: test_display (i_delay, c_external_button_1, c_external_button_2, i_analogue);
           on tile[0].core[1]: inP_Button_Task (BUTTON_1, inP_button_1, c_external_button_1);
           on tile[0].core[1]: inP_Button_Task (BUTTON_2, inP_button_2, c_external_button_2);
           on tile[0].core[3]: server_delay_iff (i_delay);
       }
   
       return 0;
   }

   Update 10April2015: XMOS informed me that they had an update that fixed this problem: xTIMEcomposer 14.0.1. After I upgraded I haven’t seen this incidence
7. How to get the ADC on startKIT to work. This took me an awful lot of time! I had already downloaded and used code from AN00177_startKIT_adc_demo and it ran. Still I used hour after hour – the debugger just left me at the i_adc.trigger() call. It looked like a deadlock. But then I discovered that the code stopped in init_adc_network in startkit_adc.xc, and that it believed that the links were not configured. Then I discovered the How
   to use the ADC on StartKit? thread, and downloaded the startkit-adc demo code. It also ran; not that strange, the demos look alike. Then I saw its config.xscope file. I pasted the contents into my Aquarium project’s config.xscope. Now it seems to work! I’ll try to make a short explanation of this when I understand it. Observe that there is a problem with the A/D values converted on the startKIT, see startKIT ADC problem (below).

   ADC on startKIT needs this config.xscope!

   <?xml version="1.0" encoding="UTF-8"?>
   <xSCOPEconfig enabled="true" ioMode="basic">
   <Probe name="ADC0" type="CONTINUOUS" datatype="INT" units="n" enabled="true"/>
   <Probe name="ADC1" type="CONTINUOUS" datatype="INT" units="n" enabled="true"/>
   <Probe name="ADC2" type="CONTINUOUS" datatype="INT" units="n" enabled="true"/>
   <Probe name="ADC3" type="CONTINUOUS" datatype="INT" units="n" enabled="true"/>
   </xSCOPEconfig>
   

8. Undefined reference; when I had copy/pasted app from main.xc in AN00177_startKIT_adc_demo, and I had forgotten to rename it to what was in the header: startkit_blackhole. I had used the new name where it was started in the par in another file; it was this compilation that failed. I can now understand the messages, but a somewhat higher level error message might have saved me an hour!
   

   'Undefined reference' log

   Undefined reference to 'startkit_blackhole'	
   Undefined reference to 'startkit_blackhole.dynalloc_maxchanends'
   Undefined reference to 'startkit_blackhole.dynalloc_maxcores'
   Undefined reference to 'startkit_blackhole.dynalloc_maxtimers'
   Undefined reference to 'startkit_blackhole.select.enable'
   Undefined reference to 'startkit_blackhole.init.1'
   Undefined reference to 'startkit_blackhole.init.0.savedstate'
   Undefined reference to 'startkit_blackhole.init.0'
   

9. I am in fine dialogue with XMOS about the problems above. They have already come back a couple of times after I filed a report.
10. 2April2015: A subscribed-to info told me that  xTIMEcomposer 13.2.2 was available. I had already been running 13.2.1 and the newer 14.0.0. But since this looked rather new, I downloaded it. When I tried to debug it said «No such debugger» as above. So I again deleted Aquarium and made a new fresh project with the same name, and imported all the files. No such debugger disappeared. But it was hard to get it to run. I have seen before that if I righ-click on the project, and use that drop-down menu to Debug As or Run As then that takes me there. But I still don’t get the starkit_adc library to run. After the first i.trigger(); to it, it stops and that’s it.
11. 2April2015. When running xTIMEcomposer 14.0.0 again after the exercise above I had to do exactly the same delete and install and then import files, to get rid of «No such debugger».
12. The big list of Invalid project paths it complained it couldn’t find (but it still compiled ok!?), like

    Include path not found (/Applications/XMOS_xTIMEcomposer_Community_14.0.1/target/include/c++/4.2.1). lib_startkit_support pathentry Path Entry Problem

    at first didn’t appear after I had again made the project from scratch and imported the three used libraries from workspace into workspace (yes!). But then, after a clean, it was there again.

13. 27April2015: New post by me in xCore Exchange: XMOS in safety critical systems: IEC 61508 and spatial and temporal independence, see http://www.xcore.com/questions/3283/xmos-safety-critical-systems-iec-61508-and-spatial-and-temporal-independence

Daily III (xTIMEcomposer 14.0.3)

First is #10.01. Started 17June2015. xTIMEcomposer 14.0.3 (for OS X Yosemite 10.10.3)

1. (16June2015) I experienced a total hang with spinning beach ball. OS X caught it and a report was sent to Apple. Probably an effect of «wild» button pressing on my behalf

Daily IV (xTIMEcomposer 14.0.4)

First is #11.01. Started 7July2015. xTIMEcomposer 14.0.4 (for OS X Yosemite 10.10.4)

1. xTIMEcomposer 14.0.4 NullPointerException, posted to xCore Exchange, see http://www.xcore.com/questions/3509/xtimecomposer-1404-nullpointerexception. Here’s the text: «I started it on OS X Yosemite 10.10.4 with Java Runitime 1.8.0_45. When I fiddled around finding my password (which, since it’s Java isn’t a process helped by the OS?) it just got the NullPointerException. When I finally found it xTIMEcomposer seems to work ok.»

startKIT ADC problem

(20May2016) At the very end of this section there is a chapter called startKIT ADC problem described by XMOS that closes this case.

(23April2015) New post by me to xCore Exchange: startKIT adc values seem to float, see http://www.xcore.com/questions/3273/startkit-adc-values-seem-float

(27Sept2015) This is the same problem as described above and filed at startKIT adc values seem to float, which was not resolved. After I got the problem well isolated I have now reported it again (7Oct2015), see lib_startkit_support ADC accuracy.

I now also  have a second startKIT. Instead of the TC1047A temperature unit I now made a small board (diagram is PDF export from iCircuit pasted into a Pages document, then PDF from it, all vectorised, just press to get it):

Press to get PDF

With the test board above, plugged into the startKIT J2 analoge input header running the following speed, I get the results (also below). I have a BitScope BS10 and the pulses are as expected. Below is the complete code. This is the server that uses the adc_task (click to expand):

startKIT ADC problem code

/*
 * startKIT-adc-test.xc
 *
 *  Created on: 29. sep. 2015
 *      Author: Øyvind Teig
 *      https://www.teigfam.net/oyvind/home/technology/098-my-xmos-notes
 */

#include  <platform.h>
#include  <stdio.h>
#include "startkit_adc.h"

#define NUM_STARTKIT_ADC_VALS 4

typedef struct tag_startkitd_adc_vals {
    unsigned short            x[NUM_STARTKIT_ADC_VALS];
    unsigned short          max[NUM_STARTKIT_ADC_VALS];
    unsigned int       mean_sum[NUM_STARTKIT_ADC_VALS];
    unsigned int       mean_cnt;
    unsigned short          min[NUM_STARTKIT_ADC_VALS];
} t_startkit_adc_vals;

#define ADC_PERIOD_TIME_USEC 0 // 1000 would mean to let
// free running and query-based "compete", not very smart!
#define ADC_NUM_SAMPLES 1000  


void test_adc (
    client interface startkit_adc_if i_analogue)
{
    unsigned wait_for_adc = 0;
    unsigned int loop_cnt = 0;
    unsigned int adc_cnt = 0;
    unsigned int no_adc_cnt = 0;
    t_startkit_adc_vals adc_vals;

    for (int i=0; i<NUM_STARTKIT_ADC_VALS; i++) {
        adc_vals.min[i]      = 0xffff;
        adc_vals.max[i]      = 0;
        adc_vals.mean_sum[i] = 0;
        adc_vals.mean_cnt    = 0;
    }
    while(loop_cnt < ADC_NUM_SAMPLES) { 
        loop_cnt++; 
        i_analogue.trigger(); 
        wait_for_adc = 1; 
        select { 
            case wait_for_adc => i_analogue.complete(): {
                wait_for_adc = 0;
                if (i_analogue.read (adc_vals.x)) {
                    for (int i=0; i<NUM_STARTKIT_ADC_VALS; i++) {
                        if (adc_vals.x[i] > adc_vals.max[i]) {
                            adc_vals.max[i] = adc_vals.x[i];
                        }
                        if (adc_vals.x[i] < adc_vals.min[i]) {
                           adc_vals.min[i] = adc_vals.x[i];
                        }
                        adc_vals.mean_sum[i] += adc_vals.x[i];
                    }
                    adc_vals.mean_cnt++; // Equally many for each
                    adc_cnt++;
                } else {
                    no_adc_cnt++;
                }
                break;
            }
        }
    }
    // Internal A/D-converter
    // 0 to 65520 (0xFFF0)
    // Div 16 = 0 to 4095, ref = 3.3V
    // 3300 mV / 4096 = 0,8056640625 mV
    // 750 mV = 25 DegC then 10 mV/DegC
    // See XS1-A8A-64-FB96-Datasheet(1.3).pdf
    // See below about "Some needed offset values"
    printf ("Summary of ADC: %u trials %u readings (%u lost)\n",
            ADC_NUM_SAMPLES, adc_cnt++, no_adc_cnt++);
    for (int i=0; i<NUM_STARTKIT_ADC_VALS; i++) {
        unsigned int adc_val_mean_i = 
             adc_vals.mean_sum[i]/adc_vals.mean_cnt;
        int  DegC_OneTenth_Parts = 
             (((adc_val_mean_i*100) - 198545) / 1985) - 400;
        int  DegC_Unary_Part = DegC_OneTenth_Parts/10;
        int  DegC_Decimal_Part = 
             DegC_OneTenth_Parts - (DegC_Unary_Part*10);
        printf ("i:%u DegC=%u.%u ", 
                 i, 
                 DegC_Unary_Part, 
                 DegC_Decimal_Part);
        if (i < (NUM_STARTKIT_ADC_VALS-1)) {
            unsigned overlapping = 
                (adc_vals.max[i] >= adc_vals.min[i+1]);
            unsigned int adc_val_mean_ip1 = 
                adc_vals.mean_sum[i+1]/adc_vals.mean_cnt;
            printf("min=%u mean=%u max=%u diff=%d X=%u\n",
                    adc_vals.min[i],
                    adc_val_mean_i,
                    adc_vals.max[i],
                    adc_val_mean_ip1-adc_val_mean_i,
                    overlapping);
        } else {
            printf("min=%u mean=%u max=%u\n",
                    adc_vals.min[i],
                    adc_val_mean_i,
                    adc_vals.max[i]);
         }
    }
}

int main () {
    chan c_analogue;
    interface startkit_adc_if i_analogue;
    par {
        on tile[0]: test_adc (i_analogue);
        on tile[0].core[0]: 
            adc_task (i_analogue, c_analogue, ADC_PERIOD_TIME_USEC);
            startkit_adc (c_analogue); // Declare the ADC service,
            // startkit_adc is the ADC hardware, not a task
    }
    return 0;
}

startKIT ADC problem log

== xTIMEcomposer 14.1.0
Cable out and in after error messages, as well as xTIMEcomposer restart
No display connected, short cable, no flourescent USB light on,
however non of this seems to matter
= ADC_PERIOD_TIME_USEC 1000 for all
  not very smart, see above - use zero. If zero then we get 0 lost all over
= ADC_TRIG_DELAY 100
Summary of ADC: 1000 trials 1000 readings (0 lost)
i:0 DegC=25.7 min=14880 mean=15030 max=15120 diff=209 X=1
i:1 DegC=26.7 min=15104 mean=15239 max=15376 diff=195 X=1
i:2 DegC=27.7 min=15312 mean=15434 max=15536 diff=198 X=1
i:3 DegC=28.7 min=15536 mean=15632 max=15760
= ADC_TRIG_DELAY 100
Summary of ADC: 1000 trials 1000 readings (0 lost)
i:0 DegC=25.6 min=14928 mean=15025 max=15120 diff=208 X=1
i:1 DegC=26.7 min=15088 mean=15233 max=15344 diff=197 X=1
i:2 DegC=27.7 min=15344 mean=15430 max=15536 diff=199 X=1
i:3 DegC=28.7 min=15472 mean=15629 max=15728
= ADC_TRIG_DELAY 40
Summary of ADC: 1000 trials 992 readings (8 lost)
i:0 DegC=25.6 min=14848 mean=15019 max=15120 diff=130 X=1
i:1 DegC=26.3 min=15008 mean=15149 max=15248 diff=197 X=1
i:2 DegC=27.3 min=15216 mean=15346 max=15440 diff=200 X=1
i:3 DegC=28.3 min=15360 mean=15546 max=15648
= ADC_TRIG_DELAY 40
Summary of ADC: 1000 trials 992 readings (8 lost)
i:0 DegC=25.7 min=14848 mean=15037 max=15136 diff=130 X=1
i:1 DegC=26.4 min=15040 mean=15167 max=15312 diff=196 X=1
i:2 DegC=27.3 min=15248 mean=15363 max=15456 diff=200 X=1
i:3 DegC=28.4 min=15424 mean=15563 max=15664

Some needed offset values

Update (Nov2016) when I finally came around to using the startKIT with for internal temperature in the box, two voltages and one light sensor connected to J2 A0-A3. I removed the connection and saw these offset values. Here is where I pick up mean values of 1000 or more raw values:

Some needed offset values code

#define OFFSET_ADC_INPUTS_STARTKIT 190,175,195,187 // Moe or less these values
case (client_state == ADC_AWAIT_READ_FROM_UP) => 
    i_startkit_adc_up.read (
        unsigned short return_adc_mean_vals[NUM_STARTKIT_ADC_INPUTS]) -> 
    {unsigned int adc_cnt, unsigned int no_adc_cnt}: {
    unsigned short offsets [NUM_STARTKIT_ADC_INPUTS] = {OFFSET_ADC_INPUTS_STARTKIT};
    for (int i=0; i<NUM_STARTKIT_ADC_INPUTS; i++) {
        if (adc_vals.mean_cnt == 0) { 
            return_adc_mean_vals[i] = 0;
        } else {
           return_adc_mean_vals[i] = 
               (unsigned short) (adc_vals.mean_sum[i]/adc_vals.mean_cnt);
           // Offsets measured on whole set with nothing connected on startKIT ADC J2
           // No underflow on unsigned short, i.e. it cannot go negative:
           if (return_adc_mean_vals[i] <= offsets[i]) {
               return_adc_mean_vals[i] = 0;
           } else {
               return_adc_mean_vals[i] -= offsets[i];
           }
       }
   }
}

Discussion

See what to expect from the processor in the next chapter (just below). Here’s a summary of what I do get:

65536 steps is 16 bits is  1 ADC per bit
 4096 steps is 12 bits is 16 ADC per bit
 1024 steps is 10 bits is 64 ADC per bit

startKIT
  3300 mV in 12 bits in 4096 steps is 0,8.. mV per bit
  3300 mV in 10 bits in 1024 steps is 2,6.. mV per bit

With my R-R network we have
  10 mV is 3,85.. steps of 10 bits
  «overlapping» (log above) is overlap from one to the next 10 mV step
  So, when overlapping is 1 it means about 8 bits accuracy
  Only difference is relevant, since the R-R network is not calibrated

750mV is 25.0 DegC at 10mv/DegC
  1.0 DegC is 10 mV is about 3.85 steps of 10 bits
  0.1 DegC is  1 mV is about one  step  of 12 bits

• The answer to these was finally provided by XMOS. See below chapter «startKIT ADC problem described by XMOS»
  • Each sample as compared to another in a set seems to be at worst 8 bit from the next
  • Mean of 1000 measurements is around 10-11 bits
  • I have tried different cores, no change
  • Is there some timing related issue in the adc_task sw or startkit_adc service?
• The answer to these is that I didn’t use ADC_PERIOD_TIME_USEC as 0, which would have meant no free-running ADC to «compete» with my query-based:
  • Why are some samples lost or not when ADC_TRIG_DELAY is changed?
  • Why doesn’t XMOS default value of ADC_TRIG_DELAY 40 cause zero lost?

XMOS internal ADC – what to expect?

I need to study what to expect, again.

startKIT board

Update Apr2018: see end of life (EOL) above.

From the startKIT Hardware Manual (https://www.xmos.com/support/boards?product=17441&component=17227) I read that  the xCORE-Analog A8-DEV device (processor XS1-A8-DEV) is only available as part of startKIT, and is therefore not separately documented. (See XMOS series of processors (above).) If you are using startKIT as a target platform and need datasheet-level documentation, you may find it useful to review the XS1-U16A-128-FB217 Datasheet, here: http://www.xmos.com/published/xs1-u16a-128-fb217-datasheet. Here’s from the 2015/04/14 doc XM002326 (text and table 18.4):

12 Analog-to-Digital Converter. The device has a 12-bit 1MSample/second Successive Approximation Register (SAR) Analogue to Digital Converter (ADC). It has 8 input pins which are multiplexed into the ADC. The sampling of the ADC is controlled using GPIO pin X0D24 that is triggered either by writing to port 1I, or by driving the pin externally. On each rising edge of the sample pin the ADC samples, holds and converts the data value from one of the analog input pins. Each of the 8 inputs can be enabled individually. Each of the enabled analog inputs is sampled in turn, on successive rising edges of the sample pin. The data is transmitted to the channel-end that the user configures during initialization of the ADC. Data is transmitted over the channel in individual packets, or in packets that contain multiple consecutive samples. The ADC uses an external reference voltage, nominally 3V3, which represents the full range of the ADC. The ADC configuration registers are documented in Appendix G.

ADC Characteristics: Resolution, Conversion Speed, Number of Channels, Input Range, Differential Non Linearity, Intergral Non Linearity, Gain Error, Offset Error, Power time for ADC Clock Fclk, Effective number of bits

Ok, with Effective number of bits 10 bits I have 3300 mV / 1024 = 3.22 mV absolute resolution. The figures I get are not near to that resolution.

startKIT ADC problem described by XMOS

(4Nov2015) I got the below document on mail from XMOS regarding my support ticket «8216: startKIT ADC problem» started 27Sept2015. They sent me the Design Advisory: XS1-U and XS1-A series ADC noise (Dated 2014-04-09). However, I did not feel it was right of me to inform about this here, so I kept silent.

(20May2016) I got a mail stating that the above mentioned design avisory «The U/A series ADC advisory has now been published on our website» at https://www.xmos.com/published/design-advisory-xs1-u-and-xs1-series-adc-noise. Here’s from it:

Issue description

Significant noise can be observed on ADC readings on the U and A series devices. For a 0 to 3.3 volt signal, this issue can introduce errors of ±50mV.

The severity of the issue is application dependent. For highly sensitive applications requiring maximum sample frequency, the issue can be critical. For applications where sensitivity is not crucial, and or oversampling and averaging techniques can be used, the severity can be regarded as normal, with workarounds available.

They also stated that there is no plan for an upgraded startKIT with an upgraded processor. Fair enough. I will use both the internal ADC with calculated long mean values and the MCP9808 High Accuracy I2C Temperature Sensor Breakout Board from Adafruit [ID:1782] in my aquarium project. (Disclaimer: this is just informative and and no ad.)

Daily VI (xTIMEcomposer 14.1.0)

Started 1Oct2015. xTIMEcomposer 14.1.0 (for OS X Yosemite 10.10.5). Machine (MacBookPro10,2). When I upgraded xTIMEcomposer I got

XTAG-2 Firmware not valid for this version, 
please power cycle the XTAG-2 device

Also when I downgraded and decided to run 14.0.4 again. It seems not to have so many of the below problems (on next try I seem to get out of them), so I have decided to continue with 14.0.4 for a while.

Running on startKIT

It’s becoming hard to get the debugger up and running. I do a lot of printf’s that may be the problem (I minimised it and it helped, but I still am plagued). Don’t know what to do. Many hang reports gone to Apple (XMOS). I have asked at xCore Exchange: ERROR: socket bind.(0). (Update: see xC is C plus x.)

This is the full list less the sequence and what I did or didn’t do:

.gdbinit: No such file or directory.
connect --adapter-id 0zGcIk5WkhKBj --xscope-realtime --xscope-port localhost:10101

Cannot connect, device is in use by another process
  Target connection failed
    Target is not responding (timed out)
    Target is not responding (timed out)
    Target is not responding (timed out)

Cannot connect, device is in use by another process
xrun: Problem in connection to device

ERROR: socket bind.(0) 

I saw these after downgrading to 14.0.4, but I seem to succeed «next time»:

First stage multi-node boot failed, please check XN file and Xmos link connectivity

Terminate failed
  Target is not responding (timed out)
    Target is not responding (timed out)
    Target is not responding (timed out)

Load failed
  Target is not responding (timed out)
    Target is not responding (timed out)
    Target is not responding (timed out)

Machine (MacBookPro10,2) restart seemed to help, first run ok (but then the log window gets full..). Some times the the xTIMEcomposer window isn’t drawn, some times it’s ok when I hover over places. At the moment I think xTIMEcomposer is too complicated (it works when everything is ok?) but impossible(?) to find out of on my own. I think 14.1.0 is worse than 14.0.4.

Daily: xTIMEcomposer (14.2.1)

14.2.1 release note here.

A crash with «xcc1: terminated due to internal unrecoverable error» was filed in March 2016 (as #8810 at the then valid xTIMEcomposer). It had not been fixed with 14.2.1, but the code was changed so I didn’t see it. Same problem with my code compiled with 14.2.3

I filed  a new error report to XMOS (as #9481) about a case when a composite structured value is declared in a header file that’s used by several:  «Error: Multiple definition of ‘i2c_server_param.globound'». I was confused because it had no member ‘globound’. If I just declare an «int value;» I would get  «Error: Multiple definition of ‘value'». It also didn’t resolve the line number where the first declaration was seen. The error listing needs to be brushed up in my opinion.

Daily: xTIMEcomposer (14.2.3)

14.2.3 release note here.

Ticket: Returning values in arrays via interfaces

I filed a new error report on 25Jan2017 called «9731: xcc1: terminated due to internal unrecoverable error». I had OS X El Capitan 10.11.6, Version: Community_14.2.3 (build 15642, Oct-17-2016). I simply declared this as a method call in an interface, I didn’t even need to implement the method.  It’s obviously(?) very wrong:

typedef interface temperature_heat_commands_if {
    {char [4], char [4], char [4]} get_all_temp_degC (void);
} temperature_heat_commands_if;

int main() {
    return 0;
}

They (as usual) came back with people on the case. I believe the compiler in the future will give a proper error report. Fair enough, even if I think it should be perfectly legal to return array(s) like that.

In communicating arrays, typically in a read method that clears_notification I’ll just quote myself in that internal XMOS ticket:

I ended up using an array of bytes in the standard parameter set, like in the return of values from the ADC module for the startKIT.

However, I do have to fill every byte by hand (or in a loop). Even if I make a typedef of the array and use that both in the parameter list and internally it will complain about lvalue. It probably is so because of a pointer behind it. Still I assume the return is by value, since the read clears_notification. When I am _using_ an array by value and in my head _thinks_ of the assignment by value then I don’t see why the not-lvalue assignment should stop me.

I could move this into the Xcore group or continue with a new case here. Maybe you could mention it for somebody. While they fix this crash now, they could get away with that lvalue problem as well and let me do

return_array = internal_array;

of same types!

I am eager to see where this ends. Up to now (and probably for the future, they tend to have things thought well through), their suggestion is shown at How to use memcpy with interface array arguments. They say  that in this solution «memcpy can actually optimize the transfer across tasks». (Noting later that it’s because on a single tile all memory is shared). Well, put it in the language then, because that’s exactly what a typesafe assigmnent of an array does!

Update 19Feb2019: I also handled this memcpy-theme at memcpy or not?

Ticket: Unrecoverable error with wrongly typed typedef of array used in interface return

I filed an error report on 9Feb2017 called «9772: Unrecoverable error with wrongly typed typedef of array used in interface return». It turned out that it had been fixed in 14.3, probably the next version.

Ticket: xTIMEcomposer hangs when starting startKIT

I filed an error report on 20Feb2017 called «9808: xTIMEcomposer hangs when starting startKIT».  This was internally passed on to engineering.

Daily: xTIMEcomposer (14.2.4)

14.2.4 release note here.

Ticket: Variable length array causes unrecoverable error

Some times I am using xC so wrongly. But the compiler needs to explain rather than crash. But then, I assume this is assert programming – so much better than quietly building a wrong object file. 18Mar2017: «9916: Variable length array causes unrecoverable error».

Ticket: Tuning down #chanends causes stops etc

I did try several #define’d par fields to experiment with moving tasks around. Quite many builds worked flawlessly, I had real fun. However, at some stage the code halted after some hundred ms. Also, in other cases I got error reports from the build system that I didn’t understand. 28Mar2017: «9964: Tuning down #chanends causes stops etc!». For the XMOS tools guys data base! These tickets are always related to in some way, and relayed back to me. Also see an xCore issue (below).

Ticket: Possibly missing error message around clears_notification

See «error: slave modifier without [[notification]] attribute is not supported» here. There is no such error message if [[clears_notification]] is missing, even if there are two or more clients. I assume that the code is built correctly, but that the error message is missing; consequently that [[clears_notification]] isn’t needed? 8April2017: «9993: Missing [[notification]] tag error message exists, but not error message for missing [[clears_notification]] tag». After this I also discovered that a missing [[guarded]] tag also is not erred.

Daily: xTIMEcomposer (14.3.0)

May 2017. 14.3.0 release note here. 14.3.0 does not build my sources as 14.2.4 since my project runs incorrecly. Need to work on it, plus report the problems I have found with 14.3.0 to XMOS. I did find the cause, see second ticket below.

Ticket: iso646 or_eq does not resolve correctly on local type

18May2017 (10110). <iso646.h> defines or_eq plainly as |=. When compiled with 14.3.0 on a locally declared enum the compiler complains with «note: expanded from macro ‘or_eq’«. Even if it seems like a note xmake exits with error. Namely this:

According to feedback from XMOS I gather that the ticket’s heading should have been «wrong error: invalid operands to binary |» – which is more precise. «Handling of bitwise operations on an enum indeed appears to have changed in version 14.3.»

Ticket: Possible boolean guard livelock on 14.3.0

20May2017 (10116). A guard was taken all the time when there was a complex boolean expression to stop it. It works on prior versions, like 1.2.4.

Update 7July2017: The title is wrong. Something like «Possible par placement causing livelock on 14.3.0» would cover better. I found a workaround that works on 14.3.0.

Update 24Aug2017: I received info from XMOS that it has been fixed and will be included in a new release

Update 6Oct2017: Fixed in 14.3.1

Ticket: xTIMEcomposer running on outdated Eclipse for some Eclipse Marketplace plugins

17July2017 (10246). See here

xTIMEcomposer more tips

This probably should all be at http://www.xmos.com/support/examples

printf from sw running on startKIT

• First, perhaps this solves your questions: AN10120: How to read/write to the console during execution
• printf lines won’t just go to your screen! And if it doesn’t there nothing that warns you that it won’t happen! Do like this:
• xTIMEcomposer:
• Run:
• Debug Configurations:
  • Main: Run on: hardware. Target: XMOS starKIT connected to …. Run JTAG I/O server
  • XScope: Real-Time Mode
  • Debugger: Stop on startup at: main (not needed for printf, though). (A problem with this is described in No source available for «main() » but there is below)

Figure 3. Visible printf lines are red

• But when you have started the debugger you won’t necessarily see the correct console window where your printf logs will appear. Hold the cursor over the icons in the Console (partial screen clip above) and activate:
  • Show Console When Standard Out Changes
  • Show Console When Standard Error Changes
• Then, press the down arrow and get the pull-down menu of the blue-framed screen. For me it has:
  • 1 CDT Global Build Console
  • 2 CDT Build Console [Aquarium]
  • 3 Aquarium.xe [xCORE Application] xgdb (21:35 13.11.16)
  • 4 Aquarium.xe [xCORE Application] /Users/../../Aquarium.xe (21:35 13.11.16)
• Also see xCore: System time tag of printf in xTIMEcomposer debug console (below)

Long compiler error logs

It is possible to do a single change of the code, in one line, and get a very, very long compiler error log that takes very long to print to the console. And the first line of the log doesn’t necessarily point to your error.

As an example I had an array of interfaces that I didn’t listen to in the select case line with the listen-to-array-of-interface syntax. It took me long to find out, because I had done some copy paste. When I used the right syntax, zero errors. With, several hundred errors.

Even if it takes perhaps 30 seconds to print to the console window, the compiler always has completed within a second. It the console printout slowed up on purpose?

This is «worse than C». The best compiler I have used on this was the Inmos occam compiler. It showed the problem, seldom more. Not follow-up errors. C is bad on this, we know that. But we also know it’s because of the many idiosyncracies of C. But I assumed that xC would be more coherent, since much of it is occam in new clothes. This is for errors on .xc files, so the compiler should know…

(Nov 2016) I filed one of these examples as a problem report to XMOS.

xCORE-XA Core Module Board (with xCOREs and ARM)

xCORE-XA board

(Update Mar2017: Has reached end of life, see xCore: xCORE-XA end of life and ARM (below))

(Update 13July2016) I bought one of these (also called xCORE XA) in early 2015, but haven’t started using it yet. I bought it because its processor has standard 8-core xCORE logical kernels and one ARM kernel (ARM Cortex-M3, Wikipedia). The processor XS1-XAU8A-10-FB265 data sheet is here. (See XMOS series of processors (above).) It is still presented on the XMOS pages, and I think it’s the only type of processor in which they have an ARM core. However, the board is already obsoleted, but you’ll find it at the XMOS | SUPPORT| BOARDS: GENERAL PURPOSE | Older boards. This link may take you there. However, the manual is here. Hopefully these links are permanent. The board should be rather ok for analogue, I assume.

When I retire (in 2017) I plan to build a general channel-based run-time (real-time, scheduler), and test it on this ARM – and the Arduino? (Update Jun2020, I did not do this. But I did pick my boards up from a box, see My processor to analogue audio equaliser notes). I did ask at the xCore Exchange whether that ARM could run xC. Of course it can’t. See Is it possible to program ARM core of xCORE-XA using xC prog. But I could do something, based on my and Vannebo’s paper «New ALT for Application Timers and Synchronisation Point Scheduling» (here) used in «ChanSched». Those who live will see.

Ok; this isn’t my first time

I have worked with development tools and external HW (and designed some boards) over a life time (Block play for blockers). I’ve had hands on with lots of IDEs. I would only just admit that my first Algol program was delivered on punched cards to the «Orakeltjenesten» at NTH here in Trondheim when I was a student 1971-76. The «Oracle service» still exists. However, I have only as a short visit worked with an Eclipse-based IDE. It was a Mentor Graphics development system for an  embedded ARM running the Nucleus OS (now RTOS) around 2006. But at that time it was rather unstable, so we ended up using the tool from Keil, just acquired by ARM. And now, when I was happy to see Java applets finally disappear from the Norwegian «BankID», I decided to use and learn the XMOS toolset. It’s a private project, and here Macs rule. I look forward to this journey!

I expect to see a modern development system, even better than the Texas Instrument Development System in the 70-80-90ies and the Occam 2 Toolset in the 85-90ies, both of which I have worked with for years. The XMOS processor architecture is a fantastic new family member, starting with grandfather Ti processors 9990’s and father Transputer. I look forwards to this!

More xCore Exchange (XE community) forum posts

The below are my xCore Exchange entries not mentioned elsewhere in this blog note. Just search for «xCore Exchange» to find all.

xCore: A nondeterministic note about nondeterminism

See A nondeterministic note about nondeterminism (25Apr2012)

xCore: Protecting startKIT I2C and 3.3V from 24V surge?

10Sept2016. See http://www.xcore.com/forum/viewtopic.php?f=47&t=4844 (10Sept2016). Here is my initial question (below). See there for any replies.

I am connecting an Adafruit MCP9808 I2C temperature sensor underneath my aquarium together with heating cable driven by 24V DC, pulsed by the startKIT. I connect SDA and SCL on MCP9808 to X0D23 (J72) and X0D22 (J73). It’s powered by the 3V3 output. I2C doesn’t need much speed.

Is there any way at all to protect the startKIT processor from a broken heating cable that hits the MCP9808? It would be ok for the MCP9808 to break, but rather not the startKIT.

I have simulated 300 Ohm in series with the SDL and SLC and 300 Ohm in series with the 3.3V, but I don’t think it much useful. NXP advices this for SDA and SCL in their UM10204 «I2C-bus specification and user manual». MCP9808 has 10K pull-ups on SDA and SLC. I have not added any zeners. See attached PDF. I’m afraid it’s too complex. It’s not going to be in a rocket..

(PDF attachment)

I have already made the layout such that during normal usage there’s virtually no probability of any accidental 24V. The heating cable seems sturdy. I do this to monitor the max temp under there of some 50-60 DegC. The cable is 2 x 14 meters to spread out the effect, 2 x 24 W.

I haven’t found any max ratings of the Tile 0 IO in the XS1-U16A-128-FB217 Datasheet.

I am tempted to let the connections just go unprotected. But in case there is a simple way?

I got a very extensive reply from «mon2», especially pointing me to I2C isolators. I was intrigued by the I2C Isolator click from MikroElectronika in Serbia. New company for me! I’ll buy one isolator!

xCore: Debug to stop at main and other breakpoints unresolved

See http://www.xcore.com/viewtopic.php?f=26&t=5003 (Nov. 2016)

Next on this theme is xCore: No source available for “main() ” but there is

xCore: An error pin?

See https://www.xcore.com/forum/viewtopic.php?f=44&t=5083 (22dec2016) about how to make one’s own exception handler and even pull a line to beep when it’s invoken.

Update 12Jan2017: After this version 14.2.4 of xTIMEcomposer came with «Improved error reporting for runtime exceptions within application code» (here). See follow-up at xCore: Improved error reporting for runtime exceptions within application code

xCore: Logical cores as IEC61508 «differing systematic capability»?

See https://www.xcore.com/forum/viewtopic.php?f=7&t=5089 (23dec2016) about this matter. I have discussed the basis of it here. This is very interesting!

xCore: Wi-Fi sliceCARD and ports on startKIT

See https://www.xcore.com/forum/viewtopic.php?f=44&t=5095 (29dec2016) (Also written: WiFi sliceCARD)

Here’s my summary in that note, done after great help from henk and mon2:

Now I got it! Since I came to the startKit not via the sliceKIT core board it took you two to point me to the fact that there are four kinds of mapping of pins with four PCIe connectors (called STAR, SQUARE, TRIANGLE and CIRCLE after slots on the sliceKIT core board with those names and labels). And alas, there is no general way to #define these in the code. And even if the startKIT has PCIe the mapping is like none of the four. Pin budgeting is difficult. So, here’s a summary of the above, with pin PCIe B6 as an example (xC coding was not in my original question):

From

https://www.xmos.com/download/private/sliceKIT-Hardware-Manual(1.0).pdf

2.10.1

STAR

    B6 X0D2 P4A0 P8A0 P16A0 P32A20
2.10.2

SQUARE

    B6 X1D2 P4A0 P8A0 P16A0 P32A20
2.10.3

TRIANGLE

    B6 X0D26 P4E0 P8C0 P16B0 (*)
2.10.4

CIRCLE

 
    B6 X1D26 P4E0 P8C0 P16B0 (*)
(*) This is the code in Main.xc in app_tiwisl_simple_webserver: XS1_PORT_4E 

From my starting question attachment #1 (2016 12 29 startKIT connections.pdf)
and in comments above:

startKIT

    B6 X0D14 P4C0 P8B0 P32A28 (*)
(*) Meaning xC remapping is necessary and makes sense

It’s a strange library/module that needs a git branch to define these matters! Has XMOS done their homework?

Update 9Jan2017: I have discovered group pin precedence (port precedence). See XS1 port-to-pin mapping, here. It’s also described in XS1 Ports: use and specification, see here. Quote from it:

The XS1 architecture has 16 logical ports, and the total number of pins by far exceeds the number of pins on the package. Ports, and Xlinks are therefore multiplexed, and there is a defined precedence when overlapping ports and links are used. The (SIC)

Also, there’s a way to display how a compiled mapping ended up, see Application Note: AN10100 How to display the pin, port and link mappings for a particular target, see here.

• Update 11Sept2017: See My xCORE-200 eXplorerKIT notes (WiFi) (below (a new note))
• Update 7Aug2017: Related note at Notes 3: WiFi sliceCARD via PCIe/GPIO?

xCore: Atomicity of handling of port pins

See https://www.xcore.com/forum/viewtopic.php?f=26&t=5096 (29Dec2016)

The short answer (to how sharing of ports is handled) is that the compiler does parallel usage checks and will neither accept sharing of the same port nor sharing of the same variable between tasks. It issues variable/port «violates parallel usage rules». I like it!

xCore: timerafter parameter

See https://www.xcore.com/forum/viewtopic.php?f=26&t=5109. (4Jan2017) Again some great answers.

I also commented on the replies in an entirely different blog note, see Know your timer’s type chapter «XMOS Xcore XE Community discussion group».

xCore: Mapper output file: mapfile?

(map file) See http://www.xcore.com/forum/viewtopic.php?f=26&t=5141. (11Jan2017) Use:

xCC_FLAGS = -O2 -g -fxscope -save-temps
xCC_MAP_FLAGS = -Xmapper --map -Xmapper _Aquarium_map.txt -Xmapper -report

Also, there are some discussion on how to get an overview of the number of timers (timer or tmr) as used in a linked and mapped system. Basically it only allocates one timer per logical core. Read in the thread. But henk sums it up:

The architecture resource ‘timer’ maps onto the xC type ‘timer’.
There is two ways that this mapping can be achieved – soft, in which case the compiler conjures up one architecture-timer per thread, or hard, in which case the compiler allocates an architecture-timer for each timer declaration in xC. The latter enables the most efficient selects with multiple time-outs.

Indeed, port counters are something different, they count clock edges from an IO pin into a clock-block.

Update 12Jan2017: After this xTIMEcomposer 14.2.4 had «Binary viewer displaying information of compiled binary including resource usage» (here). Great!

xCore: xTIMEcomposer 14.2.4 on macOS 10.12 Sierra?

See http://www.xcore.com/forum/viewtopic.php?f=26&t=5153 (16Jan2017)

xCore: myif not used in two parallel statements (byte range 4..8)

See http://www.xcore.com/forum/viewtopic.php?f=26&t=5163 (18Jan2017)

xCore: System time tag of printf in xTIMEcomposer debug console

See http://www.xcore.com/forum/viewtopic.php?f=26&t=5207 (25Jan2017)

xCore: Debugger exit code or action

See http://www.xcore.com/viewtopic.php?f=26&t=5563 (31Jan2017)

xCore: Calculating number of chanends

See http://www.xcore.com/viewtopic.php?p=28445#p28445 (Feb2017)

It’s very seldom that I don’t get a response. My guess is that this is rather sensitive information, part of XMOS’ competitive advantage, perhaps? But in my opinion XMOS has an education job to do here.

In [7] chan and chanend are defined as follows:

The chan type specifies a logical communication channel over which values can be communicated between parallel statements (§8.8). The chanend type specifies one end of a communication channel.
The locations of at most two implied ends of chan (themselves chanends) are defined through the use of the channel in at most two parallel statements (§8.8).
Channel ends are used as operands of input and output statements (§ 8.3). Channels are bidirectional and synchronised: an outputter waits for a matching inputter to become ready before data is communicated. Whether a streaming channel is synchronised or unsynchronised is implementation-defined

This means that there are two chanends per channel. But how many per interface? And how many par placement or as a function of [[combinable]], or [[guarded]] or [[notification]]–[[clears_notification]] (session or just RPC) or not?

Here’s a quote from a mail, but I have my doubts about this:

Regarding the channel end numbering, I wouldn’t know how exactly the compiler/linker allocates channel numbers. I would always expect exactly 2 channel ends per channel and 0 or 2 channel ends per interface. 0 is for combined or distributed tasks, where functions break down into blocks of code running in one logical core.

The reason for my doubts is that I have tried different combinations of this and I seem to get increments or decrements of zero, one or two chanends when I try something. It even caused the whole system to stop in some combinations (9964).

Observe that since a chanend is bidirectional then you may save two of them by correctly taking advantage of that. See Using a chanend in both directions

Update July2018: A new blog chapter xC is C plus x, chapter The combined code: 6 to zero channels shows 16 examples! It’s also shown on the xCore Exchange: The combined code: 6 to zero channels!

xCore: Number of chanends on different boards?

See http://www.xcore.com/viewtopic.php?f=26&t=5609 (Feb2017). Here’s the answer: «In short, every xcore tile in every chip we make has 32 channel ends. The startkit has one (XS1) tile available to the user, so has 32 channel ends on the available tile.» I think, minus one per tile if you’re using printf. See above, there may come some response to it there.

xCore: Safe sprintf?

I was pointed to snprintf, which is safe. However, when I replaced all sprintf with snprintf I went from 50 to 62 kB memory. So it’s very expensive. This took me back to personal code review and made myself sure that all sprintf calls were safe. Also, I now check the return, it will inform of number of filled chars, including overflowed chars and/or terminating NUL.

See http://www.xcore.com/viewtopic.php?f=26&t=5636 (Feb2017)

xCore: xCORE-XA end of life and ARM

See http://www.xcore.com/viewtopic.php?f=8&t=5653 (Feb2017)

Xcore: Different results: correct when debugged but wrong when flashed

It was my fault! I had forgotten to initialise a variable!

See http://www.xcore.com/viewtopic.php?f=26&t=5662 (Feb2017)

xCore: Improved error reporting for runtime exceptions within application code

See http://www.xcore.com/viewtopic.php?f=26&t=5678 (Mar2017)

xCore: Proving determinacy

See http://www.xcore.com/viewtopic.php?f=26&t=5712 (Mar2017)

xCore: Watchdog on startKIT processor?

The answer is no and alas, the compiler won’t stop you from trying!

See https://www.xcore.com/viewtopic.php?f=44&t=5738 (April 2017)

xCore: Being both client and server in the same select

This is a case where I seem to be forced to use a nested select construct. See update 5April2017 of https://www.xcore.com/viewtopic.php?f=26&t=5037 (Nov2016, updated April2017). I have noted to XMOS that I have a feeling that this is associated with the internal ticket 9964.

xCore: Using a chanend in both directions

A chanend is actually bidirectional, and you can use it in both directions, provided it’s done equally on both sides.

See https://www.xcore.com/viewtopic.php?p=29232#p29232 (April 2017). It’s also a chapter in xC is C plus x

xCore: [[single_issue]] and [[dual_issue]]

See https://www.xcore.com/viewtopic.php?f=26&t=5817 (May 2017)

xCore: Any xTIMEcomposer __VERSION__ like macro?

See https://www.xcore.com/viewtopic.php?f=26&t=5837 (May 2017)

xCore: Building to hex etc. file and flashing from that file without rebuilding

The XFLASH GUI didn’t work and it was reported internally at XMOS.

See http://www.xcore.com/viewtopic.php?f=26&t=5929 (July 2017)

xCore: No source available for «main() » but there is

Some kind of follow-up from Debug to stop at main and other breakpoints unresolved

See http://www.xcore.com/viewtopic.php?f=26&t=5934 (July 2017)

xCore: Free issue tracking that goes with xTIMEcomposer (or Eclipse) – or not?

See http://www.xcore.com/viewtopic.php?f=26&t=5947 (July 2017)

It boiled down to me trying to install the plugun Eclipse Todo Editor http://www.sebastianbenz.de/a-simple-text-based-todo-editor-for-eclipse. But I did not succeed.  Here’s a suggestion for a summary. It needs Xtext.

• In the Xtext page https://eclipse.org/Xtext/releasenotes.html I see that the minimal Eclipse version is called «Luna»
• In https://en.wikipedia.org/wiki/Eclipse_(software) I see that «Luna» is Eclipse 4.4 of June 2014
• According to https://www.xmos.com/download/private/Tools-Release-Notes-Community_14(Community_14.2.4).txt xTIMEcomposer uses Eclipse 4.3 («Kepler», 2013) and Eclipse Marketplace is supported.
• This could be the reason why I am not able to install Xtext(?)

I made an issue of this. See here

xCore: Chicken and egg: xTIMEcomposer and GitHub

See http://www.xcore.com/viewtopic.php?f=26&t=5962 (July2017)

Update: I’ve covered it more in a note: My Git/GitHub notes

xCore: Old USB hub causing xTIMEcomposer to hang?

I have had problems with xTIMEcomposer hanging with a rotating wheel (Mac) so much, actually for years, every new version, no change. I have had to kill it by hand. It seemed to be happening when I started debugging or changing window or something in that area.

More at http://www.xcore.com/viewtopic.php?f=26&t=6025 (Aug2017)

xCore: Loading SPI_CLK is no good

See note 143. Some adjacent search words: load, float, floating, oscilloscope probe, crash. (Sep2017)

xCore: «Parse error» causing «conflicting types» with «previous declaration» back to line of parse error

See https://www.xcore.com/viewtopic.php?f=26&t=6079 (Sept2017)

This was my problem. However, the compiler error message was very confusing, and I query if it could have been made better?

xCore: How to move files into newly made git repository

See How to move files into newly made git repository

Update: I’ve covered it more in a note: My Git/GitHub notes (also mentioned above)

xCore: xTIMEcomposer, Java Runtime JRE and macOS

xTIMEcomposer 14.3.2. See xTIMEcomposer, Java Runtime JRE and macOS (Oct2017).

I also showed this here Some macOS / OSX notes chapter «Downgrading Java on High Sierra»

xCore: MSC of chan instructions in use

See MSC of chan instructions in use on xCore Exchange (Dec2017)

xCore: «WARNING: .. There could be API incompatibilities» BUILDING AN00122_using_webserver_library

See «WARNING: .. There could be API incompatibilities» BUILDING AN00122_using_webserver_library (Dec2017)..

It’s not really the WARNING that’s the problem. It’s the fact that (I have just learned, see ticket 10692) that there is not, and will not be, any SW from XMOS that runs a webserver on the eXplorerKIT.

Here is my summary, added as an introduction to the xCore query:

Could this be the right bird’s eye view of the situation when I want to run a webserver served over the Ethernet cable on an xCORE-200 eXplorerKIT:

eXplorerKIT has RGMII with its PHY. I can find AN00199 «XMOS Gigabit Ethernet application note», but it handles ICMP pings. No webserver.

The lib_webserver uses lib_xtcp (>=4.0.0) and I only find 6.0.x which is too new, since testing it is by Application note AN00122 «Using the XMOS embedded webserver library».

In any case lib_xtcp uses the MII interface (not RGMII) with the PHY since it’s developed for the sliceKIT with boards plugged onto it.

I have got the XMOS WiFi sliceCard running with the supplied webserver in the eXplorerKIT. It’s only using SPI and it works. But it’s not stable enough since the TI CC3000 has been parked. So I have been testing with a board with the Atmel/Microchip ATWINC1500 module, which seems to be updated, on an ARM Arduino Zero variant. It seems extremely stable.

Now, whether I should, on the eXplorerKIT, hope for a webserver with RGMII cabled or the ATWINC1500 WiFi is an open question.

Here’s what XMOS writes about it’s use in the AN00122: Using the XMOS embedded webserver library usage:

Required hardware

This application note is designed to run on any XMOS xCORE device.

The example code provided with this application note has been implemented and tested on the SliceKIT Core Board (XP-SKC-L2) with Ethernet Slice (XA-SK-E100) and GPIO Slice (XA-SK-GPIO) but there is no dependency on these boards and it can be modified to run on any development board which has an xCORE device connected to an Ethernet PHY device through an MII (Media Independent Interface) interface.

So this probably stopped me at this point: My single-board boards and why notes chapter Conclusion and todo list point 3. Hmm..

However, the [lib_ethernet] (as used by AN00122) runs both on MII and RGMII! It features «Media Independent Interface (MII) and Reduced Gigabit Media Independent Interface (RGMII) to the physical layer» (here).

xCore: How to resolve a CDTDebugModelPresentation.12=signal

See How to resolve a CDTDebugModelPresentation.12=signal (Apr2018) – Not solved! Probably an error with the toolset. Reported with 14.3.2, also present in 14.3.3

xCore: Num timers for startKIT and eXplorerKIT

See Num timers for startKIT and eXplorerKIT (May2018). It’s also about num chanends. Also see N clients client-server interface code. (14.3.3)

Daily: xTIMEcomposer (14.3.1)

Released Oct 2017. 14.3.1 release note here.  Version: Community_14.3.1 (build 25370, Aug-31-2017).

I was relieved to see issue «Ticket: Possible boolean guard livelock on 14.3.0» (10116) fixed. So now I need to test it on my Aquarium code, since I up to now have had to use 14.2.4. It’s on a good course. Comparing build logs. Blue added by me:

Aquarium xTIMEcomposer 14.2.4
Constraint check for tile[0]:
  Cores available:            8,   used:          7 .  OKAY
  Timers available:          10,   used:          8 .  OKAY
  Chanends available:        32,   used:         27 .  OKAY
  Memory available:       65536,   used:      54744 .  OKAY (0 ref bytes)
    (Stack: 7584, Code: 41118, Data: 6042)

Aquarium xTIMEcomposer 14.3.0 (Did not run)
Constraint check for tile[0]:
  Cores available:            8,   used:          7 .  OKAY
  Timers available:          10,   used:          8 .  OKAY
  Chanends available:        32,   used:         27 .  OKAY
  Memory available:       65536,   used:      52592 .  OKAY (Less but didn't run)
    (Stack: 5532, Code: 41018, Data: 6042)

Aquarium xTIMEcomposer 14.3.1 (Runs?)
Constraint check for tile[0]:
  Cores available:            8,   used:          7 .  OKAY
  Timers available:          10,   used:          8 .  OKAY
  Chanends available:        32,   used:         27 .  OKAY
  Memory available:       65536,   used:      52544 .  OKAY (-2200 bytes)
    (Stack: 5532, Code: 40970, Data: 6042)

Daily: xTIMEcomposer (14.3.2)

Released Oct 2017. 14.3.2 release note here.  Version: Version: Community_14.3.2 (build 25550, Sep-30-2017) Copyright 2015 Xmos Ltd.

xTIMEcomposer and not(?) macOS High Sierra

Update 14Nov2017: With the macOS 10.13.1 the xTIMEcomposer menus are back. But you still have to use Terminal and command line tools, like for XFLASH (recipe here). XMOS has now confirmed that there are som issues with xTIMEcomposer on High Sierra, so we’ll have to wait for an upgrade or an advisory. In light of this, the rest of this chapter may be more or perhaps less relevant.

I was using OS X El Capitan 10.11.6 and thought it time to upgrade. Having skipped macOS 10.12 Sierra (on one machine, but on another I had macOS 10.12 Sierra working fine with xTIMEcomposer) I updated to macOS High Sierra 10.13. It turned out not to be a good idea for the xTIMEcomposer part. Move one paragraph further down if you don’t need the rationale for my downgrading. If not see xCore: xTIMEcomposer, Java Runtime JRE and macOS (above).

After some days I have downgraded from High Sierra. Follow link above to see the whole rationale (in short: xTIMEcomposer doesn’t work on it, at least not after I read Apple’s info that there was a critical Java security update available (8 Update 151 build 12 and I had the older Java 8 Update 144: JRE 1.8.0_144) and I was recommended to upgrade. Then, when xTIMEcomposer failed I could not find any way to downgrade the JRE again!). I used my Time Machine backup to restore from and it was ready the morning after. Recipe here: macOS Sierra: Revert to a previous macOS version (it also goes for High Sierra or any, I presume). Now xTIMEcomposer is back on solid ground again. Until XMOS updates or gives a recipe I will not reinstall macOS 10.13 High Sierra. Maybe this is even dependent on Apple and/or Oracle? Too bad, because High Sierra is nice.

To myself: clean up also here when this is fixed.

Ticket: Building a cabled webserver on the xCORE-200 eXplorerKIT from XMOS SW not possible(?)

Since the “WARNING: .. There could be API incompatibilities” BUILDING AN00122_using_webserver_library (above) reflects something I think is not possible from XMOS supplied SW, I filed it as an internal ticket (Dec2017). Ticket number 10692.

I have just learned that there is not, and will not be, any SW from XMOS that runs a webserver on the eXplorerKIT. Fair enough. See link above.

Daily: xTIMEcomposer (14.3.3)

Released April 2018. 14.3.3 release note here. Version: Community_14.3.3 (build 22296, Apr-19-2018). Copyright 2015 Xmos Ltd.

XTAG-3 debug log hanging?

See XTAG-3 debug log hanging?

xCore: Restarting a startKIT from SW?

Watchdog etc. See Restarting a startKIT from SW? (Feb2019)

xCore: Stealing a log value from a dead task

See Stealing a log value from a dead task. xC unsafe, movable, alias pointer? (Feb2019)

Have a look at [[distributable] for sharing memory (in note 175). Other words: shared memory, global memory, global variable

xCore: Some times an XScope event is lost

See Some times an XScope event is lost (Mar2019)

xCore: select, nondeterminism and deterministic properties

See select, nondeterminism and deterministic properties. (Apr2019). I also mentioned this post in Nondeterminism chapter «xC by XMOS».

Ticket: xcc1: internal compiler error llvmgen.cpp, line 14277 UNREACHABLE

This is Issue or Product Bug #32326 internally. 3Sep2019

I see XMOS now has 14.4.0 for XVF3510, so I now hope it’s coming to me as well (startKIT and eXplorerKIT) some day soon? See Update Sep2019!

Daily: xTIMEcomposer (14.4.0)

See Update Sep2019.

Daily: xTIMEcomposer (14.4.1)

It arrived on 19Dec2019 and I only discovered on 10Jan2020! Release note (here). Search for «14.4.1» in this note, too.. 28Jan20: downloaded and found an issue with the XFLASH running in Terminal (it has to) and the xCORE-200 explorer board. I think it has now been fixed through Ticket #32462 raised by me and XMOS.

10Jan2020: There is a Design Advisory – Running xTIMEcomposer on MacOS Catalina, here. Catalina is MacOS 10.15 (Oct2019)

Ticket: XFLASH 14.4.1 of xCORE-200 Explorer board fails, but not generally

This is product bug #32462 of 27Jan2020:

I am not able to run XFLASH from 14.4.1 of my xCore-200 explorer board. I get this message during XFLASH:

... s2l-n0-973c03aa:2907:3: error: use of undeclared identifer `quad_spi_qe_location_status_reg_0' quad_spi_qe_location_status_reg_0, ^ s2l-n0-973c03aa:2908:3: error: use of undeclared identifer `quad_spi_qe_bit_6' quad_spi_qe_bit_6 ^ 
Error: F03010 Failed to compile second stage bootloader bash-3.2$

This solved my problem:

Please edit this file
_Aquarium_rfm69_client/xCORE-200-EXPLORER.xn
…and make the following 2 modifications:
<Attribute Name=»QE_REGISTER» Value=»quad_spiflash_qe_location_status_reg_0″>
<Attribute Name=»QE_BIT» Value=» quad_spiflash_qe_bit_6″>

Ticket: XFLASH 14.4.1 of xCORE-200 Explorer board warnings

This is product bug(?) 32488 of 22Feb2020
Ref Ticket 32462 of 27Jan2020. This is not equal since it in fact works:

mymachine:~ teig$ /Applications/XMOS_xTIMEcomposer_Community_14.4.1/SetEnv.command 
bash-3.2$ xflash /Users/teig/workspace/_kode24_xcore200_1q2020/bin/_kode24_xcore200_1q2020.xe 
Warning: F03098 Factory image and boot loader cannot be write-protected on flash device on node 0
xflash: Warning: F03148 --quad-spi-clock not given, using default 15.62MHz
xflash: Warning: F03149 QE_REGISTER and/or QE_BIT locations not found in XN file for this flash device. Using default flash_qe_location_status_reg_0 and flash_qe_bit_6.
Warning: F03150 The use of libquadflash will be deprecated from XFLASH in xTIMEcomposer 15.0.0.
Please add the PageSize, SectorSize and NumPages attributes to your External Device definitions in your target XN file to enable the use of lib_flash.
Site 0 has finished successfully.        
bash-3.2$ 

• I XFLASH xCORE-200 eXplorer 1702-00101
• (Ticket 32462 had xCORE-200 eXplorer 1702-00015)
• To me this looks like messages to the developers or a more experienced xTIMEcomposer person than me. Is there anything I can do?
• The fix may be to make a new xCORE-200 explorer kit project and just copy the .xn file from it, over to the offending project. This did not help for me, so I had to live with the fixed .xn file from  the warnings above #32462 case

Update 31May2023. Since I still use xTIMEcomposer 14.4.1 and now am going back to the XCORE-200-EXPLORER boards (instead of MIC_ARRAY), here is the part of the XCORE-200-EXPLORER.xn file that needs fixing to avoid the extra and not necessary F03150 warning. It should look something like this:

<Device NodeId="0" Tile="0" Class="SQIFlash" Name="bootFlash" Type="S25LQ016B" PageSize="256" SectorSize="4096" NumPages="8192">
<Attribute Name="PORT_SQI_CS" Value="PORT_SQI_CS"/>
<Attribute Name="PORT_SQI_SCLK" Value="PORT_SQI_SCLK"/>
<Attribute Name="PORT_SQI_SIO" Value="PORT_SQI_SIO"/>
<Attribute Name="QE_REGISTER" Value="flash_qe_location_status_reg_0"/>
<Attribute Name="QE_BIT" Value="flash_qe_bit_6"/>
</Device>

xCore: Cloud 200W+ machines with little multi-threading. Help!

10Mar2020: https://www.xcore.com/viewtopic.php?f=18&t=7863

xCore: Is it possible to detect use of «unsafe» by inspecting the object code?

6Apr2020: Is it possible to detect use of «unsafe» by inspecting the object code?

xCore: XMOS FreeRTOS port documentation? Plus some questions

8Apr2020: XMOS FreeRTOS port documentation? Plus some questions

Xcore: Missing xCORE XA Module Board Hardware Manual circuit diagram

19May2020: Missing xCORE XA Module Board Hardware Manual circuit diagram

Xcore: AN00141 «xrun: Invalid executable file passed» for xCORE-XA Core Module

26May2020: AN00141 «xrun: Invalid executable file passed» for xCORE-XA Core Module

Ticket: xcc1: «internal compiler error»

Ticket number 81758.  xTIMEcomposer 14.4.1. Submitted by me 24Nov2020.

xCore: «xTIMEcomposer Big Sur macOS 11»

See xTIMEcomposer Big Sur macOS 11 (started by Redye 13Nov2020). Comment by me 7Dec2020.

xCore: «Collecting interfaces into an array for a parameter»

See Collecting interfaces into an array for a parameter (22Dec2020)

Ticket: Multi-tile combinable fails by hanging

Ticket number 83449. xTIMEcomposer 14.4.1. Submitted by med 30Dec2020

XMOS came back to me on this one. See 141:[Combinable all the way to no progress]

xCore: «Replicated select case index not in range of input array»

See Replicated select case index not in range of input array (30Dec2020)

Also see 165:[Replicated select case index not in range of input array].

Ticket: «Loacl (sic) variable not initialised (correctly)»

Ticket number 84030. 19Jan2021

Ticket: «xcc1: problem recovering from program error, further error messages may be suppressed»

Ticket number 86499. 2Feb2021

xCore: «xCORE Microphone Array board questions»

See xCORE Microphone Array board questions (8Feb2021)

Ticket: «Parameters of interface call ok’ed when different types on client and server sides»

Ticket number 88288. 12Feb2021

xCore: «[[notification]] and [[clears_notification]] only for single client usage?»

See [[notification]] and [[clears_notification]] only for single client usage?. 3Mar2021

xCore: «Is it possible to get a race condition in clean xC on xCore?»

See Is it possible to get a race condition in clean xC on xCore? 14Mar2021

Ticket: «Runs, compiler crash in «line 183″, runtime crash and no progess for different par configs»

Ticket number 159780. 7Apr2021

Ticket: «Compiler crash in jenkins file types.cpp, line 2303»

Ticket number 159996. 13Apr2021

xCore: «xCORE Microphone Array .xn file and xflash»

See xCORE Microphone Array .xn file and xflash. 14Apr2021 and My Beep-BRRR notes.

Daily: xTIMEcomposer 15.0.0

24Feb2020. I don’t know when or if it arrives. But have a look in the red log line above: 15.0.0. In the view of xcore.ai not mentioning xC with a single word, it is nice to see it mentioned!

References

Wiki-refs: Eclipse, IDE, I²C, Nucleus RTOS, xC,

1. adafruit monochrome 128×32 I2C OLED graphic display PRODUCT ID: 931, see http://www.adafruit.com/products/931
2. XS1 Ports: use and specification, see https://www.xmos.com/zh/download/public/XS1-Ports-Specification(X1373A).pdf
3. Introduction to XS1 ports, see https://www.xmos.com/download/public/Introduction-to-XS1-ports%28X2738B%29.pdf
4. The XMOS XS1 Architecture by David May. Copyright © 2009 by XMOS Limited. ISBN: 978-1-907361-01-2 (PBK), ISBN: 978-1-907361-04-3 Published by XMOS Limited, see https://www.xmos.com/download/public/The-XMOS-XS1-Architecture%281.0%29.pdf
5. xC Reference Manual, 2008/07/16, by Douglas WATT Richard OSBORNE David MAY (VERSION 8.7), see https://www.xmos.com/download/public/xC-Reference-Manual(8.7-[Y-M]).pdf. Old, can’t even find reserved words «server» or «client» there
6. XMOS Programming Guide (version E, Oct 09, 2014), see https://www.xmos.com/support/xkits?subcategory=Starter%20Kits&product=17441&component=17653&version=latest
7. xC Specification, see http://www.xmos.com/xc-specification. Old, can’t even find reserved words «server» or «client» there
8. Infineon Aurix processor: http://en.wikipedia.org/wiki/Infineon_AURIX
9. Symtavision: https://www.symtavision.com/
10. element14 community blog note by «shabaz»,
    – XMOS startKIT: Introduction, Terminology/Architecture, Getting Started and Example Programs, see http://www.element14.com/community/groups/internet-of-things/blog/2014/05/05/xmos-startkit-introduction-terminologyarchitecture-getting-started-and-example-programs. It also has two sub-pages:
    – XMOS startKIT: Building an XMOS and Raspberry Pi Robot XMP-1 (with SPI) and
    – XMOS startKIT: XMOS and Raspberry Pi Oscilloscope XAE 1000 (with the ADC)
11. PROCESS-ORIENTED PATTERNS FOR CONCURRENT SOFTWARE ENGINEERING. A THESIS SUBMITTED TO THE UNIVERSITY OF KENT IN THE SUBJECT OF COMPUTER SCIENCE FOR THE DEGREE OF DOCTOR OF PHILOSOPHY.By Adam T. Sampson (2008). See https://www.cs.kent.ac.uk/pubs/2008/3059/
12. XMOS secures $19M funding to accelerate growth in Design & Reuse (30Sept2019), see https://www.design-reuse.com/news/46848/xmos-funding.html (and several other places, like after some hours on XMOS’ own site when it came up. Same text I think)
13. Artificial Intelligence of Things (AIoT) by Mark Lippett (CEO of XMOS), eeNews Europe 21Oct2019, see https://www.eenewseurope.com/news/making-artificial-intelligence-things-reality
14. Enabling intelligent unmanned vehicles through XMOS Technology by Goncalo Martins, Allistair Moses, Matthew Rutherford and Kimon Valavanis, in JDMS – The Journal of Defense Modeling and Simulation (2011/01/19), see https://www.researchgate.net/publication/232957363_Enabling_intelligent_unmanned_vehicles_through_XMOS_Technology/. This paper discusses occam. However, they don’t seem to know about the virtual channel router from University of Southampton (Towards a distributed implementation of occam by Mark Debbage, Mark Hill and Dennis Nicole, in Real-time Systems with Transputers OUG-13 IOS Press (1990). I loved it for years at work.). But the paper in detail shows the potential of XMOS and xC, even though I think it’s written before concepts like interface, [[combinable]] and [[distributable]]. I have not mentioned this [14] paper in this blog note other than just here. Also see xC is C plus x [15]
15. XMOS adapts Xcore into AIoT ‘crossover’ processor by Sally Ward-Foxton, EETimes (10Feb2020), see https://www.eetimes.com/xmos-adapts-xcore-into-aiot-crossover-processor/. I found this on xcore.ai
16. tinyML Talks Webcast: «Low-cost neural network inferencing on the edge with xcore.ai» by Laszlo Kindrat – XMOS, see https://www.youtube.com/watch?v=ljJTLuNV38Y (28May2020) («XS3» at 28:56)
17. XMOS announces all-new software development kit for the artificial intelligence of things, Oct2020, see https://www.xmos.ai/xmos-announces-all-new-software-development-kit-for-the-artificial-intelligence-of-things/.