ESP8266 Developer Zone

Re: [answered -in trial-] HSPI can we check register for end of hspi transfer, can we mod the CLK

2016-07-05T16:43:34+08:00

Hello Rudi,

It is because of the users the ESP8266 is killing the competition today!
By the way, we are trying to get the HSPI documentation in a readable state. What I answered is from my experiments with the HSPI when writing SD card FAT library.
This is the best you can get right now (note that some bit descriptions are missing):

http://bbs.espressif.com/viewtopic.php?t=85

Statistics: Posted by Guest — Tue Jul 05, 2016 4:43 pm

Re: [HSPI BUG ??] HSPI can we check register for end of hspi transfer, can we mod the CLK

2016-07-04T15:52:20+08:00

pratik wrote:
Hello Rudi,

As for problem #1,
You may want to consider polling bit 18 of the SPI_CMD register. See if it helps with your problem?
Code:
// Send the data out WRITE_PERI_REG (SPI_CMD(1), (1<<18));SPI_CTRL2 // Wait while transfer is in progress while (READ_PERI_REG (SPI_CMD(1)) & (1<<18)); // Deassert the CS signal

For problem #2,
There could be 2 solutions I think. One would be to reduce the duty cycle of the clock a little bit so that the edges don't match.
But the better solution would probably be to delay the MOSI signal using spi_mosi_delay_num (bit 25:23) in SPI_CTRL2 register. Delaying should not cause the initial bit to be missed because it is valid on the falling edge only. I would recommend a delay of half-cycle.i.e. spi_mosi_delay_num = 1

I hope it helps

Hi Pratik,

fast, clear and helpfull answere.
Thank you so much. Where are you so long?

Have thinked your solution for #2 too, but do not sure know, how we can reduce the duty cyde of the clock a little bit, that they do not match on same time. Will read deeper, the better solution i will study next time better, think in this i need a little help, but i will try first to save your very helpfull time. Perhabs i must ask again for deeper info, but i will try first.

For #1 i think i have undestand, after the next ' ll try - i will response again, think i can check this next days.

Pratik thank you so much for your fast, clear and helpfull answere, hope you have a nice time too with us "annoying and whining" users

best wishes
rudi

Statistics: Posted by rudi — Mon Jul 04, 2016 3:52 pm

Re: [HSPI BUG ??] HSPI can we check register for end of hspi transfer, can we mod the CLK

2016-07-04T12:39:30+08:00

Hello Rudi,

As for problem #1,
You may want to consider polling bit 18 of the SPI_CMD register. See if it helps with your problem?

Code:

// Send the data out
  WRITE_PERI_REG (SPI_CMD(1), (1<<18));SPI_CTRL2
// Wait while transfer is in progress
  while (READ_PERI_REG (SPI_CMD(1)) & (1<<18));
// Deassert the CS signal

For problem #2,
There could be 2 solutions I think. One would be to reduce the duty cycle of the clock a little bit so that the edges don't match.
But the better solution would probably be to delay the MOSI signal using spi_mosi_delay_num (bit 25:23) in SPI_CTRL2 register. Delaying should not cause the initial bit to be missed because it is valid on the falling edge only. I would recommend a delay of half-cycle.i.e. spi_mosi_delay_num = 1

I hope it helps

Statistics: Posted by Guest — Mon Jul 04, 2016 12:39 pm

[answered -in trial-] HSPI can we check register for end of hspi transfer, can we mod the CLK

2016-07-04T16:00:45+08:00

SDK 1.5.4 NONOS

hi
saw a problem in the HSPI in MODEN ( 0,1 ) and try to reproduce it now.

i experiment just in time with the HSPI and an extra GPIO-04 for SS ( /CS ).
for /cs on start there is no problem, for /cs after HSPI transaction is a problem
if the HSPI transfer is not finnished, the /cs can be done to early.
( left side of picture )

problem one: ( red arrow)
how we can check the register, that HSPI transaction is done, to set the /CS then back?
a delay cycle ( right side picture ) for the /cs back is not a option, because if the CLK speed is change to fast,
the delay is to short, and if CLK speed lower, the delay is to long.

problem two: ( yellow lines)
HSPI with Mode
CPOL: 0 ( clock is low if inactive )
CPHA: 1 ( data valid on trailing edge )

when MOSI last bit is send, the CLK is same time finnished same Time Mosi end the communication,
that is a problem, we get allways '0' for this moment on the clock trailing edge, never get the last bit correct.

FYI: Byte 0xFF was send, the last bit never would be read, so we have 0xFE on logicanalyzer

can we extend the last mosi bit or shorten the CLK on last bit by register flags?

thanks
best wishes
rudi

Statistics: Posted by rudi — Mon Jul 04, 2016 12:16 am