Compilation of w600 port IV

[rkompass]

Checks

• I agree to follow the MicroPython Code of Conduct to ensure a safe and respectful space for everyone.

• I've searched for existing issues regarding this feature, and didn't find any.

Description

We continue here the discussions
Compilation of w600 port and
Compilation of w600 port II - II (all closed now)
of development/debugging the w60x port in MP branch w60x.

Code Size

No response

Implementation

• I intend to implement this feature and would submit a Pull Request if desirable.
• I hope the MicroPython maintainers or community will implement this feature.
• I would like to Sponsor development of this feature.

[rkompass]

I don't know whether you are interested to take this up:
I found my modified machine/machine_spi.c from last year. It was about 80% complete iirc.
The intent was to remove (with compiler flag) the option to use the (from datsheet)

6.2 High speed SPI device controller
Compatible with the universal SPI physical layer protocol, the host supports high-speed
access to the device through a data format that interacts with the host. The maximum
supported operating frequency is 50Mbps.
-Compatible with the general SPI protocol;
-Selectable level interrupt signal；
-Supports up to 50Mbps rate;
-Simple frame format, full hardware resolution and DMA

and restrict to

6.13 Master/slave SPI controller
Synchronous SPI master-slave function is supported. Its working clock is the system internal
bus clock. Its characteristics are as follows:

• The transmit and receive paths each have a FIFO of 8 words deep;
• Master supports 4 formats of Motorola SPI (CPOL, CPHA), TI timing, macrowire timing;
• The slave supports four formats of the Motorola SPI (CPOL, CPHA);
• Support full duplex and half duplex;
• The master device supports bit transmission and supports up to 65535bit transmission.
• The slave device supports transmission modes of various length bytes;
• The maximum clock frequency of the slave device input SPI_Clk is 1/6 of the system clock;

to free the relevant (now permanently occupied) RAM area.
I can collect all the relevant information if you are interested in working on this (collaborating, of course).
Although I have to admit I'm not really familiar with that any longer now.
I got distracted by the possiblity to use the websocket then and for that started to study Javascript and so on...

machine_spi.zip

[robert-hh]

Sorry for the tardy reply. I just noticed that message. Yes, you had asked that before. Sine slave mode is not used by any other port, and HSPI seems to be used only for slave mode, it could be dropped. Looking into the SDK, there seems no options for HSPI master mode.

Note that the file which you attached seems to be an old version. The actual machine_spi.c is way smaller after removing some code duplication.

[robert-hh]

Scanning through the source files of the WM_SDK and the port, it seems that the HSPI/SDIO is using 8k of RAM. The note in wm_hspi.h which talks of 26k seems wrong. The addresses mentioned there are wrong as well. At the moment we have:

20037fff: Top of Python heap
20038000: 8 k DMA data structures (not sure if these are needed)
2003A000: 8 k for HSPI and SDIO
2003C000: WiFi buffers.

[rkompass]

Yes. These are in SDK/Include/wm_ram_config.h :

#define MASTER_SPI_DMA_ADDR     0x20038000UL  /*Master SPI use buffer when spi use dma transfer mode*/
#define SLAVE_HSPI_SDIO_ADDR    0x2003A000UL  /*High speed SPI or SDIO buffer to exchange data*/
#define WIFI_MEM_START_ADDR     0x2003C000UL  /*Wi-Fi use buffer to exchange data*/

So the 8k of HSPI can be saved and hopefully also the 8k DMA.

I will now re-read our old conversation about RAM and perhaps re-post here.

[rkompass]

The rest is about the FreeRTOS tasks which you had optimized afterwards. Then we had the firmware update change.

[rkompass]

I try to understand my changes to machine_spi.c:

1. I introduced a new preprocessor switch, aiming at the ability to the abolish hspi option from the start.

#if MICROPY_HSPI_SLAVE
#include "wm_hspi.h"
#endif

if it is 0 then all aof wm_hspi.h is not included.

2. I put the info about spi type in the switch

#if MICROPY_HSPI_SLAVE
    uint8_t spi_type;/* 0-lspi, 1-hspi */
#endif

and later switched out all the code for the hspi.

[rkompass]

The section

       if (-1 == self->bits) {
            tls_spi_trans_type(SPI_DMA_TRANSFER);
        } else {
            if (8 == self->bits) {
                tls_spi_trans_type(SPI_BYTE_TRANSFER);
            } else if (32 == self->bits) {
                tls_spi_trans_type(SPI_WORD_TRANSFER);
            } else {
                tls_spi_trans_type(SPI_DMA_TRANSFER);
            }
        }

of machine_spi_init() alone determines whether DMA is used.
I self->bits , which defaults to DEFAULT_SPI_BITS, which is 8, is 8 or 32 then no DMA is used.
Can we exclude that the bits setting -1 or any other is used?

[robert-hh]

Can we exclude that the bits setting -1 or any other is used?

No, we cannot exclude that. And we cannot exclude that people use the slave mode. Maybe the buffers could be dynamically allocated, or the reserved space could be reduced.

[rkompass]

