Update hspi_slave.c

[GuaAck]

I found that SPI communication did not work due te a wrong timing of the MISO signal with respect to SCK. With slower processores like Arduino UNO (and a small delay of sck due to th level converter) it works, but with a faster Arduino DUE (without converter) it did not. Together with Jiri Bilek I found that MISODM_S has to be set. In the documentation for the ESP32 (should have a very similar SPI interface) I found that also MOSIDN_S should be set in SPI1C2. The MISO timing is correct, I tested it for a clock of 4 MHZ and 320 kHz. With experiments I found that also the timing of MOSI is robust. Neither a delay of 70 ns in SCK nor in MOSI did disturb the communication. Some oscillograms are here: http://homepage.o2mail.de/g.ackermann/ESP8266.htm

Jiri Bilek added the ICACHE_RAM_ATTR to the function hspi_slave_setStatus() because this function may be indirect called from an interrupt handler.

[JiriBilek]

Adding a picture from a logic analyzer. In the first picture you can see the MISO signal changes on rising edges. This is bad because sampling is done in the very moment.

[devyte]

@GuaAck @JiriBilek thank you for this, timing issues are difficult to find and resolve.
I think none of the currently active developers have the hw to test/verify this, so confirmation from others is needed. In the meantime, I have a few minor remarks, I'll explain inline with the code.

[devyte]

You provided an explanation for why this function should have the decorator. I suggest replacing the comment with that.
Also, I suggest inline.

[devyte]

Same here, please change the comment to add the explanation.

[JiriBilek]

Hi, there is a problem with this PR.
The updated file hspi_slave.c is now put in wrong directory: libraries instead of libraries/SPISlave/src

[JiriBilek]

Why did you delete hspi_slave_end function?

[JiriBilek]

I hope you can delete the file in your repository and the deletion is then propagated to master.

[devyte]

@Makuna is this PR relevant to your SPI testing?

[devyte]

@JiriBilek @GuaAck what is the status here? I see a deleted function and an unneeded dummy file.

[Makuna]

This timing relationship of the data pulse to clock pulse is defined by the SPI mode. See WikiPedia SPI.
I could not find what the mode was supposed to be for SPI slave in this code. It is also not exposed to change like the standard SPI master
.

[GuaAck]

@JiriBilek @GuaAck what is the status here? I see a deleted function and an unneeded dummy file.

I have nothing to do with deleted functions and dummy files, Perhaps I did siomething by accident, Ia am very beginner in github.

With my changes, the SPI communication in my project works reliable for different clock rates. For me the matter is closed. Me and Jiri provided in github a I lot of notes and diagrams with measured wave forms . The owner of hspi_slave has to decide what to do.

I am open for any technical questions,
GuaAck

[Makuna]

@GuaAck @JiriBilek What SPI mode are your changes setting the SPI Slave to? When you tested with a SPI Master, did you test all the modes?

[GuaAck]

Yes, I tested the original hspi_slave with all modes (selected in the master), all failed.

The changed hspi_slave is only valid for mode 0. I found no switch to select the mode and mode 0 seems to be most common.

To remember: The problem came up, when I changed over from my UNO to the very much faster DUE. Then I found the incorrect timing.

Best regards
GuaAck

[devyte]

@GuaAck with commit 01cf0e6 you deleted the end function, and the commit after that deleted the content of hspi_slave.c, leaving the empty file. I am therefore not sure if the PR has all changes necessary, or more changes than necessary (i.e. unneeded deletions).

[JiriBilek]

@devyte, sorry haven't seen the PR for a while. I am afraid, @GuaAck made a mistake and moved some files to a bad directory. I'm gonna fix it in another PR soon as I have no more info from the OP.

[devyte]

Closing in favor of #6022 .