arduino / arduino/ArduinoCore-samd
un-useful and bloaty assert() in SPI library.
- Dominant language
- C
- Stars
- 502
- Forks
- 740
- PR merge metrics
- No merged PRs in 30d
Description
The SPIClass Constructor in the SPI library contains an assert:
```
SPIClass::SPIClass(SERCOM *p_sercom, uint8_t uc_pinMISO, uint8_t uc_pinSCK, uint8_t uc_pinMOSI, SercomSpiTXPad PadTx, SercomRXPad PadRx) : settings(SPISettings(0, MSBFIRST, SPI_MODE0))
{
initialized = false;
assert(p_sercom != NULL);
_p_sercom = p_sercom;
```
It turns out that assert() generates live code on samd processors, and the default (defined in newlib) function invokes fiprintf()
Since stdio isn't set up in most Arduino compiles, this is pretty useless, and it can cause code bloat in sketchs that include SPI.
(I think this is normally masked because there is only one SPI port on most SAMD platforms, so the constructor always optimizes away the assert. But it's an issue for boards with more than one SPI. See https://forums.adafruit.com/viewtopic.php?f=62&t=169034 )
(Note that this is the ONLY use of assert in the entire SAMD core.)
Contributor guide
No contributing guide indexed for this repository
Research direction
Locate the SPI library's SPIClass constructor shown in the issue and inspect how assert() is provided on SAMD builds. Verify the change with a sketch that includes SPI, checking that the constructor still builds and that the assert no longer pulls in unnecessary stdio code.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- embedded-iot
- Issue type
- Refactor
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100