Scanning through the source files of the WM_SDK and the port, it seems that the HSPI/SDIO is using 8k of RAM. The note in wm_hspi.h which talks of 26k seems wrong. The addresses mentioned there are wrong as well.

That might indicate that the HSPI/SDIO functionality is never used, because, if it were, it would be in conflict with the others.
So a simple fist approach might be to remove the 8k Buffer for that and then test SPI and memory.
I can try to rework the new machine_spi.c in the same spirit like the old one.
That would ensure that HSPI/SDIO functionality is not used.

What would one use for testing SPI reliably? Does an SDcard attached externally using sdcard.py suffice for that?

At present we have (in wm_hostspi.h):
#define SPI_DMA_BUF_MAX_SIZE 8160
#define SPI_DMA_MAX_TRANS_SIZE 4092

which also could/should be reduced, of course.
I wonder if not the first should be the double of the second at least.

Also there is #define SPI_USE_DMA in wm_hostspi.h
and quite some code in wm_hostspi.c is made dependent on that.
We might try to compile setting that to 0 and testing SPI afterwards.

I thing this whole thing makes sense thinking of a later w800 compile, which should be quite identical. As all register definitions are the same and the SDK is literally a copy of the w600. With another processor and the addition of Bluetooth.

[rkompass]

I'm testing now SPI for SD card and for that read the MP Micropython user guide.

There to my surprise I found:

There are some components in WM_SDK which is useless for MicroPython. These components can be cut off
before compiling to reduce this code size. Users can open the WM_SDK/Include/wm_config.h and modify the
macro of such useless component from “CFG_ON” to “CFG_OFF”.
The suggested useless components are:

#define TLS_CONFIG_HS_SPI CFG_OFF
#define TLS_CONFIG_HOSTIF CFG_OFF
#define TLS_CONFIG_RMMS CFG_OFF
#define TLS_CONFIG_HTTP_CLIENT CFG_OFF
#define TLS_CONFIG_NTP CFG_OFF

On your MD page describing this port you only mention the latter 4 components.
Was there a reason why you did not recommend
#define TLS_CONFIG_HS_SPI CFG_OFF ?
This is exactly what we need now.
in the SDK it is still
#define TLS_CONFIG_HS_SPI CFG_ON /*High Speed SPI*/

[rkompass]

I tested the SPI with a 4GB SDCard. Using mendenms new driver and test.
Had to compile FatFS in for that.

Driver and test files are here:
sdcard_mendem.zip

Hardware SPI at 20MHz seems to work well.

The test yielded:

------- results with spi baudrate=2_000_000 -----------

Filesystem check
[]

Multiple block read/write
5400 bytes written
11 bytes written
5405411 bytes written at  0.1058971 MB/s
final file size 5405411 expected 5405411 read 5405411 rate= 0.1465636

Single block read/write
11 bytes written
11 bytes read

Verifying data read back
Small file Pass
Big read Pass

Tests passed

------- results with spi baudrate=20_000_000 -----------

Filesystem check
['rats.txt', 'rats1.txt']

Multiple block read/write
5400 bytes written
11 bytes written
5405411 bytes written at  0.1840578 MB/s
final file size 5405411 expected 5405411 read 5405411 rate= 0.3213871

Single block read/write
11 bytes written
11 bytes read

Verifying data read back
Small file Pass
Big read Pass

Tests passed

Change to the higher SPI speed really yielded faster data transfer. For comparison mendenm reported

Speed is still slow, but for a lot of data-logging stuff, maybe OK. At 120 MHz CPU, 40 MHz SPI on my Pi Pico, I get about 600kB/s write speed, and just over 1000 KB/s read speed. Much of this may due to small block sizes and poor buffer handling.

Given we have only 80MHz CPU and 20MHz SPI our values are quite o.k..

Now testing changes of SPI can begin.

[robert-hh]

The file README.md is a mix of the initial version by Winner and my additions, which start in the section "Building the firmware". I do not think that alone setting #define TLS_CONFIG_HS_SPI CFG_OFF will help, since the MicroPython API is still there, referring to HS_SPI functions.

Thank you for testing with the SD card. I had tried an SD card earlier and an external SPI chip as well and found both working. I made no speed test, but speed may not something to be expected with the W60x.

[rkompass]

Good morning Robert,

I made changes to machine_spi.c similar to the changes in the last version of that file and compiled.
==> spi did not work (at least) not with my SDCard.
Then I re-set #define TLS_CONFIG_HS_SPI to CFG_ON again, and now spi works (with my changes).
The new machine_spi.c is here:
machine_spi.zip

So if you like to try that out...
I think we can afterwards abolish the HSPI 8k buffer.
But it would be good to understand why the #define TLS_CONFIG_HS_SPI unsetting did not work.
The internals are not so clearly separated as they should, it seems.#
Do you have an idea?

[rkompass]

I do not think that alone setting #define TLS_CONFIG_HS_SPI CFG_OFF will help, since the MicroPython API is still there, referring to HS_SPI functions.

Confirmed that as it did not compile afterwards. Compiler errors lead me to apply the same changes I had done half a year ago. Now there is the #define MICROPY_HSPI_SLAVE introduced, but I leave that to you to find the right place for it (in the Makefile?).