ESP8266 Community Forum

- Tue Jul 12, 2016 11:27 am #50654 Edit: this post was related to erratic behaviour due to a distorted clock signal (spurious oscillations on edges were wrongly counted as clock cycles by the ESP). The fix works on both AVR and ESP.
Just make sure you have clean signals and skip this post

OK, I think I reached the end of my possibilities wrt AVR vs ESP.

I can only confirm that when the ESP drives the clock, the setting is required and replies are perfect.
Here are captures of messages between an ESP master (running the same code as the AVR above) and the exact ESP slave that used above, not reflashed or anything:
Communication is OK:

0-OK_replies.png

Zooming in on the 6 first bytes of any answer, they are all perfectly decoded:

1-OK on scope too.png

And finally a zoom on the 3 first bytes:

2-start of reply is ok.png

By comparison with the equivalent capture with the AVR master in the post above, the most visible difference is that the ESP master inserts delays between each byte:

Difference.png

So would it be a requirement for an ESP to have "a bit of time" between bytes, if it has to behave as a slave with the MISO edges aligned with the MOSI ones ?
Or is there a setting somewhere that says "min required time between bytes" ?

Really no idea.

Feel free to comment of course. I may have missed something obvious...

As my goal was not AVR => ESP communication anyway, I'm going to mainly focus on my protocol decoding now, which leaves me with enough challenges I guess

Kind regards,

Vicne

You do not have the required permissions to view the files attached to this post.

Last edited by Vicne on Fri Jul 15, 2016 10:31 am, edited 1 time in total.

- Tue Jul 12, 2016 12:39 pm #50657 Verry interesting finds! Wow you did quite a few tests
I would not think that the ESP will require time between the bytes. They are there because the AVR is snail compared to the ESP whatever the outcome, You have found an d debugged an interesting case to which we have a "fix". What is really sad is that the fix is not universal I wander if anything can be done on the Master ESP side that will work when talking to ESP slave and to other devices.

Async HTTP and WebSocket Server for ESP8266
Async TCP Library for ESP8266
ESP8266 Exception Stack Trace Decoder

- Tue Jul 12, 2016 3:06 pm #50661

Verry interesting finds! Wow you did quite a few tests

Yeah, I had a day off, and could not find a better way to spend a sunny summer day

I would not think that the ESP will require time between the bytes. They are there because the AVR is snail compared to the ESP

Err, actually no:
The fast ESP does insert delays in its clock and is understood by its peer slaves.
The snail AVR does not insert any delay in its clock and the ESP cannot "hang" its replies on that clock when it uses a "clean" mode 0.
Really strange...

Anyway, I performed more tests (yeah I lied ) and a clear conclusion is that the standard SPI master library from the Arduino ESP cores reverses SPI Mode 2 and 3, at least in MOSI generation. I didn't dig further in that code because it uses an undocumented field and has a suspicious "todo" comment, but all I can say is that setting a SPI master in Mode 2 outputs a Mode 3 signal and conversely.
I've opened an issue on Github about that, with a sample sketch and scope captures.

Now back to slave tuning

Vicne

- Wed Jul 13, 2016 1:34 am #50677 hmm, I guess I looked at the images backwards... That delay between the bytes on the ESP Master are strange... where do they come from? Do they exist in normal SPI communication? If my memory is correct, when I scoped the SPI bus (back more than a year ago), I did not see any such pauses.

Async HTTP and WebSocket Server for ESP8266
Async TCP Library for ESP8266
ESP8266 Exception Stack Trace Decoder