xmos / fwk_io Goto Github PK

This driver enables high priority and fast mode via the status register, on the core that it ends up executing on. It may be desired by the application that the same core that performed a spi transaction have either of these set.

SPI

QSPI

Desired behavior should have the driver store the starting state of the status register, and restore it.

The QSPI HIL module has no unit tests.

The example application could include a S/PDIF receiver using the app PLL to recover MCLK.

With inferencing removed from fwk_core, the full tests are able to run again. It appears that a few of the spi slave tests are now failing.

https://github.com/xmos/fwk_io/actions/runs/3969643737/jobs/6804413032

XMOS has a source code library, lib_sw_pll, that provides a software phased locked loop capability for tracking a clock. It is particularly useful for adaptive clocking of certain streaming interfaces such as I2S and USB. This source code library is currently internal to XMOS, but could be made public. Should lib_sw_pll become a part of the IO framework?

I2S config for slave is not initialised on creation. Therefore if the user does not set a field in the config it will have a random value and will lead to unpredictable behaviour.

https://github.com/xmos/fwk_io/blob/develop/modules/i2s/src/i2s_slave.c#L67

Suggested solution: initialise the config struct with sensible defaults

See https://xmosjira.atlassian.net/wiki/spaces/SDK/pages/3839328262/TDM16+Slave+Tx+lockup+bug for details.

There may be timing issues on the GPIO however the component should never lock up - only slip. This is a critical bug that needs fixing.

16 channel mic array to TDM16 slave Tx using new libs

Dependent on:
xmos/lib_mic_array#194
and
#72

Setting this bit guarantees performance of the current thread to f/5 minimum. However it also reduces the performance in other non-priority HW threads. Setting more than 4 can also be very strange. It is safer to do it dynamically than before a while(1) but you are just reducing the probability of MIPS robbing rather than preventing it. You could in some cases severely starve other threads resulting in unpredictable behaviour. Eg. 3 priority HW threads being active would reduce others to ~48MIPS temporarily.

The attached slide shows this. I recommend using an f/8 design philosophy is possible as this means all other HW threads will get a guaranteed minimum of f/8. This means no use of XS1_SR_QUEUE_MASK anywhere.

xs2-training.pdf.pdf

Extend 16 channel Tx with 16 channel Rx.

See: https://xmosjira.atlassian.net/wiki/spaces/SDK/pages/3811835928/Development+Notes

This was found when using FTDI to test. It was not seen during loopback where we achieve almost 1.5Mbps. I strongly suspect that the turnaround time between sampling the last stop bit and waiting for the falling edge of the next start bit is the issue since we can receive a 1.5Mbps byte with stop->start gaps.

See https://xmosjira.atlassian.net/wiki/spaces/~870418189/pages/3572039681/RTOS+UART+interoperability+HW+test for evidence

At the moment, the HIL tests are using a version of Pyxsim located in a personal fork
The upstream develop branch of test_support has now had these changes merged, and the HIL tests in this repo need slight refactoring to make compatible. Then, the version of test_support submoduled needs to be changed to the xmos/test_support:develop branch.

Expand testing to include jitter tolerance and loopback

Follows on from #7 and xmos/fwk_rtos#15 and allows early drop of basic HIL + RTOS driver

See xmos/xcore_iot#501

To reproduce on a Linux host, no hardware required:

1. Clone the head of the develop branch of fwk_io and initialise the submodules
2. Setup Python virtual environment and install requirements.txt
3. In fwk_io/test run pytest lib_i2c -n auto

Outcome: all tests that are run will fail with AttributeError: module 'Pyxsim.testers' has no attribute 'PytestComparisonTester'

The test_support submodule is version 2d6a6b9 (current head of develop) and searching through that repo there is no PytestComparisonTester method. Changing all instances of PytestComparisonTester to ComparisonTester results in the tests running successfully.

But the github actions job on the head of develop has not failed - I manually triggered a new job to make sure, and the tests all passed. I don't know enough about docker containers to understand what the contents really are. The github actions job launches the tests using the following command-line:

docker run --rm -w /fwk_io/test -v ${{github.workspace}}:/fwk_io ${FWK_IO_TESTER_IMAGE} bash -l run_tests.sh lib_i2c

I believe this is mounting the github workspace (which has checked out the head of develop of fwk_io with commit 2d6a6b9 for the test_support submodule) inside the docker container at the path /fwk_io, and then running the test script from the working directory /fwk_io/test - which should be the expected code that you want to run for the CI job. So how does that pass when a manual run outside of docker fails?

So there are (at least) two questions:

