arduino / arduino/ArduinoCore-samd
SAMD outputs do not provide high drive current
- Dominant language
- C
- Stars
- 502
- Forks
- 740
- PR merge metrics
- No merged PRs in 30d
Description
> Moved from https://github.com/arduino/Arduino/issues/5258
> Originally reported by @MLXXXp
The documentation for the [Zero](https://www.arduino.cc/en/Main/ArduinoBoardZero) and [MKR1000](https://www.arduino.cc/en/Main/ArduinoMKR1000) both state:
`DC Current per I/O Pin 7 mA`
However, according to the ATSAMD21G18 datasheet, this current is only available if the _Output Driver Strength_ bit _(DRVSTR)_ for the pin has been set to 1. Otherwise, the pin can only source a maximum of 2 mA or sink 2.5 mA. I can't find anywhere in the Arduino source code that sets the _DRVSTR_ bit for a pin. Even if it is being set somewhere that I missed, the line
`PORT->Group[g_APinDescription[ulPin].ulPort].PINCFG[g_APinDescription[ulPin].ulPin].reg=(uint8_t)(PORT_PINCFG_PULLEN) ;`
which is always executed in function _digitalWrite()_ in file _wiring_digital.c_ will clear _DRVSTR_.
Therefore, at best, the documentation is misleading.
Ways I see to address the problem:
- Change the documentation to state that only 2 mA is available unless the user writes code to manipulate the I/O output pins directly to get 7 mA, bypassing the Arduino digital pin functions. This would probably be difficult at this point. Even SparkFun and Adafruit state the higher current for their ATSAMD21 products.
- Change the code to always set outputs to high drive mode. Since in many cases high current isn't required, this could unnecessarily increase the chances of causing hardware damage due to shorted outputs.
- Add a new mode to the _pinMode()_ function, such as _OUTPUT_HIGH_CURRENT_, to be used instead of _OUTPUT_ when high drive capability is desired. In addition to changing the _pinMode()_ function, the _digitalWrite()_ function would also have to be modified to not change _DRVSTR_, as was described above.
And just a side note:
That same line quoted above that sets _PULLEN_, also clears _INEN_ (in addition to _DRVSTR_), nullifying _INEN_ having been set in _pinMode(x, OUTPUT)_. Therefore, reading the _IN_ register will not provide the state of the output pin after a _digitalWrite()_.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start in wiring_digital.c, focusing on pinMode() and digitalWrite() and the PORT PINCFG assignment quoted in the issue. Review how DRVSTR and INEN are handled, then clarify with maintainers which of the documented behavior, default high-drive mode, or new pin mode is intended; done requires an agreed resolution and verification of the affected pin behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- embedded-iot
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100