ESP8266 Community Forum

I have a very different spi_registers.h from nodemcu's repo, it doesn't have any of those bits, will try the same bit positions and see if it works, Thanks!

TheLastMutt wrote:For full-duplex operation use SPI_FLASH_DOUT only, but in combination with the SPI_DOUTDIN bit. Then you will receive the same amount of bits as you have configured in SPI_USR_OUT_BITLEN.

Hi, TheLastMutt
It possible to make MOSI in high level when spi interface in idle mode(when not transmitting)?
I have tried setting or clearing some bits in SPI_USER register, but nothing change, the MOSI pin will go low when not transmitting data.

Hi qdk0901!

Sorry, I don't know.

I doubt that this is possible. Usually you have a bit to invert the clock signal, then you get a different idle level there.
For the SPI protocol the level of MOSI and MISO only cares at the relevant clock edge while chip-select is active. So the idle level does not care.

You probably want to use MISO for something else than SPI. In this case I would electrically invert the MOSI signal using an inverter gate or just a small MOSFET+pull-up. Then invert all data before transmission in the firmware.

MarekB
Thank you Thank you.
Finally some code that is close to the hardware and respectful of the fact that the esp8266 isn't a 3 ghz PC that can make the most bloated code look good.
I have no issue with bloat to send electrons to the WiFi antenna since the asysnchronous Internet and its need for stacks is a fact of life. However to send electrons to and from a pin we need to consider speed since unlike the Internet the hardware interfaces are often synchronous and have critical timing requirements.
Microchip examples are very often just examples of moving a byte to and from an electrical interface like I2C or SPI even the more rudimentary need to sink or source a few ma from a pin is addressed.
Esp8266 examples are mostly applications and may contain low level I/O but layer upon layer of code bloat has to be peeled back to see what the electrons are doing.
Again thank you for an example that allows electrons to move at close to light speed through an SPI hardware interface.
I see the issue where the task of transmitting a byte is handed off to hardware and how the code that sets the gate pins for the LCD gets de-synchronized.. some SPI interfaces handle this within the interface.