You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This parameter should not be part of SPISettings.
Now, SPISettings fully match ArduinoCore-API definition.
Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
Copy file name to clipboardExpand all lines: libraries/SPI/README.md
-5Lines changed: 0 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -7,10 +7,6 @@ User have 2 possibilities about the management of the CS pin:
7
7
* the CS pin is managed directly by the user code before to transfer the data (like the Arduino SPI library)
8
8
* the user uses a hardware CS pin linked to the SPI peripheral
9
9
10
-
### New SPISetting parameter
11
-
12
-
*`noReceive`: value can be `SPI_TRANSMITRECEIVE` or `SPI_TRANSMITONLY`. It allows to skip receive data after transmitting. Default `SPI_TRANSMITRECEIVE`.
13
-
14
10
### New API functions
15
11
16
12
*`SPIClass::SPIClass(uint8_t mosi, uint8_t miso, uint8_t sclk, uint8_t ssel)`: alternative class constructor
@@ -21,7 +17,6 @@ _Params_ (optional) SPI `ssel` pin. This pin must be an hardware CS pin. If you
21
17
22
18
*`SPI_HandleTypeDef *getHandle(void)`: Could be used to mix Arduino API and STM32Cube HAL API (ex: DMA). **Use at your own risk.**
23
19
24
-
25
20
##### Example
26
21
27
22
This is an example of the use of the hardware CS pin linked to the SPI peripheral:
0 commit comments