Why not using hardware SPI?

[dzungpv]

This is not a bug, but why you are not using hardware SPI? I see code using digitalWrite and digitalRead to handle SPI communication.

[absalom-muc]

This is explained here, last section. For using SPI with the MHI ACs you need a cycle accurate synchronization between RX and TX. With the HW SPI I was not successful implementing it.

[hberntsen]

Mentioned here before, I have an implementation with hardware SPI on an ESP32-C3 here: https://github.com/hberntsen/mhi-ac-ctrl-esp32-c3

[glsf91]

I think we can close this one

[oliv3r]

@absalom-muc coming back to this one for a bit, I'm trying to comprehend why this was not working a bit better.

I saw somewhere in the RTOS SDK documentation can't find it with a quick browse) that there is a limit to 20 bytes, surely, this is not what you ran into?

As for the

cycle accurate synchronization between RX and TX

what did you mean? SPI by default is a fully synchronized e.g. full-duplex protocol. E.g. when you clock in a byte, you will clock out a byte. For half-duplex situations, what is often done, is that simply zero's are sent out. E.g. as master, to request data from the slave, you just transmit 8 zero's, and you get 8 databytes back. Likewise, here as slave, we can only send data, when the master clocks us anything in (could be garbage or zero's of course).

This is because in effect, SPI is just a shift-register on each side.

So when you say they have to be clock cycle accurate, I'm not sure what you mean, and I wonder what you where struggling with.

[absalom-muc]

Since I made the implementation about 5 years ago, I don't remember all details. I believe the critical topic was the synchronization between SPI read and SPI write. It means that you have to start the write during the ongoing read at the right point in time. As described above, it seems someone found a solution, I haven't checked it.

[oliv3r]

Yeah, I understand that it was a long time ago :)

So this should be handled by the simple fact that a proper SPI transaction is done, unless you need to modify bits during a transaction, e.g. bit 1 is received, which has an impact on bit 2 (or 3) (bit 1 is already pushed out :p)

If that where the case, you need to bit-bang SPI.

But indeed, the hardware SPI solution by hberendse suggests that it should be an issue of course. He has a 'problem' with that the ESP32 spi peripherial is only able to function when CS is being asserted, which is a different issue.