SPISlave.end() added #4248
SPISlave.end() added #4248
Conversation
libraries/SPISlave/src/SPISlave.cpp
Outdated
| @@ -72,6 +72,14 @@ void SPISlaveClass::begin() | |||
| hspi_slave_onStatusSent(&_s_status_tx); | |||
| hspi_slave_begin(4, this); | |||
| } | |||
| void SPISlaveClass::end() | |||
| { | |||
| hspi_slave_onData(NULL); | |||
There was a problem hiding this comment.
Please use nullptr instead of NULL
There was a problem hiding this comment.
the hspi_slave_* functions are C functions called from C++. should nullptr be used?
There was a problem hiding this comment.
Yes. NULL is a #define 0 in C, so an int that gets cast into a 32bit ptr, and in C++ it is a #define 0x00 that is cast into a void*, while nullptr is a C++ builtin that is really a null ptr. It's a type and/or style thing. As a rule of thumb, use of nullptr is considered better in C++ code. You can google nullptr vs. NULL to read about the C++ decision.
libraries/SPISlave/src/hspi_slave.c
Outdated
| void hspi_slave_end() | ||
| { | ||
| ETS_SPI_INTR_DISABLE(); | ||
| ETS_SPI_INTR_ATTACH(_hspi_slave_isr_handler, NULL); |
There was a problem hiding this comment.
Shouldn't this be something like:
ETS_SPI_INTR_ATTACH(nullptr, nullptr);
?
There was a problem hiding this comment.
sorry, the first argument should be NULL. I change it. (Even though: is this a correct way to detach an interrupt on esp8266?)
it is a C source code and nullptr is not declared
There was a problem hiding this comment.
Ah yes, C file, so NULL it is.
…add deepSleepMax based on the cali_proc function per SDK
|
I made the requested changes into the original commit "SPISlave.end() added". |
|
I very much would love having this patch merged. Thanks! |
|
@svofski try to add your request as issue, with a reason why you need this |
|
@devyte, can you merge this? |
|
@JAndrassy sure! #4511 |
resetting the registers is needed for the switch to master mode for example for AVRISP