Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pins not inputs by default? #44

Open
chrissbarr opened this issue Oct 25, 2017 · 2 comments
Open

Pins not inputs by default? #44

chrissbarr opened this issue Oct 25, 2017 · 2 comments

Comments

@chrissbarr
Copy link

I'm testing this on two boards, both F4-based. I don't know if this is F4 specific, but I imagine someone else would have run into it if it affected other series as well. It could also be something specific to my setup, but I've accounted for that to the best of my ability.

The boards I'm using are:

  • Discovery F407VG
  • Custom F446VE Board

In both cases, using the latest version of this core for the F407VG and my fork for the F446, I am seeing a problem with the pins when used as inputs.

My understanding is that it's expected the pins will work as either digital or analog inputs by default, without any call to pinMode. The code in the Arduino AnalogRead examples tends to bear this out - there is no call to pinMode in that example, nor in any of the examples included in the STM32Generic core - i.e., the AnalogReadSerial_12bit example:

void setup() {
  // initialize serial communication at 115200 bits per second:
  Serial.begin(115200);

  // configure the ADC for 12 Bits
  analogReadResolution(12);
}

// the loop routine runs over and over again forever:
void loop() {
  // read the input on analog pin 0:
  int sensorValue = analogRead(PA0);
  // print out the value you read:
  Serial.println(sensorValue);
  delay(1);        // delay in between reads for stability
}

If I run that code on either of the boards I have, the results returned seem to have no relation to the actual status of the pin. On both boards, I'm seeing very low analogRead values, < 10. The value seems to have a small amount of noise present (i.e. it might change by a digit or two) but does not change if I connect the pin to 3.3V or ground.

This problem seems to extend to using the pins as digital inputs as well, the pins appear to be stuck low and do not change as the external voltage changes.

If I add the call to pinMode(PA0) to the above code, before the pin is read, then I see values as expected, both for digital and analog reads.

Is it possible the default pin setup is leaving the pins in the wrong state somehow? Obviously it's not a problem for me to add the pinMode call to my code, but some libraries or existing applications that depend on the default behaviour might not work as expected.

@ChrisMicro
Copy link

I had also some issues which were not there in earlier versions. For this reason I didn't update my repo to the newest one of Daniel and kept it in a state which is working for me.
You could try my repo and see if it is working better.

@chrissbarr
Copy link
Author

@ChrisMicro thanks for the suggestion. I gave your repo a try, and I noticed I'm running into the same problem there too. I've tried a few different points in the main repo's history, and I seem to experience the same behaviour in all of them. I thought this was a recent problem, but perhaps it's something that's gone unnoticed for a while?

While I was trying your repo I did notice one thing that I'd missed previously - the behaviour only seems to affect some pins, not all. For instance, on the F407VG, I can use analogRead and digitalRead on pin PA0 without first calling pinMode, but if I try the same with pin PC13 it only works if I first include pinMode. So my previous example of it not working for PA0 is invalid, but if you try different values for the input pin the problem shows up.

From my brief testing, it doesn't look like a port-specific problem - some port A pins work, some don't - same for ports B, C, etc. Maybe it relates to the specific ADC channels, though I'm not sure. It's not pins that are ADC capable vs those that aren't.

I'll do a pin-by-pin test in the next few days and see if I can make a list of which pins behave as expected - hopefully that will make the problem clearer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants