search

mattairtech / ArduinoCore-samd

This is a fork from arduino/ArduinoCore-samd on GitHub. This will be used to maintain Arduino support for SAM D|L|C (M0+ and M4F) boards including the MattairTech Xeno Mini and the MT-D21E (see https://www.mattairtech.com/). It adds support for new devices like the D51, L21, C21, and D11. It also adds new clock sources, like a high speed crystal or internal oscillator.
104 stars 43 forks source link

Arduino INPUT_PULLUP on pin9 of genericSAMD11C14 #37

Open roberthart56 opened 4 years ago

roberthart56 commented 4 years ago

When using Arduino IDE, setting INPUT_PULLUP on pin 9 of the generic SAMD11C14A leaves pin 9 floating, but pulls up pin 8. Other pins seem to work as expected.

your-friend-alice commented 2 years ago

Cursed workaround:

re-run pinMode() immediately before calling digitalRead(), (or, I suspect, just after every call to Serial.print() and probably other Serial methods I haven't enumerated). From the digging i did, it appears pin 9 is set up as a serial port, so I'm guessing what happens is, every time a Serial method is called, it sets the PMUXEN bit in the PINCFG register for that pin (see datasheet section 22.8.13 for that register description). The only reason it keeps working as an input is that it appears to be mapped to a serial input. Sadly I don't know enough about Arduino to know how to properly fix this, perhaps disabling the right serial port would help.

Slight speed optimization over pinMode() workaround if it matters: to reset the PMUXEN bit, you can run this instead and save on the other register accesses pinMode() does.

PORT->Group[0].PINCFG[9].reg=(uint8_t)(PORT->Group[0].PINCFG[9].reg & B11111110);

This reads in the current PINCFG register for pin 9, sets the PMUXEN bit to 0, and writes it back out. If at the time of calling you know for a fact it's in INPUT_PULLUP, then this would save on that read and just write out a fixed value:

PORT->Group[0].PINCFG[9].reg=(uint8_t)B00000110;

This still isn't great though, because the pullup is still being turned off every time Serial.print() is called. Depending on what that pin is hooked up to, periodically glitching the pullup off and back on again (especially if you turn it back on right before reading the input) could cause problems. a more permanent workaround (or an actual fix) is still needed.

ictq-oy commented 1 year ago

This is because pin 8 and pin 9 are designated as LEDs to be used for Serial or USB in the variant.h of Generic_D11C14A.

If you edit variant.h and comment out the relevant line, you can use them as normal I/O. Specifically, it is around line 131 to 144.