Any commen term for combinable and distributable?

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

XMOS libs: synchronous/blocking when [[distributable]] and asynchronous when [[combinable]]

I have seen that in two of the XMOS XC libraries that I use they coin a [[distributable]] task as “synchronous” and they coin a [[combinable]] task as “asynchronous”. That’s for the libraries [lib_i2c] [1] and [lib_spi] [2]. You should read the descriptions in those documents, as they quite successfully describe the difference between distributed and combined tasks. Thus the sentence in both of the descriptions that “The synchronous API provides blocking operation” would be a quite correct use of that word. Even if “blocking” has some negative connotations, but there XMOS would simply mean to say that this is the option that is blocking: “The synchronous API will block your application until the bus operation is complete. In cases where the application cannot afford to wait for this long the asynchronous API can be used“. (See the problem with the blocking word discussed in [3])

It is easy to understand that since a distributable task’s cycles run on the calling task’s logical core, that this is considered synchronous. And that the “messages” (interface calls) that set off another task to do its job on its own is considered asynchronous, even if the interface calls themselves are as synchronous as can be. Here are the code in the two libraries and how the XMOS naming convention seems to be (nothing special for distributable/synchronous but with an _async postfix for the combinable/asynchronous. (But did they forget about i2c_slave_async?)

Code: Select all

[[distributable]] void i2c_master_single_port (..)
[[distributable]] void i2c_master (..)
[[combinable]]    void i2c_master_async_comb (..)
[[combinable]]    void i2c_slave (..)

[[distributable]] void spi_master (..)
[[combinable]]    void spi_master_async (..)
(This reply also a chapter in [4]. Disclaimer about [3] and [4] blog notes; no money, payment, gifts, ads. Just fun and expenses)

[1] https://www.xmos.com/support/libraries/lib_i2c
[2] https://www.xmos.com/support/libraries/lib_spi
[3] http://www.teigfam.net/oyvind/home/tech ... after-all/
[4] http://www.teigfam.net/oyvind/home/tech ... combinable


--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
akp
XCore Expert
Posts: 578
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

No, they did not forget about i2c_slave_async. A synchronous I2C slave would be of very limited usefulness, so it's pretty much got to be asynchronous.
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

Good point. But even then it should perhaps have been named i2c_slave_async?

The reason you say that a synchronous i2c_slave has limited usefulness is perhaps the same as saying it's probably not even a good idea? Being an I2C slave by polling is perhaps not so smart, you don't typically poll to see if you're addressed? And polling by being distributable would effectively move the poller one task level up? This may be seen in the code by the fact that waiting in a select for a port (for a pinseq) is not done when sync/distributable, only in the async/combinable tasks.

By the way, I also see that lib_i2c even has these:

Code: Select all

void i2c_master_async (..)      // that is a general task        (so _async does not explicitly mean combinable)
void i2c_master_async_comb (..) // that is [[combinable]] (but no _comb is most often also combinable)
Naming conventions is perhaps one of the hardest things we programmers do, I tend to think.
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
Post Reply