SPI methods are inconsistent with Arduino AVR SPI

[Makuna]

Basic Infos

APIs across platforms should try to be consistent so that library writers don't have to pepper their code with ifdefs and custom calls for standard uses.
The Esp8266 SPI has method names for functions that are inconsistent with AVR SPI but are functionally the same.

on AVR
void transfer(void *buf, size_t count)
is the same as on Esp8266
void writeBytes(uint8_t * data, uint32_t size);

[mkeyno]

sorry to be picky but what's big problem with that ? writeBytes much faster than normal transfer function

#2624

[Makuna]

The standard Arduino SPI library does not have a writeBytes, it does have a transfer that takes a byte pointer and count of bytes. The Esp8266 SPI library does not expose this transfer and further adds its own writeBytes. This is inconsistent and makes writing Arduino code across platforms harder.

I am not saying there is a need to remove writeBytes; but at least expose the standard of a transfer that takes a buffer and count of bytes.

[selste]

According to the writeBytes method comment the data has to be aligned to 32 bits - so it differs significantly from the transfer method that ships with the Arduino.
Would be great if the implementations would provide the same functionality.

[PaulStoffregen]

My improved performance Ethernet library doesn't compile on ESP8266, only because SPI.transfer(data, size) is missing.

Here's a quick implementation I added in SPI.h for testing. Maybe something like this could be merged, so Arduino sketches and libraries using this well established Arduino API can compile and run on ESP8266?

void transfer(uint8_t * data, uint32_t size) {
    uint8_t buf[40];
    while (size > sizeof(buf)) {
        memcpy(buf, data, sizeof(buf));
        transferBytes(buf, data, sizeof(buf));
        data += sizeof(buf);
        size -= sizeof(buf);
    }
    if (size) {
        memcpy(buf, data, size);
        transferBytes(buf, data, size);
    }
}

[d-a-v]

The above comments are right, writeBytes() does the job without copy, using 32 bits registers, but require 32bits aligned buffers.
We can arrange something for the non aligned bytes and use this function.
Could SPI.transfer() take a const uint8_t* ?

off-topic:
There is a work in progress to use the ethernet-only part of the W5100 or an enc28j60 (ethernet only) to use with lwIP that we luckily have on the esp. That would allow ethernet to integrate better with the network part of this core like for #4914.
Any pointer to an improved SPI driver for the W5100 would be welcome.

[PaulStoffregen]

Could SPI.transfer() take a const uint8_t* ?

No, not if you want to be compatible with Arduino programs. According to Arduino's documentation "In case of buffer transfers the received data is stored in the buffer in-place (the old data is replaced with the data received)."

https://www.arduino.cc/en/Reference/SPITransfer

The reason to implement SPI.transfer(buffer, size) is for compatibility with Arduino programs.

[d-a-v]

Yes I was just realizing that. The esp8266/arduino devs did things right.
We can probably find something that does not involve memcpy().

[d-a-v]

@PaulStoffregen
Could you by chance test this arduino compatible spi transfer function
It uses the 32bits-aligned and 32bits registers optimized esp's transferBytes().
#4925

[PaulStoffregen]

Tried it just now. Seems to work fine, at least testing with my Ethernet lib.

However, the performance is not as good as the memcpy-based code. But they're similar. With the memcpy version, I get 609.6 kbytes/sec overall speed fetching a web page from a fast Linux server on the same LAN, using a W5500 (Adafruit's Featherwing Ethernet). With this optimized version I get 582.9 kbytes/sec. I ran each a few times. The speeds are very consistent.

FWIW, ESP32's speed is 964.0 kbytes/sec on this test, using this in ESP32's SPI.h:

  void transfer(uint8_t * data, uint32_t size) { transferBytes(data, data, size); }

Unfortunately this doesn't work on ESP8266. Seems using the same pointer for read and write isn't allowed?

[PaulStoffregen]

Here's the exact code I tested in SPI.cpp.

#if 1
void SPIClass::transfer(void *buf, uint16_t count) {
    uint8_t *cbuf = reinterpret_cast<uint8_t*>(buf);
    for (; ((long)cbuf) & 3; cbuf++, count--)
        *cbuf = transfer(*cbuf);
    uint16_t count4 = count & ~3;
    transferBytes(cbuf, cbuf, count4);
    cbuf += count4;
    count -= count4;
    for (; count; cbuf++, count--)
        *cbuf = transfer(*cbuf);
}
#else
void SPIClass::transfer(void * ptr, uint16_t size) {
        uint8_t *data = (uint8_t *)ptr;
        uint8_t buf[40];
        while (size > sizeof(buf)) {
                memcpy(buf, data, sizeof(buf));
                transferBytes(buf, data, sizeof(buf));
                data += sizeof(buf);
                size -= sizeof(buf);
        }
        if (size) {
                memcpy(buf, data, size);
                transferBytes(buf, data, size);
        }
}
#endif