1. What version of the test_support submodule is actually in the docker container, allowing the tests to run?
2. If the version of the test_support submodule is not the expected one, then do we know that the version of fwk_io is correct inside the docker container? What if there is some old version of fwk_io and test_support already in the docker container and these are being tested, rather than the latest head of develop?

Thank you for submitting an SDK feature request. Please provide as much information you can.

Describe the feature
Currently, I2S communication occurs only over 1b ports. Some processors have a limited number of 1b ports, so a desire exists to enhance I2S to allow the use of 4b ports.

Will this change any current APIs? How?
The I2S API will change. (@ACascarino to supply details)

Who will benefit with this feature?
Any customer or XMOS engineer writing software for a package with a limited number of 1b ports.

Any Other info
This enhancement has been made to lib_i2s. See lib_i2s issue 98 and pull request 107 for details.

We potentially have a request to be able to instantiate UART Rx devices dynamically. Today we have rtos_uart_rx_init() and rtos_uart_rx_start() methods but no rtos_uart_rx_stop() and rtos_uart_rx_deinit().

Currently rtos_uart_rx_init spins off the xcore thread uart_rx_hil_thread and rtos_uart_rx_start enables the ISR and FreeRTOS uart_rx_app_thread. It should be possible to carefully release resources / undo ISR setup and then vTaskDelete both tasks.

The HIL thread underneath already has a uart_rx_deinit() method

Talking to @xmos-jmccarthy would be a good idea as there are likely gotchas in this approach.

small one, Just been using i2s from this library. Found the documentation for i2s_restart_t unclear

I assumed NO_RESTART meant it wouldn't send more samples, the opposite of starting is stopping. If the comment made it clear that this was the choice if you want to continue sending samples then I think I wouldn't have got stuck (I did read the comments)

System information

• OS: Windows
• XCore board XK-VOICE-L71
• SDK version tag or commit SHA 03955f0

Describe the current behavior
Observing SCL on a scope, the SCL cycle time seems to be around 2.8us (~350kHz) not 2.5us.

Describe the expected behavior
The I2C interface operates correctly but at slightly lower than maximum speed.

Standalone code to reproduce the issue
This is observed whilst running the example code in lib_ssds1306: https://github.com/xmos/lib_ssd1306/tree/develop/example/xcore
SCL can be observed on the Pi header

Interrupt handler versions of XUD_GetData(), XUD_GetSetupData(), and XUD_SetData() exist in lib_xud already as XUD_GetData_Select() and XUD_SetData_Select(), and their counterparts XUD_SetReady_Out() and XUD_SetReady_In(). However, the prototypes for these are only available for XC (surrounded by #if defined(XC)), and there is no equivalent for XUD_GetSetupData().

As a temporary workaround, these were copied into the SDK and modified. Ideally lib_xud will be updated to be fully compatible with standard C.

Waiting on xmos/lib_xud#128

The I2C docs contain a URL to a document that is no longer publicly available: https://www.nxp.com/docs/en/user-guide/UM10204.pdf

See https://www.i2c-bus.org/specification/ for information on how to address this issue.

It is not safe to call qspi_flash_xxxxx functions from multiple bare-metal threads. This enhancement request is to add a bare-metal middleware utility that wraps qspi_flash_xxxxx functions with a hardware and/or software lock.

See: https://xmosjira.atlassian.net/wiki/spaces/SDK/pages/3811835928/Development+Notes

The initial TDM implementation will be:

16 ch TX only
48 kHz audio
32b word size
I2S TDM slave
BCLK is assumed to be integer multiple of our PDM MCLK
BCLK is external
BCLK sampling rising or falling edge TBD
FSYNC offset / data alignment TBD (@andrew Cavanaugh getting answer)
FSYNC Length (we only care about edge but TBD just to know).
Target example app with 1 tile 16 mic → 16ch TDM output

See: https://xmosjira.atlassian.net/wiki/spaces/SDK/pages/3811835928/Development+Notes

https://github.com/xmos/fwk_io/blob/develop/modules/i2s/api/i2s.h#L116

To keep the compiler happy, we are making a copy. Typically a few bytes and a few cycles but worth changing in a future update.

The use case is where we do far-end DSP in a voice product which requires modifying of the received samples before sending to the application.

Currently each UART instance requires a single xcore thread per Rx (Tx is handled inline, although could be offloaded to a thread). To support multiple Rxs in a single xcore thread (and possibly even a buffered Tx) we would need a manually developed select based UART (similar to XC's combinable feature). It may also be possible using this technique to turn the Tx into a buffered version sharing the Rx xcore thread which would allow it to behave like a typical UART HW peripheral.

See: https://github.com/xmos/lib_xud/releases/tag/v2.2.3